|
 |
Nine Practical Rules for Agents Doing Real Work
In recent conversations with crews building agents, I keep hearing the same lessons. Teams with very different products are arriving independently at almost the same architectural choices. That convergence feels important. In recent posts, I argued that passing your evals does not mean an AI system is safe, and that many of the most consequential risks sit outside the model itself. This is the constructive follow-up: once an agent is doing real work, what should you actually build around it? I think a practical architecture playbook is beginning to emerge.
1. Put hard constraints in software, not prompts
Models are good at flexible reasoning. Ordinary software is good at state, permissions, calculations, retries, and predictable control flow. Reliable systems keep that division explicit rather than asking a prompt to guarantee something important. A prompt is guidance. It stays negotiable no matter how firmly you word it, which is fine for judgment calls and a real problem for anything that can’t be wrong.
The dividing line is simple: let the model handle ambiguity, which is where it creates value. Put calculations in trusted code, enforce permissions through policy systems, validate code with compilers and tests, and check important factual claims against authoritative sources. Ask what the model can currently violate that ordinary software could prevent. When a failure would create a material consequence, the architecture should make that violation impossible or require explicit approval.
 |
2. Give the agent only as much autonomy as the job needs
One pattern I keep seeing is teams giving agents more autonomy than the job requires. That excess autonomy creates more possible paths, more opportunities for error, higher operating costs, and a harder governance problem. For many applications, conventional software should control the workflow while the model handles the smaller number of steps that genuinely require judgment. Greater autonomy can be justified when the task requires exploration, open-ended planning, or creating new tools.
I would treat autonomy as a deliberate design choice rather than a default. Start with a flexible workflow, observe which paths repeat reliably, and turn those stable paths into ordinary code. List every point where the agent chooses its next action, then ask which of those choices the task truly requires. A mature agent faces fewer open-ended choices over time, not more.
3. Build the agent around the domain’s trusted process
A support workflow already specifies how to triage a request, what information to collect, when to escalate, and which actions require approval. A medical workflow does the same through diagnostic protocols. When a domain already has a proven checklist, protocol, or decision process, use that as the agent’s structure rather than starting with a generic loop that tells the model to make a plan and keep acting until it is done.
This makes the system more reliable because the structure has already been tested by the field. It also makes the system easier to understand for the people who have to trust it and sign off on it. The best agent architecture often looks less like a general-purpose digital employee and more like the field’s existing best practice made executable.
4. Design for recovery, not a flawless first pass
Small errors compound quickly in long workflows. A system that succeeds 95 percent of the time at each step has only about a 60 percent chance of completing ten independent steps without an error. That helps explain why a three-step demo can look extraordinary while a longer business process falls apart.
Do not build around the assumption that the model will stop making mistakes. Add checkpoints, checks that confirm each action produced the intended result, retries, reversible actions, and the ability to resume from a known-good state. Measure recovery separately from first-attempt accuracy. A system that detects drift and corrects itself is more useful than one that looks perfect until the first unexpected tool response.
 |
5. Evaluate the model and harness as one system
What exactly are you evaluating when you test an agent? The harness is the software su