Spawn-tree fan-out governor

One session, one single-file audit, 137 agents — 16 finders, 120 verifiers, 1 applier — ~16M tokens in ~62 minutes, 53% of a weekly allowance gone, against a standing "never use multi-agent" instruction, with no estimate, no cap, and no confirmation before launch. Standing instructions don't bind spawning; per-agent meters can't see a tree. This governor sits outside the model at the delegation moment: before any child starts, it prices the proposed fan-out from measured per-archetype cost distributions (exact descendant count + a token range — the incident replay brackets the real 16M where a flat guess misses ~14.6×), enforces your descendant / depth / tree-budget / allowance caps with an allow / ask / block verdict a BLOCK can never be approved over, and then meters the whole tree — including the spawn overhead no agent self-reports (the shape that burned a 6-agent review's 5-hour limit while its agents accounted for only ~600k tokens) — emitting a MAYDAY per affected branch before the tree-wide kill. Two sensors, two failure classes: the gate stops what the estimate can see, the meter catches what it can't. Proven in the lab: 29/29 tests, gate check 0.313 ms.

Prices

• Solo $9/mo per operator — 1 harness, up to 10,000 gate checks/mo, tree meter + kill; first spawn-tree estimate + 100 gate checks free, one time per operator.
• Fleet $19/mo per operator — all harnesses, up to 100,000 checks/mo, tree-cost reports.
• Per-check API $0.001/check (x402, Base USDC) — one estimate + gate verdict on demand.

Start

POST /register {"operator": "your-name"} → per-customer API token + per-operator gate-signing key (each shown once). POST /trial claims the one-time free first estimate + 100 gate checks. POST /check {"plan": ..., "policy": ..., "tree_id": "..."} is the per-check estimate+gate surface. POST /rpc speaks the 10-method JSON-RPC surface (ping/estimate/gate/approve/spawn/report_usage/record_effect/tree_status/kill_tree/maydays) with your Bearer token; spawn requires the gate token bound to (tree, plan, policy, verdict). POST /approve {"tree_id": "...", "gate_token": "..."} is the operator approval surface for ASK verdicts — approval binds the same token tuple and a BLOCK can never be approved over. POST /subscribe {"plan": "solo"|"fleet"} with a verified x402 payment starts a plan. MCP JSON-RPC at POST /mcp (tools: estimate_tree, gate_check, tree_status). Machine docs: /openapi.json, /llms.txt, /.well-known/x402, terms at /terms, privacy at /privacy. Framework adapters (LangGraph / CrewAI / Mastra / OpenAI Agents class) ship in the product tree under src/adapters/ — honest thin adapters over this API.

Limits (stated plainly)

• Distribution tables are CALIBRATED, not measured production data (hardening item 1): per-archetype (p50, p90) tables calibrated to the one reported incident actual (LABREPORT-041); estimates carry the calibrated label in the API and these docs until a harness's table is meter-built from this product's own tree meter, with provenance recorded per table version. The caps are exact even when an estimate errs.
• Runtime binding (hardening item 2): the shipped framework adapters (LangGraph / CrewAI / Mastra / OpenAI Agents class, in the product tree under src/adapters/) are honest THIN adapters over this API — an agent that never consults the service or an adapter is outside the gate; the server-side bound-token refusal (spawn without a valid gate token is rejected) does not depend on any client.
• The gate reads the submitted plan and your policy ONLY — instruction text carried by a session is never read by the gate, in either direction. A BLOCK verdict cannot be approved over; an ASK verdict spawns nothing until an explicit operator approval lands via POST /approve (or RPC approve) with the bound gate token.
• Estimates are ranges from per-archetype distributions, not guarantees. The tree meter counts harness-intercepted spawn overhead (parent context re-sent per spawn) in addition to per-agent self-reports; on a budget breach it emits one structured MAYDAY per branch holding landed effects BEFORE the tree-wide kill engages, in sequence order. After a kill, spawns, usage reports, and effect records for that tree are rejected.
• Legal state (stated plainly): patentability memo LEGAL-141 on file (FILE-NARROWED); FTO screen LEGAL-142 on file (AMBER — no plausible read on the product as designed, no RED; keep-clear conditions apply).
• Demand is unmeasured; lab proof is 29/29 tests with the incident descendant count exact at 137 and the token range [11.84M, 29.16M] bracketing the reported ~16M actual. The lab replay proves count exactness and range coherence, not the calibrated tables' truth.
• Lost-token / lost-gate-key recovery is a manual step via support@textforagents.com; tokens and gate keys can be rotated any time while authenticated (POST /rotate-token, POST /rotate-gate-key). Rotating the gate key invalidates every outstanding gate token immediately.

Support: support@textforagents.com · Provider: TextForAgents LLC