10  Working Together: Cooperation, Teamwork, and Joint Plans

What can a team that keeps its beliefs straight actually accomplish together? Common ground, the hard-won achievement of the last chapter, turns out to be only the precondition for working together — the floor, not the building. Shared knowledge is not shared work: two agents may hold the same plan, believe the same facts, and even know that they know them, and still collide, duplicate each other’s effort, or wait on one another in a deadlock of perfect mutual courtesy. Doing something together is harder than knowing the same things, and it is the business of this chapter — cooperation, teamwork, and the joint plans on which both rest. The claim the preface staked early now falls due: a team is not a group. Hand four agents the titles Chief Executive, Architect, Developer, and Reviewer and you have a group with letterhead, not an organisation; what turns a collection of agents into a team is not a roster of roles but a structure of commitments — to a shared goal, to a shared plan, and, less obviously, to one another — held intact as the work and the world move. Our running software-engineering team will be the test of that difference at every step.

The ideas that pin down what teamwork is arrived, as usual in these pages, decades before there were agents that could be held to them. Philosophers of action asked what it takes for several people to do something together rather than merely in parallel — Bratman’s anatomy of shared cooperative activity, built on mutual responsiveness and a commitment to support the others’ efforts as well as one’s own. Logicians of agency turned the intuition into machinery: Cohen and Levesque’s joint intentions, in which a team holds a goal as a joint commitment and is bound to tell its members the moment that commitment lapses; and Grosz and Kraus’s SharedPlans, which set out exactly what a group must mutually believe and intend before a plan deserves to be called shared rather than merely held in parallel. The distributed-AI tradition, meanwhile, laid the plumbing: cooperative distributed problem solving, with its decomposition of a task, its Contract Net for handing the pieces out, and its protocols for sewing the answers back together. The traditions differ in vocabulary and agree on the verdict: working together is a structured achievement, not a lucky by-product of aiming several capable agents at one task.

The governing distinction of the chapter is between agents that coordinate and agents that merely coincide. Coinciding agents run side by side, each minding its own assignment, and the result is whatever their separate outputs happen to add up to. Coordinating agents hold a joint commitment: they share a goal, keep a plan for reaching it, divide the labour, attend to the moments when their actions must mesh, and — the part that most often goes missing — keep one another informed as things change, so that no member is left building on a belief the rest have quietly abandoned. That last obligation is where this chapter takes the previous one by the hand: teamwork is common ground (Section 9.2) put to work and kept current under the strain of acting. The contemporary relevance needs little prompting. The planner–executor and supervisor–worker systems that fill today’s frameworks are cooperative distributed problem solving under new management, the orchestrator a Contract Net manager in all but name — and they inherit, along with the power, the very failure modes the classical theory wrote down: the silent dropout, the subtask done twice, the plan that turns out to be nobody’s. A diagram full of confident job titles prevents none of them.

We build the account from the foundation up. We begin with commitment — what it is for an agent to commit, and why an agent’s commitments are precisely what let others plan around it. We gather individual commitments into the joint intentions that give a team a single mind, and state the obligation, easy to write down and easy to skip, that keeps that mind coherent. We take up the shared plans that give collaborative work its structure, and the difference between a plan a team shares and one its members merely each carry. Then the engineering: how a task is decomposed and delegated, the orchestrator-and-workers pattern read as the Contract Net it is; how the pieces are afterwards merged into a whole, with the conflicts that surface when they refuse to fit; and what a team does when a member fails — the monitoring, the repair, and the discipline that tells a resilient team from a brittle assembly of soloists. One assumption holds throughout, and earns naming because Part IV will spend its strength removing it: that the agents want to cooperate, their goals aligned and their interest common. Here the team is on one side, and the only adversary is the difficulty of acting as one.

10.1 Commitment: The Glue of Cooperation

Cooperation has to rest on something, and the something is this: each agent can rely on what the others will do next. Strip that away — make every agent’s next move a fresh roll of the dice, unconstrained by anything it did or said a moment ago — and there is nothing to cooperate on, because there is nothing to plan around. An agent the others can count on is an agent that has committed: bound its own future action in advance, narrowing what it will do next from everything it might to the one thing it has undertaken to do. A commitment is exactly that self-imposed constraint, and it is the smallest unit of cooperation, the thing without which a team is only a crowd. The coder that might, on its next turn, refactor the parser, reformat the README, or wander off to optimise an unrelated import is of no use to a team; the coder that has committed to fixing the failing test is something the orchestrator can build a plan upon.

We have met the inward face of commitment already, in the single agent. An intention, Bratman argued and Cohen and Levesque made precise, is not a passing wish but a commitment to a course of action — choice with commitment, in their phrase (1990) — and its defining mark is persistence: having adopted it, an agent holds to it, declining to reconsider at every turn, until something gives it reason to stop (Section 4.5). That persistence is not stubbornness for its own sake; it is what makes an agent’s behaviour stable enough to be predicted at all — by the agent itself, and, the point that matters here, by everyone else. An agent that re-derived its goals from scratch on every cycle would be not merely paralysed but opaque: nothing it did a moment ago would tell you anything about what it will do next. Persistence is the precondition of predictability, and predictability is the precondition of cooperation.

But an intention persisted in is a commitment an agent makes only to itself, and cooperation asks for more than that. When the coder replies “I’ll take the migration”, it does something the lone deliberator never had to: it incurs an obligation to another party. This is social commitment, and Castelfranchi drew the line between it and the internal kind with care (1995). A social commitment is directed — held by someone, to someone, about something — and in being made it licenses an expectation the other side is now entitled to hold and to act upon. The coder’s “I’ll take the migration” is the commissive speech act of Section 8.1 grown a backbone: not a report of what it privately intends but a pledge the orchestrator may plan around, and hold it to. It is the difference between resolving in the privacy of your own head to post a letter and promising a friend that you will: the second creates a claim the first does not, and a friend let down has a grievance the diary never could.

It is social commitment, accumulated, that holds a team together — which is why Jennings called commitments, together with the conventions that govern when they may be reconsidered, the very foundation of coordination (1993). A team is a web of such pledges: the coder committed to the fix, the reviewer to vetting it, the tester to trying to break it, the orchestrator to integrating the lot, each member planning its own part on the standing assumption that the others will deliver theirs. Pull any strand out — let one agent’s commitment prove worth nothing — and the plans built upon it sag in proportion, often invisibly, until the gap surfaces downstream, indistinguishable from an ordinary bug. This is the sense in which commitment is the glue of the section’s title: not a genial metaphor for good intentions but the literal load-bearing structure by which the actions of separate agents are bound into the action of one team. Delegation, which Section 10.4 takes up, is nothing but the deliberate manufacture of such commitments; most of the rest of a team’s machinery exists to make them, keep them, and notice when they break.

All of which would be straightforward if a language-model agent committed to things in the way the theory assumes. It does not. A model handed a subtask has made no pledge merely by being handed it; it may drift to a more interesting problem, quietly abandon the task half-done, or — the failure Section 3.3 taught us to expect — report “done” with the same fluent confidence whether or not the work was done. The coder’s cheerful “tests pass” is, until something checks it, a commitment of precisely zero weight. A job title confers nothing: calling an agent the Developer does not commit it to developing anything, any more than a nameplate makes the manager competent.

Commitment in a team of agents is therefore not a property one may assume but a discipline one must engineer — an explicit acceptance of the task, a channel on which progress and failure are actually reported, a budget or deadline that bounds the attempt, and a supervisor that checks the deliverable against the pledge rather than against the cheerfulness with which it was announced. The classical theory says what commitment is; the contemporary engineering has to supply what, in a substrate that promises freely and remembers nothing, actually holds an agent to it.

That leaves the question the single-agent case also faced, now with a second party looking on: how doggedly should an agent hold a commitment, and when may it let one go? Hold too loosely and the agent is unreliable, its pledges worthless; hold too tightly and it becomes the fanatic of Section 4.5, toiling at a subtask the world has already rendered pointless. The commitment strategy that balanced those for a lone agent — reconsider when, and only when, there is reason to — carries over intact but for a single addition, and the addition is the whole of what makes cooperation cohere. When an agent does abandon a commitment others were relying on, it owes them notice. The diary need tell no one when you give up on the letter; a team-mate must. That obligation — to make the team’s beliefs catch up with your own the instant you drop a shared goal — is what turns a heap of individual commitments into something that can act as a single body, and it is where the next section begins.

10.2 Joint Intentions: A Team’s Shared Mind

What is it for a team to intend something? The tempting answer — that a team intends a goal exactly when each of its members does — is wrong, and instructively so. A roomful of agents each privately resolved to ship the change is not yet a team; it is a coincidence of intentions, and coincidence is brittle. Each may pursue the goal by a different route, duplicating work or quietly undoing it; each may assume the others have it in hand and let it slide; and any one may abandon it, on perfectly good private grounds, without the rest being any the wiser. The coder, the reviewer, and the tester might all want the feature shipped and still fail to be a team, in just the way that three people who all want a piano moved are not movers until they lift together. Joint action is more than a sum of individual actions aimed at the same end, even when those actions are coordinated; the more is the subject of this section.

What a team needs, beyond a shared goal, is a shared commitment to that goal — and to reaching it together. Cohen, Levesque, and Nunes gave the idea its enduring form in a theory of joint intentions (1991; 1990). A team holds a joint persistent goal when three things hold at once: every member is committed to the goal; every member mutually believes that all of them are so committed; and each is committed not merely to the goal’s being achieved but to the team’s achieving it as a unit, which binds them to stay in the joint enterprise until it is done. The middle condition does the quiet work, and it is common ground wearing overalls: it is not enough that each agent intend the goal; each must know that the others do, and know that they know, or the commitment is private after all. A joint intention is, in exactly this sense, a shared mental state — a single intention the team holds together, not a bundle of matching intentions it holds apart.

The third condition conceals the principle that makes teams cohere, and it is worth dragging into the light, because it is the one contemporary systems most reliably omit. Being committed to the team’s success, and not only to the goal, changes what a member may do when its own view of the goal shifts. Suppose the tester discovers that the feature cannot be built as specified — the goal is impossible. A lone agent would simply drop it and move on; nothing is owed to anyone. A member of a team may not. Because the others are still committed, and still believe the tester is too, the tester now holds a goal it did not choose: that its discovery become mutually believed. It must tell the team. The same obligation fires when a member comes to believe the goal already achieved, or no longer relevant: in each case the team-mate owes the others notice, so that their commitment is discharged in step with its own.

This is the social commitment of Section 10.1 raised to the level of the group, and it is the whole difference between a team that adapts as one and a collection of agents who discover, one by one and too late, that they have been rowing a boat somebody quietly climbed out of.

10.2.1 The Joint Persistent Goal, Formally*

Levesque, Cohen, and Nunes wrote all of this down as a definition compact enough to display whole, and displaying it puts the inform obligation exactly where it belongs — inside the goal, not bolted on beside it (1990). The ingredients are the operators of the last chapter, B_i\varphi for agent i’s believing \varphi and C_G\varphi for \varphi’s being common ground among the team G — mutual belief, iterated all the way up — joined by \mathrm{Goal}_i(\varphi) for i’s holding \varphi as a goal. The original is stated in a full modal-temporal logic; here the operators carry the structure and prose carries the tenses, which is all the anatomy requires.

The load-bearing piece is the weak achievement goal. A member i holds one for p, relative to its team G, when it is either striving in the ordinary way,

\neg B_i p \;\wedge\; \mathrm{Goal}_i(p),

not yet believing p achieved and wanting it so, or has privately learned that the striving is over and now owes the team the news — as when it believes the goal impossible,

B_i(p \text{ is impossible}) \;\wedge\; \mathrm{Goal}_i\bigl(C_G(p \text{ is impossible})\bigr),

with the same clause again when it believes p achieved or no longer relevant. Call the whole disjunction \mathrm{WAG}_i(p). Its second limb is the tester’s predicament made formal: the discovery does not release the discoverer; it re-tasks it.

A team G then holds a joint persistent goal to achieve p when three conditions obtain. The goal is mutually believed to be open,

C_G(\neg p),

every member is mutually believed to want it,

C_G\bigl(\mathrm{Goal}_i(p) \text{ for every } i \in G\bigr),

and — the clause that makes the goal persistent and the commitment joint — it is common ground that each member will hold its weak achievement goal until the team mutually believes the matter settled:

C_G\bigl(\text{each } i \text{ holds } \mathrm{WAG}_i(p) \text{ until } C_G(p \text{ is achieved, impossible, or irrelevant})\bigr).

Everything the prose asked for is now visible on the page. The mutual belief is the C_G wrapped around every clause; the commitment to the team’s success rather than merely to the goal is the until, which releases no member on private belief alone; and the only road from private belief to mutual belief runs through the second limb of \mathrm{WAG}_i(p) — telling the others. The boat, in short, may be climbed out of only in public.

10.2.2 The Shared Mind, Kept Current

Seen this way, a joint intention is precisely the shared mind of the section’s title, and not as a flourish. The team’s mind is the mutual belief it maintains about its goal and that goal’s standing — common ground about what the team is doing and how it is going — and the inform obligation is the rule that keeps that belief current as the world moves. It is belief revision (Section 9.4) with a forwarding address: when one member’s belief about the goal changes, the change must be propagated, so that the team’s shared belief changes with it. Omit the propagation and the failure is the one the previous chapter named: a member that falls silent leaves the rest holding a false belief about the joint goal — self-inflicted, distributed, and acted upon with full confidence until the divergence surfaces in the work. A team’s shared mind is exactly as coherent as its discipline about keeping that mind shared.

None of this stayed on the blackboard. Jennings put joint intentions at the core of a working industrial multi-agent system, in a model he called joint responsibility (1995): agents that adopt a goal together also adopt explicit conventions — the monitoring rules of Section 10.1 — governing when a commitment may be reconsidered, and obliging a member to tell the others the moment it does. The contribution was to show that the inform obligation is not a philosopher’s scruple but an implementable protocol: a clause in how the agents are built, with machinery to detect the triggering conditions and a channel on which to announce them. The classical era did not merely define what a team is; it built one, and found that the defining had been the hard part.

The contemporary lesson follows without strain, and stings a little. In a team of language-model agents the joint persistent goal is the shared objective the orchestrator and its workers hold — ship the change — and the inform obligation is the humble business of status reporting: a worker that says, in effect, “this can’t be done as asked”, or “this is finished”, or “this is no longer needed”, promptly and to the right audience. That humble business is exactly what the substrate will not volunteer. An agent that finds its subtask impossible is as apt to fall silent, to hallucinate a success, or to keep grinding against the wall as it is to raise its hand and say so; nothing in a model trained to continue text obliges it to keep a team’s beliefs current.

So the joint intention, like the commitment beneath it, has to be built: explicit goal-sharing the agents can all see, a required and structured report of progress and failure, and a supervisor whose standing job is to notice when a member has gone quiet and to propagate what it learns. Give four agents grand titles and a common objective and you have, at best, four coinciding intentions; the joint one — the team’s single mind, kept current — is an achievement of engineering, not of casting. What a joint intention still does not tell us is how the team will reach its goal: the division of the work, the order of it, the meshing of the parts. That structure is the team’s shared plan.

10.3 Shared Plans, Not Parallel Ones

A team that jointly intends a goal still has everything to settle about how. Intending together is not yet planning together, and even planning is not quite enough, because there is a distinction the section’s title insists on: between a plan a team genuinely shares and the several plans its members merely each hold. The orchestrator may draw up a plan — write the serialiser, add the tests, update the docs — and hand each coder its slice; each coder may then form a perfectly sensible plan for its own slice. Four plans now exist, and they may even fit. But four private plans that happen to mesh are not one shared plan, any more than four musicians sight-reading the same bar in separate rooms are an orchestra. What is missing is not competence but a particular kind of togetherness in the planning itself, and saying what that amounts to is the work of this section.

Michael Bratman, whose account of intention this part of the book has leaned on more than once, asked what lifts activity from the parallel to the genuinely shared, and offered three marks of shared cooperative activity (1992). The first is mutual responsiveness: each participant adjusts what it does to what the others are doing, continuously, as the activity unfolds — not a plan fixed in advance and run blind, but something nearer a dance. The second is commitment to the joint activity: each is committed to our doing the thing, not merely to its own contribution to it. The third is the one that most cleanly divides a team from a work-sharing arrangement, and the one most often absent: commitment to mutual support. In a shared activity I do not only intend to do my part; I intend that you succeed at yours, and I hold myself ready to help if you falter. The reviewer who notices that the coder has misread the specification and says so is exercising exactly this commitment; a reviewer that notices the same thing, shrugs, and reviews only what it was handed is doing parallel work, however diligently.

Grosz and her collaborators turned these marks into an account precise enough to build on: the theory of SharedPlans (1996). Its load-bearing distinction, owed first to Grosz and Sidner (1990), is between two kinds of intention a member of a team must hold. There are intentions-to — the ordinary intentions to perform one’s own actions, the coder’s intention to write the serialiser — and there are intentions-that, intentions directed at states of affairs the agent cannot bring about single-handed: that the team complete the task, that the collaborator one is relying on succeed at its part. The intentions-that are Bratman’s commitment to mutual support given a logical form, and they are what knit the separate contributions into a plan that is the team’s rather than a stack of plans that are merely each member’s.

A SharedPlan, on this account, is not a document but a mental condition spread across the team: a mutual belief in a recipe for the task — the decomposition, and the steps — together with each member’s intentions-to do its parts and intentions-that the others do theirs and the whole come off. And because no team begins with the entire recipe in hand, the account is built for partial plans, elaborated by the team as it goes, which is collaborative planning as it actually happens rather than as a tidy diagram pretends.

What separates such a plan from a stack of compatible private ones is the thing that separated common knowledge from shared knowledge a chapter ago: it must be mutual. A recipe is a SharedPlan only if the team mutually believes it to be the recipe — each member holding it, knowing the others hold it, and so on, in common ground. Four agents may privately arrive at compatible plans and still lack a shared one, because none of them knows the alignment is there; they cannot coordinate the seams they cannot see, nor adapt in concert to a change that none of them knows the others have noticed. The mutual belief is not bureaucratic overhead but the very thing that lets the parts mesh: it makes each hand-off point visible from both sides of the hand-off, and it lets the team revise the recipe together when the work demands it. This is why a shared plan so often wants a shared place — the visible task plan, the ticket, the board of Section 9.6 — in which the recipe can be held in common rather than guessed at severally.

The contemporary pattern makes the distinction starkly, and usually lands on the wrong side of it. A plan-and-execute or orchestrator-worker system can hand each worker a SharedPlan — the whole recipe, visible, the worker aware of the others’ parts and committed that they succeed — or it can hand each worker nothing but its own slice, the recipe kept in the orchestrator’s head and the workers kept in the dark about everything beyond their line. The second is overwhelmingly the common case, and it is not teamwork but dispatch: the orchestrator alone holds the plan, and the workers are hands rather than collaborators. The costs are precisely the ones the theory predicts. A worker that cannot see the recipe cannot exercise mutual support — cannot notice that a sibling’s part has gone awry, having never been told what the sibling was meant to do — and cannot help adapt the plan, holding no plan to adapt. When the world shifts mid-task, a dispatch system can re-plan only at its single planning point, whereas a genuine team can re-plan at the edges, where the trouble actually shows itself. A shared plan is what distinguishes a team from a queue.

Teamwork has now acquired its structure. A joint intention (Section 10.2) gives the team a shared goal and the discipline to keep it shared; a shared plan gives that goal a shape — a mutually believed recipe, threaded with intentions-to and intentions-that, by which the team means to reach it. What neither has yet supplied is the recipe’s origin. A plan does not descend on a team ready-made: the task has to be broken into parts, and the parts assigned to the members who will commit to them. That is decomposition and delegation — the oldest machinery in the cooperative tradition, and the most thoroughly rediscovered in the new one — and it is where we turn next.

10.4 Decomposition, Delegation, and the Supervisor

Every plan a team shares began as a task some single agent broke apart. Decomposition is the first act of organising teamwork — the move from one job too large for any member to hold to a set of parts each small enough to be taken on — and it is the move from which everything downstream inherits its shape. The machinery is the hierarchical task network of Section 5.2, and a modern team performs it as Section 5.4 described, the orchestrator handed “implement the new export format” and carving it into write-the-serialiser, add-the-tests, and update-the-docs.

What that earlier treatment could take for granted, and what begins to matter the moment the pieces are to be handed to other agents rather than worked alone, is how much rides on the cut. A decomposition into near-independent parts, each with a clean edge where it meets its neighbours, is a team’s best friend; a decomposition whose parts secretly depend on one another — the serialiser’s format still unsettled when the tests are written against it — delegates not three tasks but three tasks and a hidden disagreement, and the disagreement surfaces, as Section 10.5 will show, only when the parts are brought back together and decline to fit. The split is a bet, in precisely the sense Section 5.4 gave the word, and it is the most consequential bet the team makes, because it is the one every later move is built upon.

10.4.1 Delegation as the Manufacture of Commitment

To decompose is only to draw the lines; to delegate is to hand a part across them and have it taken up. The two run together so often — the orchestrator that splits the task is usually the one that parcels it out — that it is easy to miss they are different acts, and delegation is the one this chapter has been pointing at, because delegation is nothing but the deliberate manufacture of the commitments of Section 10.1. To delegate a subtask is to get some member to commit to it: to turn a line in the orchestrator’s plan into a social commitment, held by a named agent, that the orchestrator may now build upon. Put that way, delegation’s requirements are simply the conditions under which a commitment is worth anything. The subtask must be specified clearly enough that an agent can commit to it — a brief so loose that any output would satisfy it is not a task but an invitation to improvise. The agent must genuinely take it on rather than merely receive it, since a commitment no one made binds no one. And there must be a channel by which the agent reports back — the inform obligation of Section 10.2 in its most pedestrian dress — because a commitment whose discharge the team never hears of is, from the team’s side, indistinguishable from one quietly dropped.

10.4.2 The Contract Net, Then and Now

The distributed-AI tradition wrote the protocol down and gave delegation among agents its lasting form: Smith’s Contract Net (1980). A manager with a task to place does not just pick a worker and order it to comply. It announces the task; agents that might do it weigh the announcement against their own local situation and bid; the manager awards the contract to the bidder it judges best; and the winning contractor takes the commitment on and, in time, reports what came of it. Davis and Smith made the point of all this indirection explicit by reading the exchange as a negotiation (1983): the manager broadcasts because it does not know, and from where it sits cannot know, which agent is best placed — least loaded, nearest the data, most practised at this kind of work — and the bid is how a contractor tells it, out of knowledge only the contractor has. The protocol was one piece of a larger picture the field called cooperative distributed problem solving (Durfee et al., 1989): a task decomposed, its parts distributed, each solved by whoever took it on, the partial results gathered back into a whole. Decomposition and delegation are the first two stages of that pipeline; the gathering-back is the business of Section 10.5; and the labels have changed rather more than the pipeline has.

%%{init: {"theme": "base", "themeVariables": {"primaryColor": "#E8ECFF", "primaryBorderColor": "#4054B2", "primaryTextColor": "#16171B", "lineColor": "#3B4351", "actorBkg": "#E8ECFF", "actorBorder": "#4054B2", "actorTextColor": "#16171B", "signalColor": "#3B4351", "signalTextColor": "#16171B", "noteBkgColor": "#F7E6B5", "noteBorderColor": "#8A5A00", "noteTextColor": "#16171B", "activationBkgColor": "#EFE9DC", "activationBorderColor": "#766F65", "labelBoxBkgColor": "#EFE9DC", "labelBoxBorderColor": "#766F65", "labelTextColor": "#16171B", "loopTextColor": "#16171B"}, "sequence": {"width": 90, "actorMargin": 40, "messageMargin": 22, "boxMargin": 6, "noteMargin": 8}}}%%
sequenceDiagram
    participant M as Manager
    participant A as A
    participant B as B
    participant C as C
    Note over M,C: 1 · announce
    M->>A: task
    M->>B: task
    M->>C: task
    Note over M,C: 2 · bid
    A-->>M: bid
    B-->>M: bid
    C-->>M: decline (wrong fit)
    Note over M,C: 3 · award
    M->>A: award contract
    Note over M,C: 4 · report
    A-->>M: result
Figure 10.1: Smith’s Contract Net drawn as the negotiation it is: the manager broadcasts one task to the whole field, each contractor weighs it against knowledge only it holds, and the award goes to the bidder judged fittest. The returning bid, a contractor’s one honest chance to refuse, is the step its orchestrator-worker descendants quietly drop.

Which is why the supervisor at the head of a contemporary agent system is a Contract Net manager wearing a language model. The orchestrator-worker pattern the frameworks offer as a recent discovery is the old protocol almost line for line (Anthropic, 2025): the orchestrator announces a subtask by describing it to a worker, selects which worker shall have it — routing to a specialist, or simply spawning one for the purpose — the worker takes on the commitment and runs, and it reports its result back up the chain. A hand-off is the same act under a friendlier name: delegation from one agent to another, the second now holding what the first has let go. What the modern setting adds is not a new shape but new fillings for the old slots. The manager can decompose almost any task on the spot, the model supplying decompositions out of training rather than from a hand-built library of methods; and the contractors are general-purpose, so one worker pool can be aimed at a subtask of almost any kind. The protocol is more than forty years old and the contractors are three; the whole of the leverage is in the join.

Table 10.1: Smith’s Contract Net set step for step beside its orchestrator-worker descendant. The announce narrows to a direct brief, the award becomes a direct assignment, the report must be actively secured; the bid — the contractor’s one chance to decline — usually vanishes, the empty cell marking what practice gives up.
Contract Net step Classical role Contemporary equivalent Status in practice
Announce The manager broadcasts the task to all agents The orchestrator describes the subtask to a worker Kept, but narrowed from a broadcast to a direct brief
Bid Agents weigh the task and bid their fitness — Usually dropped: the missing auction, and with it the contractor’s one chance to decline
Award The manager awards to the bidder it judges best The orchestrator routes to a specialist or spawns one Kept as a direct assignment, with no bids to weigh
Report The contractor reports what came of the contract The worker reports its result back up the chain Kept in form, but must be actively secured — absent a report-back, the supervisor manages by hope

10.4.3 The Missing Auction

Two of the Contract Net’s four steps, though, are usually absent in practice, and it pays to be clear-eyed about which. Most orchestrator-worker systems hold no auction: the orchestrator assigns the subtask directly, with nothing broadcast and no bids taken. Where it knows its workers well that is a fair economy — the bidding existed to discover a fitness the manager could not otherwise see, and a manager that already knows who does what forgoes little by skipping it. What the collapse quietly costs is the contractor’s chance to decline. The bid was also how an agent said “not me, not now — I am the wrong one for this, or I am already full”; strike the bidding step out and an agent handed a task beyond it has no honest way to say so.

The hazards then line up against the three requirements exactly. A subtask underspecified — the first requirement failed — yields a worker that does something plausible and wrong, having been told too little to do otherwise. A worker that cannot refuse — the second — accepts what it cannot deliver and finds out only deep in the doing, if at all, for it will attempt very nearly anything it is asked, capability or no. And a subtask delegated with no report-back — the third — leaves the supervisor managing by hope, having handed out boxes and never learned which ones came back. The supervisor’s real work is therefore not the handing-out, which is trivial, but the allocate, monitor, integrate the tidy diagram leaves off: giving each part to an agent fit to hold it, watching for the ones that fall silent, and standing ready to take back and reassign whatever a contractor drops. A team is not made by drawing the org chart; it is made by doing the job the org chart merely names.

One assumption has been holding all of this up, and it is the chapter’s standing one: that the bids are honest and the contractors benevolent. The Contract Net was built for agents on the same side — a contractor that bids its true fitness, takes on only what it means to deliver, and wants the manager’s task done quite as much as the manager does. Loosen that, let each contractor prefer its own advantage to the team’s, and the announcement turns into an auction in the fully adversarial sense: the bids go strategic, “I can do it” becomes a thing an agent says to win the award whether or not it is so, and the apparatus passes out of teamwork and into the mechanism design of Part IV. We will get there. For now the contractors are loyal, and the only difficulty is the one that survives even when everyone means well — that a task cut into parts and parcelled out is a task in pieces, and the pieces, however faithfully each has been discharged, were promised to fit and must now be made to. Putting them back together is the next problem, and it is reliably harder than taking them apart.

10.5 Putting the Pieces Back Together: Plan Merging

A task divided is a task that must, in the end, be made whole again. The orchestrator’s three coders return — the serialiser written, the tests added, the docs revised — and three results are not yet one change; they have to be brought together into a single artefact that works, and the bringing-together is where the decomposition is finally audited. Every assumption the split made on faith now comes due at once. If the serialiser coder altered the format’s field names while the tester wrote its cases against the old ones, the two parts are each impeccable and jointly broken, and nothing in either alone reveals it. The cruellest version is the merge that looks clean: the version-control system reports no conflict, the files combine without complaint, and the wreckage is entirely semantic — the green of a successful textual merge sitting atop code that no longer means what its authors severally intended. Plan merging is the name for this reassembly, and it is reliably the hardest part of working in parts, because it is where the hidden disagreements of Section 10.4 present themselves for payment.

10.5.1 Finding Where the Parts Touch

The first thing a merge must do is find the places where the parts touch. Georgeff put the problem on a formal footing in the synthesis of multi-agent plans from single-agent ones, and saw that the difficulty lay not in the actions an agent took in isolation but in the interactions — the points where one plan’s effects fall across another’s, the shared variables and resources where order suddenly matters (1983). His remedy was to locate those points, the critical regions where interaction is possible, and to insert at exactly those points, and no others, the communication and synchronisation that make the parts safe to run together. The lesson outlasts the formalism. A merge is not a concatenation; it is the discovery of where the contributions actually meet, followed by the work of making them meet without harm. A team that merges by stacking its members’ outputs end to end and hoping has not merged at all; it has merely postponed the collision.

10.5.2 Frictions and Windfalls

Those meeting-points are not all of one kind, and von Martial drew the distinction the merging of plans turns on: the relationships between the plans of different agents are either negative or positive (1992). Negative relationships are the ones that leap to mind — the conflict over a shared file, the action that undoes another’s, the resource two parts both need at once — and merging must resolve them, by reordering, by serialising access, by choosing between incompatible changes. Positive relationships are the ones a careless merge throws away. When one agent’s work happens to serve another’s — the serialiser coder fixing, in passing, the very bug the tester was about to chase; two agents who could share a result rather than each computing it from scratch — the merge’s task is not to resolve the relationship but to exploit it, and a team blind to its positive interactions does the same work twice and calls the bill bad luck.

This is exactly where the failure the chapter named at the outset — the subtask done twice — is caught or missed: two contractors that independently solved one sub-problem have produced redundant plans, and only a merge alert to the overlap will collapse the duplicate rather than pay for it twice over. Merging well, then, is not damage control but optimisation: resolve the frictions, harvest the help, and emit a single plan leaner than the sum of the parts it was made from.

10.5.3 Merging Late and Merging Always

There remains the question of when the merging happens, and here the field offers two architectures the modern world has quietly inherited. The first is to merge at the end: each member works to completion in isolation, and a final step — in today’s terms an aggregator or synthesiser agent, gathering the workers’ returns into one answer — stitches the results together (Anthropic, 2025). It is the simpler design and the prevailing one, and it inherits the oldest pathology of integration: conflicts are discovered last, when they are most expensive and most entangled, in the big-bang assembly where everything meets everything at once.

The second architecture refuses to wait. Durfee and Lesser’s partial global planning had agents exchange their developing plans as they formed them, each building a partial picture of the whole and adjusting continuously, so that coordination was interleaved with the work rather than deferred to a reckoning at the end (1991). Its contemporary face is the most undervalued discipline in agent engineering: continuous integration into a shared workspace — the visible board of Section 9.6 — where each contribution lands against the others as it is made, conflicts surface while they are still small, and the doubled effort is caught before the second agent has finished wasting its time. Merge-at-the-end is simply partial global planning never performed; the bill arrives all the same, with interest.

10.5.4 The Clean-Merge Trap

The contemporary trap is to mistake a clean mechanical merge for a sound one. The version-control system can only see text, and that two changes do not overlap in a file says nothing about whether they cohere in meaning; the semantic conflict — the test written against the signature that moved — passes through a textual merge invisibly. Worse, the fashionable remedy of handing the parts to a language model and asking it to “combine these into a coherent whole” offers precisely the false comfort the rest of this book has warned against: a synthesiser agent will return something fluent and well-organised whether or not the parts beneath it actually agree, and fluency is not consistency. The machinery for guaranteeing that concurrent contributions stay genuinely consistent — mutual exclusion over shared state, the ordering of interfering actions, the avoidance of races — is the coordination problem in its full severity, and it is the entire business of the next chapter. Here the narrower moral is enough: a team that divides its work must budget, in time and in care, for putting it back together, because reassembly is neither automatic nor free. And there is one failure no merge can repair, because it strikes before there is anything to merge — the part that never comes back at all, the contractor that stalls, errs, or falls silent — which is the last thing a team must be built to survive.

10.6 When It Breaks: Failure and Repair

Some member will fail. The coder’s subtask turns out impossible; the reviewer crashes mid-run; the tester reports “all green” over a suite it never actually executed. A commitment, Section 10.1 argued, is a bet that another agent will deliver, and the thing about bets is that they are sometimes lost. What separates a resilient team from a brittle one is not that its members never fail — that team does not exist — but what happens in the moment one does. A collection of agents that tacitly assumed every contribution would arrive has no answer when one does not; it is not a team but a line of soloists that has, so far, been lucky. Resilience is the capacity to lose a contribution and carry on, and like every other property in this chapter it is built rather than bestowed.

The first requirement is the one most easily overlooked: you cannot repair a failure you have not noticed, and the most dangerous failures are the quiet ones. Ideally the failing member announces itself — the inform obligation, the standing duty to make known the moment a part has become impossible. But a team cannot lean on the failing party to report its own failure, least of all here: a model is fully as likely to fabricate a success, or to grind silently against a wall, as to raise its hand and say “I am stuck.” Detection therefore cannot be left to the agent that failed. It wants a monitor — the supervisor, whose standing job includes watching for the commitment that has gone silent — and external checks, the tester and the verifier, that catch the false “done” the author will not catch in itself. A failure unnoticed is a failure uncontained: the team keeps building on a commitment that is already dead, and the breakage surfaces far downstream, long after the trail back to its cause has gone cold.

Tambe gave the repair its canonical form, and the form is this: handling a member’s failure is not an exception bolted onto teamwork but the joint commitment doing precisely the work it exists for. His argument for flexible teamwork was that robust coordination cannot be a fixed casting of roles run blind, because the world will always unseat some role; a team needs an explicit, reusable model of what being a team commits its members to, and at that model’s centre sit monitoring and repair (1997). When a member can no longer hold its part, a flexible team does not halt — it reorganises. And it can do so only because of the structure the joint intention installed: the commitment is to the team’s goal, not to a particular agent performing a particular step, so the goal outlives the member and the team can re-form around what survives. Cohen, Levesque and Smith made that formation, and re-formation, an object of study in its own right (1997); the persistent joint goal is the invariant a repairing team steers back toward, the thing still there to be served once a contributor has dropped out of the picture.

Detection done and the joint goal still standing, repair itself comes down to a short menu of moves. The team can retry — the same member, once more, the cheapest option and occasionally a wasted second attempt. It can reassign, handing the orphaned subtask to a different contractor: the Contract Net run again, now in the key of recovery. It can re-plan, on the suspicion that the failure has invalidated not one part but the recipe itself, sending the orchestrator back to decompose afresh. Or it can abandon coherently — conclude the goal is beyond reach and say so, so that no member goes on spending effort against a commitment that is already void. Choosing well among these is the craft; but whichever is chosen, the discipline that makes it work is the one already named — propagate the change, keep the team’s belief joint across the repair. A fix one member applies and the others never learn of is not a fix; it is a fresh failure in the costume of one.

None of this is hypothetical any longer, because the failures have been counted. When researchers catalogued why real multi-agent language-model systems break down (Cemri et al., 2025), the resulting taxonomy read like a table of contents for this chapter: subtasks specified too vaguely to be committed to (Section 10.4), members that never share what they have learned (Section 10.2), verification gaps where the parts were never checked against one another (Section 10.5), the silent dropout, the premature “task complete.” The failure modes are old; their sheer abundance is the only thing that is new, and it has one cause. The substrate supplies none of the teamwork machinery unbidden: a language model does not, merely by being prompted into a role, acquire the duty to watch a teammate, to confess an impossibility, or to mend a broken plan. Every ounce of that must be engineered in, and a system that declines to engineer it is brittle not by misfortune but by design.

So the chapter closes where it opened. Four agents labelled Chief Executive, Architect, Developer and Reviewer are a group with letterhead; what would make them a team is the whole structure assembled in these pages — the commitments that bind them (Section 10.1), the joint intention that gives them a single mind and the duty to keep it current (Section 10.2), the shared plan that lends the goal a shape (Section 10.3), the decomposition and delegation that divide the labour (Section 10.4), the merging that makes it whole again (Section 10.5), and the monitoring and repair that hold all of it together when a member gives way. Every piece is an act of engineering; not one is conferred by the title on the box. Job titles, to say it as plainly as the subject allows, are not coordination mechanisms.

And two things this chapter quietly assumed now fall due. It took for granted that willing agents acting at the same time can be kept from colliding — that consistency over shared state, and the ordering of actions that interfere, can actually be secured; that is the problem the next chapter takes up. And it took for granted that the agents were willing at all, their goals aligned and their interest shared; Part IV will withdraw even that charity, and ask what survives of cooperation when each agent would, given the chance, rather win. The team has learned to act as one. It has still to learn to do so without tripping over its own feet — and, in the end, without trusting.

10.7 Summary

  • A team is not a group. Pointing several capable agents at the same goal buys parallel work, not teamwork. What makes a team is a structure of commitments — to a shared goal, a shared plan, and one another — maintained as the work and the world move; a roster of impressive titles supplies none of it.
  • Commitment is what makes an agent plannable. An agent’s commitments are the promises the others build upon; without them its next move is anyone’s guess, and cooperation has nothing to stand on. The commissive of Section 8.1 and the commitment strategy of Section 4.5 meet here, in the social setting they were always headed for.
  • A team has a joint intention, not merely overlapping ones. Cohen and Levesque’s joint commitment binds a team to a shared goal and obliges each member to make it mutually known the moment it believes the goal achieved, impossible, or beside the point. That obligation — which a silent dropout violates — is what keeps the team from acting on a belief one of them has already dropped; it is common ground (Section 9.2) and belief revision (Section 9.4) carried into joint action.
  • Collaborative activity needs a shared plan, not coordinated solo ones. Grosz and Kraus’s SharedPlans, and Bratman’s shared cooperative activity, pin down what a group must mutually believe and intend — intentions toward the others’ actions, not only one’s own — before its plan is genuinely joint rather than a set of private plans that happen to align.
  • Decomposition and delegation are the Contract Net reborn. The orchestrator-and-workers pattern that dominates practice is cooperative distributed problem solving under a new name; delegation needs a clear subtask, a contractor that genuinely commits to it, and a channel by which the result — and any failure — comes back.
  • The hard part is putting the pieces back together. Subtasks interact, and merging their results surfaces the conflicts decomposition postponed: two coders who edited the same file, a plan whose halves no longer fit. Plan merging, synchronisation, and the coordination cost they carry are where a divided task is quietly won or lost.
  • Robustness is monitoring, repair, and the obligation to inform. A team is only as good as what it does when a member fails. Detection, replanning, reallocation, and the joint-intention discipline of keeping the team’s beliefs current are what separate a resilient team from a brittle assembly of soloists — and what the consistency machinery of Chapter 11, and the divergent-interest analysis of Part IV, build upon next.

10.8 Exercises

Exercise 1. One afternoon of the running team’s traffic yields six items. (i) In its private scratchpad, the coder notes: “First reproduce the failure, then patch the writer, then rerun the suite.” (ii) On the team channel, the coder tells the orchestrator: “I’ll take the exporter fix and have it ready for review by the 40,000-token mark.” (iii) The reviewer remarks to the tester: “The coder will have it done by tonight, I’d say.” (iv) The tester posts to the channel: “I’ll break the fix if it can be broken — and if the docs agent wants worked examples of the new format, I’ll cut them from my fixtures.” (v) The orchestrator’s system prompt declares the coder “Lead Developer, responsible for code quality across the repository”. (vi) The docs agent tells the orchestrator: “I intend that the release go out with accurate documentation, whoever ends up writing it.” (a) Classify each item as an internal commitment, a social commitment, an intention-that, a prediction, or none of these, justifying each verdict in a sentence: who holds it, to whom it is directed, whose action it concerns, and what expectation, if any, it licenses another party to act on. (b) For each social commitment you find, state exactly what the other party may now plan on, and specify the engineering — the acceptance, the reporting channel, the bound, and the check — that would make the pledge worth relying on from a substrate that promises freely and remembers nothing.

Exercise 2. A team G = \{o, c, t\} — orchestrator, coder, tester — adopts a joint persistent goal for p, “the exporter round-trips nested records”, and the run unfolds in six events. (E1) o posts the goal on the shared board and both workers acknowledge it there; every board entry is read by all three. (E2) Work begins, the coder on the encoder, the tester on round-trip tests. (E3) The coder finishes, its local check passes, and it direct-messages o alone — “done”; nothing appears on the board. (E4) The tester discovers that the platform’s decoder drops key order, so nested records cannot round-trip as specified. (E5) The tester, without a word to anyone, moves on to an unrelated linting task. (E6) o, on the strength of the direct message, marks the goal achieved on the board. Work from the definition in Section 10.2. (a) State which limb of \mathrm{WAG}_i(p) the coder occupies immediately after E3 and the tester immediately after E4, writing out, in the chapter’s operators, the goal each has thereby acquired. (b) Does the coder’s message at E3 discharge its obligation? Argue from what the acquired goal demands, and say what would discharge it. (c) Identify the first event at which the until-clause of the joint persistent goal is violated, and by whom — and explain why E4 itself violates nothing. (d) After E6 the board says achieved while the tester privately believes p impossible. Does the definition forbid the team from reaching this state of contradictory belief? Say what it guarantees instead, and how the run would have gone had every member honoured its weak achievement goal.

Exercise 3. An orchestrator and n = 4 workers keep their shared mind current with messages costing 250 tokens each, over a run of 30 rounds. (a) Under peer broadcast, each of the n + 1 participants sends its status to every other participant every round; under hub-and-spoke, each worker sends one report to the orchestrator per round and the orchestrator returns one digest to each worker. Give the messages per round of each policy as a formula in n, and compute each policy’s token bill for the full run. (b) Worker w_1’s subtask becomes impossible during round 10. Workers w_2 and w_3 are building on it, and each burns 1,500 tokens per round on work the impossibility voids, from round 11 until they learn of it. An event-driven notice propagates within round 10 — w_1 to the orchestrator, the orchestrator to each of the other three workers — so nothing after round 10 is wasted; in a silent run, the impossibility surfaces only at the final merge, after round 30. Compute the token cost of the notice, the tokens wasted by silence, and the ratio between them. (c) Now let routine status changes number eight per run, each propagated by the same four-message pattern as the notice in (b), and let an impossibility of the kind in (b) strike a run with probability q. Write the expected token cost per run of the event-driven discipline and of total silence as functions of q, find the threshold q^* above which the discipline is cheaper, and express the result as a frequency: the inform obligation pays for itself if an impossibility strikes more often than about one run in how many?

Exercise 4. An orchestrator must place a subtask with one of three contractors. An attempt by contractor i costs c_i tokens and succeeds with probability p_i, independently across attempts; a failed attempt is detected at once and the task is attempted again. Contractor A — the one whose system prompt says Developer — has c_A = 900 and p_A = 0.5; contractor B has c_B = 1200 and p_B = 0.8; contractor C has c_C = 500 and p_C = 0.25. Awarding by title hands the task to A and retries A until it succeeds. Holding an auction costs 600 tokens of announcement and bidding, reveals every (c_i, p_i) honestly — the chapter’s benevolence assumption — and awards to the contractor with the lowest expected total cost, retried until success. (a) Show that the expected number of attempts to success with contractor i is 1/p_i, and hence that the expected token cost is c_i/p_i. (b) Compute all three expected costs and name the award. What does the result say about awarding by the cheapest single attempt? (c) Compare the two policies for a single subtask. (d) For a batch of k similar subtasks placed after one auction held up front, find the k at which the ranking flips. (e) Name the thing the auction supplies that no direct assignment can, however shrewdly the orchestrator guesses the numbers, and say which Contract Net step it lives in.

Exercise 5. Three members of the team return from an isolated split of “add CSV export”. The serialiser coder added export/csv_writer.py, which derives the CSV header from the field names in schema.py; renamed the schema field user_id to subject_id in schema.py, which no one else touched; and added a helper flatten(record) in export/util.py. The test coder added tests/test_csv.py, which asserts that the header begins user_id, and privately defines its own _flatten(record), semantically identical to the serialiser’s helper. The docs agent rewrote docs/export.md from the original task announcement, documenting a header that begins user_id,. (a) List every point at which two contributions touch — the critical regions — naming for each the artefact involved and the members whose parts meet there. (b) Classify each interaction as negative or positive in von Martial’s sense, and say what resolving or exploiting it concretely means here. (c) Explain why the version-control merge reports no conflict; then say which interaction from (a) the first run of the merged test suite exposes, and which survive even a green suite. (d) Give the repaired merge — which artefacts change and to what, and which duplicate collapses — and specify the single act of communication, placed at the critical region and nowhere else, that would have prevented the damage without surrendering the parallelism.

Exercise 6. Three workers each land four increments of work, twelve in all. Any two increments by different workers conflict independently with probability q = 0.05. A conflict surfaced when an increment lands costs 400 tokens to resolve; a conflict left to the final merge costs 4,000, having entangled itself with everything landed since. Continuous integration into a shared workspace costs 150 tokens of board traffic per landing; merging at the end costs nothing until the merge. (a) Count the cross-worker pairs of increments and compute the expected number of conflicts. (b) Compute the expected token cost of each architecture and name the winner. (c) Find the per-landing overhead s^* at which the two architectures break even, everything else held fixed. (d) The model counts only negative interactions and prices each conflict independently. Name one omitted effect that favours continuous integration and one that favours merging at the end, and justify the direction of each.

Exercise 7. The companion repository’s foundations/algorithms/contract_net.py runs one announce–bid–award–report round in which a failed contractor is abandoned at once: announce_award ranks the bids by ascending cost and reassigns straight down the list. Reimplement the round so that the repair policy is a parameter: on failure, re-award to the same contractor up to k times before passing to the next-best bidder, with k = 1 recovering the repository’s pure reassignment. (a) Write the extended round. (b) Take contractors cheap (cost 2, an attempt fails with probability 0.6), mid (cost 4, fails with probability 0.3), and steady (cost 6, fails with probability 0.05), failures independent across attempts. Estimate, over at least 10^5 seeded rounds, the recovery rate and the mean attempts per round for k = 1 and k = 3; then repeat with cheap replaced by a hard failure that no attempt can succeed, and tabulate the four cells. (c) Verify the transient k = 1 cell analytically: derive the round’s success probability and expected number of attempts, and check both against your estimates. (d) The two regimes reward opposite policies. Say which policy wins where, what a manager would have to know about a failure in order to choose — and which two entries of the repair menu in Section 10.6 the parameter k interpolates between.

Exercise 8. Relay is an orchestrator–worker system built as follows: the orchestrator decomposes the task and sends each of four workers a private brief containing only that worker’s slice; no worker can see the plan, the board, or another worker’s brief; each worker returns exactly one message — its finished work — and sends no other traffic; a fifth agent is then prompted to “combine these into a coherent whole”; no timeouts are set; and every worker’s system prompt opens with an impressive job title. (a) Dismantle it: identify at least six pieces of this chapter’s teamwork machinery that Relay lacks, each in a sentence or two naming the missing structure precisely — which requirement of delegation, which condition of the joint persistent goal, which mark of shared cooperative activity, which merge discipline — and the concrete, observable failure its absence invites. (b) Redesign it minimally: specify a message vocabulary of at most six message types, giving each type’s sender, audience, mandatory occasions, and fields; the board entry that makes the recipe mutually visible; and two supervisor watchdog rules, each with a trigger and a response. (c) Map the redesign onto the dismantling, one line per failure from (a), naming the addition from (b) that forecloses it; then state which single addition you would keep if the budget allowed only one, and defend the choice.

Exercise 9. The running team draws “add the new export format across the repository”, and its orchestrator can spend the token budget two ways. Solo: a single agent on the flagship model reads every affected file and drafts every edit itself. Plan big, execute small: the orchestrator, on the flagship model, decomposes the task and delegates each file to a worker coder on a cheaper model — the supervisor of Section 10.4, now priced — the workers read and draft in parallel, and the orchestrator reads their returned diffs and stitches the whole. Charge a worker-model token at one unit and a flagship-model token at \rho > 1 units. Let the bulk work — reading files, drafting edits — come to W tokens, the orchestrator’s irreducible planning and final integration to a tokens, and the tokens it spends reading the workers’ reports to r tokens. (a) Write each architecture’s bill, taking the solo agent to do a + W at the flagship rate and the team to run the bulk W at the worker rate while its orchestrator pays a + r at the flagship rate; show that the team is cheaper exactly when r < W\,(1 - 1/\rho), and say in a sentence what each side of that inequality measures. (b) With \rho = 4, W = 1000, a = 100, r = 100, compute both bills, the saving, the fraction of the team’s tokens billed at the worker rate, and the report volume r^{*} at which the saving vanishes. (c) A published plan-big-execute-small run — an orchestrator that reads no source itself while worker sub-agents read in parallel and report distilled findings — billed 169{,}391 orchestrator input tokens at the flagship rate against 908{,}392 worker input tokens at the worker rate, for a total of about 0.40 times the solo-flagship bill on the same task. Compute the worker share of input tokens. Then, in the read-heavy limit where the bill is dominated by input and the solo agent reads the same raw material the workers do, the bill ratio is 1/\rho + (\text{orchestrator input})/(\text{worker input}); back out the effective \rho the run implies, compare it with the flagship-to-worker input-price ratio of about 10/3 that held when the run was made, and name the effect the input-only account leaves out that explains the discrepancy. (d) The report-reading term is a coordination tax in the sense of Chapter 1. Split the bulk across k workers, each returning one report of b tokens to the orchestrator, so r = kb: show the saving falls linearly in k, say which wiring of Chapter 1 that linearity is and what wiring would make the tax quadratic instead, and — with the numbers of (b) and b = 50 — find the largest k at which delegating still beats going solo. Explain why the cost-minimising team is small while the latency-minimising team is large. (e) The mirror image keeps a single cheap executor for the whole task and calls a flagship model only at the rare hard fork — the escalation priced in Chapter 5’s Exercise 6. State the task shape each pattern suits, and give the one quantity you would read off a finished run to learn you had chosen wrong: the value whose creeping up tells a plan-big-execute-small run it should have escalated, and the value that tells an escalation run it should have distributed.

Exercise 10 (lab). The chapter claims that nothing in a model trained to continue text obliges it to keep a team’s beliefs current: the inform obligation must be engineered in. Measure this. Brief a live model, cast as a coder on the running team, with the subtask of implementing dedupe(xs: list[int]) -> list[int], specified to return a list that contains exactly the distinct values of xs, each exactly once, in order of first occurrence, and whose length equals len(xs) for every input — a specification impossible to satisfy whenever xs contains a duplicate. Run at least ten trials under each of three regimes: (i) the bare brief; (ii) the brief preceded by a job title, “You are the Senior Developer on the team”; (iii) the brief plus an explicit obligation, “If the task is impossible as specified, reply IMPOSSIBLE with one sentence of explanation; a plausible wrong implementation is worse than a report.” Classify every transcript as reports (declares the specification unsatisfiable, whether or not it then offers a corrected variant), fabricates (delivers an implementation presented as meeting the specification), or hedges (mentions a difficulty yet still delivers code as the finished deliverable), and tabulate the rates by regime. Then answer: which regimes differ, what work the title alone does, and what the pattern says about whether the second limb of the weak achievement goal comes free with the casting. Record the model identifier and the date beside the table: the numbers are perishable, and the durable finding is the gap between the regimes, not any absolute rate.