AI Agents: The Gap Between Keynotes and Reality
The keynote version of an AI agent starts with a goal and ends with a completed task. Travel gets booked. Email gets handled. A project moves forward while the owner does something more interesting.
Production adds the parts that disappear from the demo: an expired login, a renamed spreadsheet column, two customers with the same name, and a policy exception nobody wrote down. The agent reaches one of those edges and has to choose between guessing, stopping, or making a mess at machine speed.
That gap explains most of the disappointment around agents. Companies buy autonomy and discover they first need a well-run operating process.
Three places agents break⌗
The first problem is specification. “Handle my email” contains dozens of decisions about priority, tone, authority, privacy, and escalation. A useful agent needs the same detail a competent employee would need, plus explicit rules for situations where the detail runs out.
The same requirements problem appears in prompt engineering, with fewer consequences. A vague chatbot response wastes a minute. A vague agent can send the response, update the CRM, and close the ticket before anyone notices.
The second problem is the tool chain. Agents work through calendars, databases, APIs, browsers, and file systems. Authentication expires. Interfaces change. Rate limits appear. A field that accepted free text last week becomes a dropdown.
Model Context Protocol reduces some integration work by giving tools a common interface. It still leaves permissions, business rules, error handling, and the reliability of each underlying system to the team deploying the agent.
The third problem is judgment. Most workflows contain a routine center and an awkward edge. A refund under $20 may be automatic until the account shows three refund requests in a month. A calendar request may be easy until accepting it creates a travel problem the following morning.
Humans accumulate these exceptions through experience. An agent needs them expressed as rules, examples, tests, or escalation conditions.
Build the escalation path first⌗
A reliable deployment works like a queue with a good triage system.
Give the agent a narrow job. Define the normal path. Set limits on the actions it can take. Log every action. Route ambiguous cases to a person with enough context to decide quickly.
Suppose a support queue receives 100 routine billing requests a day. An agent that safely completes 60 and packages another 25 for quick review has removed a large amount of mechanical work. The remaining cases also reveal where the process lacks clear rules. A human still owns the exceptions, with far less routine sorting around them.
The percentage will vary by workflow. The operating design stays the same:
- Start with a repeated task whose inputs and outputs are visible.
- Write acceptance checks before giving the agent access.
- Limit permissions to the actions the task requires.
- Define the conditions that stop execution and request review.
- Measure completed work, correction time, and costly mistakes.
The planning discipline in Slow Is Smooth and Smooth Is Fast helps define the workflow. The verification discipline in If You Can’t Read the Diff, You Need a Better Test keeps the review surface small enough for a person to trust.
Measure labor saved and errors created⌗
“Fully autonomous” makes a good slide because it sounds like a clean replacement. Real workflows rarely have clean boundaries, and the last slice of exceptions can consume more effort than the routine majority.
A better scorecard asks how many useful tasks the agent completed, how long review took, how often work had to be corrected, and what damage a bad action could cause. Those numbers tell you whether the deployment earns its cost.
Agents already create value inside those constraints. They monitor predictable systems, transform data, prepare routine communications, and move information between tools. Each success depends on a human deciding where the lane ends.
The keynote skips that decision because guardrails make autonomy sound smaller. In production, those guardrails are the product. They turn an impressive loop into work you can leave running.