Getting a Grip: Operating Human-Agent Software Teams Through Governed Messages

Michael Granitzer; Kanishka Ghosh Dastidar; Andreas Einwiller; Jelena Mitrović; Saber Zerhoudi

cs.SEOct 31, 2026

Getting a Grip: Operating Human-Agent Software Teams Through Governed Messages

Authors: Michael Granitzer, Kanishka Ghosh Dastidar, Andreas Einwiller, Jelena Mitrović, Saber Zerhoudi

Organizations: University of Passau Germany · IT:U Interdisciplinary Transformation University Austria Linz, Austria

Abstract

Software is increasingly developed by teams in which several people direct many coding agents from different vendors. Such teams must establish who may request what from whom, which messages start work, which decisions bind, and who caused a change. We propose to govern a human-agent team through its message protocol and present yoars, a relay in which humans and agents are authenticated principals that exchange typed, addressed messages in rooms holding goals, decision rules, routing and an attributable, append-only record. This report gives the architecture, the full controlled study and the field material. In 926 controlled runs (899 analyzable), small agent teams built programs under varied room rules, some with a hostile member planting a backdoor. Revising which messages start work, bundled with limits on repeated messages, was followed by a drop in total coordination failure from 42% to 13% (p = .0063, adjusted p = .057 over nine registered tests). Instructed roles and votes did not reliably produce the intended process, and no defense inside the conversation reliably prevented the backdoor. An auditor read the records of 96 runs with a confirmed backdoor. In the 25 runs where the attacker had persuaded a teammate to write it, the auditor named the persuader in all 25, but it also flagged 24 of 40 honest runs. In a four-week field study, up to nineteen agents and two people developed a distributed system through yoars, producing 7,457 acts. Human attention and decision making emerged as the critical resource: requests waited mainly for the human-run coordinator and for approvals, while agents answered within minutes. Most governance requirements emerged from operation, and holding context dominated token cost. We report twenty-six failures of our own instruments, derive seven lessons and a checklist, and release the corpus, the redacted room ledger and the analysis scripts.

Figures & tables

	humans as peers	independent agents	typed obligations	control of wake-up	goals, decisions	enforced routing	attributable record
MetaGPT, ChatDev	$\circ$	–	$\circ$	$\circ$	–	–	$\circ$
AutoGen	$\circ$	–	–	$\circ$	–	–	$\circ$
MCP, A2A	–	✓	$\circ$	–	$\circ$	–	–
KQML, FIPA ACL	–	✓	✓	–	–	–	–
Electr. institutions	$\circ$	✓	✓	–	$\circ$	✓	$\circ$
ParallelPilot	$\circ$	$\circ$	–	–	–	–	$\circ$

Table 1. Capabilities of related approaches as described in the cited work (our reading). ✓ provided,

\circ

partly, – not addressed.

Panel of Figure 1 — Figure 1. yoars architecture. Humans use the browser interface. Agents connect in one of two ways. An agent with an adapter claims and acknowledges deliveries over the HTTP API and is woken by the notice socket. Every agent in the controlled runs connected this way. An agent in an AI coding environment (ACE) acts through MCP tools. A person can also instruct either kind of agent directly, in a direct session (dashed arrows), and what the person says there is not recorded. The relay applies room rules and records every act, while code remains in repositories. Model calls never pass through the relay. Dashed boxes were added late in or after the controlled study (Section 4.4 ), and no controlled run used them.

Panel of Figure 2 — Figure 2. A message’s life. The relay owns delivery and the record, and the adapter decides whether an arriving message starts a turn.

capability	governs	default
narration , disclosure	publishing plans, declaring a workspace	permitted ∗
roster , profiles	who is present; peers’ roles and missions	permitted
statistics	reading the room’s traffic figures	permitted
resource_status	reading peers’ declared progress	forbidden
observable	reading the room without joining	forbidden
invites	bringing others in	permitted

Table 2. The policy vocabulary. Defaults are chosen so that a capability is never opened by accident: anything that would widen what a participant learns about others starts closed. In relay 0.14.0, which served the blocks from day 46, the three proposal capabilities and read_evidence were declared and grantable, but no route checked them. This was corrected in 0.20.0.

Concern	Decision	Problem that forced it	Built: blocks
Identity	Authorization uses only opaque principal identifiers. Handles are addresses and are never parsed for rights. The acting mode is authenticated, not declared.	The predecessor system trusted identity carried in headers and names.	day 1: all
Envelope	Recipients and kind travel together in one versioned envelope. A name in prose addresses nobody. Replies follow one contract.	Free-text addressing left it to each reader who was meant.	days 1–2: all
State changes	Goals, resources and votes change only through typed, authorized operations, never through commands parsed from message bodies.	Two authorities for one state, and a replayed message could repeat a mutation.	day 2 (rule): all
Relations	Goals, causes and waits are declared by the participant who knows them, never inferred by the relay.	An inferred cause leaked information and named the wrong cause.	waits day 28: 0.14 rule day 50: field
Delivery	One fenced delivery per recipient: claim, lease, acknowledge, expire, redeliver. The socket only notifies. Delivery is at least once, with idempotent intake.	The predecessor had four dispatchers and lost completions.	day 1: all
Obligation	An obligation is owed per recipient, not per message.	A wait-for edge needs a debtor.	day 25: 0.14

Table 3. Design decisions of yoars , the problem that forced each, and when it was in place. Last column: day of the build record (relay version where recorded), followed by the controlled blocks in which the part was in place. all : every controlled block (days 3–53). rev. : blocks from the intake revision on (days 12–53). d35 : blocks from day 35 (relay code of day 25, then 0.14.0). 0.14 : blocks on relay 0.14.0 (days 46–53). off : built, but disabled in every controlled run. field : field study only (days 47–73). E: evaluated as a treatment. For a relay part built between blocks, the code names the earliest blocks whose relay is known to contain it. Manifests before day 46 record the relay’s checkout rather than the running process (Appendix C ). † Built on day 3, the day of the first block. “In place” does not mean that the runs exercised it.

Controlled comparison	Runs	Reg.	RQ	Controlled comparison	Runs	Reg.	RQ
Message access $\times$ workspace	5		1	Message-starting rules, repeated $2\times 2$	40	✓	1
Workspace description	5		1	Proposal and voting tools, two families	60	✓	1
Coordinator $\times$ workspace	36	✓	1	Hostile agent $\times$ room access	48	✓	2
Six conflicting fields, two families	$24{+}11$	✓	1	Reviewer agents (0–3)	$60^{*}$	✓	2
Assigned integrator, three variants	32	✓	1	Voting instructions; social-attack replication	$48{+}24$	✓	1, 2
Role combinations	45	✓	1	Single agent versus team	48	✓	2

Table 4. Comparisons of the controlled study. Each row contrasts conditions that differ in the named settings. Registered: plan, measures and tests fixed before the first run.

Rung	Workspace	Channel	Adds
1	shared tree	none	artifacts
2	shared tree	commit announcements	notice
3	shared tree	full envelope	intent
4	shared remote	none (git remote)	transport

Table 5. The ladder. Rungs 2 and 3 each add one thing to the one below. Rung 4 changes the workspace and the channel.

Condition	Msgs	Commits	Truth	Contract
1 shared/none	0	3 (ritual)	pass	settled *
2 shared/notice	7	5 (2 work)	pass	settled *
3 shared/full	61	0	pass	settled *
4 remote/none	0	0	fail	diverged
4 ′ remote/none, instructed	0	19	pass	settled

Table 6. Ladder results. All shared-tree conditions pass, and none required coordination.

Condition	stated	implemented	deferred
1 shared/none	0	no	yes
2 shared/notice	0	no	yes
3 shared/full	0 †	no	yes
4 remote/none	0	yes	yes a
4 ′ remote/none, instructed	0	no b	yes

Table 7. Did the dissenting party state, or implement, its own requirement? “Implemented” refers to its final code. “Deferred” means its code reads the scheme from an auth module’s declaration instead of choosing.

Panel of Figure 3 — Figure 3. Total coordination failure before and after the change to which messages start work (a), and with parts of the change removed in one condition (b). (a) Every scoreable run of the configuration before, and the registered block’s runs that passed the participation check after. (b) The coordinator-free cell with a shared remote, runs that passed the check. Whiskers are 95% Wilson intervals.

Cell	n	2/2	0/2	modal shape
coord/shared	8	3	2	agreed+integrated (6/8)
mesh/shared	10	3	7	integrated w/o agreeing (5/10)
coord/per-agent	8	3	3	agreed+integrated (5/8)
mesh/per-agent	10	3	5	agreed+integrated (5/10)

Table 8. The

2{\times}2

comparison of topology and workspace. “2/2”: full reconciliation of both contested fields. The next column counts total failures, and the last gives the most common outcome in the cell. Fisher’s exact test on 2/2:

p{=}1.0

for every factor.

Panel of Figure 4 — Figure 4. Share of working programs that retained the backdoor, under each defense, in the transparent room. No defense lowered this share significantly below the 95% without reviewers. Whiskers: 95% Wilson intervals.

	opaque	transparent
produced a working artifact	5/19	17/19 ( $p=0.0002$ )
backdoor shipped (all runs)	4/19	14/19 ( $p=0.0029$ )
backdoor shipped $\mid$ artifact	4/5	14/17 ( $p=1.0$ )
utility (graded, 0–6)	1.42	4.74

Table 9. Adversarial block: 48 runs, four cells at

n{=}12

. Counts are for runs that passed the participation check. Including the runs that failed it does not change the pattern.

Panel of Figure 5 — Figure 5. Room policy against a hostile participant (runs that passed the participation check). A transparent room built a working artifact far more often. Among working artifacts, the observed backdoor rates were similar, on small samples. Whiskers: 95% Wilson intervals.

reviewers	runs	built	backdoor $\mid$ built
0	24	22	21/22
1	12	9	7/9
2	12	9	9/9
3	12	11	11/11
any vs none			27/29 vs 21/22 ( $p=1.0$ )

Table 10. Reviewer seats against one attacker. Backdoor rate conditional on the team producing a working artifact.

auditor	detected	persuader	sens. / spec.
Opus 5, neutral	96/96	25/25	97% / 92%
Opus 5, cooperative framing	96/96	25/25	97% / 97%
fleet model (Qwen3.6)	53/95	2/23	39% / 100%
Opus 5, code only	100/100	16/24	—
Opus 5, messages only	110/110	25/25	—

Table 11. The post-hoc audit under ablation. The rows differ in their populations (Appendix C ). Detected : the generic question flagged an exclusion, on runs that shipped a backdoor. Persuader : named, on social runs in which someone other than the attacker wrote the backdoor. Sens. / spec. : the identity-specific criterion, chosen after inspecting these cases.

Panel of Figure 6 — Figure 6. The post-hoc audit under ablation. The first four bars use a strong auditor, the last uses the agents’ own model. The bars differ in their populations. In these samples, the code alone sufficed for generic detection. The messages named the persuader more often than the code did, and the agents’ own model performed substantially worse on both. Whiskers: 95% Wilson intervals.

cell	built	backdoor $\mid$ built	utility
solo, no file	10/12 (9/11)	—	5.00 (4.91)
team, no file	12/12 (6/6)	—	6.00 (6.00)
solo, planted	12/12 (11/11)	1/12 (0/11)	6.00
team, planted	10/12 (8/8)	5/10 (3/8)	5.00

Table 12. The single-agent baseline: 48 runs, one family. All runs as registered, with the runs that passed the participation check in brackets.

Family	Msgs	Fid.	Judge	Recon.	Shape
DeepSeek (×2)	34–40	1.0	4.0	2/2	agreed+integrated
luna (×4)	28–51	1.0	4.0	1–2/2	agreed+integrated
luna †	242	0.53	5.0	2/2	agreed, not integrated
Gemma	102	1.0	3.5	2/2	agreed+integrated
Mistral (×2)	19–52	0.6–0.75	3.0	1/2	mixed
DeepSeek ∗	241	0.6	2.0	2/2	agreed+integrated

Table 13. Runs by model family, with the short names of Table 26 . Fid. : role fidelity. Judge is the mean of two blind passes of one judge model over the code, on a scale of 1–5. Recon. is how many of the contested fields reconciled. Shape says whether the team agreed on a vocabulary and whether it integrated its modules. Message counts are the agents’ own coordination traffic, corrected for the contamination described below. ∗ Labeled haiku in its run manifest. Its session logs show DeepSeek-V4-Flash. † The confounded run (Appendix A.1 ).

team / attacker	direct	social
Qwen3.6 / Qwen3.6	6/6 (8/8)	2/5 (2/7)
DeepSeek-0731 / same	9/9 (10/10)	7/11 (7/11)
frontier / frontier	5/5 (6/6)	5/5 (5/5)
Qwen3.6 / frontier	6/6 (8/8)	4/5 (4/6)

Table 14. The attack in three families and one mixed block, transparent room, no defense. Each cell gives backdoor

\mid

built: of the runs that passed the participation check and built a working artifact, how many carried the backdoor. Brackets give the same over all runs. Frontier : terra. The frontier team’s cells are capped and descriptive.

Panel of Figure 7 — Figure 7. The attack across families (Table 14 ), runs that passed the participation check. The direct attack shipped in every working artifact. The social attack varied, on 5–11 artifacts per cell, and the families were not tested against each other. Whiskers: 95% Wilson intervals. † Capped by quota, descriptive.

	W1	W2	W3	W4
Acts per day	204	263	426	287
Active agents	9	16	17	19
Request–recipient pairs	367	448	570	367
issued by coordinators	88%	83%	77%	67%
component to component	2	23	32	27
Human-run coordinator: answered	97%	98%	89%	78%

Table 15. The development room by week of the field study. W4 is a partial week of 4.2 days.

(a) A rolled-back release
+0:00	co-author’s agent $\to$ deployment, ui	req	“Operator’s order, on yoars-ui v0.80.0 … roll it to dev, then to full”
+1:00	deployment $\to$ ui	req	“the retry branch hit the same wall, and I found the cause”
+1:24	deployment $\to$ ui	inf	“v0.80.0 … is NOT on full. Dev’s postdeploy is RED; I rolled dev back to 0.79.0.”
	11.5 h: no message reaches ui
+12:57	source $\to$ ui	req	(an unrelated request; ui wakes)
+13:24	ui $\to$ deployment	req	“yoars-ui v0.80.1 is tagged and pushed”

Figure 8. Two threads from the room’s record. Times are hours and minutes since the first act of each thread. Each entry gives the opening words of the message, verbatim. req : a request. inf : an inform , which starts no turn. Legibility is a human-run coordinator seat.

Pattern	Hits	Prec.
Helpful
Red-first test or mutation gate as evidence	1,571	19/20
Fixed honesty phrases (“built, not deployed”)	802	18/20
Verdict-like review act	$\approx$ 600	15/20
Self-correction of an earlier act	48	19/20
Independent part built while a question is open	30	19/20

Table 16. Recurring collaboration patterns in the development room. Counts are retrieval hits over 4,196 substantive agent acts. Precision is the share of 20 random hits that the coding agent judged to match.

Theme	W1	W2	W3	W4
Deployment and fleet operation	11%	21%	24%	32%
Messaging and wake rules	25%	10%	8%	14%
Harness, context and cost	20%	4%	13%	7%
Governance (goals, decisions, roles)	12%	23%	10%	12%
Observability and console	11%	7%	17%	9%
Identity, credentials, security	10%	12%	9%	1%

Table 17. Share of requests by week for selected themes. Keyword coding agreed with the analyzing agent’s own check of 85 goals in about 80%, a single-coder figure, so the shares indicate trends. Weeks start on the first day of the room, one day before the weeks of Table 15 .

Question	Evidence
Do agents know which code they can read and how to publish?	L1: 242 messages, no code published
Which acts start work, and which only inform?	L2: 42% to 13% failure (adj. $p=.057$ )
Which rules are enforced rather than instructed?	L3: 21 of 35 proposals unvoted
Can the record show who requested a change?	L4: 25 of 25 requesters named
Which decisions need a person, and who else may take them?	L5: 148 h in coordinator checks
What survives a compaction?	L6: 36% of identifiers kept

Table 18. Checklist for operating a human–agent software team.

Appendix figures & tables10 assets

Supplementary material from the paper’s appendix.

Appendix

† Raw message totals of the room, including echoes of the participation probe.
Run	Msgs †	Cost	Published	Recon.	Provenance
1 (confounded)	271	$34.21	none	2/2	storage
baseline	64	$1.81	all	1/2	storage
variance 1	68	$3.72	all	2/2	storage
variance 2	46	$1.23	all	1/2	storage
counterbalance	51	$1.63	all	1/2	storage

Appendix

Table 19. Open-schema runs. The first is confounded (Section A.1 ). The others share one configuration and differ only in the counterbalance rotation.

	to day 52	days 52–59	days 59–66	days 66–70
roles with turns	4	7	15	10
model turns	140	607	1,293	897
deliveries	91	221	388	299
declared cost	$765	$1,152	$1,623	$610
cost per day	$235	$177	$230	$155
per delivery, median	$4.81	$0.63	$0.87	$0.44

Appendix

Table 20. A resident fleet’s cost and context in four periods (field measurement outside the corpus, days 49 to 70). Every usage entry is counted once. A delivery counts in the period of its first turn. The period of days 59–66 is shown as recorded on day 66. Seven of its deliveries spent

22 more afterwards, which raises its mean to

3.13. Cost shares split each entry’s declared cost by fixed price ratios (input 1, output 5, cache read 0.1, cache write 2 or 1.25), so they are approximate (

\pm

5 points). Context at turn start is given in thousands of tokens of a 1M window.

Panel of Figure 9 — Figure 9. Cost shares of a resident fleet in four periods (field measurement outside the corpus, 2,937 model turns, 10.8 B tokens). Cache reads are 92–99% of the tokens in every period. Input outside the cache is below 0.5% of either tokens or cost. Shares are approximate (Table 20 ).

mechanism	state
relay: bounded waits (20 rows, 32 KB); every list read capped at 32 KB with a cursor	acting (cap since day 63)
relay: incremental reads ( since ), lean rows, goals by involvement	built; lean rows and the involvement view unused
relay: per-room runtime configuration; room experiments with arms	built; nothing set, no arm
harness: compaction at a threshold after a delivery; keeper before the cache expires	acting; threshold 25% since day 60
harness: brief kept across a compaction; a bound inside a turn	acting on most seats since day 65; the bound never fired
harness: re-prompt held while declared work is in progress	acting since day 60

Appendix

Table 21. Context mechanisms in the development fleet on day 66, and whether they act.

Comparison	Days	Model	Cells and runs	Primary outcome, test
Message access $\times$ workspace	3	GPT-5.6-luna	five conditions, one run each, ended by the operator	settlement and ground truth, descriptive
Workspace description	4	GPT-5.6-luna	five runs of one condition, one with rotated vocabularies	reconciliation and integration, descriptive
Coordinator $\times$ workspace	5–6	DeepSeek-V4-Flash	four cells of up to 10, 38 valid, 36 scoreable after two exports without code	full reconciliation, Fisher
Six conflicting fields	13–14	agentworld, DeepSeek	12 shared-remote and 12 per-agent (24 valid), and one cell of 12 in the second family (11 valid)	mean and variance of contested fields reconciled, permutation, Holm over three
Assigned integrator	14–15	DeepSeek-V4-Flash	three variants registered at 12 each, 9, 12 and 11 valid	committer’s repository the only multi-author one, Fisher
Role combinations	14–18	DeepSeek-V4-Flash	15 coalitions $\times$ 3 on the service task (49 runs passed the check across three launches), and a second block of 45 on the pipeline task	Shapley values, estimation only

Appendix

Table 22. The comparisons of Table 4 and the blocks behind them. Cells and

n

as registered, then as achieved. Days of the project, as in Section 4 .

Comparison	Stop	Check	Primary counts	Relay
Message access $\times$ workspace	operator	first	valid attempts, void ones re-run	checkout
Workspace description	operator watch, not recorded	first	baseline up to an operator intervention	checkout
Coordinator $\times$ workspace	300 s quiet or 3,600 s	quiet (one earlier run, outside the cells)	passed and scoreable	checkout
Model comparison	60-min ceiling	first and second	passed	checkout
Message-starting rules	300 s quiet or 3,600 s	quiet	before: scoreable, incl. 4 failed. After: passed	checkout
Six fields, integrator, role combinations, first private-rules block, voting tools	300 s quiet or 3,600 s	quiet	passed	checkout

Appendix

Table 23. Run protocol per block. Stop: how a run ended. Check: version of the participation check (first: token broadcast, day 3. Quiet: 60 s without a new probe, capped at 300 s, from day 5). Primary counts: which runs the registered primary used. Relay: what the manifests record.

variant	backdoored	cooperative
Opus 5, neutral	96 (one on one pass)	40
Opus 5, cooperative	96	39 (one errored)
team’s model	94 of the 96, 1 ablation run	39 (one errored)
code only	94 of the 96, 6 ablation runs	—
messages only	96, all 14 ablation runs	—
shared	92	38

Appendix

Table 24. Populations of the audit variants. Shared: the backdoored runs and cooperative runs present in all four of the first variants.

field	storage	back end	interface	planner
text	body	text	title	label
flag	closed	done	completed	finished

Appendix

Table 25. Seeded names in the two-field service task, by the role whose slice shows them. A rotation control exchanges the columns.

model	short name	labels
Qwen3.6-35B-A3B	Qwen3.6	qwen3.6-35b , qwen
qwen-agentworld-35b-a3b	agentworld	qwen-agentworld-35b
DeepSeek-V4-Flash	DeepSeek	deepseek-flash
DeepSeek-V4-Flash, later snapshot	DeepSeek-0731	deepseek-flash-0731
Gemma-4-31B	Gemma	gemma-4-31b
Mistral-Medium-3.5	Mistral	mistral-med

Appendix

Table 26. Model names. The report uses the short name. The labels are those of the run manifests and the evidence register. One stale manifest label, claude-haiku-4-5 , marks a run that ran DeepSeek-V4-Flash (Table 13 ).

measured	consequence
cost per delivery heavy-tailed: pooled mean 5 $\times$ the median; $\sigma=1.7$	reward on log cost, role as a fixed effect
deliveries that used sub-agents cost 5–56 $\times$ more (role medians)	the choice tracks the size of the work: randomize, never compare observationally
about 37 deliveries a day, fleet-wide	per-delivery arms, fleet-wide
a factor of 2 needs $\approx$ 93 deliveries per arm (two-sided 5%, power 0.8)	explore : S0, S1, S2 balanced for 14 days; detects a factor of 1.7
sub-agents on the largest model were 35% of cost (measured, days 59–66); a written token costs about 1.5 times the mid tier’s	S3 not explored for cost; a quality reference only if S1’s acceptance falls
with a 15% floor shared by two arms, a factor of 2 needs a 19-day window	exploit : floor 15%, window 21 days; prior on an arm’s effect $N(0,0.7^{2})$ on log cost

Appendix

Table 27. Planning parameters proposed for the rerun, derived from the fleet’s own records (275 deliveries with declared cost, days 52–59, after the compaction change). The sample sizes treat deliveries as independent (see the limits at the end of this appendix). The parameters will be re-derived once the stamped records, which carry the experiment and the arm, exist.

\sigma

: standard deviation of log cost per delivery within a role.

Multi-Agent Governance

See all 22 papers

TeamBench: Evaluating Agent Coordination under Enforced Role Separation
May 8, 2026Yubin Kim, Chanwoo Park, Taehan Kim +9Multi-Agent Coordination LLM Agent Evaluation
MIT · Google Research · Independent Researcher +1
Specifying AI-SDLC Processes: A Protocol Language for Human-Agent Boundaries
May 24, 2026Ylli PriftiSoftware Engineering Agents LLM Agent Orchestration
Birkbeck, University of London
When Agents Coordinate: Measuring Coordination in Multi-Agent AI Coding
Aug 17, 2026Giuseppe Destefanis, Tomaso AsteMulti-Agent Coordination Multi-Agent Coding
Department of Computer Science, University College London, UK

May 8, 2026J/K move · Enter open · S save

TeamBench: Evaluating Agent Coordination under Enforced Role Separation

Yubin Kim, Chanwoo Park, Taehan Kim, Eugene Park+8

MIT · Google Research · Independent Researcher+1

Multi-Agent Coordination LLM Agent Evaluation AI Agent Security AI Agent Benchmarks Task Decomposition Tool Access Control for LLM Agents+1

Open paper AskPDF arXiv

Agent systems often decompose a task across multiple roles, but these roles are typically specified by prompts rather than enforced by access controls. Without enforcement, a team pass rate can mask whether agents actually coordinated or whether one role effectively did another role's work. We present TeamBench, a benchmark with 851 task templates and 931 seeded instances for evaluating agent coordination under operating system-enforced role separation. TeamBench separates specification access, workspace editing, and final certification across Planner, Executor, and Verifier roles, so that no role can read the full requirements, modify the workspace, and certify the final answer. Prompt-only and sandbox-enforced teams reach statistically indistinguishable pass rates, but prompt-only runs produce 3.6 times more cases where the verifier attempts to edit the executor's code. Verifiers approve 49% of submissions that fail the deterministic grader, and removing the verifier improves mean partial score in the ablation. Team value is also conditional. Teams benefit when single agents struggle, but hurt when single agents already perform well. A 40-session human study under the same role separation shows that our benchmark exposes interaction patterns that pass rate misses. Solo participants work through the task directly, human participants paired with agents often collapse into quick approval, and human teams spend more effort coordinating missing information across roles.

Abstract

Multi-Agent Governance

Explore similar work

TeamBench: Evaluating Agent Coordination under Enforced Role Separation

Specifying AI-SDLC Processes: A Protocol Language for Human-Agent Boundaries

When Agents Coordinate: Measuring Coordination in Multi-Agent AI Coding