The operating model for a custom AI agent

Does it speak, or does it act?

Retrieval, summarisation and drafting are speech. A write to a system of record, a payment, a status change, an outbound message to a customer or a regulator is an action, and an action needs a declared contract, an identity of its own, and an approval gate on anything whose reversal would be expensive. This is where the biggest misjudgement of effort happens, because the demo makes the whole thing look finished long before it is.

What does it cost to be wrong?

Most wrong answers are service failures that a person corrects and everybody moves on. Some are not. A wrong statement about cover, eligibility, entitlement or a preserved balance creates an obligation, and unwinding it is a remediation exercise with a compliance record attached. That reclassification, from service failure to obligation, is what moves the workload up a rung, and it is a property of the process rather than of the assistant.

Does behaviour have to hold still?

Ask whether anyone would notice if the assistant behaved differently next month. If the honest answer is no, a managed surface that improves on its own schedule is a benefit. If a release has to be gated on a fixed set of cases with stated pass and fail criteria, or an incident review has to reconstruct what was asked, which tool was called and under whose identity, then you need a versioned artefact and a trace you own. You cannot gate what you cannot version, and you cannot version somebody else's runtime.

How does it start, and does it hold state?

A person asking a question is one shape. An event, a queue or a schedule is another. If the work holds state across steps, needs an idempotency key so a retry does not duplicate an effect, or has a compensating step for a partial failure, that is a workflow rather than a conversation, and state that has to survive the turn belongs outside the model in something you can read and replay.

The rung most teams skip

Most estates jump from the licence straight to a custom build, and the middle rung is skipped for a reason worth naming: it is unglamorous, and it does not look like engineering. That instinct costs more than it saves.

A configured agent is the correct answer to a large class of work: a bounded task, a fixed order where the order matters, a small set of tools reaching a system of record, and an audience inside the tenant. Declared topics are the right tool when a process has a financial consequence and its ordering should not be inferred. Generative orchestration is the right tool for everything else. Drawing that line, deciding where the model is allowed to decide, is the actual design work, and leaving it undrawn is how a model ends up choosing the order of a payment.

The honest failure mode of this rung is different from the one people expect. It is not that the configured agent turns out to be incapable. It is that it turns out to be unversioned. A declaration edited in a browser by whoever had access, with no record of what changed or why the behaviour moved, is a production system with no change control, and that is a governance problem rather than a platform limitation. If you take the middle rung, take the release discipline with it.

The operating cost that lands first

There is a cost in a Microsoft estate that almost every business case puts in the wrong place, and it is the reason the cheap option is frequently not cheap.

Grounding on a tenant inherits decisions nobody remembers making. A site opened to the whole organisation so one team could get on with a project years ago. A shared drive migrated across with its permissions intact because re-permissioning it would have delayed the migration. A person who changed role and kept every group they had. None of that was a problem while finding the document required knowing it existed.

A copilot removes that requirement. It is faithful to the permissions it finds, which means it reproduces the defect rather than catching it, and it makes the defect reachable in one plain-language sentence. This is the failure that turns a rollout into an incident, and it is a failure of the estate rather than of the model.

Microsoft states the behaviour plainly in its own documentation: Copilot only shows the data that users have permission to access. That sentence is published as reassurance and it is true. Read it a second time as a specification and it is also the warning, because it makes the accuracy of your permissions the ceiling on the safety of your rollout.

The default is not in your favour, and this is not a matter of opinion either. Microsoft's own Copilot readiness guidance states that by default SharePoint sets sharing settings to the most permissive option. The same guidance points administrators at a data access governance report whose entire job is to list the top 100 sites where content was shared with the whole organisation in the past 28 days. When a vendor ships a report shaped like that, the problem it answers is not hypothetical.

The good news is that the scale of the work is knowable before you commit to anything. SharePoint Advanced Management is included with the Microsoft 365 licence, and Microsoft recommends running its Content Management Assessment before turning Copilot on and re-running it every 30 days to track progress. Run it once and you have an estimate for the permission work rather than a guess. Read the 30-day cadence as what it is: a standing cost, not a project with an end date.

The consequence for the decision at hand is precise. The permission and label review is not a build cost, so it does not disappear when you choose the licence. It lands before the licence rather than after the first complaint, and it lands whichever rung you end up on, because a custom retrieval layer built over the same content inherits the same defect unless the entitlement filter is applied at retrieval rather than after it. There is a sharper version of the same problem once an assistant can act rather than only read, set out in the piece on prompt injection and tool calling: an over-broad permission that only ever leaked a document becomes an over-broad permission that can be talked into performing an action. Microsoft Purview sensitivity labels are applied where the policy never actually reached, Restricted Content Discovery keeps a high-risk site out of Copilot and search without disturbing its permissions, and Restricted SharePoint Search is treated as what Microsoft says it is, something that gives you time to review and configure the correct permissions, rather than as a control in its own right.

Running both rungs without two regimes

Assume most organisations that take this seriously will end up running all three rungs at once, because different workloads land in different places and that is the correct outcome rather than a failure of standardisation. The failure mode to avoid is not multiple rungs. It is multiple governance regimes.

The shape of the problem is specific to a Microsoft tenant. The same enterprise action gets requested from three different places. Microsoft 365 Copilot asks in the name of the person at the keyboard. A Copilot Studio agent asks through a connector. A hosted agent asks as itself. Built separately, that is three integrations with three authorisation models, and during an incident there is no single answer to the question of what an assistant was permitted to do.

Three things should be singular across the estate, and everything else can vary.

• One tool layer. The engineering case for this is already made at length in one governed toolset, which works through a build where four separate assistants call the same management surface and arrives at the line worth borrowing here: the number to minimise is not how many assistants you have, it is how many places the authorisation decision lives. Take that as read. What a Microsoft estate adds on top is that you do not have to invent the principal model, because the three callers are already named and already carry identities. Entra ID resolves a delegated user identity for the person at the keyboard, a workload identity for a Copilot Studio connector, and an Entra Agent ID for a hosted agent asking as itself. That turns the problem from a design question into an organisational one: the work is not designing the tool layer, it is stopping three teams from each building their own. So declare and authorise each contract once, before any agent behaviour is written, with its inputs, its side effects and the approval it requires stated in the contract, and let Entra ID make the same decision for all three callers. Identity decides what may be reached, never the prompt. A prompt is an instruction to a probabilistic system and it is not an access control mechanism.
• One evaluation register. Every assistant on every rung, including the licensed one, has a set of cases it is expected to handle and a stated result for each. What makes the register worth keeping is comparability, which is a property of the harness rather than of the cases, and the companion piece on harness infrastructure covers what it takes to get it. The licensed rung cannot be gated, which is exactly why it should be sampled on a schedule instead. A suite built only from questions the assistant already handles measures the suite rather than the assistant, so the awkward cases belong in it: ambiguous phrasing, questions just outside scope, and cases where the correct behaviour is to refuse and route to a person.
• One incident register. When an assistant says something it should not have, the review is the same review regardless of which rung it happened on, and the remedy usually lands on the estate rather than on the assistant. Whether that review is possible at all is decided long before the incident, by what the system recorded at the time, which is the subject of tracing a conversation end to end. Splitting incidents by platform is how the same underlying permission defect gets fixed three times and understood once.