Making Microsoft 365 Copilot worth the seat.
A HIPAA-regulated healthcare software company had bought Copilot across its engineering org and watched almost no one open it. We built the grounded knowledge layer that finally gave the assistant something true, and permission-safe, to say.
The mandate. Microsoft 365 Copilot seats had been bought across a 500-engineer, HIPAA-regulated EHR company, and adoption was near zero. The assistant could polish an email but could not answer a question about the company's own product, tickets, or test cases, because none of that knowledge lived anywhere Copilot could safely reach.
The outcome. A grounded, permission-aware knowledge layer, built, documented, and transferred to the client's own team in 16 weeks.
The headline numbers
- Six enterprise systems unified into a single grounded, permission-aware answer.
- Seven AI agents shipped into Teams and Copilot, then handed over.
- 16 weeks from baseline to handover, ahead of schedule throughout.
- 100% of answers grounded in a real source. No model guesswork, no fabrication.
- Four documents per agent, the full middleware codebase, and deployment guides transferred. Nothing left behind that the client cannot run itself.
The brief: they had paid for the assistant, it had nothing to stand on
The client is a private-equity-backed healthcare software company, a HIPAA-regulated EHR platform with roughly 500 engineers across fifty-odd product teams. The estate is almost entirely Microsoft: Microsoft 365, Teams, Azure DevOps, SharePoint and Confluence, sitting on a deep base of ASP.NET, Classic ASP, and SQL Server stored procedures.
They had done the obvious thing (bought Microsoft 365 Copilot seats) and, like most organizations that do, were not getting their money back. The assistant could tidy a message. It could not answer a question about their product, their tickets, or their test cases, because none of that knowledge sat anywhere Copilot could safely see.
Why this keeps happening
The seats are not the problem. The ground beneath them is. Copilot answers only as well as the knowledge it is allowed to stand on, and in most companies that knowledge is scattered across systems, over-shared, or simply invisible to it.
How the work ran
| Phase | Duration | Value delivered |
|---|---|---|
| Phase 1 | Weeks 0 to 3 | Baselined developer experience, designed the knowledge-engine architecture, ran the build-vs-buy selection (choosing Amazon Q Business, to sit where their data and AI-native flows already lived) and picked five pilot teams. |
| Phase 2 | Weeks 3 to 8 | Stood up JIG on Amazon Q Business. Built JIG's connector into Microsoft 365 Copilot (wk 6), took Copilot grounding live (wk 7), and shipped JIG's MCP connector into the engineers' IDEs (wk 8). First agents went live in Teams. |
| Phase 3 | Weeks 8 to 12 | Extended into delivery: QA and release agents, plus an AI-augmented SDLC and an enablement kit handed to the pilot teams. |
| Phase 4 | Weeks 12 to 16 | Technical transfer, operational handoff, an impact baseline, and a wave-based plan to roll out across roughly fifty teams. |
The architecture: what we built
Copilot's reach stops at the edge of Microsoft 365. On its own it cannot ground an answer in Azure DevOps work items, in TestRail cases, or in anything outside the Microsoft Graph. So we built the layer it was missing, JIG, Livehopper's grounded knowledge layer, and put it where it belonged. In their world Microsoft 365 is the gate people pass through to work; AWS is where the business data lives. JIG sat on the data side of that line, reached through the Microsoft gate.
JIG: the layer between sources and tools
JIG sits between an organization's context sources (SharePoint, Confluence, Azure DevOps, GitHub, TestRail, Salesforce) and the tools its people actually work in (Microsoft 365 Copilot, GitHub Copilot, Teams). At its core is a business index that does the grounding: it ingests each source with its access lists, redacts PHI and secrets at the door, chunks and embeds the content while keeping its surrounding context, stores every fragment tagged with the permissions it came from, and then retrieves, reasons, and cites. JIG is a service, not a single product, so we choose the business index that best fits each organization. Here, with the operational data already on AWS and the AI-native flows already running on Amazon Bedrock, that index was Amazon Q Business, run beside the data it already sat next to. The permission tag is enforced at retrieval, so JIG can only ever return what the asking person is already cleared to see.
The connectors after Q Business
A grounding engine is only useful if the tools people already live in can reach it. These connectors are the part of JIG that reaches into the tools themselves, and they were the distinctive build. Microsoft 365 Copilot cannot natively call Amazon Q Business, so we built the connector that lets it: an On-Behalf-Of token exchange that carries the asking user's identity the whole way through, so Q answers as that person and never surfaces anything their permissions forbid. A small AWS Lambda performs the SAML-to-IAM token exchange that Q's API requires, since it expects signed, identity-aware calls tied to the federated user. We packaged it as an AWS SAM stack with an OpenAPI definition wired into a Copilot Studio agent, then extended the same layer into a Model Context Protocol server, so the engineers' editors (GitHub Copilot and Claude in Visual Studio) can query the very same grounded knowledge without leaving the IDE. One integration backbone, two surfaces: everyday Microsoft 365 and Teams for the business, the editor for the engineers.
The hard parts, and the honest ones
- Oversharing. Years of permission drift meant SharePoint would have handed Copilot confidential files for anyone to find. We indexed a tight, named set of sites, crawled every access list, and let the permission tags, not luck, decide who sees what.
- Grounding gaps. The knowledge that mattered lived outside Microsoft 365. We wrote custom connectors for Azure DevOps and TestRail and routed the rest through JIG, so Copilot finally saw the whole picture rather than half of it.
- Recency. A two-year-old spec used to outrank last week's decision. We ranked freshness first and made the current documentation the source of truth.
- PHI in a regulated tenant. Here the wrong answer is a breach. We strip PHI and secrets before anything is indexed, switch off the model's freedom to improvise, and require every answer to cite its source.
And the unglamorous truth: a custom connector shipped with two defects, and we turned the fixes around inside a day. One per-user sign-in error is still open with the client's IT. A prototyping tool we wanted was blocked on compliance grounds, and we are still making the case for it. We even changed our own recommendation mid-engagement, dropping a second AI tool once we saw the team genuinely lived in Visual Studio, because the right answer mattered more than the original plan. That is what real implementation looks like.
The economics, said plainly
- Microsoft 365 Copilot. $30 per user / month, on top of a qualifying base license (E3 $36, E5 $57; both rising on 1 July 2026). Copilot Studio agents bill on usage.
- Amazon Q Business. $3 per user / month on Lite, the tier we ran here; the Enterprise index runs about $190 a month per unit, where a unit holds roughly 20,000 documents.
- The build-vs-buy call. We chose this deliberately over a heavier do-it-yourself stack: separate vector and graph databases, bespoke redaction. Their operational data and AI-native flows already lived on AWS, so Q Business sat next to them rather than copying data across clouds; and for a regulated 500-person organization, fewer moving parts is the safer and the cheaper answer.
We tell clients the real numbers before they commit a single seat. The licenses are rarely where a Copilot program goes wrong; the missing ground beneath them is. Start with the data, the permissions, and the few questions people actually need answered, build the grounded layer that makes the assistant worth opening, and the seats finally earn their keep. Quietly, in production, and handed back to the client to run.
