Building AI agents that can act, without giving them more rope than you meant to
An agent is a model that can do things, not just say things. That single change moves every design question from "is the answer good" to "what happens when it is wrong and it already acted".
By Quality AboveAll · · 9 min read
- Scope tools narrowly and enforce permissions in your application, never in the prompt.
- Separate reads from writes, and require confirmation for anything irreversible, financial or externally visible.
- Most agent failures are recovery failures: a tool call fails mid-sequence and the agent proceeds on missing data.
What makes it an agent
The distinguishing feature is the loop: the model plans, calls a tool, observes the result, and decides what to do next, repeating until the task is done. That autonomy is the value, because it handles the variation a fixed workflow cannot.
It is also the risk. A chatbot that is wrong produces a bad sentence; an agent that is wrong produces a bad sequence of actions against real systems, and it may take several steps before anyone notices. Design accordingly.
Scope the tools, not the intentions
Each tool the agent can call should do one narrow thing with a clearly typed interface, and its permissions must be enforced in your application against the acting user's identity. An agent calling with service-level credentials becomes a privilege escalation path regardless of how carefully it was prompted.
Resist the temptation to expose a general-purpose capability like arbitrary database queries. Narrow tools are easier to reason about, easier to test, easier to audit, and they bound what a mistaken plan can accomplish. This is the guardrails principle at the action layer.
Give an agent a query tool and you have given it every capability that query language has, including the ones you did not think about.
Reads, writes and approval gates
Reading is cheap to get wrong and easy to recover from. Writing is not. Separate them explicitly, allow read tools freely within the user's permissions, and put a confirmation step in front of anything that spends money, contacts a customer, or cannot be undone.
Where full autonomy is genuinely wanted, constrain it with limits the application enforces: maximum spend, maximum actions per run, allowed recipients, reversibility windows. Autonomy inside a fence is a product; autonomy without one is an incident waiting for a trigger.
Multi-step state and recovery
The failure mode we see most is an agent proceeding after a tool call returned nothing useful, treating absence as an answer and building subsequent steps on it. Every tool result needs explicit handling for empty, error and timeout, and the agent's instructions must define what to do in each case.
Test this deliberately by injecting failures mid-sequence, because production will. An agent that handles the happy path and collapses on a timeout has been demonstrated rather than tested, a point we make at length in testing AI agents and MCP servers.
Observability and the standard interface
Log the full trace: the plan, each tool call with arguments, each result, and the final outcome. Without that, debugging an agent is guesswork, and with it, most failures are obvious within a minute of reading the trace.
Standardising how tools are exposed helps considerably, which is what the Model Context Protocol addresses, covered in our MCP explainer. Multi-agent structures add coordination concerns on top, which we cover in multi-agent architecture.
Frequently asked questions
When is an agent the right architecture?
When the task genuinely varies step to step and a fixed workflow would need endless branches. If the sequence is predictable, ordinary software is cheaper, faster and more reliable.
How much autonomy should an agent have?
As much as the reversibility of its actions justifies. Free rein over reads, gated writes, and hard application-enforced limits on anything financial or externally visible.
What is the most common cause of agent failure in production?
Poor handling of failed or empty tool results. The agent continues as though it received an answer, and the error compounds across subsequent steps.
Considering an agent that will touch real systems? A free 30-minute consultation will map the tool permissions and approval gates before anything is built.
