Microsoft built a Copilot Studio feature whose job is to not trust its own agent

Every vendor demo makes agents look like magic. One prompt, one clean result, everyone claps. Then you ship it, and the real work shows up: the agent skips a step, burns your token budget on nothing, or writes to a live blog while nobody is watching. A fresh wave of writeups from people who run these systems all land on the same hard-won point. Let me catch you up on what they figured out.

The deep cut

• The model recommends. Your code decides. OpenAI's Decisions API ships as a recommendation inside a contract, never as the policy engine.
• Some things must happen every time, not when the agent feels like it. Microsoft built Copilot Studio Hooks to take decisions away from its own agent.
• A write is not done until a read confirms it. GoodBarber's server asks for read-back on every write, and three in five never get one.

Give the agent a lane, not the wheel

The pattern across all these pieces is the same split: let the model propose, let plain code decide. OpenAI's Decisions API makes this literal. A decision response is a recommendation. Your application owns the options, the policy, the effect, and the recovery path. The model picks a lane. It never becomes your policy engine.

The rule that keeps a clever demo from becoming an incident: separate recommendation from authorization. A model can suggest routing a ticket to "technical." Only deterministic code checks the fields, the integration health, and whether the action already happened. Write the contract before you touch the beta, version it, and review it like any API change.

The same logic shows up in the queue world. Claude Haiku 5.5 work queues warn that "the model sounded confident" is not an acceptance check. Build a gate that tests shape, grounding, and business rule separately, and have it enforce the rule even if the prompt gets ignored or shortened later.

The thing that must happen every time

Microsoft shipped a feature in Copilot Studio called Hooks, and one line in its docs says more than most keynotes this year: use a hook "when you need something to happen every time, rather than only when the agent decides it's relevant." A tool runs when the agent judges it relevant. A hook fires every time, full stop.

Read that for what it is. One of the largest enterprise software companies built a feature to stop its own agent from deciding things. Logging, redaction, policy checks, audit trails: those are not places for agent judgment. They are places for a rule.

The timing makes the point sharper. Two days before Hooks, OpenAI pulled GPT-6.1 Astra the night before DevDay. Saachi Jain, their head of safety systems, said the model "didn't quite meet the bar in terms of staying within scope and authorization." Even a top safety team cannot trust a model to stay inside its own limits. So they build the fence instead.

What the server sees that the demo never shows

The sharpest reality check comes from someone who runs the other side of the connection. The engineering lead at GoodBarber counted 92 days of traffic to their production MCP server. Close to a hundred thousand calls. 62.8 percent were writes. Agents are not browsing customer apps, they are filling them. And 34 tool names that never existed got called 125 times, every one an error, before anyone noticed.

Their server returns verification_required: true on every write, with the tools to read back and confirm. Three writes out of five never get the read-back. The policy is advice. The clients decide, and they skip it.

Then there is silence. A scheduled run that never started "writes nothing, and nothing is the same colour as green." A report nobody opens looks exactly like a report nobody sent. The fix is boring and he admits he doesn't have it yet: a heartbeat on every run, with absence as the alert. Ask yourself the plain question he asks. How do you know your agent ran this morning? Not that it was right. That it ran.

The bill hides in the loop, not the price sheet

Swap Opus for Haiku and you'd expect the bill to drop 75 percent. On a tool-heavy agent, it barely moves. The per-token price was never the big variable. The loop is. Every tool result gets re-read and re-billed on each call that follows, because the Messages API resends the full history every time. One retry can cost more than the planning call that triggered it.

Anthropic's own context-editing example cut one turn from 70,000 input tokens to 25,000 by clearing stale tool results. A 64 percent drop, no model change. The levers that actually work: prompt caching, context editing, and a flat 50 percent batch discount for anything that doesn't need a same-turn answer. But none are worth touching blind. Log input, output, and cache tokens per step first. FinOps for agents looks like profiling, not price negotiation.

Keep useful work moving while a human decides

The patience failure is ordinary. The agent finds one missing detail, who a report is for, and freezes on a spinner. GPT-6.1 Sol's async tool calling removes the model-side wait so it can keep gathering facts while a person answers. But the API does not run your jobs, store state, or chase the user. Your app still owns the hard part.

The rule that prevents a common bug: "Question displayed" is an event, not a tool result. A human question is complete only when the user answers, declines, or times out with an explicit outcome. Persist the call before you show the UI, make completion idempotent, and bind every answer to identity and conversation. A task handle is a locator, not permission.

The same restraint applies to speed. GPT-6.1 Sol Ultrafast is worth paying for only when it shortens a decision a human is actively waiting on. Make the agent interruptible before you make it quicker. Give every run a task ID and a version, so a correction creates a new version and a stale result from the old one cannot change the workspace.

Three questions for your team

1. Which decisions in our agent flow run on the model's judgment that should be a Hook-style rule instead? Name the ones where "every time" matters: logging, redaction, escalation, approval.
2. Do we know our agent's writes get confirmed, and could we tell you right now what share get a read-back? If not, that number is your next sprint.
3. Are we logging tokens per step of the loop, or just staring at the monthly invoice? Pick one agent and break out where the spend actually goes before you change a model tier.