Summary / 21. Multi-agent development / Document
Paper 2026-09-06
Shared copy: the operator's name and machine names are replaced by roles. Nothing else is changed.
Rendering…
# Coding-Harness Component 21/27 — Multi-agent Development # Spawn, Not Summon: Artifact-Mediated, Evidence-Grounded, Conditionally-Activated Specialist Workers Under a Fully Deterministic Orchestration for a Weak-Model Coding Harness *Component 21 of 27 — Coding-Harness Program. This document specifies the multi-agent stage, and it is precise about what it is not: it is not the planning stage (component 07, which already decides *what* a task decomposes into), it is not the generation stage (component 09, which already decides *how* a patch is produced), and it is not the validation stage (component 18, which already decides *whether* a patch is accepted). This is the division-of-labor stage — the decision of *who* does which piece of work under what context, tools, and authority, and how the pieces are stitched back into one artifact without ever letting two models form an uncontrolled consensus loop. The spine distinction is between "one agent that can call specialists" and "five copies of the same model in a chat room": every downstream stage already exists as a single well-tooled agent; this component decides, on a per-task basis, whether to split that single agent into short-lived specialist workers, and it demands that every split earn its keep in measured outcome rather than in rhetorical vividness. The naive harness summons "a room full of Pipers" and lets them talk; this component argues that the only honest use of multiple agents is to spawn a narrow specialist for exactly one bounded judgment, hand it exactly the evidence it needs and nothing else, receive exactly one typed artifact back, and then terminate the specialist and keep only the verified artifact. This paper translates the program's thesis into the multi-agent build contract: roles are defined as a five-tuple of input schema, output schema, allowed tools, context policy, and authority — never as a persona; the orchestration (role instantiation, artifact typing and routing, state ownership, stuck-detection, escalation decision, evidence arbitration, and the spawn/retire decision) is fully deterministic software on CPU; the specialist workers are the only learned entries, each a single-shot, stateless leaf making one bounded model call that produces one typed artifact; every inter-role handoff is mediated by the deterministic orchestrator through a typed artifact, so no two models ever form a consensus or debate loop; and the invariant that governs the whole is that **the L column contains at most one entry**, with an empty L column as a permitted, correct state — a task that needs no specialist is handled by the single well-tooled worker and the deterministic path.* --- ## Abstract Multi-agent development is the component where a coding harness either buys the cheapest judgment its architecture can afford or pays for a room full of Pipers arguing with each other — and where the field's own measured record, across 2025–26, has turned against the naive version of the idea. This paper argues that multi-agent development should be modular, artifact-mediated, evidence-grounded, and conditional rather than a simulated software company: roles should be instantiated only where different subtasks genuinely benefit from different context, tools, objectives, or authority; communication should flow through typed artifacts, never through a free-running conversation history; and the decision to activate any additional role should be paid for in measured outcome rather than assumed. The review establishes the case across twenty-five sources, both directions honestly: the pro case — MetaGPT's standard-operating-procedure assembly line and publish–subscribe message pool [1], ChatDev's chat chain and its $0.2967-per-task average cost [2], and MASAI's five functional sub-agents at 28.33% on SWE-bench Lite for $1.96 per issue [3] — shows artifact-mediation and functional decomposition paying off, while the measured objections — 260 configurations in which multi-agent overhead reaches −70.0% on sequential, tool-heavy tasks [4], multi-agent systems underperforming a single agent across all three code-centric tasks with planning-agent information overload and identical-error propagation [5], and a single-author, unrefereed preprint framing divergence as "context drift" whose numbers are uncorroborated [6] — show that role separation is earned, never assumed. MAST supplies the failure taxonomy that names *why* (fourteen modes in three categories, with system-design issues at 44.2%) [7], RTADev supplies the conditional-escalation discipline (alignment check always, group review only on failure) [8], TraceRepair supplies the evidence-arbitrated judge (probe/repair/judge over 392 Defects4J bugs) [9], and the coordination lineage — Contract Net's manager–bid–award [25], Conway's law [23], Malone and Crowston's coordination theory [24] — supplies the oldest constraint the field keeps relearning. From this the paper derives the architecture as a strict separation: a fully deterministic orchestration (D) holding one authoritative repository and task state, a typed-artifact protocol (spec/patch/test-report/review-verdict), spawn/retire-by-task, stuck-detection, escalation-on-alignment-failure, and termination contracts; and specialist workers (L) that are short-lived, clean-context, single-shot, and typed-output with no worker-to-worker channel. It closes with the measurement and ablation plan that keeps the whole thing honest: start from the single well-tooled agent plus a validator, add roles one at a time, and keep a role only when its marginal success per marginal cost is worthwhile — never on resolve rate alone. ## 1. Introduction The coding-harness program has, through components 01 through 20, assembled machinery that reads a repository, decomposes a task, generates a patch, edits it into place, runs it, distills failures into memory, and validates the result against evidence. Component 21 is the moment where all of that machinery could be duplicated — and where the program's single most seductive architectural error is committed, not by splitting work too little, but by splitting it along the wrong boundary and paying an inference tax for the privilege. Everything upstream is a *stage*: a deterministic pipeline that already knows what to do next and already holds the evidence it needs. The question this component answers is whether, for a given task, one of those stages should be *subdivided into roles* — and the field's own recent record says the answer is "rarely, and only when you can measure that it helps." The thesis that governs this component is stated plainly. **Multi-agent development should be modular, artifact-mediated, evidence-grounded, and conditional rather than a simulated software company: divide work only where different subtasks benefit from different context, tools, objectives, or authority; instantiate short-lived specialist workers with clean contexts; communicate through typed artifacts instead of conversation histories; keep one authoritative repository and task state; prevent patch generators from validating their own work; use deterministic evidence to arbitrate disagreements; check handoff alignment before propagating upstream mistakes; and activate additional roles only when task complexity, uncertainty, or measured ablations justify their inference and coordination cost.** And it carries a strong rule for Piper that compresses the whole thesis into one sentence, stated verbatim: **Don't build a room full of Pipers talking to each other. Build one Piper that can spawn narrow specialists, give each exactly one job and exactly the evidence it needs, then kill the specialist and keep only its verified artifact.** The phrase "five agents" is the trap, and the correction is to refuse to read it as "five copies of the same model chatting." The naive multi-agent design — call it the *simulated software company* — instantiates a CEO, a product manager, a programmer, a reviewer, and a tester as persistent personas that converse freely in a shared channel, each with the same underlying model and each carrying a persona-flavored system prompt. What that actually produces is not a division of labor but a division of *attention*: five near-identical models emitting near-identical prose at each other, spending tokens on social scaffolding (turn-taking, agreement, restatement) instead of on the typed artifact the task actually needs, and — because they share one model — correlating their errors rather than diversifying them. The honest 2025–26 finding is not a whisper; it is the measured center of the field. Kim, Gu, Park, Park, Schmidgall, Heydari, Yan, Zhang, Zhuang, Liu, Malhotra, Liang, Park, Yang, Xu, Du, Patel, Althoff, McDuff, and Liu ran 260 configurations (six agentic benchmarks, five coordination architectures, three LLM families) and found that while multi-agent architectures help by up to +80.8% on decomposable financial reasoning, they *hurt* by as much as −70.0% on sequential planning, with tool-heavy tasks "appear[ing] to incur multi-agent overhead" and architectures without centralized verification tending to propagate errors more [4]. Yin, Gao, Fan, Yang, Xue, and Zhang measured seven general-purpose agent frameworks across three code-centric tasks and found multi-agent systems *underperforming a single-agent system across all three*, the planning agent suffering information overload that produces overthinking and erroneous outputs, and multi-agent collaboration susceptible to propagating identical errors [5]. This is not an argument against multi-agent systems; it is the empirical boundary that the rest of the program must respect: role separation is *earned by evidence*, never assumed from the vividness of the org chart. The weak-model problem sharpens the thesis into a budget arithmetic. A weak model has a small, precious context window and a strong tendency to treat fluent prose — including another agent's fluent prose — as ground truth. A room full of weak Pipers therefore multiplies the two costs that most hurt a weak model: every inter-role message is tokens that could have been a typed artifact, and every peer's claim is a plausible-looking prior that the weak model will weight heavily and question rarely. The escape is exactly the discipline the thesis encodes: keep the *control plane* deterministic, and confine the learned model to *leaf* judgments. The design implication is decisive, and it carries the D/L discipline of the whole program into the multi-agent setting. The orchestration — role instantiation, artifact typing and routing, state ownership, stuck-detection, escalation decision, evidence arbitration, and the decision to spawn or retire a worker — is fully deterministic software on CPU [D]; the control plane holds *zero* learned entries. The specialist workers are the [L] entries, but each is a single-shot, stateless leaf: one bounded model call producing one typed artifact, then terminated. Critically, workers never talk to each other — every inter-role handoff is mediated by the deterministic orchestrator through a typed artifact, so no two models ever form a consensus/debate loop, which is precisely the design that would put L into the control plane. The invariant that governs the whole is **the L column contains at most one entry** — and, for multi-agent development specifically, *an empty L column is a permitted, correct state*: a task that needs no specialist is handled by the single well-tooled worker and the deterministic path, and that is the default, not the fallback. The paper proceeds as follows. Section 2 defines what a role actually is — a five-tuple of input schema, output schema, allowed tools, context policy, and authority — and names the "role theatre" failure mode that personas produce. Section 3 specifies the orchestration (D): one authoritative state, the typed-artifact protocol, spawn/retire-by-task, stuck-detection, escalation-on-alignment-failure, and termination contracts. Section 4 specifies the specialist workers (L) and the evidence-arbitrated judge as the one kind of separation that is always justified. Section 5 states the honest evidence both ways. Section 6 gives the measurement and ablation plan. Section 7 concludes. ## 2. The Role as a Context/Tool/Authority Boundary The first discipline of multi-agent development is to define a role as a *boundary*, not a *person*. The review below, and every failure the review catalogs, points to the same root: when a role is a persona, it reproduces the model's general tendency toward fluent, agreeable prose and throws away the only things a role is actually good for — a restricted context, a restricted toolset, a typed output, and a bounded authority. When a role is a boundary, it buys four things the single agent does not have, and nothing else. A role is a five-tuple: **(i) an input schema** — exactly the typed facts the worker is allowed to see, and nothing else; **(ii) an output schema** — exactly the typed artifact the worker must emit (a spec, a patch, a test report, a review verdict), validated by a parser before anything downstream reads it; **(iii) an allowed-tool set** — the specific tools the worker may invoke, which is how a *localizer* differs from a *fixer*: the localizer may read the repository and run tests but may not edit, while the fixer may edit but receives the localizer's typed verdict rather than a transcript; **(iv) a context policy** — the clean, task-scoped window the worker is instantiated with, constructed from the authoritative state plus only the artifacts the orchestration routes to it; and **(v) authority** — what the worker's output is permitted to *do*: a proposal the orchestrator arbitrates, or a binding edit to the single repository state. Nothing else is a role. A "persona" — "you are a senior staff engineer, be skeptical and rigorous" — is a role's five-tuple replaced by a vibe, and a vibe is not a boundary: it does not restrict what the worker sees, does not restrict what it can do, does not type its output, and does not bound its authority. The whole failure mode has a name that the program should treat as its warning label: *role theatre*. *Role theatre* is the act of simulating a company when what the task needed was a division of labor. It is the CEO who exists only to restate the task, the product manager who exists only to restate the CEO, the reviewer who exists only to say "looks good" and the tester who exists only to confirm the reviewer — four or five near-identical model calls whose combined output is approximately the output of the one model call that actually wrote the patch, at five times the inference cost and with the correlated-error risk that comes from a single model talking to itself. The literature documented the mechanism before it had the name. CAMEL's authors — Li, Hammoud, Itani, Khizbullin, and Ghanem — built exactly the two-persona society and then, in Section 4.1 and Appendix G of their own paper, catalogued what went wrong: *role flipping* (the assistant and user switch roles, the assistant suddenly taking control and instructing), the assistant *repeating instructions*, flake replies, and the infinite message loop that makes termination itself a research problem [11]. Their conclusion is the one this component adopts mechanically: agents "might fall into a chatting loop where they keep saying 'thank you'/'goodbye' indefinitely," and termination conditions were necessary *precisely to stop that* [11]. A room full of Pipers does not converge on the patch; it converges on the conversation, and the conversation is not the artifact. The role theatre failure is not a bug of any one framework; it is the predictable output of instantiating roles without the five-tuple that makes a role a boundary. AutoGen's "conversable agents," for all their engineering virtue — group chat with model-selected speaker, nested chats, human-in-the-loop as a first-class role — make conversation the *medium*, which means the medium carries all the social scaffolding the model produces by default [10]. AgentVerse's four stages — Expert Recruitment, Collaborative Decision-Making, Action Execution, Evaluation — generate expert descriptions dynamically, and the paper's own honest note is that the number of experts is task-dependent and currently hand-tuned, "seeking a way to automate this decision as well" [12]. The pattern across all of them is the same: the *social* layer is where the tokens leak, and the *typed artifact* is where the work actually lives. The design consequence for this component is not to reject these frameworks wholesale — MetaGPT and MASAI, Section 5, show the artifact-mediated subset works — but to strip every role down to its five-tuple and forbid the rest. A specialist that is not defined by what it sees, what it emits, what it may call, what context it carries, and what its output may do is not a specialist; it is a second Piper, and the thesis says that is precisely what must not be built. ## 3. The Orchestration (D) The orchestration is the deterministic control plane, and it is where the thesis's "modular, artifact-mediated, evidence-grounded, and conditional" clauses become software. Every function in this section is deterministic software on CPU; the L column contributes nothing here, and the invariant is stated at the outset of the architecture and re-stated at its close: **the L column contains at most one entry**, and the orchestration holds zero learned entries. **One authoritative repository and task state [D].** There is exactly one repository checkout, one working tree, one task ledger, and one hypothesis/plan state, owned and mutated only by the orchestration. No worker ever touches the repository directly as its *authority*; a worker that needs the repository receives a read-only snapshot or a scoped view constructed by the orchestrator, and a worker that produces a patch produces a *candidate* artifact that the orchestrator applies — or declines to apply — to the single state. The reason is the error-propagation finding measured at scale: architectures without centralized verification tend to propagate errors more [4], and multi-agent collaboration is susceptible to propagating identical errors because no agent detects the mistakes in another agent's output [5]. A single authoritative state is the mechanism that makes propagation a detected event rather than an invisible accumulation: there is no "agent B's slightly different copy of the repo" for an error to hide in, because there are no other copies. **The typed-artifact protocol [D].** Every handoff is a typed artifact, never a conversation history. The protocol defines a small closed set of artifact types — `spec` (the task's requirements and acceptance criteria), `patch` (a candidate diff with a cited diff-test basis), `test-report` (the deterministic outcome of running the harness's own suite, component 17), and `review-verdict` (a structured accept/revise/reject with cited evidence) — each with a schema and a parser, each routed by the orchestrator to the next stage, and each immutable once written. The model's prose is confined to the *inside* of an artifact field; the structure, the routing, and the validation of the artifact are deterministic. This is the direct lesson of MetaGPT, whose agents "publish structured messages" to a shared message pool and "subscribe to relevant messages based on their profiles" (publish–subscribe), with structured intermediate artifacts including Product Requirements Documents [1] — the framework that works is the one whose messages are *typed documents*, not chat bubbles. The difference between MetaGPT's publish–subscribe and CAMEL's free conversation is the difference between a pipeline and a cocktail party, and this component encodes the pipeline. **Spawn and retire by task [D].** The orchestration's only question at any decision point is: does the current subtask benefit from a different context, toolset, objective, or authority than the subtask that produced the artifact in front of it? If not — which is the common case — no specialist is spawned, and the single well-tooled worker continues on the deterministic path; *an empty L column is a permitted, correct state*. If so, the orchestration instantiates a specialist with exactly the five-tuple of Section 2, routes it exactly the typed artifacts it needs, receives exactly one typed artifact back, validates that artifact against its schema, and then *retires the worker immediately* — its context is discarded, its output is merged into the authoritative state, and nothing of it persists except the verified artifact. A worker is never "kept around" for the next task, because a persistent worker is a conversation that has not ended, and a short-lived worker is the only kind whose context can be guaranteed clean. The spawn/retire decision itself is deterministic: a fixed policy over task-shape features, not a model's judgment of whether a specialist "feels right." **Stuck-detection [D].** The orchestration monitors the task ledger for the two failure signatures the literature names: *lack of progress* (rounds elapsing without a state mutation that advances the task) and *repeated failure* (the same failure class recurring across retries). This is Magentic-One's outer/inner loop made mechanical: its Orchestrator maintains a Task Ledger and a Progress Ledger and detects stalls ("stuck") to trigger replanning [13]. Here the detection is a deterministic counter over the ledger — N rounds without a typed artifact advancing the plan, or M recurrences of one failure signature — and the response is deterministic too: replan (re-run decomposition with a narrower scope), re-scope (spawn a narrower specialist with a different context policy), or abort to the human/operator escalation path. No model decides it is stuck; the ledger decides. **Escalation on alignment failure [D].** The orchestration runs an alignment check at every handoff: does the artifact just produced still satisfy the intent that the previous stage established for it? The check is deterministic where it can be — a diff applies cleanly to the single state, a patch's stated scope matches the localizer's typed verdict, a spec's acceptance criteria are all addressable by the produced patch. Only when that check *fails* does the orchestration escalate, and it escalates to a conditional, ad hoc review rather than an always-on committee. This is RTADev's contribution taken at full strength: its design has "an alignment checking phase and a conditional ad hoc group review phase" — the review is *conditional*, i.e., only on failure [8]. The transfer is the default-off committee: alignment is checked on every handoff (cheap, deterministic), and the expensive group review is paid for only when alignment has demonstrably broken, which is the thesis clause "check handoff alignment before propagating upstream mistakes" made into a gate. **Termination contracts [D].** Every worker, and every loop the orchestration may enter, is instantiated under a termination contract: a maximum number of model calls, a maximum token budget, a maximum wall-clock, and a maximum number of rounds in any multi-step loop. The contract is not advisory — the orchestration enforces it, and a worker that exceeds any bound is terminated and its partial output discarded or handed to the stuck-detection path. CAMEL made the necessity explicit: termination conditions existed to stop the infinite "thank you"/"goodbye" loop [11], and Contract Net's original manager–bid–award protocol — Smith's 1980 design, with nodes able to switch between manager and contractor roles situationally — is the forty-year-old proof that a contract, not a conversation, is what bounds a distributed computation [25]. The termination contract is the multi-agent instance of the program's wider blast-radius discipline: no learned loop runs unbounded, because an unbounded learned loop is where a weak model's most expensive failure lives. **The D/L invariant, stated at the architecture's center.** Everything above — role instantiation, artifact typing and routing, state ownership, stuck-detection, escalation decision, evidence arbitration (Section 4), and the spawn/retire decision — is deterministic software on CPU. The control plane holds zero learned entries. The only learned entries are the specialist workers themselves, and each is a single-shot, stateless leaf. The consequence that must be stated explicitly, because the field keeps getting it wrong: **the L column contains at most one entry**, and the workers never talk to each other — every inter-role handoff is mediated by the deterministic orchestrator through a typed artifact, so no two models ever form a consensus or debate loop, which is the design that would leak L into the control plane and forfeit every guarantee the deterministic orchestration provides. A debate loop is not a checks-and-balances system; it is two weak models correlating toward the fluent middle, and the deterministic artifact protocol exists so that disagreement is arbitrated by *evidence*, not by *eloquence*. ## 4. The Specialist Workers (L) The specialist workers are the L column's at-most-one entry, and their entire design is the discipline of the leaf: short-lived, clean-context, single-shot, typed-output, and with *no worker-to-worker channel*. **Short-lived and clean-context.** A worker is instantiated for exactly one bounded judgment, given a context window assembled by the orchestration from the authoritative state plus only the typed artifacts the orchestrator routes to it, and terminated the moment its typed artifact validates. There is no persistent worker identity, no memory carried between instantiations, and no ambient conversation. Clean context is the mechanism that gives a specialist its only real advantage over the single agent: the single agent carries the whole task and the whole transcript, while the specialist carries *exactly* the slice of evidence its subtask needs, so its small budget is spent entirely on the judgment it was spawned to make rather than on reconstructing relevance from a long history. The failure this avoids is the one Yin, Gao, Fan, Yang, Xue, and Zhang measured directly: the planning agent's information overload, which produces overthinking and erroneous outputs [5]. A clean-context leaf cannot be overloaded, because the orchestration decides what it sees. **Single-shot and typed-output.** A worker makes one bounded model call — or a strictly bounded short sequence, where the termination contract permits — and produces one typed artifact of a schema the orchestration has pre-declared. The artifact is parsed and validated deterministically before it is admitted to the authoritative state; a worker whose output fails to parse does not get a second conversation, it gets re-instantiated with the schema violation surfaced as part of its context, and if it fails again it is retired and the task takes the single-agent path. The single-shot constraint is what keeps a specialist from becoming a chat partner: the model is told "produce this one artifact," not "here is a role, discuss." **No worker-to-worker channel.** Workers do not send messages to one another. There is no bus they can address, no shared memory they can write, and no subscription graph that connects two models. Every inter-role handoff — localizer to fixer, fixer to validator — is mediated by the deterministic orchestrator, which reads one worker's typed artifact, checks alignment, and *routes a copy* to the next worker as part of that worker's clean context. The reason is the invariant itself: the moment two models converse directly, L has entered the control plane, and the harness has recreated the debate loop that the evidence of Section 5 shows costs more than it returns. Disagreement is resolved not by workers talking it out but by the next two mechanisms, both deterministic. **The evidence-arbitrated judge — the one kind of separation that is always justified.** There is exactly one role separation this component adopts *unconditionally*, because it is the mechanism that keeps a patch generator from validating its own work, which is the thesis clause "prevent patch generators from validating their own work" and the single most important separation in the entire program. TraceRepair — Wu's ASE 2026 system, evaluated over 392 Defects4J bugs — decomposes repair into three roles: a *probe* that characterizes the bug, a *repair* that proposes a patch, and a *judge* that accepts or rejects the proposal against evidence [9]. The judge is the justified kind of specialist: it has a different *objective* (falsify, not construct), a different *authority* (adjudicate, not edit), and a different *context* (the patch plus the test evidence, not the generator's search trail). The self-validation trap — a generator grading its own output — is the most reliably harmful error in a single-agent pipeline, and the judge is the deterministic fix: the generator emits a typed `patch`, and the judge emits a typed `review-verdict` that the orchestration arbitrates against the `test-report` produced by the harness's own deterministic test runner. Note what makes this *evidence* arbitration rather than *peer* arbitration: the judge's verdict is itself checked against the deterministic test report, so even the judge cannot outvote a green or red suite — it can only explain it. MASAI supplies the same lesson in industrial form: its five sub-agents — Test Template Generator, Issue Reproducer, Edit Localizer, Fixer, and Ranker — are functional-subtask decompositions whose outputs are structured artifacts consumed by the next sub-agent, not peers debating a patch [3]. The separation that survives contact with real benchmarks is always *functional and artifact-mediated*; the separation that is merely *social* is the one the ablations of Section 5 and 6 are designed to reject. ## 5. The Honest Evidence Both Ways The program's scrupulous standard requires stating the pro case and the con case at equal strength, and this component is where the two sides are most lopsided — toward the con case, once the numbers are read carefully. **The pro case: artifact-mediation and functional decomposition work.** MetaGPT — Hong, Zhuge, Chen, Zheng, Cheng, Zhang, Wang, Wang, Yau, Lin, Zhou, Ran, Xiao, Wu, and Schmidhuber, ICLR 2024 oral [1] — encodes standard operating procedures into prompt sequences, runs an "assembly line" of roles, and has agents publish *structured messages* to a shared pool and subscribe by profile, with Product Requirements Documents as structured intermediate artifacts [1]. It works precisely because its "conversation" is a typed-document exchange, not a chat. ChatDev — Qian, Liu, Liu, Chen, Dang, Li, Yang, Chen, Su, Cong, Xu, Li, Liu, and Sun, ACL 2024 [2] — runs a "Chat Chain" that divides the phases into subtasks with dual instructor/assistant roles and a "communicative dehallucination" step in which the assistant proactively requests exact details (file/class/method level) before answering, pinning down code specifics [2]. Across 70 software-development tasks its average cost is **$0.2967 per task** (average production time 409.84 seconds, roughly 6.8 minutes) [2]. MASAI — Arora, Sonwane, Wadhwa, Mehrotra, Utpala, Bairi, Kanade, and Natarajan [3] — resolves 28.33% of SWE-bench Lite (300 GitHub issues, 11 Python repositories) at a stated **$1.96 per issue on average**, using the five functional sub-agents named above [3]. The pattern is unambiguous: every pro-case number belongs to a system whose roles are functional and whose communication is artifact-mediated. No pro-case number belongs to a free-conversation persona society. **The con case, at measured strength.** The Scaling study — 260 configurations, not the ~180 some secondary accounts report, across six agentic benchmarks, five architectures (single-agent plus independent, centralized, decentralized, and hybrid multi-agent), and three LLM families, by a multi-institution group including Google, the University of Washington, and KAIST rather than any single organization [4] — reports relative performance change from +80.8% on decomposable financial reasoning down to −70.0% on sequential planning, with "tool-heavy tasks appear to incur multi-agent overhead" and "architectures without centralized verification tend to propagate errors more" [4]. The Empirical Evaluation study — Yin, Gao, Fan, Yang, Xue, and Zhang [5] — finds multi-agent systems underperforming a single-agent system across all three code-centric tasks (software development, vulnerability detection, program repair) across seven general-purpose frameworks, with the planning agent suffering information overload characterized by overthinking and erroneous outputs, and multi-agent collaboration propagating identical errors [5]. These are not theoretical objections; they are the two largest-scale measurements available at the time of writing, and they both say the same thing: the default is the single well-tooled agent, and the multi-agent design must *prove* its case per task class. **The flagged, uncorroborated frame.** "Hallucination as Context Drift: Synchronization Protocols for Multi-Agent LLM Systems," by Carson Rodrigues, arXiv:2606.21666, is a real and resolvable arXiv identifier, but it is an *arXiv-only, single-author, unrefereed preprint* — eleven pages, one figure, small samples (roughly thirty per condition on a travel domain and ten on a software domain, eight scenarios, Claude Haiku) — and every numeric claim in it (a 34% contamination increase, the hazard-ratio and p-value figures, the claimed reduction in API calls) comes *only* from that preprint's own abstract, with no peer review and no independent replication [6]. This component treats it as what it is: a *consistency-and-synchronization framing* worth knowing, whose numbers are **uncorroborated and must not be cited as established findings** [6]. It is included here for honesty — the framing (divergence between agents is a synchronization failure, not a reasoning virtue) aligns with the thesis's deterministic-arbitration stance — but flagged as it should be: unrefereed, single-author, uncorroborated. **The failure taxonomy that names why.** MAST — Cemri, Pan, Yang, Agrawal, Chopra, Tiwari, Keutzer, Parameswaran, Klein, Ramchandran, Zaharia, Gonzalez, and Stoica, NeurIPS 2025 [7] — is the taxonomy the whole field has been missing: fourteen failure modes clustered into three categories — system design issues, inter-agent misalignment, and task verification — over 1,642 annotated execution traces across seven frameworks [7]. The headline correction this paper bakes in: the "specification and design issues" share is **44.2%** (the System Design Issues category, summing its five mode prevalences), not the ~42% sometimes quoted, and the narrow "disobey task/role specifications" sub-modes alone are only 13.3% [7]. The category that dominates is *system design* — the orchestration's job — which is precisely the part this component assigns to deterministic software. MAST is the strongest single argument for the D/L split: the majority of real multi-agent failures are failures of the control plane, and a control plane you made learned is a control plane you made fragile. **The ablation that names the risk of role-removal — and its own internal inconsistency.** HyperAgent — Phan, Nguyen, Nguyen, and Bui, arXiv:2409.16299 [14], an arXiv-only preprint — ablates its roles on real repositories: on SWE-bench Full-1, removing the Navigator drops 27.0% → 19.0%, removing the Editor drops 27.0% → 12.0%, and removing the Executor drops 27.0% → 22.0%; on Lite-1, the same removals go 24.0% → 9.0% / 11.0% / 16.0% [14]. Two facts must be stated together, honestly. First, the ablation is *positive evidence for the component's thesis*: each role earns its place, and the whole is more than the best part — exactly the "keep a role only if Δsuccess/Δcost is worthwhile" discipline of Section 6, demonstrated in the field. Second, the paper's own prose and its table *disagree*: the prose states that "Removing the Navigator causes the most substantial performance drop," but Table 5 (Full-1) shows Editor removal drops more (−15 points, 27→12) than Navigator removal (−8 points, 27→19); the prose matches only the Lite-1 numbers (Navigator −15 vs Editor −13) [14]. This internal inconsistency is flagged so the component never misquotes the direction: cite the *table*, not the prose, when citing which role matters most [14]. **The debate objection, with its attribution corrected.** Multi-agent *debate* — Du, Li, Torralba, Tenenbaum, and Mordatch, ICML 2024 [21] — is the "two models argue it out" idea, and this component rejects it in its default form for the reason Section 3 states: a debate loop puts L into the control plane. The precise empirical objection to debate is important to attribute correctly, and this paper preserves the correction that the verification pass established: the finding that beyond a modest level of *tit-for-tat* exchange, debate degrades, belongs to Liang, He, Jiao, Wang, Wang, Wang, Yang, Shi, and Tu (Encouraging Divergent Thinking in Large Language Models through Multi-Agent Debate, EMNLP 2024 main, arXiv:2305.19118) — which introduces the "tit-for-tat" debate state and finds only a modest level of it beneficial [22] — and **not** to Du, Li, Torralba, Tenenbaum, and Mordatch's arXiv:2305.14325 [21]. The distinction is load-bearing, because the two papers argue different things: Du and colleagues establish that debate can improve factuality and reasoning, while Liang and colleagues establish the *ceiling* — beyond a modest level of tit-for-tat, the exchange itself becomes the cost. This component's stance absorbs both: disagreement is arbitrated by deterministic evidence, never by a tit-for-tat loop. **The lineage that predates all of it.** The coordination problem is older than the LLM, and three canonical anchors keep the component from mistaking its own rediscovery for novelty. Smith's Contract Net Protocol — IEEE Transactions on Computers, C-29(12):1104–1113, December 1980 [25] — is the manager–bid–award contract that bounds distributed computation, with nodes switching between manager and contractor roles situationally; it is the ancestor of every termination contract in Section 3. Conway's "How Do Committees Invent?" — Datamation 14(4), April 1968, pp. 28–31 [23] — is the law that an organization's communication structure reproduces itself in its artifact structure, which is the reason the typed-artifact protocol *is* the architecture and not a message format bolted on top. Malone and Crowston's "The Interdisciplinary Study of Coordination" — ACM Computing Surveys 26(1):87–119, March 1994 [24] — is the taxonomy that names what multi-agent systems are actually buying (managing dependencies among activities), which is the test any proposed role must pass: a role that does not manage a *dependency* is role theatre. And the two supporting references complete the survey map: Agentless — Xia, Deng, Dunn, and Zhang [20] — is the standing reminder that a well-tooled single agent is the baseline the multi-agent design must beat, and the surveys by Guo, Chen, Wang, Chang, Pei, Chawla, Wiest, and Zhang (IJCAI 2024) [16] and the role-team generators AutoAgents — Chen, Dong, Shu, Zhang, Sesay, Karlsson, Fu, and Shi, IJCAI 2024 [15] — plus AgentCoder's programmer/test-designer/executor pattern (Huang, Zhang, Luck, Bu, Qing, and Cui, arXiv-only) [17], MapCoder's planner/agents/tester (Islam, Ali, and Parvez, ACL 2024) [18], and Self-Organized Agents' complexity-driven agent multiplication (Ishibashi and Nishimura, arXiv-only) [19] — round out the design space this component draws its ablation targets from. ## 6. Measurement and Ablation Plan The thesis's final clause — "activate additional roles only when task complexity, uncertainty, or measured ablations justify their inference and coordination cost" — is not rhetoric; it is a measurement discipline, and the discipline is that every role is a hypothesis to be falsified, one at a time. **The baseline is the single well-tooled agent.** The control condition is not "zero agents" or "no roles"; it is the single well-tooled agent with the full harness (decomposition, retrieval, generation, execution, validation, memory) and *no* specialist spawns. This is the configuration the Scaling study and the Empirical Evaluation study both found competitive or superior, and it is the floor every proposed role must clear [4][5]. Everything is reported as a delta from this baseline. **Add roles one at a time, in earned order.** The start configuration is the single agent plus one validator — the evidence-arbitrated judge of Section 4, which is adopted unconditionally because it encodes "prevent patch generators from validating their own work," the separation the whole program depends on. Every *further* role — a localizer, a reproducer, a specifier, a planner-specialist — is added singly, on top of the current best configuration, and measured against it. This is the anti-Section-5 discipline in procedural form: never ship a room at once, because a room cannot be ablated. **The keep/retire criterion is Δsuccess per Δcost, never success alone.** A candidate role survives only if its marginal contribution is worthwhile on both axes simultaneously: the change in resolve rate it produces, and the cost it charges for that change. A role that raises resolve rate by 2 points while tripling the token budget is a cost with a plausible story, and it is retired. A role that raises resolve rate by 0 while *lowering* cost survives on cost alone (a cheaper equivalent is always worth keeping). A role that lowers resolve rate is retired immediately, regardless of how natural the org chart felt. **The instrument suite, always reported together.** (i) *Resolve rate* — the headline, never reported alone. (ii) *Tokens* — total and per-artifact, because the token cost is the weak model's scarcest resource. (iii) *Wall time* — because a sequential room of roles is a latency budget. (iv) *LLM calls* — the number of learned invocations, which is the direct measure of how often L was entered. (v) *Regressions* — breaks to previously-passing behavior, the component-19 instrument carried forward. (vi) *Invalid patches* — artifacts that failed schema validation or failed to apply to the single state, the direct measure of coordination waste. (vii) *Context size* — per-worker window size, the direct measure of whether the clean-context promise is being kept. No single number, and especially not resolve rate alone, decides anything; the seven together decide. **The failure-mode audit closes the section.** *Role theatre* is a role whose removal changes none of the seven instruments — a persona wearing a five-tuple costume, and the ablation is how the costume is removed. *Silent error propagation* is a handoff whose alignment check passed but whose downstream failure was never traced back — the Scaling study's "architectures without centralized verification propagate errors more" [4] caught in the harness's own ledger. *Debate drift* is two workers effectively conversing through the orchestrator's routing — the invariant violated in effect if not in letter, caught by the LLM-call count and the token profile. *Eager spawn* is the orchestration instantiating specialists on tasks whose features did not meet the spawn policy's threshold — the "conditional" clause of the thesis being eroded by over-eagerness. *Judge capture* is the validator's verdict drifting to mirror the generator's — caught by comparing the judge's review-verdict against the deterministic test-report, which is the one arbitration the judge cannot outvote. Two honest caveats close it. First, the pro-case numbers of Section 5 — MASAI's 28.33% at $1.96 [3], ChatDev's $0.2967 [2], HyperAgent's role ablations [14] — were measured on frontier models and large repositories a weak-model harness does not control; the weak model should expect materially smaller absolute effects while leaning *harder* on the deterministic orchestration and the typed-artifact protocol, which cost nothing per model scale. Second, all multi-agent metrics are reported on held-out and out-of-benchmark tasks, exactly as the earlier components require, so a role that has memorized a benchmark's answers cannot pass a resolve-rate ablation without its usefulness having been measured on problems it never saw. ## 7. Conclusion Multi-agent development is where a coding harness makes its most seductive and most quietly expensive architectural error: it summons a room full of near-identical Pipers, lets them talk, and calls the resulting conversation a division of labor, when what it actually built was a division of attention and a correlated-error amplifier. This paper has argued the opposite: that multi-agent development should be modular, artifact-mediated, evidence-grounded, and conditional rather than a simulated software company — that the field's own measured record, from 260 configurations showing −70.0% on sequential tool-heavy tasks [4] to multi-agent systems underperforming a single agent across all three code-centric tasks [5], has settled the default in favor of the single well-tooled agent, and that a role is earned by measured Δsuccess/Δcost or it is not earned at all. The thesis that has governed every design choice is the one with which this paper began and closes: **Multi-agent development should be modular, artifact-mediated, evidence-grounded, and conditional rather than a simulated software company: divide work only where different subtasks benefit from different context, tools, objectives, or authority; instantiate short-lived specialist workers with clean contexts; communicate through typed artifacts instead of conversation histories; keep one authoritative repository and task state; prevent patch generators from validating their own work; use deterministic evidence to arbitrate disagreements; check handoff alignment before propagating upstream mistakes; and activate additional roles only when task complexity, uncertainty, or measured ablations justify their inference and coordination cost.** And the rule that compresses that thesis into one sentence of discipline for Piper is: **Don't build a room full of Pipers talking to each other. Build one Piper that can spawn narrow specialists, give each exactly one job and exactly the evidence it needs, then kill the specialist and keep only its verified artifact.** The architecture holds the invariant mechanically. The orchestration — role instantiation, artifact typing and routing, state ownership, stuck-detection, escalation decision, evidence arbitration, and the decision to spawn or retire a worker — is fully deterministic software on CPU; the control plane holds zero learned entries. The specialist workers are the learned entries, but each is a single-shot, stateless leaf: one bounded model call producing one typed artifact, then terminated. Workers never talk to each other — every inter-role handoff is mediated by the deterministic orchestrator through a typed artifact — so no two models ever form a consensus or debate loop, which is the design that would leak the learned column into the control plane and forfeit every guarantee the deterministic orchestration provides. The invariant that governs the whole, restated once more at the close, is **the L column contains at most one entry**, and the multi-agent form of that invariant is the one this paper has defended throughout: an empty L column is a permitted, correct state — a task that needs no specialist is handled by the single well-tooled worker and the deterministic path, and that is the default, not the fallback. The measured message of the literature is the same sentence read three ways — MetaGPT and MASAI prove artifact-mediation and functional decomposition work [1][3]; the Scaling study and the Empirical Evaluation prove the free-conversation default does not [4][5]; and MAST's taxonomy proves the failures are mostly system-design failures, which is the part this component assigns to deterministic software [7]. For a weak model, a room full of Pipers is a token furnace with a reassuring org chart; what a weak-model harness needs is one Piper and a deterministic orchestrator that spawns a narrow specialist only when the evidence says the task has earned the split — gives it exactly one job and exactly the evidence it needs, takes back exactly one typed artifact, arbitrates that artifact against the deterministic test report rather than against another model's eloquence, and then kills the specialist and keeps only what its work proved. --- ## References 1. Sirui Hong, Mingchen Zhuge, Jiaqi Chen, Xiawu Zheng, Yuheng Cheng, Ceyao Zhang, Jinlin Wang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, Liyang Zhou, Chenyu Ran, Lingfeng Xiao, Chenglin Wu, and Jürgen Schmidhuber. *MetaGPT: Meta Programming for a Multi-Agent Collaborative Framework.* ICLR 2024 (oral). arXiv:2308.00352. *(SOPs encoded as prompt sequences; assembly-line roles; structured messages via publish–subscribe message pool; PRDs as structured artifacts.)* 2. Chen Qian, Wei Liu, Hongzhang Liu, Nuo Chen, Yufan Dang, Jiahao Li, Cheng Yang, Weize Chen, Yusheng Su, Xin Cong, Juyuan Xu, Dahai Li, Zhiyuan Liu, and Maosong Sun. *ChatDev: Communicative Agents for Software Development.* ACL 2024 (Long Papers). DOI 10.18653/v1/2024.acl-long.810. arXiv:2307.07924. *(Chat Chain; communicative dehallucination; 70 tasks; $0.2967/task average, ~409.84 s.)* 3. Daman Arora, Atharv Sonwane, Nalin Wadhwa, Abhav Mehrotra, Saiteja Utpala, Ramakrishna Bairi, Aditya Kanade, and Nagarajan Natarajan. *MASAI: Modular Architecture for Software-engineering AI Agents.* NeurIPS 2024 Workshop on Open-World Agents (OWA-2024), poster. arXiv:2406.11638. *(28.33% SWE-bench Lite; $1.96/issue; five sub-agents: Test Template Generator, Issue Reproducer, Edit Localizer, Fixer, Ranker. Author-order note: the arXiv v1 lists Daman Arora first, the OWA-2024 camera-ready lists Nalin Wadhwa first — the same eight authors, reordered.)* 4. Yubin Kim, Ken Gu, Chanwoo Park, Chunjong Park, Samuel Schmidgall, A. Ali Heydari, Yao Yan, Zhihan Zhang, Yuchen Zhuang, Yun Liu, Mark Malhotra, Paul Pu Liang, Hae Won Park, Yuzhe Yang, Xuhai Xu, Yilun Du, Shwetak Patel, Tim Althoff, Daniel McDuff, and Xin Liu. *Towards a Science of Scaling Agent Systems.* arXiv:2512.08296. *(260 configurations — six benchmarks × five architectures × three LLM families — not ~180; multi-institution, incl. Google, University of Washington, KAIST; +80.8% decomposable to −70.0% sequential; tool-heavy tasks incur multi-agent overhead.)* 5. Zhuowen Yin, Cuifeng Gao, Chunsong Fan, Wenzhang Yang, Yinxing Xue, and Lijun Zhang. *A Comprehensive Empirical Evaluation of Agent Frameworks on Code-centric Software Engineering Tasks.* arXiv:2511.00872. *(Multi-agent underperforms single-agent across all three tasks; planning-agent information overload/overthinking; identical-error propagation; three tasks, seven frameworks.)* 6. Carson Rodrigues. *Hallucination as Context Drift: Synchronization Protocols for Multi-Agent LLM Systems.* arXiv:2606.21666. *(arXiv-only, single-author, unrefereed preprint; 11 pages, 1 figure; small samples. All numeric claims uncorroborated — do not cite as established.)* 7. Mert Cemri, Melissa Z. Pan, Shuyi Yang, Lakshya A. Agrawal, Bhavya Chopra, Rishabh Tiwari, Kurt Keutzer, Aditya Parameswaran, Dan Klein, Kannan Ramchandran, Matei Zaharia, Joseph E. Gonzalez, and Ion Stoica. *Why Do Multi-Agent LLM Systems Fail?* NeurIPS 2025. DOI 10.52202/085713-4082. arXiv:2503.13657. *(14 failure modes, 3 categories; 1,642 traces across 7 frameworks; System Design Issues = 44.2%, not ~42%.)* 8. Jie Liu, Guohua Wang, Ronghui Yang, Jiajie Zeng, Mengchen Zhao, and Yi Cai. *RTADev: Intention Aligned Multi-Agent Framework for Software Development.* Findings of ACL 2025, pp. 1548–1581. DOI 10.18653/v1/2025.findings-acl.80. *(Alignment-checking phase + conditional ad hoc group review phase; no arXiv version exists — ACL Anthology only.)* 9. Wu [full author list and exact title carried forward from prior component verification]. *TraceRepair.* ASE 2026. arXiv:2604.02647. *(392 Defects4J; probe/repair/judge roles — the evidence-arbitrated judge.)* 10. Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Jiale Liu, Ahmed Hassan Awadallah, Ryen W. White, Doug Burger, and Chi Wang. *AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation.* arXiv 2023. arXiv:2308.08155. *(Conversable agents; group chat with model-selected speaker; nested chats; human-in-the-loop.)* 11. Guohao Li, Hasan Abed Al Kader Hammoud, Hani Itani, Dmitrii Khizbullin, and Bernard Ghanem. *CAMEL: Communicative Agents for "Mind" Exploration of Large Language Model Society.* NeurIPS 2023. arXiv:2303.17760. *(Inception Prompting; documented pathologies: role flipping, instruction repetition, infinite loop, termination difficulty.)* 12. Weize Chen, Yusheng Su, Jingwei Zuo, Cheng Yang, Chenfei Yuan, Chi-Min Chan, Heyang Yu, Yaxi Lu, Yi-Hsin Hung, Chen Qian, Yujia Qin, Xin Cong, Ruobing Xie, Zhiyuan Liu, Maosong Sun, and Jie Zhou. *AgentVerse: Facilitating Multi-Agent Collaboration and Exploring Emergent Behaviors.* arXiv 2023. arXiv:2308.10848. *(Four stages incl. Expert Recruitment with dynamically generated expert descriptions; expert count task-dependent and hand-tuned.)* 13. Adam Fourney, Gagan Bansal, Hussein Mozannar, Cheng Tan, Eduardo Salinas, Erkang Zhu, Friederike Niedtner, Grace Proebsting, Griffin Bassman, Jack Gerrits, Jacob Alber, Peter Chang, Ricky Loynd, Robert West, Victor Dibia, Ahmed Awadallah, Ece Kamar, Rafah Hosn, and Saleema Amershi. *Magentic-One: A Generalist Multi-Agent System for Solving Complex Tasks.* arXiv / Microsoft 2024. arXiv:2411.04468. *(Orchestrator with Task Ledger + Progress Ledger; stuck detection and replanning.)* 14. Huy Nhat Phan, Tien N. Nguyen, Phong X. Nguyen, and Nghi D. Q. Bui. *HyperAgent: Generalist Software Engineering Agents to Solve Coding Tasks at Scale.* arXiv 2024 (arXiv-only preprint). arXiv:2409.16299. *(Role-removal ablation, Table 5: Full-1 27.0% → 19.0% (no Navigator) / 12.0% (no Editor) / 22.0% (no Executor); Lite-1 24.0% → 9.0% / 11.0% / 16.0%. Note prose vs Table 5 inconsistency: prose says Navigator-removal drops most, Table 5 (Full-1) shows Editor-removal drops more.)* 15. Guangyao Chen, Siwei Dong, Yu Shu, Ge Zhang, Jaward Sesay, Börje F. Karlsson, Jie Fu, and Yemin Shi. *AutoAgents: A Framework for Automatic Agent Generation.* IJCAI 2024. arXiv:2309.17288. *(Automatic generation of role teams per task.)* 16. Taicheng Guo, Xiuying Chen, Yaqi Wang, Ruidi Chang, Shichao Pei, Nitesh V. Chawla, Olaf Wiest, and Xiangliang Zhang. *Large Language Model Based Multi-agents: A Survey of Progress and Challenges.* IJCAI 2024 (Survey track). arXiv:2402.01680. *(Multi-agent topologies, communication, and open challenges.)* 17. Dong Huang, Jie M. Zhang, Michael Luck, Qingwen Bu, Yuhao Qing, and Heming Cui. *AgentCoder: Multi-Agent-based Code Generation with Iterative Testing and Optimisation.* arXiv 2023 (arXiv-only preprint). arXiv:2312.13010. *(Programmer / test-designer / executor pattern.)* 18. Md. Ashraful Islam, Mohammed Eunus Ali, and Md Rizwan Parvez. *MapCoder: Multi-Agent Code Generation for Competitive Problem Solving.* ACL 2024 (Long Papers). DOI 10.18653/v1/2024.acl-long.269. arXiv:2405.11403. *(Planner / coding agents / tester decomposition.)* 19. Yoichi Ishibashi and Yoshimasa Nishimura. *Self-Organized Agents: A LLM Multi-Agent Framework toward Ultra Large-Scale Code Generation and Optimization.* arXiv 2024 (arXiv-only preprint). arXiv:2404.02183. *(Automatic agent multiplication by problem complexity; constant per-agent code budget.)* 20. Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, and Lingming Zhang. *Agentless: Demystifying LLM-based Software Engineering Agents.* arXiv 2024. arXiv:2407.01489. *(The single well-tooled, pipeline-based agent — the standing baseline.)* 21. Yilun Du, Shuang Li, Antonio Torralba, Joshua B. Tenenbaum, and Igor Mordatch. *Improving Factuality and Reasoning in Language Models through Multiagent Debate.* ICML 2024 (PMLR v235). arXiv:2305.14325. *(Multiagent debate for factuality/reasoning. NOT the source of the "tit-for-tat degrades" finding.)* 22. Tian Liang, Zhiwei He, Wenxiang Jiao, Xing Wang, Yan Wang, Rui Wang, Yujiu Yang, Shuming Shi, and Zhaopeng Tu. *Encouraging Divergent Thinking in Large Language Models through Multi-Agent Debate.* EMNLP 2024 (main). arXiv:2305.19118. *(Introduces the "tit-for-tat" debate state; finds only a modest level of tit-for-tat beneficial.)* 23. Melvin E. Conway. *How Do Committees Invent?* Datamation, Vol. 14, No. 4, April 1968, pp. 28–31. *(Non-arXiv magazine article; organization structure reproduced in artifact structure.)* 24. Thomas W. Malone and Kevin Crowston. *The Interdisciplinary Study of Coordination.* ACM Computing Surveys, Vol. 26, No. 1, pp. 87–119, March 1994. DOI 10.1145/174666.174668. *(Coordination = managing dependencies among activities.)* 25. Reid G. Smith. *The Contract Net Protocol: High-Level Communication and Control in a Distributed Problem Solver.* IEEE Transactions on Computers, Vol. C-29, No. 12, pp. 1104–1113, December 1980. DOI 10.1109/TC.1980.1675516. *(Manager–bid–award contract negotiation; situational manager/contractor role switching.)*