Every one of those four places demos identically. Someone types a question, something sensible comes back, the room nods. That is exactly why the choice gets made badly: the demo is the one situation in which the difference between them is invisible.
This year I delivered three agents to three clients, and all three ended up somewhere different. One is a declarative agent inside Microsoft 365 Copilot. One is a set of agents in Copilot Studio handing work to each other. One is mostly custom code.
That was not variety for its own sake. It came out of the question I now ask before anything else: where should this agent live?
Not "can we build it" — these days you almost always can. The question is where it will still make sense in a year, when somebody else maintains it and somebody pays the bill.
The four options
A declarative agent in Microsoft 365 Copilot. Your users are already in Copilot, the job is about knowledge and data that lives in the tenant, and you want to run no infrastructure at all. Instructions, sources, done. The licence is usually already paid for, so running it costs nothing extra.
Where it ends: it never starts by itself. It cannot react to an incoming mail, a changed record, or a time of day. It is an assistant somebody talks to, not a process that runs.
Copilot Studio with classic topics. The path can be drawn in advance and you want it walked the same way every time. Audit, compliance, predictable cost. When someone asks six months later why it did that, you show them the diagram.
Where it ends: anything you did not anticipate falls straight through. And the topic tree grows — after a year it is an artefact somebody has to hold in their head in full.
Copilot Studio with the agentic loop. The input is messy and the path cannot be drawn ahead of time. This is the case where humans send mail: one message is an enquiry, the next a payment, the third a question about documents, the fourth all three in one paragraph. The agent works out which is which, goes into the CRM, and reports back to the team.
Where it ends: non-determinism needs a fence around it. You need a set of real inputs you re-run regularly, and you have to accept that the cost of a single pass varies.
Custom code. The output is an artefact whose shape matters — a document in a corporate template, a deck, a report. That is where the platform stops. An agent can write the content, but nothing holds a template as precisely as code written to fill it.
Where it ends: now you run it. Everything the platform was giving you for free — sign-in, logs, deployment — is suddenly yours.
Five questions that settle it
You do not need to know everything up front. These five are enough:
- What starts it? A person in a chat, or an event — mail, a record, a schedule? The moment the answer is "an event", the declarative agent is out and there is no point discussing it further.
- What does the input look like? A form, or a sentence written by a human? Structured input does not need a model to understand it.
- Can the path be drawn in advance? If it can, do not buy non-determinism. It is a complication you will spend the whole project containing.
- What comes out the other end? An answer in a chat, a record in a system, or a file where the formatting matters? Each of those three points somewhere different.
- Who maintains it a year from now? This one overrides the rest. Something a business user can adjust has a different life expectancy from something that requires calling me.
What it usually dies on
Not the technology. Two other things.
Volume. A per-user licence and a per-message charge are entirely different financial models. An agent that touches every incoming mail has a volume you can estimate — and it needs estimating before anything is built, not when the first invoice arrives. It is one of the few cases where I recommend an hour in a spreadsheet before anyone opens the designer.
Cramming everything into one agent. The pull is strong, because it is "all one tool anyway". In that mail triage case there are two agents: one clears the inbox and never speaks to a user, the other serves sales staff looking things up and never writes to a system. Two different jobs for two different audiences. In a single agent the instructions would fight each other, and neither half could change on its own.
The part I would not skip
This layer moves faster than anything else in the Microsoft stack. Over the past year the way agents are built in Copilot Studio changed enough that what I built at the start of it, I would build differently now — and I see no reason to expect a calmer year ahead.
The practical consequence: do not let business logic get stuck inside the agent. When the real work sits behind an API or a flow and the agent is only the surface calling it, swapping surfaces takes days. When the logic is scattered across instructions and topics, it is a rewrite.
It is the same rule that has always applied to portals, mobile apps and everything else that is really a channel. It is just more visible here, because this channel changes every six months.
So
Choosing the place is a twenty-minute conversation. When it goes badly you pay for it in months — either rewriting the agent, or watching it sit in the demo and never reach production.
And so far, not once has the right answer been "all of it in one tool".
If you are working out where an agent belongs — or whether to build one at all — reach me at vit.lachner@email.cz or on LinkedIn.