@ssheleg/agent-stack 0.19.1 → 0.20.0

package/CHANGELOG.md

@@ -1,3 +1,39 @@
+## v0.20.0 — what a trajectory cannot carry across a vendor, and where the capability goes
+
+Three findings from the harvest, all landing on the same question: **which model does what,
+and what survives when that changes mid-run.** §6 shipped three traps about routing, and all
+three quietly assume the *request* is what moves.
+
+- **A trajectory carries a vendor credential, and it may not be attached to the reasoning.**
+  Tool calls and results are portable — different structure, same meaning, re-render and
+  send. Reasoning is portable *text* plus a **non-portable credential** the vendor attaches
+  to prove the reasoning is its own, and vendors disagree on what they demand: one end
+  validates nothing, the other rejects any credential it did not issue. The credential
+  sometimes sits on 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. 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 — the planner is the bottleneck.** *Plan-and-Act*
+  (arXiv:2503.09572) found that with good enough planning a relatively simple executor
+  suffices, and with a wrong decomposition every downstream executor is building 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.** Standard agents have no budget awareness, so
+  at **300 steps** they still plateau at roughly what they achieve at **30**. A
+  max-iteration guard is the floor of this rather than the mechanism — it stops the spend
+  and never changes the behaviour that led there.
+
+**And the second displacement in two releases.** The body was at 4609/4750 after v0.19.0
+bought that headroom back; these three lines would have left **5 tokens**. §1's context
+dataclass and sub-agent base class moved to `references/patterns.md`, beside the loop
+listing that went there in v0.19.0, landing the body at **4631/4750**. That is now twice in
+a row that an addition has cost a displacement, which is the auditor's own signal — *the
+answer then is a split, not a trim* — and it is filed rather than absorbed again.
+
 ## v0.19.1 — the class the umbrella had been catching for us, twice
 
 `B-126`'s board row shipped in v0.19.0 with **nine cells against the eight its header

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ssheleg/agent-stack",
-  "version": "0.19.1",
+  "version": "0.20.0",
   "scripts": {
     "test": "python3 test/validate.py && python3 test/plant_guard_test.py && node test/installer_test.js"
   },

package/plugins/agent-stack/.claude-plugin/plugin.json

@@ -3,7 +3,7 @@
   "name": "agent-stack",
   "displayName": "Agent Stack",
   "description": "Four skills: agent-orchestrator — tool-calling loops, pipelines with checkpoints, provider routing with fallback, memory architecture, plus the wallet side of reselling LLM access; agent-evals — run/trace/thread evals, LLM judges, and fixtures grown from production; agent-interop — MCP servers and clients, A2A agent cards, the MCP Registry, and gateways; agent-harness — system prompts, tool shaping, workflow-vs-agent, and auditing an agent system.",
-  "version": "0.19.1",
+  "version": "0.20.0",
   "author": {
     "name": "ssheleg",
     "url": "https://x.com/sshlg93"

package/plugins/agent-stack/skills/agent-orchestrator/SKILL.md

@@ -40,23 +40,12 @@ OrchestratorAgent.run(AgentContext)
 
 ### Shared Context Object
 
-Pass a single immutable-ish context object to all sub-agents:
+Pass a single immutable-ish context object to every sub-agent. It carries the request
+(`project_id`, `user_question`, `chat_history`), the machinery (`llm_router`, `tracker`,
+`workflow_id`), the resolved provider and model, and one `extra` dict for pipeline flags.
+The full dataclass is in [`references/patterns.md`](references/patterns.md) → *The
+orchestrator's shared context and sub-agent protocol*.
 
-```python
-@dataclass
-class AgentContext:
-    project_id: str
-    user_question: str
-    chat_history: list[Message]
-    llm_router: LLMRouter           # provider abstraction with retry/fallback
-    tracker: WorkflowTracker        # SSE event emitter for real-time UI
-    workflow_id: str                 # unique ID for this request
-    connection_config: ... | None   # external resource config
-    user_id: str | None
-    preferred_provider: str | None  # e.g. "openrouter"
-    model: str | None               # e.g. "<provider>/<model-id>"
-    extra: dict[str, Any]           # pipeline_action, flags, overrides
-```
 
 **Key principles:**
 - Sub-agents never modify context — they return typed results
@@ -65,20 +54,10 @@ class AgentContext:
 
 ### Sub-Agent Protocol
 
-Every sub-agent extends a base class:
-
-```python
-class BaseAgent(ABC):
-    @abstractmethod
-    async def run(self, context: AgentContext, **kwargs) -> AgentResult: ...
-
-    @property
-    @abstractmethod
-    def name(self) -> str: ...
+Every sub-agent extends one base class with a single abstract `run(context) -> Result`,
+so the orchestrator never learns what any of them does internally. The class is in the same
+reference section.
 
-    @staticmethod
-    def accum_usage(total, usage): ...  # merge token counters
-```
 
 Typed result subclasses per agent (e.g. `SQLAgentResult` with `query`, `results`, `attempts`).
 
@@ -108,6 +87,7 @@ was gathered rather than returning nothing. The full listing is in
 - **Token limit recovery**: On `LLMTokenLimitError`, compress to 60% and retry once. If still fails, return partial answer
 - **Max iterations guard**: Always have a hard limit. On exhaustion, compose best-effort answer from data gathered so far
 - **Iteration refund**: a recoverable provider error is not charged to that guard
+- **Budget awareness**: tell the model what is left, or 300 steps performs like 30
 
 ---
 
@@ -197,6 +177,11 @@ fallback chain and per-provider retry with exponential backoff, and its
 - **Model selection has three levels** — the request, the tenant, the system
   default — and a tenant override that silently loses to a request parameter is
   how a cheap model ends up billed at a premium one's rate.
+- **Those three assume the REQUEST is portable; the trajectory is not.** Reasoning carries
+  a vendor credential — sometimes on the tool call — so mid-turn failover can 400, and
+  *strip all reasoning* is what causes it. Fail over between turns.
+- **Capability is not spent evenly**: the planner is the bottleneck, so the strongest model
+  goes to the manager, not to whichever agent does the most work.
 ## 7. Multi-Layer Memory System
 
 Four layers, each with a different lifetime and a different reason to exist:

package/plugins/agent-stack/skills/agent-orchestrator/references/llm-proxy-billing.md

@@ -260,3 +260,57 @@ model" is otherwise unanswerable.
 
 See `patterns.md` for the retry, health-check and error-hierarchy patterns these
 routing calls sit inside.
+
+### What a trajectory cannot carry across a vendor
+
+The routing above assumes the **request** is portable. Mid-run failover is a different
+problem, because by then there is an accumulated history and not all of it can move.
+
+- **Tool calls and results are portable.** They differ in structure between vendors and
+  mean the same thing, so re-rendering them is enough.
+- **Reasoning is not.** It is portable *text* plus a **non-portable credential** the vendor
+  attaches to prove the reasoning is its own. Vendors disagree on what they demand: one end
+  validates nothing, the other rejects any credential it did not issue.
+- **The credential is not always attached to the reasoning.** It may sit on the *tool call*
+  — which is why the apparently safe policy *"just strip all reasoning before failing
+  over"* is exactly what fails at some vendors, and fails as a 400 rather than as
+  degradation.
+
+Design rules that follow:
+
+- Store trajectories in a **neutral internal format**: keep the text, discard the
+  credential, re-render per vendor at send time.
+- Decide the failover boundary deliberately. **Between turns** is cheap and safe; **inside
+  a turn**, after reasoning has been emitted, is where the credential problem lives.
+- A fallback chain that has never been exercised **mid-trajectory** has not been tested.
+  A green health probe answers a question about the endpoint, not about your history.
+
+### Where the capability goes — not evenly
+
+The intuitive allocation is to spend evenly across agents, or to give the strongest model
+to whichever agent does the most work. Both are wrong for a planner–executor pair.
+
+*Plan-and-Act* (arXiv:2503.09572) found the **planner is the bottleneck of the whole
+system**: with good enough planning a relatively simple executor suffices, and with a wrong
+decomposition every downstream executor is building on a false premise. Their 54% on
+WebArena-Lite came from improving the **planner's** planning, not the executor's execution.
+
+So: **give the strongest model and the most carefully written prompt to the manager**, and
+let the executors be cheaper. It also sets 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.
+
+### Budget awareness — steps the agent cannot see buy nothing
+
+Raising a step budget does not by itself buy more work. Google's *Budget-Aware Tool-Use
+Enables Effective Agent Scaling* reports that standard agents have **no budget awareness**,
+so at **300 steps** they still conduct shallow searches and plateau at roughly what they
+achieve at **30**.
+
+Spending a larger budget requires telling the model where it is in that budget, so it can
+shift strategy — broad exploration early, narrowing later. The multi-agent form is the
+manager allocating step budget per sub-task rather than handing every executor the same cap.
+
+A max-iteration guard that only composes a partial answer at exhaustion is the *floor* of
+this, not the mechanism: it stops the spend, and it never changes the behaviour that led
+there.

package/plugins/agent-stack/skills/agent-orchestrator/references/patterns.md

@@ -200,6 +200,51 @@ for attempt in range(1, max_retries + 1):
 
 ---
 
+## The orchestrator's shared context and sub-agent protocol
+
+`SKILL.md` §1 states the two rules — one context object down, typed results back — and this
+is the shape they describe. It moved here in v0.20.0 for the same reason §2's loop listing
+did in v0.19.0: the body carries what is read every time, a reference carries what is read
+once.
+
+```python
+@dataclass
+class AgentContext:
+    project_id: str
+    user_question: str
+    chat_history: list[Message]
+    llm_router: LLMRouter           # provider abstraction with retry/fallback
+    tracker: WorkflowTracker        # SSE event emitter for real-time UI
+    workflow_id: str                 # unique ID for this request
+    connection_config: ... | None   # external resource config
+    user_id: str | None
+    preferred_provider: str | None  # e.g. "openrouter"
+    model: str | None               # e.g. "<provider>/<model-id>"
+    extra: dict[str, Any]           # pipeline_action, flags, overrides
+```
+
+**Key principles:**
+- Sub-agents never modify context — they return typed results
+- Provider/model preferences flow down from user → project defaults → app defaults
+- `extra` carries pipeline state, flags like `_skip_complexity`, session ids
+
+```python
+class BaseAgent(ABC):
+    @abstractmethod
+    async def run(self, context: AgentContext, **kwargs) -> AgentResult: ...
+
+    @property
+    @abstractmethod
+    def name(self) -> str: ...
+
+    @staticmethod
+    def accum_usage(total, usage): ...  # merge token counters
+```
+
+The single abstract method is what keeps the orchestrator ignorant of any sub-agent's
+internals; a second one is how that boundary starts leaking.
+
+
 ## The tool-calling loop, in full
 
 `SKILL.md` §2 states the six steps and the guard; this is the listing they describe. It