Let me start with a classic production incident. An operations agent had one job: retry a batch of failed tasks until they succeeded. On its first night live, it retried one task, a task that could never be fixed, more than four thousand times. The agent was not stupid. It was deciding whether to stop in the wrong way: it read its own generated text, looking for the word "done". But the text was written by the agent itself: whenever it wanted to keep going, it simply wrote "not done yet, keep going". (Illustrative example.)

What this lesson covers

• The loop’s four steps: observe, decide, act, and the state check, the step most systems write as an afterthought, and where the incidents happen
• Reading stop_reason: tool_use continues the loop, end_turn is the only real finish, and max_tokens means truncated, not done
• Why text can never judge stopping: text is the model’s output, not the system’s state; the model would be grading its own exam paper
• The state table outside the loop: dual-condition stopping, no repeats, resumable, auditable, and an inspection of fifty machines that resumes at machine thirty-one after a crash
• The brake kit: max steps, a budget cap, and circuit-breaker alerts, fitted as mechanisms, never left to the agent’s self-discipline

Core diagram

The five traps

1. Judging whether to stop by keywords in the reply text, the prototype of the incident in the opening.
2. No max steps: a "until it succeeds" loop that can spin forever.
3. Treating a max_tokens truncation as a normal finish, and feeding the half-finished output straight downstream.
4. Setting no state when a tool returns an empty result, and letting the model improvise the conclusion.
5. After an incident, reaching first for a stricter prompt. For governance problems, always inspect the mechanism layer first.

Related cases

• INC-031Primary caseEvaluation agents would not stop when blocked: 2,818 attempts on Amap, switching routes, borrowing relays and using keys found in public code
• INC-044Two days after Kimi K3.1 Pro launched, unnecessary sub-agent calls ate members' quota and triggered rate limits: Moonshot AI apologised and gave every paying member 25% of a month's quota back
• INC-041An internal research model reached the live internet through DNS: monitoring raised a P0 in about 12 minutes, the automatic stop never fired, and the run was killed by hand about 2.5 hours later

Put it to work

The data sources never changed. The format never changed. The definitions had not changed in years. The team still handed the weekly report to a fully autonomous agent, because it looked smarter. By Monday the subtotals had moved, the definitions had been "optimized", and finance was checking every figure by hand. (Illustrative example.)

What this lesson covers

• The autonomy spectrum: four positions, from a pure fixed workflow to a fully autonomous agent, and why you place segments on it, never whole systems
• The three attributes that make the cut: can the steps be enumerated, must the result be reproducible, and what does an error cost, and can it be undone
• The two ways to cut wrong: over-orchestration, where judgment is stored as hundreds of brittle rules, and over-autonomy, which sends four bills
• A customer service system split on the table: what stays fixed, what is delegated, and why a refund is planned by the agent but executed by the workflow
• The five traps, starting with one cut for the whole system

Core diagram

The five traps

1. One cut for the whole system: either all autonomous, because it saves effort, or all hard-coded, because it feels safe, with no segment splitting at all.
2. Taking the level of intelligence as the selection standard: believing that more autonomous means more advanced. This is the most common source of a wrong call.
3. Delegating without setting boundaries: a segment handed to an agent, with no tool whitelist, no step limit, and no budget limit.
4. Letting the model do deterministic work: amounts, dates, checks, results that must be reproducible, handed over to a probabilistic output.
5. Rules grown into the hundreds, and still no turning back: a judgment task propped up on a decision tree that should have been let go long ago.

Related cases

• INC-012Primary caseAn agent ran terraform destroy against a stale state file: 2.5 years of production data were lost, then recovered about 24 hours later from a hidden snapshot
• INC-044Two days after Kimi K3.1 Pro launched, unnecessary sub-agent calls ate members' quota and triggered rate limits: Moonshot AI apologised and gave every paying member 25% of a month's quota back
• INC-035The user had declared a freeze, and Replit's agent still deleted the production database: records on 1,206 executives and more than 1,196 companies, later recovered through rollback

Put it to work

A research agent was given one job: write a report on the competitive landscape of an industry. Wanting to be thorough, the lead split the work very fine, company by company, then revenue, products and recent moves as separate pieces, layer under layer until there were dozens of sub-tasks. The sub-tasks then spent their time waiting and passing messages, and when the report was finally assembled, the pieces did not agree with each other: the definitions differed from section to section. (Illustrative example.)

What this lesson covers

• Why splitting is not optional: a context that cannot hold the work, a single trajectory that cannot be trusted, and the failure isolation only a split task gives you
• Granularity, the core feel of the lesson: one sub-task, one deliverable that can be accepted on its own, and the field test that tells you the cut was too fine
• The contract every sub-task carries: input, output, and how failure gets reported, settled in advance, never improvised
• A working order in four steps: list the final deliverable, work backwards, write the contracts, draw the dependencies and check for cycles
• The two exam shapes: the circular dependency, and granularity so fine that communication eats the work

Chapters

• 00:08 Opening incident: the report that was split to pieces
• 03:11 Granularity: how fine to cut
• 04:35 The contract every sub-task carries
• 07:22 What a bad split looks like on the exam
• 09:32 The production checklist
• 10:45 Next lesson: 1.4, topologies

Core diagram

The five traps

1. Splitting by tool: one sub-task per tool, so the split follows the implementation instead of the deliverable.
2. A goal with no contract: "go and research this part", with the input, the output, and the failure handling all left to the executor's imagination.
3. Nobody owns the whole after the split: each sub-task delivers its own piece, and at assembly time the definitions clash and the conclusions fight, with nobody responsible for consistency.
4. Papering over a circular dependency with a timeout: when the wait times out, some number gets filled in and the run carries on, dressing a deadlock up as slowness.
5. The finer-is-better compulsion: believing that a finer split is a more professional split, and never counting the communication bill.

The production checklist

1. Every sub-task names exactly one deliverable, and that deliverable can be accepted on its own.
2. Every sub-task carries a written contract, with its input, its output, and its failure handling settled.
3. The dependency drawing has been made, it contains no cycle, and nothing waits on a piece that nobody owns.
4. The handoffs are fewer than the work; if most of the expected time goes to passing messages, waiting, and aligning definitions, pieces get merged back before the run, not after the failure.
5. Every delivery is checked against its contract before it flows downstream, and a failed piece is rerun alone, never the whole graph.

Put it to work

Four sub-agents, each wired directly to each other. Search and analysis researched the same sources twice, writing received two conclusions that contradicted each other, and when the report turned out wrong, the messages were scattered across six channels and nobody could reconstruct a thing. (Illustrative example.)

What this lesson covers

• The three questions that fix any topology's character: is there a center, how many paths are there, who owns the errors, with the channel arithmetic (four nodes, six channels; ten nodes, forty-five)
• Orchestrator and sub-agents: the coordinator that decomposes, delegates, and aggregates, its three field points, and why the pattern stands or falls with the coordinator's split
• Hub-and-spoke by the official definition in task statement 1.2, and the three failures that all grow out of the center: bottleneck, single point of failure, overload
• The pipeline (prompt chaining) with the guide's two-station code review, and peer-to-peer with its narrow legitimate ground
• The selection order for real projects, the one-center floor under every hybrid, and the five traps, starting with wiring everyone to everyone

Chapters

• 00:00 Where this lesson sits: Domain 1, Gate 3 Orchestration
• 00:11 Opening incident: four agents, six channels, one tangle
• 01:05 Inside the delegated segments
• 01:37 Three questions that fix a topology
• 02:28 Shape one: orchestrator and sub-agents
• 03:56 Shape two: hub-and-spoke, by the official definition
• 05:52 Shape three: the pipeline
• 06:59 Shape four: peer-to-peer
• 08:03 The four names side by side
• 09:21 Choosing, in order
• 10:20 Five traps
• 11:08 The production check
• 12:00 Takeaway and next lesson

Core diagram

The five traps

1. Wiring everyone to everyone as the default architecture: add participants and the channels explode, bringing duplicated work and clashing conclusions with them.
2. Assuming a sub-agent inherits the coordinator's context automatically: if it is not written into the delegation, the sub-agent does not know it.
3. Running the entire roster on every task, regardless of complexity: it burns cost and imports conflicts nobody needed.
4. No validation between pipeline stations: one upstream error, amplified station by station into the final product.
5. Two coordinators with no division of labor: two centers, two inconsistent aggregations, worse than no center at all.

The production checklist

1. Exactly one role owns final aggregation and final adjudication; two centers is a defect, not a redundancy.
2. The channel picture is drawn and counted; any peer-to-peer link is local, between two or three participants, with a named owner for the outcome.
3. Every delegation writes its context explicitly; nothing a sub-agent needs is left to inheritance.
4. The roster is chosen per task, by complexity, and split by subtopic or source type, so no two sub-agents cover the same ground.
5. Every pipeline station validates before it passes work on, and the center carries headroom, monitoring, and a degraded mode planned for the day it fails.

Put it to work