← All Case Studies
Client Story

An AI Agent That Never Worked, Rebuilt to Just Work

A group of five sister companies already had one Copilot agent meant to pull reports across all of them. It just broke constantly and answered almost nothing. We rebuilt the backend on the Model Context Protocol so that same agent now works reliably across every company.

5
Companies, Each Own MCP
68
Tested Tools Per Server
29 + 11
Entities + Reports Covered

The Situation

Our client owns a group of five sister companies. They already had one Microsoft Copilot agent set up for their team, meant to pull reports across all five from a single place, which makes sense when one owner needs a view of the whole group without opening five separate sets of books. The idea was simple and good: ask a plain-English question, get an answer straight from the accounting data. No digging through reports, no exporting spreadsheets, no logging into each set of books.

The reality was different. The team's honest summary was that the agent "never worked." It failed often, it failed unpredictably, and even when it did respond, it could only reach a narrow slice of the data. The single-agent, all-five-companies experience was there in theory, but nobody trusted it enough to rely on it, so they stopped using it.

The Bottleneck

The root problem wasn't the AI's intelligence, and it wasn't the one-agent-across-five-companies concept. That part was the right idea. The problem was the architecture underneath it.

Each company was connected to the agent by having the AI write database-style queries on the fly for every question. Each request meant the model was hand-authoring raw query syntax against QuickBooks. Small mistakes in a field name, a filter, or the syntax produced a failed call, and those failures showed up to the user as errors instead of answers. Nothing was checked before it ran, so problems only surfaced at the worst possible moment. The unified agent was only ever as reliable as those fragile per-company connections, which is to say, not reliable at all.

The core challenge: The agent depended on the AI to construct correct queries for every request, which is inherently error-prone. Fixing one broken query often broke another, and there was no stable, testable definition of what the agent could actually do.

What We Built

Instead of patching the query generation, we replaced the whole approach. We rebuilt the agent on the Model Context Protocol (MCP): a modern, standardized way for AI to interact with a system through a defined set of pre-tested tools rather than improvised queries.

The shift in responsibility is the whole point. The AI decides what to ask. The system guarantees the request is made correctly.

Phase 1
Diagnose the Failure Pattern
Traced why the agent broke so often. The common thread was clear: the AI writing its own queries was the single biggest source of failure. That became the thing to design out entirely.
Phase 2
Build the MCP Server + Tool Set
Built a QuickBooks MCP server exposing roughly 68 named, typed tools. Each tool has a defined input schema that's validated before anything reaches QuickBooks, plus stable, documented behavior. The server owns the hard parts: authentication, token refresh, request formatting, pagination, and error handling.
Phase 3
Expand Coverage, Lock Down Access
Extended reach from a thin query surface to full read coverage: 29 entity types (customers, invoices, bills, vendors, accounts, and more) and 11 financial reports (profit and loss, balance sheet, aged receivables, and others). Every mutating operation was disabled, making the agent strictly read-only.
Phase 4
Deploy & Secure Per Company
Stood up a dedicated MCP server for each of the five companies on Azure App Service. Every instance is locked down: its own credentials in Key Vault, managed identity, and bearer-authenticated endpoints, so nothing is reachable without a valid token and no company can see another's data.
Phase 5
Reconnect the Existing Copilot Agent
Swapped the fragile query backends behind the team's existing Microsoft Copilot agent for the new MCP servers, connected through per-company custom connectors. Same one-agent, all-five-companies experience the team already had, except now it actually works: ask in plain English, pull reports across any or all five companies.

The Deliverables

QuickBooks MCP Server
A dedicated server that exposes ~68 tested, named tools and handles authentication, formatting, and error handling on the AI's behalf.
Validated Tool Catalog
29 entity types and 11 financial reports, each a defined unit with a schema checked before any call, so bad requests are caught early instead of becoming user-facing errors.
Read-Only Safety Model
All write, update, and delete operations disabled. The agent can report on the books but cannot change anything, by design.
Per-Company Isolation
All five companies run their own dedicated MCP server, each with its own secrets in Key Vault, so one company's data and issues can never touch another.
Copilot Agent, Now Reliable
The team's existing Microsoft Copilot agent, re-backed by all five MCP servers, so pulling reports across every company from one conversation finally works.
Secured Deployments
Bearer-authenticated endpoints, managed identity, and Key Vault secrets on every instance, so each server is reachable only with a valid token.

The Result

The rebuilt agent does the one thing the old one couldn't: it works consistently. The single most common cause of failure, the AI writing its own queries, is gone entirely. The model now picks from a list of tools that are known to work, and the server guarantees each call is made correctly.

~68
Tested tools replacing fragile, hand-written queries
29 + 11
Entities & Reports Now Reachable
0
Write Operations Exposed

Beyond reliability, the agent simply answers more. It went from a narrow query path to full read coverage of detailed records and complete financial reports: profit and loss, balance sheet, aged receivables, and more. And because behavior is deterministic and tested, the failures that do happen are diagnosable instead of mysterious. That's exactly what the business had been missing.

Just as important, the team kept the workflow they already knew. The same single Copilot agent still sits in front of all five companies. Nothing about how they ask changed. What changed is that it now delivers: someone asks in plain English and gets a report from any company, or a comparison across all of them, instead of an error. And every one of those requests runs against a locked-down, per-company server: token-authenticated, isolated, and strictly read-only, so broad access never means loose access.

Why It Mattered

An AI tool that works "sometimes" is worse than no tool at all, because people stop trusting it and route around it. The old agent looked fine in a demo and fell apart in daily use. That gap between demo and reality is where most AI projects quietly die.

Rebuilding on MCP closed that gap. The improvement wasn't a smarter prompt or a bigger model. It was better architecture: move the fragile, error-prone work out of the AI's hands and into a tested system built to do it correctly. New capabilities now get added by writing a clean, tested tool, not by trial-and-error prompt tweaking that trades one failure for the next.

The takeaway: Reliability isn't about making the AI smarter. It's about giving it a solid foundation to stand on. Let the model decide what to ask, and let a tested system guarantee the request is made correctly.

Tools Used

Have an AI tool that looks good in a demo but breaks in real use?

We rebuild AI systems on solid architecture so they're reliable enough to actually trust. If your agent works sometimes but not when it counts, let's talk.

Book a Free Discovery Call