Agents that finish the job

The gap between an agent demo and an agent in production is not intelligence. It is what happens on the unhappy path — when a tool returns an error, when the model picks the wrong tool, when a step half-succeeds and the agent confidently continues.

A task completed 70% of the way is not 70% valuable. If a human has to audit the whole output to find which 30% is wrong, you have added work rather than removed it. Reliability is the product.

Tools are an API for a careless caller

Design every tool assuming the caller will pass a plausible-but-wrong argument, because eventually it will. Three rules make a real difference:

• Narrow inputs. An enum of five statuses is better than a free-text status field. The model cannot invent an option that does not exist.
• Errors that teach. Invalid date: expected YYYY-MM-DD, got '12 March' lets the model self-correct. Error 400 produces a retry loop.
• Describe when not to use it. Tool descriptions are prompt real estate. Use only after the customer has confirmed the address prevents a whole class of mistakes.

One agent per job

A single agent handed twenty tools becomes indecisive. It picks plausibly rather than correctly, and its context fills with irrelevant schemas.

Splitting the work into specialists with typed handoffs improves accuracy and, more importantly, makes failures legible. A triage agent classifies, a retrieval agent gathers evidence, a drafting agent writes, a verification agent checks. When the output is wrong you know which stage produced it.

const result = await planner.run(request, {
  agents: {
    triage:   { tools: [classify, prioritise] },
    retrieve: { tools: [searchDocs, fetchHistory] },
    draft:    { tools: [composeReply] },
    verify:   { tools: [checkPolicy, checkTone] },
  },
  maxSteps: 12,
  onStep: (step) => trace.record(step),
});

Always bound the loop

Agents get stuck. They call the same tool with the same failing arguments, or oscillate between two states forever. Every loop needs a hard step cap, a wall-clock timeout and a token budget — and hitting any of them should escalate to a human, not fail silently.

Put humans where the risk is

Full autonomy is rarely the right target. The useful question is which actions are cheap to reverse and which are not.

• Reversible and low-value — drafting text, tagging, summarising. Let it run.
• Reversible but visible — sending an email, posting a comment. Run it, but log it and make undo obvious.
• Irreversible — taking payment, deleting records, sending money. Require explicit confirmation, every time.

This is not a limitation to be engineered away. A checkout agent that pauses for one tap before charging a card is more trustworthy, not less capable — and trust is what determines whether anyone uses it twice.

MCP as the tool boundary

The Model Context Protocol gives tools a standard shape, which matters more than it first appears. Define your catalogue, cart and checkout operations once as an MCP server and any compliant client can drive them — your own agent today, someone else's assistant later.

It also enforces a healthy boundary. Tools become a versioned, documented interface with its own tests, rather than functions that happen to live next to your prompt.

The short version

1. 1Narrow tool inputs and write errors the model can recover from.
2. 2Split into specialists with typed handoffs rather than one agent with everything.
3. 3Bound every loop with steps, time and tokens; escalate on limit.
4. 4Trace every step so failures are diagnosable.
5. 5Gate irreversible actions behind a human, permanently.