[AI Burst] Everyone Is Shipping AI Agents. Almost No One Can Run Them

Treat the headline as a challenge

The original headline uses a broad contrast to ask a practical question. It is not a measured claim about how many organizations can operate AI agents. The durable issue is the gap between making a system perform a task once and keeping a service dependable when the surrounding business changes.

A demonstration usually has an attentive operator, a convenient example, and a clear finish. Production has interrupted sessions, missing records, changing permissions, unavailable tools, and customers who return with the same request. An executive considering rollout should ask what happens between those two environments.

Choose the smallest useful operating model

Anthropic distinguishes predefined workflows from agents that dynamically choose their own steps, and recommends starting with the simplest approach that meets the need. More autonomy can introduce additional cost and delay. That distinction helps prevent buying flexibility for work that already has a stable sequence.

Source: Anthropic: Building effective agents →

Describe the service before the intelligence

Write a short operating description that a manager outside the project can understand. Name the incoming work, the permitted output, the system that records completion, and the person accountable for exceptions. If completion means only that the model stopped responding, the service does not yet have a business definition of done.

Consider a hypothetical agent that prepares replacement orders. Finding an eligible order is one step; reserving stock, confirming the destination, and recording the approved replacement are different steps. A fluent message saying the replacement is ready cannot substitute for evidence that those changes occurred.

Give each request a durable identifier that connects the incoming case to its downstream records. Make the workflow distinguish prepared, awaiting approval, submitted, confirmed, and uncertain. These are proposed operating states, not claims that every platform supplies them automatically. Their purpose is to stop an interrupted attempt from looking like either success or harmless failure.

Design for uncertain outcomes

In the same hypothetical service, the order system accepts a replacement but the response never reaches the agent. An immediate retry could create another order. A useful recovery process first checks the existing transaction or request identifier. Where the downstream service supports duplicate protection, configure and test it. Where it does not, route uncertainty to a person with enough context to reconcile the record.

Write the recovery procedure while the team still remembers the happy path. A person taking over should see what was attempted, what was confirmed, which changes need checking, and what the customer has already been told. A raw transcript with hundreds of steps is a poor substitute for that handover.

Keep authority separate from recovery

OWASP identifies excessive functionality, permissions, and autonomy as causes of excessive agency. Its guidance favors narrow tools and authorization enforced outside the model. A recovery mechanism should therefore operate inside the same authority limits as the original request.

Source: OWASP: LLM06:2025 Excessive Agency →

Run an operational rehearsal

Before widening access, ask the team to demonstrate the following situations using test records. The point is to observe the service and its operators together, rather than reward an isolated model answer.

• A required tool is unavailable midway through the task, and the request reaches a visible exception queue.
• A downstream action succeeds but its acknowledgment is lost, and recovery avoids an unintended duplicate.
• An approval expires or the requested details change, and execution waits for a valid decision.
• The on-call owner pauses new work while preserving enough state to reconcile tasks already underway.
• A model or connector update is reversed, and previously accepted cases still pass the agreed checks.

Fund the work after launch

Operational ownership needs time and authority. Assign someone to review exceptions, maintain the test cases, assess changes, and decide when the service should stop accepting new work. Give that person a business escalation route rather than making every problem an engineering emergency.

For an initial review, compare completed business outcomes with the requests accepted into the service. Examine unresolved cases, repeated attempts, manual repair, and the age of the exception queue. Pair those observations with customer impact and operating cost. A service that creates a growing cleanup backlog has not demonstrated sustainable capacity.

Expansion should follow evidence that the operating team can absorb normal variation and recover from failures. The next release may need better task state, clearer ownership, or fewer permissions more than it needs a more capable model. That is a useful result: it identifies the real constraint on dependable automation.