Comparison Reviewed September 2026

Copilot or custom AI?

We build custom AI systems and this is the comparison we lose most often, usually correctly. If the work happens inside documents, mail and meetings and you already run Microsoft 365, the assistant you can switch on this afternoon is very likely the right answer.

THE CASE FOR THE LICENCE

A licensed assistant embedded in the productivity suite starts from a position no custom build can match: it is already inside the place the work happens. The documents are there, the mail is there, the meetings are there, and — the part that is genuinely difficult to reproduce — the permission model is there. It sees what the signed-in person is entitled to see, because it inherits the tenant's own access control rather than reimplementing it.

That last point deserves more credit than it usually gets in these comparisons. Building a retrieval layer over an organisation's documents that correctly honours every group, sharing link and inherited permission is a substantial piece of engineering, it is the part most likely to go wrong, and it is the part with the worst consequences when it does. An assistant native to the tenant gets it as a property of where it runs.

Add the rest of the buy case: there is no integration project, no infrastructure to operate, no evaluation harness to build before anyone can use it, and the administration and data-handling surface is the one your IT function already understands. Deployment is a licence assignment and a change-management exercise. Against a six-to-twelve-week build, that is not a close race for the problems it covers.

So the useful question is not which is better. It is whether your problem is one of the ones it covers.

WHERE IT COVERS THE PROBLEM

Work inside the suite

Drafting, summarising, rewriting, finding something in a long thread, catching up on a meeting nobody minuted. The material is already in the tenant and the output is read by a person. This is the assistant's home ground, and a custom system built to do it would be a worse version of it.

Broad, shallow usage

Many people each saving small amounts of time on varied tasks. That pattern suits a per-seat product and suits a general assistant, because there is no single workflow worth specialising for. It is also the pattern least likely to justify a build, since there is nothing specific enough to build.

A person always in the loop

Every output is read, edited and accepted by the human who asked for it, so the quality bar is “useful draft” rather than “correct without review”. Where that is genuinely true, the absence of an evaluation harness costs you very little, and building one would be effort spent on a risk you do not carry.

SIDE BY SIDE

	Licensed assistant	Purpose-built system
Time to first value	Days	Weeks to months
Reaches data inside the tenant	Natively, with tenant permissions	You build the connector and the filter
Reaches your line-of-business systems	Through connectors and agent tooling	Directly, on your terms
Runs unattended on a schedule or a trigger	Improving, and person-shaped by design	The normal case
Quality measured against a test set	Not the product model	A gate on every deploy
Control over model, prompt and retrieval	Set by the vendor	Yours
Cost shape	Per seat, per month, ongoing	Build cost, then per use and hosting
Cost behaviour at scale	Rises with headcount	Rises with usage, not headcount
Explaining one specific decision later	Interaction-level records	Whatever your audit design requires
Deployment where data cannot leave	Vendor cloud regions	Your accounts, or your hardware
Who maintains it	Vendor	You or a partner
What happens when it is wrong	The person editing catches it	Designed for: checks, escalation, audit

Reviewed September 2026, and deliberately about structural properties rather than features. Product capabilities on both sides move every quarter, so treat any feature row as a prompt to check the vendor's current documentation rather than as a settled fact.

WHERE IT STOPS BEING ENOUGH

The data lives somewhere else

The answer depends on your claims system, your warehouse management system, a twenty-year-old database or a product catalogue that has never been near the tenant. Connectors close part of this gap and the remaining part tends to be the specific, awkward, valuable part — the join across three systems that only your business needs.

Nobody is driving

A person asking for help is a different design from a process that runs on an event: an invoice arriving, a ticket opening, a nightly batch. Unattended work needs retries, idempotency, queues, alerting and a defined behaviour when it is unsure — engineering concerns rather than assistant concerns.

Output has to be measurably right

Where an output is acted on without a human reading it, or where being wrong has a regulatory or financial consequence, you need an evaluation set, a threshold and a gate that blocks a change that regresses it. That is a property of a system you own, and it is the single clearest line between the two options.

Per-seat economics stop working

A per-seat licence is excellent value for someone who uses it daily and poor value for someone who does not. At a few hundred occasional users the arithmetic often favours a per-use system serving the same workflow. Model it at your real adoption rate rather than your headcount, and revisit it once you have usage data.

You need the controls yourself

Choosing the model, pinning it, deciding what goes into the context, setting the retrieval strategy, versioning the prompt, and knowing that none of it changed under you last Tuesday. In a licensed product those are the vendor's decisions, which is usually a feature and occasionally disqualifying.

The data cannot go to a hosted service

Some material may not be processed outside a defined boundary, whatever the contractual assurances. Where that is the constraint, the choice is not between two products; it is between a system in your own infrastructure and no system at all.

THE QUESTION TO ASK BEFORE EITHER

Is this a productivity problem or a process problem? A productivity problem is many people each doing varied work slightly faster, and the value is diffuse, real and hard to attribute. A process problem is one defined workflow, running many times, with a measurable outcome — claims triaged, documents extracted, tickets resolved. Licences answer the first well. Systems answer the second well, and the second is where a business case survives a finance review, because you can count the thing that happened.

Organisations get into trouble by buying seats for a process problem and then being disappointed that time savings did not appear in a budget line. That is not a failure of the product; it is a category error at the point of purchase, and it is the most common one we see in this comparison.

Then measure adoption before scaling either. Per-seat assistants are frequently bought at organisation scale and used by a fraction of the licensed population. Before extending a pilot, look at what proportion of assigned seats were active last month and what they were used for. That number decides whether the next spend is more licences, training on the licences you already have, or a system for the one workflow that turned out to matter. It is also the cheapest piece of evidence in this entire decision, and almost nobody collects it.

MOST ORGANISATIONS END UP WITH BOTH

The framing as a choice is mostly an artefact of how budgets are approved. In practice the two occupy different layers: the assistant covers the broad, person-driven work across the whole organisation, and a small number of purpose-built systems cover the specific processes where volume, measurement or integration justify them. Neither displaces the other, and the custom surface stays small, which is what keeps it maintainable.

Where the two meet is worth designing rather than leaving to chance. A custom system's output landing where people already work — a document in the tenant, a message in the channel, a record in the line-of-business system — is far more likely to be used than one behind a new login. Equally, a custom agent exposed through the platform's own extensibility surface can be reached from inside the assistant, which is often the right delivery route for something you built yourself. Building a separate portal for a capability people were meant to use daily is the mistake this section exists to prevent.

One caution on terms. Licensing tiers, data handling, regional processing and which capabilities require which subscription are the vendor's to set, and they change. Anything in this comparison that depends on them is stated as at the time of writing; confirm against the provider's current terms and your own agreement before a decision rests on it.

QUESTIONS

QUESTIONS — 5

For most of what people do in a working day, you would not, and we would say so on the first call. The build case starts where the licence stops: a process that runs without a person driving it, data in systems outside the tenant, an output that has to be measurably correct rather than a good draft, or a per-use cost structure that fits the workload better than a per-seat one. If none of those describe your problem, the licences are the answer and the conversation is short.

Yes, through the platform's APIs, and the honest caveat is that honouring every permission correctly is real engineering rather than a configuration step. It is done routinely and it is one of the parts we test hardest, because a retrieval layer that leaks across a permission boundary is a serious incident rather than a bug. If document access inside the tenant is the entire requirement, that engineering is a cost with no offsetting benefit, and the licensed assistant is the better answer.

They are a genuine middle option and worth trying before commissioning anything. A low-code agent inside the platform can cover a surprising amount of workflow, inherits the tenant's identity and governance, and is quick to stand up. The limits show up in the same places low-code always does: complex logic, versioning and testing discipline, dependence on connectors that may not cover your system, and a ceiling on how much you can inspect or change. Start there for a bounded workflow, and treat difficulty in expressing the logic as the signal to move.

It depends on adoption and usage, and the shapes differ rather than one being uniformly lower. Per-seat licensing is an ongoing cost that scales with headcount and is predictable to budget. A custom system is a capital cost followed by per-use inference and hosting, so it scales with usage instead. Model both at your projected volume and honest adoption rate, over three years, including the maintenance either way. Do not compare a build quotation against one year of licences, which is the comparison that gets put in front of a board most often.

No, and you should read the page with that in mind. We benefit when the answer is a build. What makes it worth publishing anyway is that an engagement which should have been a licence purchase ends badly for both of us: the system underperforms a product that was already paid for, and it produces no reference. Telling you to switch on the seats you already own is the cheapest way we earn a call about the workflow that genuinely needs building.

Keep reading

AI Readiness Assessment

→

Pricing

→

30-minute technical call · no deck