How do you build one AI copilot that searches corporate knowledge, plugs into a code assistant, and checks its own answers against live data?
Azati built an AI analytics copilot for a retail analytics team, combining a custom hybrid retrieval approach over corporate analytics knowledge, an MCP server connecting the system to the client's Cursor code assistant, and an SQL execution layer that checks answers directly against the client's own data environment.
The copilot is now used by 25+ analysts across multiple business domains, up from zero users on the AI-built prototype it replaced, with a benchmark repository driving continuous retrieval quality improvement.
analysts using the copilot daily across multiple business domains
search upgraded from literal keyword matching to context-aware retrieval
integrated components: semantic search, MCP server, SQL execution, and a benchmark repository
A retail analytics team spread across multiple business domains needed one system that could do three different things well: search corporate analytics knowledge by meaning when nobody remembers a document’s exact wording, give a code assistant direct access to that same knowledge, and let an analyst or an agent check a hypothesis against real production data.
An earlier prototype had already tried. It was assembled with AI assistance, then kept on life support, and it had zero users. Full-word matching meant an analyst searching for one phrasing got nothing when the document used another, answers were slow to come back, and nothing was instrumented, so there was no way to tell whether any change made things better.
Azati rebuilt the system around a custom hybrid retrieval approach that combines Okapi BM25 keyword ranking with semantic embeddings and purpose-built ranking models tuned to the client’s own analytics data, so a query matches intent as well as exact phrasing. An MCP server connects the client’s Cursor-based code assistant directly to the analytics knowledge base, and an SQL execution layer runs an agent’s queries inside the client’s own data environment, so answers trace back to real data. A benchmark repository tracks retrieval quality as the platform keeps expanding to new domains.
An unused tool isn’t a head start, it’s a credibility problem. Analysts had already decided the previous version wasn’t worth their time, which meant the rebuilt version had to earn adoption from scratch:
Fifty-plus analysts spread across multiple business domains don’t ask questions the same way, and a retrieval system tuned for one domain’s vocabulary can quietly fail for another:
A semantic search result that reads convincingly but can’t be verified against real data doesn’t help an analyst make a decision, the same problem Azati writes about in fixing broken LLM pipelines for measurable results:
The system had to run entirely inside the client’s own environment, using the client’s own data stores, which meant every architectural decision had to work within constraints that weren’t negotiable:
Rather than wiring up a stock vector database and calling it semantic search, Azati developed a custom retrieval approach for the client’s analytics corpus, including purpose-built ranking models tuned to how that data is structured and how analysts query it. That work is what separates a search box that returns something from one that returns the right thing.
Combining Okapi BM25 keyword ranking with semantic embeddings was a direct response to why the original search failed: analysts don’t always know the exact words a document uses, but they know what they mean. Hybrid retrieval closes that gap while keeping precision on the exact terms that do matter: report names, internal metric names, product identifiers.
Search quality isn’t something you ship and walk away from. Building a benchmark repository into the system from the start means every change to retrieval can be measured against the last one. Without it, the team is judging search quality by anecdote.
This wasn’t a handoff between specialists. One ML engineer owned retrieval architecture, the MCP server, the SQL execution layer, the benchmark repository, and the project roadmap, which kept decisions across those pieces consistent.
We build retrieval, code assistant integration, and data verification as one connected system, not three separate tools bolted together. Tell us what your analytics team actually needs.
Ask us about your analytics AI roadmapFour pieces, each solving a distinct part of how analysts actually work with data.
The core of the system: a semantic API that holds the client’s analytics knowledge and searches it by meaning rather than exact wording. This is what replaced the original full-word matching that analysts had learned not to trust.
Hybrid retrieval combines Okapi BM25 keyword ranking with semantic embedding search, scoring both signals for every query. It keeps the precision on exact terminology that pure vector search loses, while capturing the intent that pure keyword search misses.
An MCP server connects the client’s Cursor code assistant directly to the analytics knowledge base, so developers and analysts working inside their existing coding tools can query the same retrieval layer without switching context.
An MCP (Model Context Protocol) server exposes tools and data sources to an AI assistant through a standard interface, so the assistant can call them without custom integration code.
An execution layer that runs an agent’s SQL directly inside the client’s data environment, letting a hypothesis get checked against real numbers in the same session that produced the question.
A repository built specifically to track retrieval quality over time, so every change to the system can be measured against a known baseline.
| Area | Azati contribution |
|---|---|
| Retrieval | Rebuilt search from full-word matching to a custom hybrid approach combining Okapi BM25 and semantic retrieval, with purpose-built ranking models |
| Code assistant integration | Built an MCP server connecting the analytics knowledge base to the client’s Cursor code assistant |
| Hypothesis testing | Built an SQL execution layer running agent queries inside the client’s data environment |
| Quality tracking | Built a benchmark repository for iterative retrieval quality improvement |
| Architecture | Broke the original prototype into microservices and modules, and defined a staged improvement roadmap for the whole project |
| Feedback mechanisms | Added analyst feedback capture and GitLab integration |
The system runs entirely inside the client’s proprietary infrastructure, with no external cloud dependency. SQL execution runs inside the client’s own data environment, using the client’s existing access paths.
One engineer embedded directly with the client’s analytics team, owning the platform end to end from architecture through ongoing iteration.
The engagement runs on Kanban, with no fixed end date. The team started with an initial MVP assembled from the original system’s pieces, then broke it into microservices and modules, with retrieval rebuilt as the first priority ahead of new feature work.
Each phase followed a documented plan rather than reacting to whatever came up next. The SQL execution module, analyst feedback mechanisms and GitLab integration were added as the system matured, once the retrieval layer was stable.
The clearest measure of whether this rebuild worked isn’t a retrieval accuracy score, it’s that analysts who ignored the previous version now use this one, across multiple business domains with genuinely different terminology.
Analysts no longer need to guess the exact phrase a document used. Hybrid retrieval matches on meaning as well as exact terms, which is the difference between a search tool people tolerate and one they reach for.
The SQL execution layer means a convincing-sounding answer isn’t the end of the conversation. Analysts and the agent itself can verify a claim against real data in the same workflow where the question was asked.
The benchmark repository means retrieval quality changes get tracked against a real baseline, so the team knows whether a change helped before it ships broadly.
The client extended the work beyond the initial rebuild, and development is ongoing.
What this engagement actually taught the team:
An MCP server, an SQL execution layer, and a benchmark repository are only as useful as the search underneath them. Getting hybrid retrieval right first is what made every other piece of the platform worth building on top of, a lesson Azati relearned building its own internal AI operating system, ACOP.
Building the benchmark repository alongside the retrieval rebuild, not after it, is what makes continuous improvement real. Without it, every change to search is a guess dressed up as an upgrade.
An analytics copilot that only returns convincing answers is a liability. Putting SQL execution directly in the loop is what turns a search result into something an analyst can act on.
Retrieval, code assistant integration, and data verification, built as one system with room to keep improving. Let’s talk about your analytics stack.
Talk about your analytics stack| Priority | Why it matters | When it becomes urgent |
|---|---|---|
| Retrieval quality | If the search itself doesn’t understand what users mean, nothing built on top of it will get adopted either. | When user adoption is at or near zero and the tool has otherwise shipped. |
| Verifiability | Answers that sound right but can’t be checked against real data erode trust fast, especially with analysts. | When users start double-checking the tool’s answers manually instead of trusting them. |
| Quality measurement | Without a benchmark, every improvement is a guess, and regressions go unnoticed until users complain. | Before the next round of changes ships, not after the first complaint arrives. |
| Integration into existing workflows | A copilot that requires switching tools entirely faces a much higher adoption bar than one embedded where people already work. | When the roadmap includes code assistants, dashboards, or other tools analysts already use daily. |
If you’re the one who has to explain to your team how this copilot actually works before they’ll trust it with real decisions, this FAQ is written for that conversation.
It searched by literal full-word matching, returned slow answers, and had no baseline metrics to improve against. More importantly, it had zero adoption: none of the client’s own analysts were using it. If nobody opens a prototype, it isn’t solving their problem, and no accuracy metric changes that.
Azati’s analytics copilot exposes a semantic API over the client’s analytics knowledge base, so analysts can search by meaning even when they don’t know a document’s exact wording. An MCP server connects it to the Cursor code assistant, an SQL execution layer runs an agent’s queries inside the client’s data environment for fast hypothesis testing, and a benchmark repository tracks retrieval quality over time.
Azati built a custom hybrid retrieval layer combining Okapi BM25 keyword ranking with semantic embedding search and purpose-built ranking models tuned to the client’s own analytics data, so queries match on exact terminology and on meaning at the same time.
An MCP (Model Context Protocol) server exposes tools and data sources to an AI assistant through a standard interface. Azati built a FastMCP-based server so the client’s Cursor code assistant could query the same analytics knowledge base as the copilot, instead of duplicating the retrieval layer inside a second tool.
Because a search answer isn’t always enough. A retrieved answer describes what should be true; an executed query shows what is true. When an analyst or the agent needs to check a hypothesis against real numbers, the SQL execution layer runs that query inside the client’s data environment and returns the result, closing the loop between finding an answer and verifying it.
More than 25 analysts across multiple business domains, up from zero users of the prototype it replaced. That adoption curve, more than any single accuracy metric, is the number this engagement is judged on.
Explore our successful projects and see how Azati delivers measurable results for our clients.
Engineering teams accumulated valuable knowledge across capital projects, but finding a comparable past observation required manually searching project records, reviews, and documentation. As the client's enterprise platform grew to cover engineering reviews, requirements, PDRI assessments, and project observations across large oil and gas projects, experts needed a faster way to reuse relevant engineering knowledge without leaving their existing workflow.
Azati embedded AI-powered semantic search directly into the existing capital project platform, allowing experts to find and rank similar observations within the relevant engineering discipline. The solution combined enterprise AI orchestration, domain-restricted retrieval, and contextual recommendations while preserving the existing UX, governance, and review process, delivered in four weeks.
The client wanted generative AI to improve employee productivity, but public LLM services created security, compliance, and confidentiality concerns. They needed an enterprise AI assistant that could securely give employees fast access to internal knowledge while keeping sensitive business information entirely within the corporate environment.
Azati developed a secure, locally hosted enterprise LLM platform combining private AI infrastructure, Retrieval-Augmented Generation, and enterprise knowledge integration, delivering ChatGPT-like capabilities while keeping full control over corporate data.
A large insurance enterprise wanted to reduce engineering effort spent on repetitive software development tasks while maintaining the security, governance, and approval processes required in a regulated environment. The solution needed to integrate directly with existing Azure DevOps workflows and comply with strict information security policies.
Azati designed an enterprise AI agent ecosystem automating routine engineering activities across the development lifecycle, combining secure LLM deployment, Azure DevOps integration, intelligent request routing, and AI-powered development assistants.
Last updated
