Agent demos look like workers. Reading documents, answering questions, taking actions. The natural assumption: point an agent at a task, it does the task.
These deployments usually fail.
The problem isn't capability. Agents are capable. The problem is that "do the task" assumes the task is defined well enough to be done. Usually it isn't. The task works when humans do it because humans fill in gaps that nobody wrote down.
Agents work better as translators. They sit between fuzzy human input and structured systems, converting one into the other.
The Translation Layer
A customer sends a support email. It's rambling, maybe emotional. It mixes multiple issues. It says "my order" without specifying which one, "the thing I talked to someone about" without dates or details. A human reader resolves these ambiguities without thinking about it.
The support system needs structure. Tickets have categories from a defined set. They have priority levels. They're linked to specific customers and orders. They move through states: open, in progress, waiting, resolved. You can't resolve without a resolution note. You can't escalate without a reason.
The fuzzy email has to become a structured ticket. Someone has to do that translation.
Before agents, humans did it. A support rep reads the email, figures out the actual issue, looks up the customer, creates a ticket with the right category and priority. The rep translates unstructured input into structured data.
Agents are good at this. They can read a rambling email and extract the issue. They can identify which customer, which order, what category. They can produce a structured ticket.
But the agent doesn't define what categories exist. It doesn't decide what states are valid. It maps fuzzy input onto structure that already exists. Multiple agents and humans all work from this shared structure. That's what makes consistent handling possible.
Why the Worker Model Fails
"We'll deploy an agent to handle support tickets." Handle them according to what rules? Route them to whom? What's the escalation path? What does "handle" mean?
If these questions don't have explicit answers—if they live in people's heads, in tribal knowledge—the agent can't do the job. The job isn't defined well enough to be done.
Human workers navigate this ambiguity. They absorb context through hallway conversations. They learn implicit rules by making mistakes and being corrected. They build mental models of how things actually work, distinct from how they're officially supposed to work. They fill gaps with judgment, and that judgment improves over time.
Agents can't do this reliably. They fill gaps with hallucination. They apply "judgment" without feedback loops. They do the wrong thing confidently.
The worker model assumes the job is defined well enough to be done. Often it isn't. The job works only because humans fill gaps that nobody documented.
The Interface Model
Think about the history of human-computer interaction.
Command lines let you interact with the operating system by typing precise commands. Powerful, but you need to know the commands, the syntax, the flags. The system is fully structured; the interface requires you to speak its language.
GUIs let you interact by clicking, dragging, pointing. You don't need to memorize commands. The interface shows you what's possible. But it's still the same system underneath—same operations, same constraints. The GUI just makes them visible and accessible.
Natural language interfaces—agents—let you interact by describing what you want. "Schedule a meeting with the design team next week." "Show me sales by region for Q3." The agent translates your request into operations the system supports.
This translation isn't limited to human commands. When an event arrives from another system, an agent can answer the question "what does this mean for my system?" Agents can be an interface between humans and machines, or between different machines.
Each layer makes the underlying system more accessible without changing what the system is. A GUI doesn't give the operating system new capabilities. It gives you new access to existing capabilities. Agents are the same.
This is why structure matters. The agent is a translation layer, but translation requires something to translate into. If the system has good structure—clear entities, defined operations, explicit constraints—the agent has something to work with. If the system is a mess of implicit knowledge and undocumented rules, the agent has nothing to map to.
An agent without structure operates in a void. It takes actions, but those actions aren't validated against any coherent model. Errors go undetected. Results vary unpredictably.
What Translation Actually Requires
The translation agents do is genuinely difficult.
Natural language is ambiguous. "My order" could refer to any of twelve orders. "The usual" assumes shared context the system doesn't have. "Something's wrong" could mean a hundred different things. The agent has to resolve these ambiguities correctly or route to a human when it can't.
Context matters enormously. "Cancel it" means different things in different conversations. The agent has to track context, know what "it" refers to, understand what operation makes sense given what came before.
Messy inputs are the norm. Typos, fragments, mixed languages, autocorrect errors, stream-of-consciousness requests. The agent has to extract meaning from noise. Humans do this unconsciously; it takes significant capability to do it at all.
The mapping is often non-obvious. A customer saying "I want my money back" might need a refund, or a billing correction, or an explanation of a charge they didn't recognize. The agent has to figure out which, and it's not always clear from the words alone.
Getting this translation right is valuable. A support rep doesn't need to learn the ticketing system's idiosyncrasies—they can focus on helping customers while the agent handles the system interface. A salesperson doesn't need to master the CRM's fifteen-click workflow—they describe what they need, and the agent translates.
But this value depends on having a system worth translating into.
What This Implies
If agents work as translators, the bottleneck shifts. The limiting factor isn't agent capability. It's whether the structure exists for agents to translate into.
Structure is expensive to build. Defining explicit entities, states, transitions, operations, constraints—this requires understanding the domain deeply. It requires making decisions that people have been avoiding. It requires writing things down that have been conveniently fuzzy.
Many organizations have operated for years on implicit structure. It works because humans fill the gaps. The weekly meeting where someone says "wait, I thought we were doing X"—that's a gap-filling mechanism. The senior person who reviews everything and catches mistakes—that's another one. The unofficial process that everyone knows but nobody documented—another one.
These mechanisms work, but they don't scale, and they don't transfer to agents. When you deploy an agent on a process held together by implicit knowledge, the agent exposes every gap. It does the wrong thing in exactly the places where a human would have known better—because those are the places where the structure is missing.
Before you can get value from agents, you need to do the structural work you've been avoiding. Define the entities. Enumerate the states. Specify the operations. Document the constraints. Make explicit what has been implicit.
This feels like a detour. You wanted to deploy agents; now you're doing process documentation. But it's not a detour. It's the prerequisite.
Where to Deploy Agents
The translation model gives you a heuristic:
High translation value, existing structure: Good fit. The system is already well-defined, but accessing it is cumbersome. CRM data entry. Expense report filing. Ticket triage. The agent makes an already-useful system more accessible.
High translation value, missing structure: Requires investment. The domain would benefit from automation, but the structure doesn't exist yet. This can be worth it—but recognize that you're building the structure, not just deploying an agent.
Low translation value, existing structure: Marginal fit. The system is well-defined, but the inputs are already structured. Maybe you're replacing a form with a chat interface—okay, but the gain is smaller.
Low translation value, missing structure: Bad fit. No point deploying an agent on a process that's neither well-structured nor suffering from a translation bottleneck.
The Opportunity
Agents don't just translate into existing structure. They shift constraints—making new structure economically viable.
Before agents, structure had to be accessed by humans who learned the system. This limited how much structure was worth building. If a workflow would only be used ten times a day, building an elaborate structured system for it didn't pay off. Better to have humans handle it flexibly.
Agents change this calculus. If natural language is the interface, you don't need to train humans on the system. You don't need to build elaborate GUIs. You define the structure, point an agent at it, and anyone can interact with it by describing what they need.
This makes structure viable in places it wasn't before. Workflows that were too low-volume to justify a formal system can now have one. Processes that were "too complex" to structure can be structured incrementally, with agents handling the translation.
The opportunity is to make structure accessible, so that more structure gets built, so that more processes become reliable and automated.
Get the structure right, and agents become genuinely powerful. Skip the structure, and you're asking a translator to speak a language that doesn't exist.
This essay is part of a series on building reliable AI agent systems.
Overview: The Structure Problem
Previous: What Happens Next
Next: Why Reliable Systems Look the Way They Do — Why structure enables reliability