AI Agent Governance: The Hard Part Is the Write, Not the Decision

An AI agent that only reads is a search box with better manners. The moment it can act — file a ticket, send an email, update a record, close an issue — it stops being a demo and becomes something that can be wrong in a way that costs money.

The industry talks about agents as if the difficulty were the reasoning. It is not. Frontier models decide well enough. The difficulty is the write: making an action happen once, only when it should, in a way you can prove and undo. τ-bench, the public benchmark for tool-using agents in real customer-service domains, makes the point in numbers — what collapses is not whether an agent can do a task once, but whether it does the same task reliably across repeated trials. In production, the expensive form of unreliable is not a crash. It is a confident "done" over an action that did not happen, or happened twice.

Why is a write harder to govern than a read?

Every resilient system retries. A request times out, a worker restarts, a run resumes from where it paused — and the framework quietly runs the step again. For a read, that is free. For a write, it is a second ticket in someone's helpdesk.

The timeout fires after the downstream API has already processed the request; the retry sends it again; the record is created twice. Many orchestration tools acknowledge this in their documentation and recommend that you add an idempotency key on your side. That advice is correct — and it hands the whole problem back to the team building the agent.

How do you make an agent action happen exactly once?

SphereIQ keys every write by what actually identifies it: the run, the step within the run, and the call within that step — not the payload. That distinction matters. A resumed run reaching the same step is the same request even if a template filled a different timestamp into the body a minute later. Keying on the payload would treat it as new and create a duplicate; keying on run, step and call treats it as the second attempt at one action.

The key is enforced by a unique constraint in the database, so two workers racing on the same step do not both get through — they settle to one write, and the second reads the first one's result. A retry that reaches an action already executed does not run it again; it returns the original outcome.

Where does human approval fit?

Exactly-once is necessary and not sufficient. The other half is deciding whether the write should happen at all, and letting a person stand in front of it.

When an agent runs for real, every action passes one governed lifecycle: validate, scan for injection and policy violations, check the environment, produce a dry run, then either execute or pause for approval. The default is to pause. An action requires approval unless an administrator has explicitly set it to run automatically, and it fails closed: if the policy cannot be read, it asks rather than acts. A caller can ask for more review than the policy requires, never less.

A paused run is not a dead end. It posts itself to the approver — in the product, in Slack or in Teams — and the decision resumes it as a new run that points back at the one it continues, so the audit trail is a chain and not a gap. Separation of duties is enforced where it matters: on a production deployment, nobody may publish an agent they authored, because a control one person can satisfy alone is not a control.

While an agent is being built, none of this is even reached — in the builder, every write is simulated. That part is covered in how no-code agent builders stay safe.

What did the agent change in other systems?

The last property is the one a regulator or auditor asks about: after the fact, what did this run actually change? Every write records what it did — create, update, close or send — and where it landed, and those records are joined back to the run. So "what did agent run 4,812 change in Jira, Confluence and the CRM" is a query, not an archaeology project. Releases of an agent carry an Ed25519-signed receipt, so a change to what is live is itself a verifiable record rather than a claim.

One deployment-level rule sits under all of this. Whether an instance is production is set by its environment, not a database flag that a mistaken row could flip. A non-production deployment performs no external changes until someone says so, and acts only as the accounts it is given.

How to evaluate AI agent governance

Watch what happens when a run is interrupted and resumed, not what happens on the happy path. Resume it mid-write and check the downstream system for a duplicate. Ask where approval sits and whether it fails open or closed. Ask for the list of what a given run changed in your other systems.

For where the line sits between agents that answer and agents that act, see AI agents that act vs. AI that answers. For how agents reach your systems through one governed interface, see what MCP means for the enterprise.

Frequently asked questions