How to move AI agents from copilot to production

The jump is smaller than it sounds and harder than it looks

Worth stating the distinction plainly, because half the arguments in the room come from two people using the same word differently. A copilot performs a task when prompted, with a person at every decision point before anything becomes an action. An agent can watch for a condition, start a workflow, or act with no prompt at all, and can assess a situation and execute without routing the result past anyone. That framing comes from Microsoft's own product language, reported consistently across secondary write-ups rather than quoted here from a first-party glossary. The engineering between the two states is modest. The control work is not.

Draw the boundary tight

Bind the agent to tools, not to systems. "Can use the CRM" is not a boundary. "Can read an order, and can email the customer on that order" is one. Everything outside the list is unavailable by default rather than forbidden by exception, and you will see the difference the first time somebody adds a tool to the underlying server. Write down what the agent exists to do while you are there, in a field the agent's own instructions cannot influence, because a stated purpose is the thing a reviewer can hold a surprising action against later.

Gate what you cannot undo, and only that

Anthropic published an analysis on 18 February 2026 of 998,481 random tool calls through its public API. 80% of those calls carried at least one safeguard, either restricted permissions or a human-approval requirement, 73% looked as though a human was in the loop in some way, and only 0.8% of actions appeared irreversible, such as sending a customer an email. That is API-wide usage rather than a survey of enterprise agent deployments, so read it as a shape rather than as your number. The shape is what matters. If well under 1% of what an agent does cannot be undone, approving everything spends your reviewers' attention on the 99% that never needed it. Gartner's May 2026 press release arrives at the same place from the other direction, arguing that treating agent governance as binary, locked down or fully trusted, is what makes deployments fail.

Do not take the agent's word for it

An agent reporting a task as done is producing text about its own behaviour. It can be confidently wrong, and it can be talked into saying so by something it read mid-run. OWASP's 2026 agentic list names both cases: Rogue Agents is ASI10, Human-Agent Trust Exploitation is ASI09. Verify completion against the system that would show it. Read the ticket. Confirm the record was written. Check the email actually left. This is dull work, and teams skip it because the agent sounded certain, which is precisely why it belongs on the migration checklist rather than in somebody's memory.

Keep a record, and keep a way back

Two questions decide whether you can operate this thing in production: what happened in that run, and how do we reverse it. The record has to come from whatever made the decisions, because a log written by the agent's own code inherits the agent's confidence. The way back is more mundane. For every gated action, know the reversal, who is allowed to perform it, and how long it stays possible. Anthropic's own framing of the gap is that effective oversight will need new post-deployment monitoring infrastructure as well as new ways for a person and an agent to manage autonomy between them. Neither ships off the shelf yet, which is the honest state of this in 2026.

How Difinity.ai draws the same line

In Difinity the move from suggesting to acting is structural rather than a setting somebody has to remember to switch. An agent's tools are bound to its agent version, each binding names the tool and the catalogue it was approved against, and an agent version binds at most 32 tools. A published agent version keeps the tools it was approved with, so re-reading a tool server's list never quietly widens a live agent, and picking up a new tool is a draft edit that goes back through review. Anything effectful is judged before it runs whatever the tool's written rule says, while a read-only tool with no written rule and no configured posture is not judged at all: proportionality expressed in code rather than in a policy document. When an action does need a person, only the person the agent is acting for can approve it. No approver group, no shared queue, no delegation, and a run nobody answers expires. That person sees the whole action with its real arguments rather than a summary, the answer is signed, and the tool gateway checks the signature against the action it stored before anything runs. An approval is single use. While the run is happening the workspace shows it in the order it happened, and the reason the model gives for an action is displayed as a claim rather than as a fact.

A sequence for the first migration

Do these in order. Steps 3 and 4 are the ones that get postponed, and postponing them is how a pilot becomes an incident.

• Pick one job the copilot already does well, with an owner who will answer the phone about it at an awkward hour.
• List the actions that job needs, then cut the list. Bind tools, not systems.
• Mark every action reversible or not, and write the reversal for each irreversible one before you build anything.
• Take the credentials off the agent. Whatever holds them instead is now your enforcement point, so choose it deliberately.
• Put the gate on the irreversible list only, and name the person who answers it. If that person is a group, you have not decided yet.
• Test the ordinary path, a refusal, a system that is down, and an approval nobody answers. The last one is the test everybody skips.
• Read one complete record with the owner and with risk in the room. If they cannot follow it, you are not in production. You are in a pilot with better branding.