Key takeaways
- Scope the agent to a task with a checkable definition of done.
- Fewer, well-documented tools beat a large tool catalogue.
- Cap loops, spend and runtime before the first production run.
- Log every step. An unobservable agent cannot be debugged or trusted.
- Keep a human approval gate on anything that writes, pays or sends.
What separates an agent from a prompt
A prompt produces one output. An agent plans, calls tools, reads the results and decides what to do next until it believes the goal is met. That loop is the entire difference, and it is also the source of every new failure mode.
Because the loop is autonomous, small errors compound. A misread field in step two becomes a confidently wrong report in step nine. Good agent design is mostly about making each step verifiable rather than making the model smarter.
Tasks agents are genuinely good at
Research and synthesis across many sources, where the output is a summary a human will read and can sanity check. Inbox and ticket triage, where classification is checkable against a taxonomy. Data cleaning and enrichment, where the schema defines correctness.
Code migrations with a test suite attached are one of the strongest cases available, because the tests are an automatic oracle. Whenever an automatic oracle exists, agents perform far above their reputation.
The common thread is a cheap way to answer 'is this right?'. Without one, you are shipping unverified work at machine speed.
Where agents still fail
Long-horizon strategy, negotiation and anything requiring accountability to a person outside your company. The model can produce a plausible artefact, but nobody can confirm it before it causes damage.
Tasks with hidden state also break agents. If success depends on context living in someone's head or in a system the agent cannot query, expect confident nonsense.
Treat cost as a failure mode too. An unbounded loop on a large model can burn a month of budget in an afternoon.
Reference architecture
Five components: a goal specification, a tool layer, a memory store, a controller that runs the loop, and an observability layer. Keep them separate so each can be tested alone.
Write tool descriptions as if for a new colleague: what it does, what arguments mean, what it returns, and when not to use it. Most agent failures traced back to a tool description that was ambiguous rather than a model that was weak.
Give memory a shape. Unstructured conversation history degrades quickly. Store facts, decisions and artefacts in named fields the agent can query deliberately.
Guardrails that belong in every deployment
Hard caps on iterations, wall-clock time and token spend, enforced by the controller rather than requested in the prompt. Prompts are suggestions, code is a limit.
An allowlist for tools that mutate state, with human approval required for writes, payments, emails and deletions. Read-only agents can run freely, write-capable ones should not.
Structured output validation on every tool call. Reject and retry on schema violation rather than letting malformed data flow onwards.
Evaluation and observability
Keep a suite of 20 to 50 recorded tasks with known good outcomes and run it on every prompt, model or tool change. Score completion rate, step count, cost per task and human intervention rate.
Log the full trace of every run: plan, tool call, arguments, result, and the model's stated reason. When an agent misbehaves in production, the trace is the only thing that turns a mystery into a bug.
Review intervention logs weekly. The tasks where humans keep correcting the agent tell you exactly which tool or instruction to fix next.
Rolling out without losing trust
Start in shadow mode: the agent produces its answer, a human does the work as usual, and you compare. Two weeks of shadow data is worth more than any demo.
Move to suggest mode, where the agent drafts and a person approves with one click. Only after the approval rate is consistently high should any step run unattended.
Publish what the agent can and cannot do to everyone affected. Most internal resistance to automation comes from uncertainty about scope, not from the technology itself.
References
- [1] Anthropic engineering guidance on building effective agents — anthropic.com
- [2] OpenAI documentation on tool calling and structured outputs — platform.openai.com
Frequently asked questions
Do I need a framework to build an agent?
No. A loop, a tool dispatcher and structured logging in your existing language covers most needs. Frameworks help with tracing and multi-agent orchestration, not with correctness.
Are multi-agent systems better than one agent?
Usually not. Multiple agents add coordination failures. Split into several agents only when the sub-tasks need genuinely different tools or permissions.
How much do agents cost to run?
Budget per completed task rather than per token. A research task typically runs a few cents to a few dollars depending on model and depth, and caps should be enforced in code.
Can agents replace a team?
They replace steps, not responsibility. Every production deployment we have seen still has a named human owner for the outcome.