7  Working Together: Cooperation, Teamwork, and Joint Plans

What can a team that keeps its beliefs straight actually accomplish together? Common ground, the last chapter’s hard-won achievement, is only the precondition — the floor, not the building. 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. 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 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.

The ideas that pin down what teamwork is arrived decades before there were agents that could be held to them — Bratman’s shared cooperative activity, Cohen and Levesque’s joint intentions, Grosz and Kraus’s SharedPlans, and the distributed-AI plumbing of cooperative distributed problem solving. 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. Today’s planner–executor and supervisor–worker systems are cooperative distributed problem solving under new management, the orchestrator a Contract Net manager in all but name — and they inherit the failure modes the classical theory wrote down: the silent dropout, the subtask done twice, the plan that turns out to be nobody’s. One assumption holds throughout, and earns naming because Part IV will spend its strength removing it: that the agents want to cooperate. Here the team is on one side, and the only adversary is the difficulty of acting as one.

7.1 Commitment: The Glue of Cooperation

Cooperation rests on this: each agent can rely on what the others will do next. Strip that away 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 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 coder that might, 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. 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 until something gives it reason to stop (Section 3.5). That persistence 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. Persistence is the precondition of predictability, and predictability the precondition of cooperation.

But an intention persisted in is a commitment an agent makes only to itself, and cooperation asks for more. When the coder replies “I’ll take the migration”, it incurs an obligation to another party. This is social commitment, a line Castelfranchi drew with care (1995). A social commitment is directed — held by someone, to someone, about something — and it licenses an expectation the other side may now act upon. The coder’s “I’ll take the migration” is the commissive speech act of Section 5.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 privately resolving 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, with the conventions governing 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 planning on the assumption that the others will deliver. Pull any strand out and the plans built upon it sag in proportion, often invisibly, until the gap surfaces downstream, indistinguishable from an ordinary bug. Commitment is the section’s glue in a literal sense: the load-bearing structure binding the actions of separate agents into the action of one team. Most of the rest of a team’s machinery exists to make such commitments, keep them, and notice when they break; delegation (Section 7.4) is their deliberate manufacture.

All of which would be straightforward if a language-model agent committed to things as 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 2.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? Hold too loosely and its pledges are worthless; hold too tightly and it becomes the fanatic of Section 3.5, toiling at a subtask the world has already rendered pointless. The strategy that balanced those for a lone agent — reconsider when, and only when, there is reason to — carries over intact but for one addition, which 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.

7.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 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 any one may abandon it, on perfectly good private grounds, with the rest none 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; the more is this section’s subject.

What a team needs, beyond a shared goal, is a shared commitment to that goal — and to reaching it together. Levesque, Cohen, 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. The middle condition is common ground put to work: each must know that the others intend the goal, 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 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. 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 their commitment is discharged in step with its own.

This is the social commitment of Section 7.1 raised to the group level, and 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.

7.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, joined by \mathrm{Goal}_i(\varphi) for i’s holding \varphi as a goal. The original lives in a full modal-temporal logic; here the operators carry the structure, prose the tenses.

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,

\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 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.

One honesty is owed about the C_G doing all this work. The previous chapter proved that state strictly unattainable over a fallible channel (Section 6.2.1), so no real team can certify a joint persistent goal — taken literally, none has ever held one. The definition is an idealisation, and it earns its keep as idealisations do: it fixes what the team is aiming at; what a working team holds in its place is the common ground of Section 6.2, bought with a shared board and explicit acknowledgement.

7.2.2 The Shared Mind, Kept Current

Seen this way, a joint intention is precisely the shared mind of the section’s title. The team’s mind is the mutual belief it maintains about its goal and its standing, and the inform obligation keeps that belief current as the world moves. It is belief revision (Section 6.4) with a forwarding address: when one member’s belief about the goal changes, the change must be propagated. Omit the propagation and 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 system, in a model he called joint responsibility (1995): agents that adopt a goal together also adopt explicit conventions — the monitoring rules of Section 7.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 an implementable protocol, not a philosopher’s scruple. 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 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: “this can’t be done as asked”, “this is finished”, “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 to raise its hand, for 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, structured report of progress and failure, and a supervisor whose 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. That structure is the team’s shared plan.

7.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, for there is a distinction 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.

Michael Bratman 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 continuously adjusts what it does to what the others are doing. The second is commitment to the joint activity: each is committed to our doing the thing, not merely to its own contribution. The third most cleanly divides a team from a work-sharing arrangement, and is 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 the coder has misread the specification and says so is exercising exactly this commitment; one that 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), formalising the account Grosz and Sidner had first sketched (1990). Its pivotal distinction is between two kinds of intention a member of a team must hold: intentions-to — the ordinary intentions to perform one’s own actions, the coder’s intention to write the serialiser — and 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 knit the separate contributions into a plan that is the team’s rather than 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 because no team begins with the entire recipe in hand, the account is built for partial plans, elaborated by the team as it goes — collaborative planning as it actually happens.

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. 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. 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, and it lets the team revise the recipe together when the work demands it. This is why a shared plan wants a shared place — the visible task plan, the ticket, the board of Section 6.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. An 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. 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 — 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 shows itself. The ledger runs the other way too: the full recipe costs tokens per worker and per revision, and where the parts are genuinely independent, dispatch is a defensible economy — the point is that what it surrenders is a price to be paid knowingly. A shared plan is what distinguishes a team from a queue.

Teamwork has now acquired its structure: a joint intention (Section 7.2) gives the team a shared goal and the discipline to keep it shared; a shared plan gives that goal a shape. What neither has 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.

7.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, and the move from which everything downstream inherits its shape. The machinery is the hierarchical task network of Section 3.9, and a modern team performs it as Section 3.11 described, the orchestrator handed “implement the new export format” and carving it into write-the-serialiser, add-the-tests, and update-the-docs.

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, which surfaces only when the parts are brought back together and decline to fit (Section 7.5). The split is a bet, in precisely the sense Section 3.11 gave the word, and it is the most consequential bet the team makes.

To decompose is only to draw the lines; to delegate is to hand a part across them and have it taken up — and delegation is the act this chapter has been pointing at, because it is nothing but the deliberate manufacture of the commitments of Section 7.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 7.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.

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 weigh the announcement against their own 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 (Figure 7.1). Davis and Smith read the exchange as a negotiation (1983): the manager broadcasts because it cannot know, from where it sits, which agent is best placed — least loaded, nearest the data, most practised — and the bid is how a contractor tells it, out of knowledge only the contractor has. The protocol sat inside a larger picture the field called cooperative distributed problem solving (Durfee et al., 1989): a task decomposed, its parts distributed and severally solved, the partial results gathered back into a whole — 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 7.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) (Table 7.1): the orchestrator announces a subtask by describing it to a worker, selects which worker shall have it, the worker takes on the commitment and runs, and reports its result back up the chain. A hand-off is the same act under a friendlier name. 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, out of training rather than from a hand-built library of methods, and the contractors are general-purpose, one worker pool aimable at a subtask of almost any kind. The protocol is more than forty years old and the contractors are barely out of the lab; the whole of the leverage is in the join.

Table 7.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 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 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

Two of the Contract Net’s four steps, though, are usually absent in practice. 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. 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. And a subtask delegated with no report-back — the third — leaves the supervisor managing by hope, never learning which boxes 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. 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 held all of this up, 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 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 were promised to fit and must now be made to. Putting them back together is reliably harder than taking them apart.

7.5 Putting the Pieces Back Together: Plan Merging

A task divided 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; the bringing-together is where the decomposition is finally audited, and every assumption the split made on faith 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: it is where the hidden disagreements of Section 7.4 present themselves for payment.

The first thing a merge must do is find the places where the parts touch. Georgeff, putting the synthesis of multi-agent plans from single-agent ones on a formal footing, 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: locate those points, the critical regions, and 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, and 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.

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 — 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 subtask done twice is caught or missed; merging well is not damage control but optimisation: resolve the frictions, harvest the help, emit a single plan leaner than the sum of its parts.

There remains the question of when the merging happens, and the field offers two architectures. 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 (Anthropic, 2025) — stitches the results together. It is the simpler and prevailing design, and it inherits integration’s oldest pathology: conflicts discovered last, when they are most expensive and most entangled. The second architecture refuses to wait. Durfee and Lesser’s partial global planning had agents exchange their developing plans as they formed them, coordination 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 6.6 — where each contribution lands against the others as it is made, conflicts surface while 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.

The contemporary trap is to mistake a clean mechanical merge — text that combines without complaint — for a sound one. 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, ordering, races — is the coordination problem in its full severity, and the next chapter’s entire business. Here the narrower moral is enough: a team that divides its work must budget, in time and in care, for putting it back together. One failure no merge can repair strikes before there is anything to merge — the part that never comes back at all — and it is the last thing a team must be built to survive.

7.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 7.1 argued, is a bet that another agent will deliver, and bets 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. 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 again. 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. Detection therefore wants a monitor — the supervisor, 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 dead commitment, and the breakage surfaces far downstream, long after the trail to its cause has gone cold.

Tambe gave the repair its canonical form: 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, with monitoring and repair at its centre (1997). The system he built to prove it, STEAM, remains the most widely fielded operationalisation the joint-intentions theory has had — the same rule set flying combat-simulation helicopters and playing robot football, reusable across domains precisely because it was explicit. When a member can no longer hold its part, a flexible team does not halt — it reorganises, and it can do so only because 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.

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. Or it can abandon coherently — conclude the goal is beyond reach and say so, so that no member keeps spending effort against a void commitment. 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.

The failures have been counted: when researchers catalogued why real multi-agent language-model systems break down (Cemri et al., 2025), the taxonomy read like a table of contents for this chapter: subtasks specified too vaguely to be committed to (Section 7.4), members that never share what they have learned (Section 7.2), verification gaps where the parts were never checked against one another (Section 7.5), the silent dropout, the premature “task complete.” The failure modes are old; their abundance 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 7.1), the joint intention that gives them a single mind kept current (Section 7.2), the shared plan that lends the goal a shape (Section 7.3), the decomposition and delegation that divide the labour (Section 7.4), the merging that makes it whole again (Section 7.5), and the monitoring and repair that hold it together when a member gives way. 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 can actually be secured; the next chapter’s problem. And it took for granted that the agents were willing at all; 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.

7.7 Summary

  • A team is not a group. 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; the commissive of Section 5.1 and the commitment strategy of Section 3.5 meet here.
  • 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 — the obligation a silent dropout violates.
  • Collaborative activity needs a shared plan, not coordinated solo ones. SharedPlans and 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.
  • Decomposition and delegation are the Contract Net reborn, and the hard part is putting the pieces back together. Delegation needs a clear subtask, a contractor that genuinely commits, and a channel for the result; merging then surfaces the conflicts decomposition postponed.
  • Robustness is monitoring, repair, and the obligation to inform. Detection, replanning, reallocation, and the discipline of keeping the team’s beliefs current separate a resilient team from a brittle assembly of soloists — the machinery Chapter 8 and Part IV build upon next.

7.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 7.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. 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 7.6 the parameter k interpolates between.

Exercise 6. 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.

Further exercises for this chapter continue in the web edition’s exercise bank.

“No conflicts were reported.”