A system is an agent to the extent that it, rather than its author, decides what happens next. That is the distinction we find load-bearing, and everything below follows from it: once control is delegated at run time, the engineering problem stops being "is the output good" and becomes "what can this thing do, and what can it not undo".
The loop
Delegated control expresses itself as a loop. The agent assembles what it knows, reasons about it, selects an action, observes the consequence, and decides whether to continue.
- 01Input
- 02Context
- 03Reasoning
- 04Tool selection
- 05Action
- 06Observation
- 07Memory
- 08Next action
The stage that receives the least attention and causes the most trouble is the exit. An agent needs a stop condition it can actually evaluate - and "I think I am done" is not one. In practice a production loop terminates on a verified post-condition, a handover, a budget ceiling or an iteration limit, and the first of those is the only one that is not a failure.
Tool calling is an interface problem
Tools are the boundary between something that reasons probabilistically and something that has consequences. Most agent reliability problems that present as model problems are tool design problems: a schema that permits an ambiguous argument, a description that does not separate two similar tools, or an empty result reported as an error so the agent retries forever.
- Narrow beats generic. A tool with the business rules already applied keeps them in code, where they can be tested, instead of in a prompt, where they cannot.
- Idempotency is mandatory. Agents retry. A side-effecting tool without an intent-derived idempotency key will eventually produce two of something.
- Three result kinds, not two. Error, empty result and refusal have to be distinguishable, because only one of them should ever be retried.
- Descriptions are prompts. They are read at selection time and their wording changes behaviour. They belong under review like any other prompt.
Planning under a latency budget
Much of the published work on agent planning assumes the agent has time to think. Inside a phone call it does not: every planning step is audible. This constraint pushes us toward shallow plans with verified steps rather than deep plans executed optimistically, and toward doing the planning work in the tool layer where it can be precomputed.
The general version of the trade-off: reasoning depth buys correctness on hard cases and costs latency on every case, including the easy ones that dominate real traffic.
Memory
We model agent memory in three tiers with different lifetimes and different sharing rules - turn state, episode summary, durable facts - and enforce one rule above all: the agent has no private long-term store. Durable facts live in the system of record and are read through a tool, so that deletion has exactly one address.
Multi-agent systems
Multi-agent architectures are more often a symptom than a solution. Splitting a task across agents adds a communication channel with no schema, and the failure modes it introduces - inconsistent state, lost context at the boundary, cascading retries - are worse than the prompt-length problem it usually set out to fix.
Where it genuinely helps: when subtasks have different tool permissions, different data access or genuinely different latency budgets. Those are boundaries with a reason to exist. "The prompt got long" is not.
Human-in-the-loop
Approval gates should be rare by construction - reserved for irreversible or high-consequence actions, so that seeing one is itself information. A gate that fires on every action is clicked through inside a week, after which the system carries a recorded human decision nobody actually made.
Open questions
- How far does the narrow-tool principle scale before a catalogue of very specific tools becomes more brittle than a general one plus good instructions?
- Can an agent reliably assess its own uncertainty well enough to trigger escalation, or must escalation always be driven by structural signals from outside the model?
- What is a defensible stop condition for an open-ended task, as opposed to a budget ceiling dressed up as one?