v0.20.0 — what a trajectory cannot carry across a vendor, and where the capability goes

[sshlg]

§6 shipped three routing traps, and all three quietly assume the request is what moves. A mid-run failover moves a trajectory, and not all of it can go.

A trajectory carries a vendor credential

Part	Portable?
Tool calls and results	yes — different structure, same meaning, re-render and send
Reasoning	text yes, credential no — the vendor attaches proof that the reasoning is its own

Vendors disagree on what they demand: one end validates nothing, the other rejects any credential it did not issue. And the credential is sometimes attached to the tool call rather than the reasoning — which is why "just strip all reasoning before failing over", the policy that sounds safest, is the one that produces a 400 instead of a graceful degrade.

The rules that follow: store trajectories in a neutral internal format (keep the text, discard the credential, re-render per vendor at send time), and put the failover boundary between turns. A fallback chain never exercised mid-trajectory has not been tested — a green health probe answers a question about the endpoint, not about your history.

Capability is not spent evenly

Plan-and-Act (arXiv:2503.09572): with good enough planning a relatively simple executor suffices; with a wrong decomposition every downstream executor builds on a false premise. Their 54% on WebArena-Lite came from improving the planner, not the executor.

So the strongest model and the most carefully written prompt go to the manager. It also says where to look when a multi-agent system underperforms: a weak plan is invisible in every executor's transcript, because each one did its own step correctly.

Steps the agent cannot see buy nothing

At 300 steps a standard agent still plateaus at roughly what it achieves at 30 — without budget awareness the extra steps go into shallower search. Our max-iteration guard is the floor of this rather than the mechanism: it stops the spend and never changes the behaviour that led there.

Two things worth flagging beyond the content

Second displacement in two releases. These three lines alone left the body at 4745/4750 — five tokens. §1's context dataclass and sub-agent base class moved to references/patterns.md, landing at 4631/4750. Each displacement was defensible alone, but the pattern is a body at capacity, and the auditor states its own remedy — the answer then is a split, not a trim. Filed as B-129 rather than absorbed a third time, because a split means deciding which of the 13 sections are one skill and which are another: a routing decision, not a formatting one.

The table-shape guard from v0.19.1 caught its author. Both new board rows were inserted after the last row of any table and landed in the three-column Open, and why — refused twice with row has 8 cells against the 3 its own header declares. Third occurrence of that class, and the first caught by this repository instead of the umbrella.

Evidence

Check	Result
npm test	rc=0
Auditor	0 GAP, 14 PASS, body 4631/4750
Guard	refused both misplaced rows before they could ship

Board B-128, B-129. Ledger MR-1 … MR-5.

🤖 Generated with Claude Code