The short answer
Agent pilots stall on operating decisions that were skipped. It's rarely the model. The two that matter most: nobody wrote down what done meant in a form a second person could check, and nothing runs on a schedule to notice when the agent stops meeting it. Both are fixable in about two weeks, before a single line of the agent changes. Microsoft is consolidating agent identity, policy and monitoring into Agent 365, which makes the access half easier than it was a year ago. The ownership half is still yours.
A demo is a controlled environment with a friendly operator. The floor is not. The gap between the two is rarely about capability, and a team that thinks it is will spend the next quarter trying a better model on a problem that was never about the model.
Anyone who has watched a pilot go well and then watched it sit for six months knows the pattern. The demo answered five questions correctly in front of the leadership team. Then the pilot met a real week: inputs arriving in a format nobody described, an edge case that turns out to be a third of the volume, a system the agent cannot reach because access was never requested, and a question nobody could answer, which is whether the thing is still working. Every one of those is a decision that was skipped, not a limit that was hit. Forrester has a report on this failure class, Why AI Agents Fail (And How To Fix Them), which is worth reading alongside your own post-mortem rather than instead of it.
What a demo proves against what production requires
| What the demo established | What production needs | |
|---|---|---|
| Inputs | A handful of clean examples. | The real distribution, including the ugly third. |
| Success | It looked right to the room. | A written rule someone can check without you. |
| Access | A person had the data open. | The agent holds its own permitted access. |
| Failure | Somebody noticed and re-ran it. | A defined failure state with a destination. |
| Ownership | The builder was in the room. | A named owner who is not the builder. |
| Drift | Not applicable, it ran once. | A recurring check that it still meets the rule. |
Read the right-hand column as a checklist rather than an argument. Every row is a small piece of work. Skipping any row is what produces a pilot that impresses and never ships.
What does done actually mean for an AI agent?
Done means a written rule that a person who was not in the room can apply to a single output and get the same verdict you would. That rule has to be specific enough to disagree with. If two reasonable people read your definition of success and score the same output differently, the definition is not finished.
The common failure is a definition made of adjectives. Accurate. Useful. On-brand. None of those can be checked, so nobody checks them, and the agent's quality becomes whatever the last person to look at it felt. The version that works is closer to a rubric: the output includes these fields, cites this source, stays inside this range, and never asserts anything not present in the input.
Our methodology treats this artifact as a prerequisite rather than a deliverable. Before an agent gets built, a small set of real examples is scored by hand against a draft rule, and the rule is revised until two people scoring independently agree. That exercise usually takes an afternoon, and it routinely changes what gets built, because writing down what good looks like exposes which part of the job actually carries the value.
Why does an agent that worked in June behave differently in September?
Because the inputs moved and nothing was watching. Upstream systems change formats, a supplier renames a field, a policy update alters what a correct answer is, and the agent keeps producing confident output against a world that shifted underneath it. Nothing announces this. The output still looks like output.
This is why an evaluation set matters more than an evaluation. A single pass at launch tells you the agent worked on the day you looked. A held-out set of scored examples, re-run on a schedule against the same written rule, tells you whether it still does. The cost is small and the alternative is discovering the problem through a complaint.
The operating rule worth adopting: any check that only ever runs once is a launch activity, not a control. If nobody can point to a run of the check that failed, nobody knows whether the check works either.
What access does an agent need, and who grants it?
An agent needs its own identity and its own permitted reach, granted deliberately, rather than inheriting a person's session. That distinction is what makes the access reviewable later, and it is now the direction the platforms are moving. Microsoft is consolidating agent security capabilities from Copilot Studio and Microsoft Foundry into Microsoft Agent 365 (Microsoft Learn, accessed August 2026), so identity, policy and monitoring resolve against one record.
Insufficient access is an underrated cause of stall because it presents as a quality problem. An agent that cannot reach the system holding the answer will produce a worse answer rather than an error, and the team reads that as the agent being weak. The diagnostic question is simple and it gets skipped constantly: for each thing the agent got wrong, could a person with the same access have got it right? When the answer is no, the fix is a permission, not a prompt.
Agent 365's July 2026 update extended discovery and governance across ecosystem platforms and brought partner risk signals into one view (Microsoft Community Hub, accessed August 2026). Practically, that means the access question and the inventory question are becoming the same question, which is good news for anyone who has tried to audit this by hand.
Where do humans belong in the run?
At the points where a wrong answer is expensive and hard to reverse. Not everywhere, which kills the value, and not nowhere, which is how a small error becomes a large one. The design question is not how much to trust the agent. It is which specific steps produce consequences you cannot undo.
The pattern that holds up: the agent gathers and drafts, a person approves the step that commits, and the agent carries out the rest. Approval sits at the commit rather than at the draft, because approving a draft is just reading and approving a commit is a decision. Platform support for this has caught up too, so an approval step is increasingly a configuration rather than something a team hand-builds.
Teams that get this right usually start with more gates than they need and remove them as the evaluation record earns the removal. Starting loose and tightening after an incident is the expensive order to do it in.
What happens when the pilot team moves on?
Whoever owns the agent has to be somebody who did not build it, and they need three things: the written definition of done, the evaluation set, and the authority to turn the agent off. An owner without the third one is a spectator.
This is the row most often skipped, and it is the one that determines whether the agent survives its first quiet failure. The builder knows what the agent was supposed to do and can tell by eye when it is wrong. That knowledge is not written anywhere, so when the builder moves to the next project, the agent loses its only working quality control. The handoff artifact is not documentation about how it was built. It is the rule, the examples, and the off switch.
The four checks that gate an agent into production
Run these in order, and treat a failure on any of them as a stop rather than a note.
- First, the definition of done is written and two people scored a real sample independently and agreed.
- Second, the agent holds its own identity and its own permitted access, and every wrong answer in testing has been classified as either a capability problem or an access problem.
- Third, an evaluation set exists and runs on a schedule, with a threshold that has been crossed at least once in a controlled test so you know the alarm works.
- Fourth, a named owner who is not the builder holds the rule, the set, and the ability to switch it off.
None of those four require a better model, a larger budget, or a new platform. They require about two weeks of deliberate work in front of a build that would otherwise take a quarter and stall.
ArchitectNow runs exactly this sequence inside an AI Innovation Assessment, working from your real process rather than a reference architecture. If you have a pilot that demos well and has not moved in a month, the fastest thing to check is which of the four is missing. It is usually the first one, and it is usually missing because it felt too obvious to write down.
Sources and references
- Why AI Agents Fail (And How To Fix Them), Forrester. https://www.forrester.com/report/why-ai-agents-fail-and-how-to-fix-them/RES183446 (accessed August 2026)
- Transition Microsoft Copilot Studio and Microsoft Foundry agent security capabilities to Microsoft Agent 365, Microsoft Learn. https://learn.microsoft.com/en-us/defender-xdr/security-for-ai/transition-agent-security-to-agent-365 (accessed August 2026)
- What's new in Agent 365, July 2026, Microsoft Community Hub. https://techcommunity.microsoft.com/blog/agent-365-blog/whats-new-in-agent-365-%E2%80%93-july-2026/4543654 (accessed August 2026)