AI Agents — Frequently Asked Questions

Whether to build one#

What actually makes something an agent?#

It decides what to do next. A pipeline that calls a model at step three is not an agent; a system that chooses which tool to call, in what order, and when to stop, is.

That single property is the source of both the capability and every operational problem below.

When is a plain workflow the better answer?#

Whenever the steps are known in advance. If you can draw the flowchart, build the flowchart — it is cheaper to run, produces the same result every time, fails in ways you can read, and can be tested with ordinary tests.

Agents earn their cost when the path genuinely varies with the input: triage across messy cases, investigation, tasks where the next step depends on what the last one returned.

Why do agent demos work and agent deployments stall?#

A demo is one path through a happy case with a human watching. A deployment is thousands of runs where tools time out, input is ambiguous, a page returns something unexpected, and nobody is watching at 03:00. The gap is not model quality — it is bounded autonomy, error handling, spend control and observability, none of which are visible in a demo.

Tools and safety#

How should we decide which tools an agent gets?#

Sort every candidate tool by reversibility and blast radius, not by usefulness. Reading is nearly free. Writing to a scratch space is cheap. Sending a message to a customer, moving money, deleting data or changing infrastructure are different in kind, not degree.

Grant the reversible ones freely, put a human in front of the irreversible ones, and give the agent the narrowest version of each tool that still does the job. "Run any query" and "run this one parameterised query" are not the same tool.

What is prompt injection in an agent context, and why is it worse?#

An agent reads content — pages, documents, tickets, tool output — and that content can contain instructions written for it. In a chatbot, the damage is a bad answer. In an agent holding tools, the damage is an action.

The dangerous combination is three things at once: it reads untrusted content, it holds a tool with real effect, and it acts without confirmation. Break any one of the three. Mitigation through cleverer prompting is not reliable, because the attacker also gets to write text.

Does the agent need its own credentials?#

Yes, its own — never a shared or human user's. Scope them to exactly what the tool inventory requires, make them revocable in one action, and log every use. When something goes wrong you want to answer "what did the agent touch" without reconstructing it from three systems.

Controlling cost and loops#

How do we stop an agent burning money?#

Hard caps enforced outside the agent. Per task and per day, in the layer that runs it, not in its instructions. An agent can reason its way past its own guidance; it cannot reason past a supervisor that refuses the next call.

Add step limits, a wall-clock limit, and loop detection: identical action repeated, tool error repeated, no measurable progress. Then test that the cap actually stops it — an untested cap is a comment.

Why do agents loop?#

Usually because success is undefined. Given no clear stopping condition, "try again differently" is always an available next step and often the highest-scoring one. Define what done looks like, in a form the agent can check, and give it a way to conclude that the task cannot be completed.

Being able to give up is a feature. Without it, failure and infinite retry are the same state.

Multi-agent systems#

Do we need multiple agents?#

Rarely at first. Multi-agent designs are attractive on a whiteboard because they mirror how teams work, and expensive in production because each hand-off loses context, multiplies cost, and adds a place for the task to be quietly misunderstood.

Start with one agent and good tools. Split when you have a concrete reason — genuinely parallel work, or a step that needs different permissions, a different model, or isolation.

What breaks first in a multi-agent system?#

Context. Agent A knows why it asked; agent B receives only what was passed. Errors compound silently, because B does its best with a garbled instruction rather than refusing it.

If you do split, make the interface between agents explicit and structured, and log both sides of every hand-off. A free-text hand-off is an untyped API.

Running and evaluating#

How do you test something that never runs the same way twice?#

Test the boundary, not the transcript. Fix a set of representative tasks and measure outcomes: did it reach a correct end state, how many steps, what did it cost, did it stop when it should.

Then test the failure paths deliberately — tool returns an error, input is ambiguous, content tells it to do something else, spend cap is reached. Those four cases cover most real incidents, and none of them appear in a happy-path test.

What should we log?#

Every tool call with its arguments and result, the decision trace, cost per task, and the reason for stopping. The standard to hold yourself to: could you reconstruct, from logs alone, why the agent did something surprising three days ago? If not, the observability work is not finished.

How much autonomy should a new agent start with?#

Less than you think, with a written condition for increasing it. Start with suggestions a human approves, watch a few hundred real runs, and move up only when the failure modes are known and bounded. Autonomy granted before the failures are understood is not a capability, it is an untested assumption running unattended.

When should an agent be retired?#

When the path stops varying. Successful agents often reveal that the real work follows two or three patterns — at which point a workflow does the job more cheaply and more predictably. Noticing that is a good outcome, not a failure.

Back to AI Agents