v0.22.0 — the failures named from outside, and the control that is absence

[sshlg]

graph-engineering.md argued everything from failure and cited nothing

Why Do Multi-Agent LLM Systems Fail? (2025) measured the same ground: traces from seven mainstream frameworks — MetaGPT, ChatDev, AG2, Magentic-One — with human annotators independently analysing ~150 traces at Cohen's kappa = 0.88, yielding 14 failure modes in three groups.

The reason to carry it is that the groups land on this file's own five-field node contract without being bent to fit:

MAST group	The field it lands on
System design flaws — unclear interfaces, overlapping roles, wrong tool config	input/output, and owner
Inter-agent alignment failures — inconsistent objective, downstream misinterpretation, contradictory operations	the edge payload (§3's Carries column)
Missing task verification — an agent reports completed and the result does not meet the requirement	check, and §6's checker node

An outside measurement arriving at the same joints is worth more than another argument from failure.

And the load-bearing result is the negative one. Better prompts, more explicit roles and retries bought ChatDev 15.6% — the authors conclude the modes are architectural rather than bugs, which is exactly the claim §1 makes about the two fields nobody draws.

governance.md never named the control before per-tool authorisation

The model cannot reason about capabilities it does not know exist.

A tool absent from the schema cannot be invoked, argued for, or probed for a bypass. A tool present and refused at call time is a negotiation, and negotiations are won sometimes.

Sub-agent isolation needs both halves: schema filtering at construction and message_history = None at execution — a sub-agent handed its parent's transcript has been told about every capability you carefully removed from its schema.

Two numbers pointing opposite ways, on purpose

Eager MCP schema loading at startup	40% of the context budget before the first user message
Metadata index, schema on selection	under 5%
The same system's own prompt and tool schemas	built eagerly, in the constructor

The rule is not lazy is better. It is eager for what you own and always need, lazy for what is foreign and might not be used — the first removes latency and races from the hot path, the second removes a cost you cannot predict.

Approval fatigue is a safety failure, not a UX complaint

No persistence → re-approving the same operations every session → blanket auto-approval, defeating the safety system entirely — through the user rather than through a bug, so nothing in the logs looks wrong. A control that is asked too often is a control on its way to being switched off.

Evidence

Check	Result
npm test	rc=0
Auditor	0 GAP, 14 PASS, body 4655/4750 — unchanged
Placement	both findings written entirely into references; B-129 records this body at capacity and this release spends none of it

Board B-132, B-133. Ledger MS-1 … MS-7.

🤖 Generated with Claude Code