What is different from the agents you know
Classic agent theory still holds; the parts just sit in different places. Each row is the same idea, relocated.
| Classic agent | Where it lives in an LLM agent |
|---|---|
| Autonomy | A permission setting in your harness, not a property of the thing. You choose per tool: read freely, write only after approval. |
| Persistence / state | Nowhere by default. The model forgets everything between calls. State is a file or a database your loop re-reads and re-injects each turn. |
| Goal / intention | A sentence in the prompt. No goal stack, no BDI machinery — only what you re-state every turn, so a long run drifts unless you restate it. |
| Perception | Whatever text you paste in, plus tool results. It sees nothing you did not hand it, and it cannot tell fresh data from stale. |
| Learning | Not in the loop. Weights are fixed at run time. "Learning" means you wrote something down and put it back in the context next time. |
| Coordination | No protocol, no shared blackboard, no negotiation. One agent calls another the way a function calls a function, and gets text back. |
| Reactive vs deliberative | Both come from the same model. The difference is only whether your loop lets it plan before acting. |
The parts
The shapes worth knowing
Ordered by cost and risk. Go down the list only when the one above genuinely fails; most jobs people call "agentic" are the first two.
| Shape | What it is | Reach for it when |
|---|---|---|
| Workflow | Fixed steps you wrote, model calls inside them. No decisions about control flow. | You already know the steps. Cheapest, most reliable, most of what ships. |
| Tool loop (ReAct) | Think, call a tool, look at the result, repeat. The model chooses the next move. | The path depends on what it finds. The default "agent". |
| Plan then execute | Write the whole plan first, then run the steps, replanning only on failure. | Long jobs where wandering is expensive. Gives you a plan to approve. |
| Reflection | A second pass critiques the first against stated criteria, then it revises once. | Quality matters more than latency. Cap it at one or two rounds; more drifts. |
| Router | A cheap call picks the specialist, model or tool, then hands off. | Mixed traffic with clearly different kinds of work. |
| Orchestrator + subagents | A parent splits the work, children run with their own context, parent merges. | Independent pieces, or you need isolation. See the last two sections. |
| Human in the loop | The agent proposes; a person confirms before anything lands. | Anything that writes, spends, sends or publishes. This is Command's shape. |
The everyday loop
Pick one unit of work. Assemble its context from scratch — instructions, the task, the few things it needs. Call the model; if it asks for a tool, run the tool and put the result back. Stop on an answer, a question, or a limit, then write the result somewhere durable and let a human look. Repeat with the next unit. That is the whole craft: the interesting engineering is in what you put in the context and where you stop, not in the model call.
Safe to try
These cannot damage anything, and they are how you build confidence before letting an agent near real work.
node _agents/runner.js --dry # lists what it would pick up, changes nothing
model: mock # a fake provider that answers from memory, no network, no key
--max 3 # at most three steps a tick, so a bad run stays small
sh _agents/run-tests.sh # 62 checks on a throwaway board and fake APIsThe general versions: a dry run that prints the plan, a mock model, a hard cap on steps and spend, and read-only tools. If a framework makes any of those four hard, that is a reason to distrust the framework.
Practice, start to finish
- Write the task as one step with a clear finish line, and say which model. You should be able to state, in one sentence, what "done" looks like.
- Run it against the mock provider. The step moves to "for review" with a fake answer — proving the plumbing, not the intelligence.
- Switch to a real model, one step only. Now you get a real answer, plus tokens, cost and elapsed time recorded on the step.
- Read the answer and the trace, not just the answer. Right answer by a wrong route means the next, slightly different task will fail.
- Send it back with a reason instead of fixing it yourself. The reason and the previous attempt go into the next context — that is the feedback loop.
- Only now let it run unattended, with the caps on. Cost per run and steps per tick should be numbers you know before you sleep.
When it goes wrong
| Symptom | What it really is | Way out |
|---|---|---|
| It loops forever | No stop condition it can reach; each turn re-reads its own last turn | Cap steps and tries. Make "I am stuck" a legal, rewarded answer. |
| Good at first, vague later | Context rot: distraction — it starts copying the shape of its own earlier turns instead of thinking | Shorter runs. Summarise and restart rather than appending forever. |
| Repeats a wrong fact | Context poisoning: one hallucination entered the context and is now cited as evidence at every step | Never let the model's own output back in as fact. Restart the context; do not patch it. |
| Confidently off-target | Context confusion: too much irrelevant material in the window | Put in less. Relevance beats volume; a bigger window does not fix it. |
| Tool call fails or mis-fires | The most common production failure, usually bad arguments or a changed interface | Hand the error text back as a normal result and let it try once. Validate arguments before executing. |
| Right answer, wrong work | It used last year's file, or guessed | Judge the trace, not the output. This is what evaluation is for. |
| It obeys a web page | Prompt injection — text it fetched contained instructions, and it followed them | Treat every tool result as data, never as instruction. Keep dangerous tools behind approval, so an injection has nothing to grab. |
| Bill is a surprise | Fan-out: retries, reflection and subagents multiply | Record cost per run from day one. Cap per task, not per month. |
Leave this alone: an agent with unattended write access to the only copy of something. Not because it is malicious, but because it is confident and quick. Any write it makes must be either reversible, backed up before the fact, or gated behind a human yes.
Where it runs: the sandbox
Gates decide what an agent may ask for. A sandbox decides what it can reach even if nothing stops it — the difference between a rule and a wall. Instructions are advice to a model that can be talked out of them; a wall is not. Four dials, from loosest to tightest:
| Dial | What you set | What it stops |
|---|---|---|
| Filesystem | One working directory it can read and write; everything else invisible or read-only | The confident rm in the wrong folder; reading credentials it was never meant to see |
| Network | Deny by default, allow named hosts | Data walking out, and a poisoned page calling home |
| Credentials | The child process gets a bare environment: no keys, no tokens, scoped to one job | A leaked key in an error message or an echoed request |
| Machine | A container or VM with a snapshot, thrown away after the run | Everything else, and it makes "undo" a single command |
The practical rule: the blast radius should be obvious before the run, not discovered after it. Unattended work belongs one level tighter than attended work, because nobody is watching the moment it goes wrong. Note the cost too — a real sandbox adds startup time, and cutting the network breaks the tools that need it, so most setups end up with a narrow allowlist rather than a wall.
Agents spawning agents
A subagent is not a new kind of thing. It is the same loop, started by another loop, with its own fresh context and its own tools. The parent sends a task; the child runs blind to everything it was not told; only the child's final answer comes back, as text, into the parent's context.
Why it helps
- Isolation. The child's 40 messy steps never enter the parent's window. Context rot is the real reason this pattern won, more than parallelism.
- Parallelism. Independent pieces run at once. Five searches in the time of one.
- Specialisation. Different instructions, tools, permissions or model per child — a cheap model for retrieval, a strong one for judgement.
- Independent verification. A child that has not seen the parent's reasoning is a genuine second opinion. A child that has seen it will agree with it.
What it costs
- Money and time multiply, roughly by the number of children, and each child re-reads its own instructions.
- The merge is the hard part. Children finish with contradictory answers and the parent must reconcile them with less information than either had.
- Debugging gets a dimension. A failure two levels down arrives as one flat sentence of text.
- Errors propagate as confidence. A child's guess arrives at the parent stripped of hedging and gets treated as a finding.
Utility agents: the other reason to have two
Not every second agent is a worker splitting a task. A utility agent runs beside the task agent and does one job on its behalf. The clearest current example is a proactive memory agent: instead of the worker deciding when to search its own notes, a separate agent watches the run and pushes the fact forward when it becomes relevant. Reported gain on Terminal-Bench 2.0 with Sonnet 4.5: 37.6% to 45.9%, with no retraining — a pattern change, not a model change. The same shape fits a critic, a budget watcher, or a safety check. What makes it work is that the second agent has a different job and a different context, so it notices what the first one is too deep in to see.
Rules that keep it sane
| Rule | Why |
|---|---|
| Depth two, hard | Parent and children. Grandchildren make cost and blame untraceable. Children may not spawn. |
| Written contract per child | One objective, the inputs, the shape of the answer, the tools allowed. If you cannot write it, do not delegate it. |
| Pass the budget down | Every child gets a share of steps, tokens and time. Unbudgeted children are how a run costs 50×. |
| Children return data, not orders | The parent treats a child's answer as a claim to weigh, exactly like a tool result. Otherwise one poisoned child steers the whole run. |
| Parent owns every side effect | Children read, think and report. Writes, sends and spends happen once, at the top, where the human gate is. |
| Make them independent | If child B needs child A's output, they are not parallel — that is a workflow, and a plain sequence is cheaper and clearer. |
When it is not worth it: a task under a few steps, anything sequential, or anything where merging costs more thought than doing it yourself. The honest default is one agent, small steps, until you can point at the specific window or wall-clock problem a fan-out solves.
The atom
The unit of agent work is one step: one objective, one context, one result. Not a conversation, not a session, not a project. Everything good about an agent system comes from getting that unit small and well-shaped, because the unit is what you retry, parallelise, review, price and blame.
| Property | Meaning | What it buys |
|---|---|---|
| Bounded | One finish line, plus caps on steps, tokens and time | A bad run is cheap. You can say no to it early. |
| Self-contained | Its context is assembled from durable state, not from whatever happened to be in the window | It runs the same tomorrow, on another machine, after a crash. |
| Re-runnable | Running it twice is harmless, or is explicitly gated so it cannot be | Retry becomes a non-event instead of a risk. |
| Observable | It produces a result you can read and a trace you can replay | You can judge the work, not just the wording. |
| Gated | Its side effects are reversible or need a yes | Autonomy becomes a dial you turn per step, not a leap of faith. |
Compose atoms; do not grow them. A big job is a list of small steps with a review between, not one long-running agent with a big goal — the long run is where drift, cost and unreviewable output all come from. This is also the honest answer to "how autonomous should it be": as autonomous as one atom, then a human or a parent decides again.
Where this lands in Command
| Concept | In Command |
|---|---|
| The atom | A checklist step on a card — one objective, its own instructions, its own result |
| Permission | actor (human, agent or both) and approved, decided before anything runs |
| Budget and retries | agent_tries, three then it waits for you; steps per tick; a timeout per call |
| Result and trace | result, plus agent_run with model, provider, tokens, cost and elapsed time |
| The human gate | Every finished step lands in "for review". Send back with a reason, and the reason becomes the next context |
| The door to real agents | The command driver: any program that takes a step as JSON and returns an answer — LangGraph, an Agent SDK script, a shell script |
Words you will see
The landscape, in one line each
LangGraph — your agent as a graph of steps with explicit state; good when you want the control flow visible and resumable. Claude Agent SDK — the loop, tools and permissions already built, close to how Claude Code itself works. OpenAI Agents SDK — the production replacement for the archived Swarm; handoffs and guardrails as first-class parts. Microsoft Agent Framework — Semantic Kernel and AutoGen merged into one runtime. Memory layers (Mem0, Letta, Zep) — storage for what should survive between runs. Anthropic's own guidance, and the honest consensus: use the simplest composable pattern that works, and add a framework only when you can name what it saves you.
Deliberately not here
Fine-tuning and RL for agents — you will not train a model before you have traces worth training on. Vector-database choice, chunking and retrieval tuning — that is its own primer, and most agents need less retrieval than people assume. Framework APIs — they change faster than this page. Multi-agent negotiation, auctions and emergence — the classic literature you already know, which LLM agents do not currently implement. Benchmarks and leaderboards — they measure what is easy to measure; your own eval set on your own work is worth more than all of them.
AI agents · primer, four pages · September 20, 2026 · Written for Rich Price, with examples from Command 1.5's runner.