Built AI-first · Chapter 6 of 9
An agent that cannot read your calendar, your books or your line-of-business system is a very articulate stranger. The Model Context Protocol is the standard way to end that — one common interface between an assistant and the systems a business actually runs on, instead of a bespoke integration for every pairing.
It is genuinely the piece that makes the previous five chapters operational. It is also routinely oversold, and the oversell is specific enough to name: MCP is an interface standard, not a security model.
What it is
Before a standard existed, every assistant needed its own purpose-built connection to every system. Five assistants and eight systems is forty pieces of glue, each written by somebody, each breaking on its own schedule, each with its own idea of what it is allowed to do.
MCP replaces the pairing with a shape. A system is exposed once, through a server that declares what it can do and what it holds; any assistant that speaks the protocol can then use it. Forty pieces of glue becomes thirteen — and, more usefully, the thirteen are describable, inventoried and revocable in a way that forty scripts never were.
● Code red · bespoke glue
Written per tool, usually by whoever needed it that week. Credentials embedded wherever was convenient. No inventory, so nobody can answer what is currently connected to what. Changing assistants means rewriting all of it, which is how organisations end up locked to a tool they have outgrown.
● Code green · one protocol
Declared capability, one place to grant and revoke, one place to look when asking what an agent can reach. Swapping the assistant does not mean rebuilding the plumbing — which matters, because the assistant you use in three years is probably not the one you use now.
The part that matters to us
For the organisations we work with — agencies with public-records obligations, cities, practices holding client confidences — the connection question is never "can it reach the system". It is "under whose identity, with what permissions, visible to whom, and how do we turn it off".
That is why our own build sits inside Microsoft 365 rather than beside it. Identity is the tenant's identity, consent and access policy are the ones the organisation already runs, and the audit trail lands where the administrators already look. Our agent roster registers as a connected platform, so the agents appear in the same governed inventory as any other connected agent in the tenant — named, attributed, and visible to IT rather than running quietly in somebody's personal account.
Two ecosystems usually written up as competitors, cooperating — with the governance trail intact. That is the bit that matters the moment anyone asks what is touching their data.
We also publish, on the agent team page, which of our connections are live, which are in build and which are merely planned. That is a low bar and it is worth holding anybody to it, us included.
The correction
Everything below is a real thing we have watched people assume. None of it follows from adopting the protocol.
The checklist
Ask these of us, of any vendor, and of your own team. They are the same six regardless of platform, and the answers should be boring.
| Ask | What a good answer sounds like |
|---|---|
| Whose identity is it acting as? | A named service identity in our own directory, or a specific user with consent recorded. Not a shared account, and not somebody's personal login. |
| What exactly can it reach, and what can it change? | An enumerated scope, read and write listed separately. If the answer is a broad grant "for now", the temporary will outlive everyone in the conversation. |
| Where does the audit trail land? | In the logs the organisation already reviews. A trail that only exists inside the vendor's console is a trail you cannot use during an incident. |
| How is it revoked, and by whom, at 2am? | One place, by an administrator, without contacting anybody. Test it before you need it. |
| Does any data leave our tenant, and to where? | A specific answer naming services and regions. For records-bearing and confidential work this determines whether the connection is permissible at all. |
| What happens when it fails? | The failure is reported as a failure. A connection that degrades into silence, or into stale data presented as current, is worse than one that is plainly down. |
In your world
The first connection should be one where the value is obvious and the blast radius is small. Read-only, bounded, and in a system whose failure modes you already understand.
Start with the reporting exports and the document library — read-only, on a known cadence. The operational side stays out entirely: no dispatch, no CAD, no station alerting, no patient records, and that is a structural boundary rather than a phase-one caveat.
Adopted code, resolutions and the meeting cycle. Both are already governed under your retention rules, which means the connection inherits a policy that exists rather than requiring a new one.
Invoices, ageing and the balance behind every cash question — read-only until the routine has a track record. Ours reads the accounting system and drafts; it has never been able to issue anything.
Where a practice's real state lives. Scope to what the routine genuinely needs — a fortnight forward, one shared mailbox — rather than everything the account can technically see.
What we will not claim
Where this sits
Once connecting is cheap, the constraint stops being capability and becomes judgement — which tools to buy, which to build, and which decisions to deliberately not make yet. That is chapter seven.