Where Copilot stops and a custom agent starts: drawing the line in a Microsoft estate

The question arrives in a particular shape, and the shape is the problem. Somebody has priced a build. Somebody else points out that the organisation is already paying for Microsoft 365, that a copilot is licensable into the tenant this afternoon, and asks why any of the build is necessary. The room then argues about capability, which is the one axis on which the argument cannot be settled, because both options can technically answer most of the questions on the list.

The honest answer is a boundary rather than a verdict. There is a real line, it is drawable in an afternoon with the right seven questions, and it sits nowhere near where most build-versus-buy conversations put it. This piece is that line, the reasoning behind each part of it, and a table you can run your own workload list through.

What is already true

A Microsoft engagement rarely starts at zero, and that changes the first question rather than merely making it easier. Microsoft is usually already the identity provider, already the document store, already the place work is discussed, and often already the service record. A finished assistant is already licensable into the tenant. So the opening question is not which service to use. It is how far a request has to travel before a build is justified at all.

That framing has an uncomfortable consequence for anyone selling a build, and it is worth stating before anything else. The most expensive mistake available in a Microsoft estate is not choosing the wrong service. It is building something the tenant would already have done. The second most expensive is licensing something that was never going to reach the system where the answer actually lives. Both are common. Both are avoidable in a fortnight of design, which is cheap next to either.

Three rungs, defined

Three rungs matter, and it helps to define them without reference to any of them being better.

A licensed copilot is an assistant you configure rather than build. Microsoft 365 Copilot answers over Microsoft Graph and returns what the person asking could already open, using semantic indexing across files, mail, chat and sites. You do not write it, you do not version it, and you do not control when its behaviour changes. Microsoft 365 Copilot Chat is a separate, unlicensed tier and is a different product rather than a smaller one.

A configured agent is declared rather than coded. In Microsoft Copilot Studio you declare topics where the order of a conversation has to be fixed, generative orchestration where it does not, agent flows for automation, and tools that reach a system of record under a declared contract. The unit is now called an agent rather than a bot, and the older experience is now labelled classic. You own the declaration and the grounding, and you still do not own the runtime.

A custom agent is code you wrote, running somewhere you chose, under an identity you issued. On Microsoft that usually means Foundry Agent Service in Microsoft Foundry, the platform Microsoft called Azure AI Foundry until recently, either as a prompt agent that is declarative but versioned and evaluated on its own release cycle, or as a hosted agent that runs your own code. Orchestration is authored with the Microsoft Agent Framework where it is better written than configured. Tools run as Azure Container Apps services or Azure Functions with one managed identity each. You own all of it, including the pager.

Each rung costs more to own than the one below it, and a rung you have climbed unnecessarily is a permanent operating cost bought with a one-off saving.

Capability is the wrong test

Almost every build-versus-buy conversation is conducted on capability, and capability is the wrong test for two reasons.

The first is that capability arguments expire, and the rate at which they expire is now a published forecast rather than a hunch. Gartner, in a press release dated 26 August 2025, predicted that 40 per cent of enterprise applications would feature task-specific AI agents by the end of 2026, up from fewer than 5 per cent in 2025. Read that as a statement about where the agent you are pricing today is likely to end up: inside an application you already licence. Microsoft ships against the gaps you named roughly monthly. A decision recorded as 'we had to build this because the licensed product could not do X' is a decision that quietly becomes wrong, usually without anyone revisiting it, and you are left operating a custom system whose entire justification evaporated in a release note. The most common form of technical debt in a Microsoft estate is not old code. It is a build that was correct at the time and is now a duplicate of a feature.

The second is that capability was never the constraint anyway. A licensed copilot can already summarise a policy document, draft a letter and answer a question about a contract. If you are choosing on that basis, the demo will decide the architecture, and the demo is the least informative artefact in the entire process because it is run on content someone chose.

The line that does not move is accountability. Who is answerable when the answer is wrong, what the answer touched on its way out, and whether anyone can reconstruct the decision six months later. Those questions do not get solved by a release note. They resolve into seven tests, and every one of them is about the shape of the work rather than the cleverness of the model.

The decision table

Run each workload through the table below. Any single yes in the build column moves the workload up a rung. Nothing is scored or weighted, because a weighted matrix invites the answer somebody already wanted, and these are not tie-breakers. They are disqualifiers.

• Where the answer lives. A licence suffices when the answer is in documents, mail, chat and sites inside the tenant, reachable through Microsoft Graph. Build when the answer is in a system of record behind a contract, an external API, or a core system with a nightly batch window. Why: nothing outside Graph is a licensing question, it is a retrieval and integration question, and it is the strongest single predictor of a build.
• Whose permissions apply. A licence suffices when the answer is exactly what the person asking could already open. Build when the answer spans entitlements no single person holds, or is shown to somebody who is not the requester. Why: inheritance is the right semantics until the correct entitlement decision stops being the requester's own.
• Speaks or acts. A licence suffices when the system retrieves, summarises and drafts, and a person does the rest. Build when it writes to a record, moves money, changes a status, or sends something outward to a customer or a regulator. Why: an action needs a declared contract, its own identity and an approval gate, and the language half is the easy half.
• Cost of being wrong. A licence suffices when a wrong answer is a service failure that somebody corrects and the day continues. Build when a wrong answer is a statement that creates an obligation, or a decision with a financial or regulatory consequence attached. Why: autonomy is set by the cost of being wrong, not by model capability, and a better model changes how often, never what happens then.
• Stability of behaviour. A licence suffices when nobody would notice, or mind, if it behaved differently next month. Build when a release has to be gated on a fixed evaluation set, and an incident review has to reconstruct a decision. Why: you cannot gate what you cannot version, and you cannot version somebody else's runtime.
• Who the user is. A licence suffices when the user is an employee, inside the tenant, under existing acceptable use. Build when the user is a customer, member, claimant or the public. Why: a tenant licence does not reach people who are not in the tenant, and facing outward is a different system, not a wider rollout.
• How it starts, and state. A licence suffices when a person asks a question and reads an answer, and nothing survives the turn. Build when an event, a queue or a schedule starts it, and it holds state across steps with a compensating step for failure. Why: a conversation is not a workflow, and state that has to survive the turn belongs outside the model, where it can be read and replayed.

The seven tests in order

The tests are ordered by how early they can be answered and how expensive they are to get wrong, so the first two settle most workloads before anyone has drawn an architecture. A workload enters at the top of the sequence below and falls through each test in turn. Any single yes exits sideways to an outcome and the sequence stops there. A workload that answers no to every one of the seven tests falls through to the bottom, where the outcome is that the licence is the whole build and no build is justified.

• Test 1, where the answer lives. Does the answer live outside what Microsoft Graph reaches? A yes lands on a custom agent.
• Test 2, whose permissions apply. Must the answer differ from what the requester may already open? A yes lands on a custom agent.
• Test 3, speaks or acts. Does it act, and not only answer? A yes lands on a configured agent at minimum.
• Test 4, cost of being wrong. Is a wrong answer a regulated or financial consequence? A yes lands on a custom agent, gated.
• Test 5, stability of behaviour. Must behaviour hold still across a release? A yes lands on a custom agent, gated.
• Test 6, who the user is. Is the user outside the tenant? A yes lands on a custom agent.
• Test 7, how it starts, and state. Is it event driven, or does it hold state across steps? A yes lands on a custom agent.

No to all seven: the licence is the whole build. This is a reasoned decision aid, not a description of any single engagement.

When the answer is neither

The strongest position in this piece is the one that costs the most to hold. A meaningful proportion of the requests that arrive as build a copilot for this are not assistant problems at all, and the diagnosis is worth more than either option on the table.

The tell is usually in where the time actually goes. If the bottleneck is an approval step with a single owner, an assistant in front of it will produce faster arrival at the same queue. If the bottleneck is that the published answer and the operational record disagree, the assistant will state the disagreement more fluently and more often. If the policy the team is asking to automate is a policy they are not permitted to change, no rung on this ladder is the answer, and a well-run fortnight of design will say so.

That answer costs the person delivering it the build. It should still go in the report, because the alternative is a system that industrialises a process nobody defended. The commercial discipline is to record why no build was recommended, name the condition that would change that recommendation, and revisit the decision only when that condition arrives.

Writing a decision that survives

The last thing to get right is the record itself, and it is the part most often skipped. A decision written as 'we built this because the licence could not do X' has a shelf life measured in release notes. A decision written against the tests above does not, because the tests are about the shape of the work rather than the state of a product.

So write the decision down in that form. Name the test that was failed, name the rung it pushed the workload to, and name the condition under which the decision should be revisited. If the reason was that the answer lives in a system of record outside the tenant, the revisit condition is a supported connector reaching that system, not a general improvement in model quality. If the reason was that the release has to be gated, the revisit condition is a versioning and evaluation capability on the managed surface, which is a thing you can watch for rather than a feeling you have to relitigate quarterly.

Reviewed on that basis, the boundary moves in exactly one direction over time. Work migrates down the ladder as managed products absorb it, which is the outcome you want and the reason to keep the record in a form that lets you notice. The custom builds that remain are the ones whose reasons were never about capability in the first place: an entitlement decision that is not the requester's own, an action with a consequence that has to be approved, a behaviour that has to be held still, and a user who was never in the tenant.

References

Every number in this piece is either a published third-party figure with its source named here or a calculation directly derived from one. Nothing in between.

• AU$31.40 per user per month, AU$37.68 month to month, promotional AU$26.91: Microsoft 365 Copilot Business add-on pricing, read from Microsoft 365 Copilot for business on 28 July 2026, where the add-on shows as originally starting from AU$31.40 and now starting from AU$26.91 per user per month paid yearly, and AU$37.68 per user per month on a monthly commitment. All prices there exclude GST. The thousand-seat figure is the AU$31.40 annual price multiplied out, nothing more.
• AU$299.30 per pack of 25,000 Copilot Credits per month: Microsoft Copilot Studio pricing, read from the Copilot Studio pricing page on 28 July 2026, where the pre-purchase plan shows as AU$299.30 per pack per month excluding GST, including the pay-as-you-go alternative and the inclusion of Copilot Studio for licensed Microsoft 365 Copilot users building internal agents.
• 40 per cent of enterprise applications by the end of 2026, up from fewer than 5 per cent in 2025: Gartner press release, 26 August 2025. Used to size the rate at which a capability-based decision ages, not as anybody's result.

Further reading. Microsoft 365 Copilot overview, for semantic indexing, the separate Copilot Chat tier, and the statement that Copilot only shows the data users have permission to access, which tests one and two turn on. Get ready for Microsoft 365 Copilot with SharePoint Advanced Management, the source for the most-permissive sharing default, the Content Management Assessment and its 30-day cadence, the data access governance reports including the organisation-wide sharing report, Restricted Content Discovery and Restricted SharePoint Search. Microsoft Copilot Studio fundamentals, for topics, generative orchestration, agent flows, and the current agent and classic terminology. What is Microsoft Foundry, for the brand change from Azure AI Foundry and for the prompt agent and hosted agent shapes in Foundry Agent Service. Microsoft Agent Framework overview, which states its own relationship to the two frameworks it succeeds. Microsoft Entra ID fundamentals, for delegated and workload identities and for Entra Agent ID as a governed identity for an agent. Azure AI Search overview, for classic search alongside agentic retrieval over knowledge bases built from knowledge sources. Microsoft Purview, for sensitivity labels and data loss prevention across the content a copilot grounds on. OWASP Top 10 for Large Language Model Applications, the reference we hold tool-holding systems against, and the source of the excessive agency framing used in tests three and four. ISO/IEC 42001, the AI management system standard, for the obligation to record decisions and oversight rather than assert them.