DataQI: enterprise agentic data platform

From R&D to a product

DataQI began with applied-AI research at Razor rather than a finished product brief. I built early proofs of concept for document-powered RAG in Python and natural-language SQL querying with Semantic Kernel. I also built an evaluation tool that used an LLM to score the semantic difference between expected and generated answers, making useful regression testing possible without requiring exact text matches.

Those prototypes helped establish the product direction: an AI agent that could work across an organisation's existing information rather than inside a single isolated chatbot.

My role and ownership

My formal title at Razor is Senior Engineer. On DataQI, I have served as the Technical Lead and remained deeply hands-on from the first prototypes through both major product versions and production deployment.

The initial versions were developed by teams of around five people. In the first product iteration I owned the SQL-querying capability end to end, from database import and schema labelling through to the Python tool exposed to the agent. I also owned the wider connections area, including filesystem structure and document import from Google Drive and SharePoint.

Later, after the team became much smaller, I became the principal hands-on developer across the .NET backend and React frontend while continuing to make the core architectural decisions.

Version one: proving the direction

The first version turned the research prototypes into a working commercial platform. It supported Microsoft SQL Server, PostgreSQL, and MySQL, alongside document and file-store connections.

That version validated the central idea and exposed useful architectural lessons. The fast-moving AI landscape made clear that the product needed stronger boundaries between data connections, retrieval, and agent behaviour if it was going to keep evolving without becoming fragile.

Version two: designing for change

I led the technical design of the second version from the start. We treated the earlier implementation as evidence, keeping what had worked while rebuilding around clearer responsibilities and enterprise deployment needs.

The backend moved more heavily towards C# and .NET for type safety, maintainability, long-term support, and a stronger architectural foundation. Python remained part of the wider AI skill set, but .NET became the main product platform. A frontend specialist redesigned the interface in React, replacing the original Vue implementation.

I contributed substantially to the C# agent framework and was effectively the sole developer of the expanded connections subsystem.

Retrieval built around real document estates

The second version added an on-premises file-store connector through a service installed inside a customer's network. It also introduced a tiered retrieval design for very large document collections:

1. Index filename and location information during import.
2. Use keyword-level information to identify likely documents.
3. Expand into full document content only after a document becomes a credible candidate.

This avoided treating every byte of every document as equally relevant at the first retrieval step. It reduced unnecessary work while preserving the ability to search deeply when the agent had enough context to justify it.

Context-aware routing and MCP

As I took on broader full-stack ownership, I added Model Context Protocol connections supporting anonymous access, OAuth 2.0 dynamic client registration, and manually configured OAuth clients.

I also redesigned the agent's routing path so tool selection depended on the user's request and available context. The agent could decide whether it needed document retrieval, a SQL query, or an MCP call instead of following a fixed sequence or asking every subsystem indiscriminately.

Cloud and on-premises deployment

DataQI supports conventional cloud deployment and a fully on-premises option using open-source models. That matters for organisations whose data, sovereignty, privacy, or infrastructure constraints make a cloud-only AI product unsuitable.

The platform runs on Kubernetes, including Azure Kubernetes Service and customer-hosted clusters. I contributed to the deployment work, while another engineer primarily owned cluster operations; my main ownership remained the application architecture and implementation.

Where the product is now

DataQI is a production-deployed platform that brings documents, relational databases, file stores, and external MCP tools into one agent experience. More importantly, its architecture can accommodate new connection types and rapid changes in AI capability without discarding the enterprise engineering underneath it.

Why I include this work

This work shows the combination I bring to AI engineering:

• Technical leadership from research and product definition through production.
• Hands-on ownership across RAG, SQL tooling, agent orchestration, integrations, backend, and frontend.
• Constructive architectural change based on evidence from a real first version.
• Enterprise deployment choices shaped by maintainability, data location, and customer constraints.