« Phase 00 README · Warmup · Hitchhiker's · Deep Dive · Core Contributor · Staff Notes

Phase 00 — Principal Deep Dive: Trust Boundaries, Reliability & Cost Math

The deep dive derived four numbers. This document is about what those numbers do to a platform. At principal scope you are not implementing compound_reliability; you are letting \(p^n\), the step budget, the token curve, and $/resolved-task select an architecture, size its capacity, and decide where the bodies get buried. These four numbers are, quite literally, an architecture-selection function you run before the first line of the platform is written.

The step budget forces the topology

The single most consequential design output of this phase is the reliable step budget \(n_{\max}=\lfloor \ln T/\ln p\rfloor\). At \(p=0.95, T=0.90\) it is 2. That number does not describe the agent; it constrains the graph. If the task genuinely needs eight LLM-directed decisions but your budget between verified points is two, the architecture is decided for you: you must insert checkpoints every ~two steps.

Each of the "buy reliability back" levers is a structural component, not a tweak:

• Durable checkpoints (Phase 08) — persist state at each verified point so a failure resumes rather than restarts. This is why serious agent platforms are built on a durable execution substrate (event-sourced state, replayable steps) rather than an in-process for loop. The step budget is the reason durability is table stakes, not a nice-to-have.
• Verifier / critic gates (Phase 07) — a second model or rule that inspects a step's output before it propagates, converting "hope it was right" into "check it was." A gate resets the compounding: a verified checkpoint is a new \(p\approx1\) anchor, so the budget clock restarts after it.
• Eval gates (Phase 11) — offline, they gate deployment; the platform refuses to ship a version whose measured success_rate regresses.
• Human-in-the-loop (Phase 10) — the last resort for high-blast-radius actions, and an availability/latency cost you budget for deliberately.

So the design rule is not "add guardrails." It is: the budget tells you the maximum span of autonomy between anchors, and each anchor is a component you must build, run, and pay for. A platform architecture is, in large part, the placement of those anchors.

Workflow-vs-agent is an architecture-selection function

The most senior decision this phase trains — use the least-agentic thing that works — is a selection function with a strict priority order, and it belongs at the top of every design review:

1. Workflow if the action sequence is known and does not branch on runtime observations. You hard-code it: determinism, ~10× lower cost (no LLM re-planning a fixed pipeline every run), trivial debuggability, and durability nearly for free. A router that picks one of three known pipelines is still a workflow.
2. Agent only if the model must choose the next action at runtime and the required step count fits inside \(n_{\max}\).
3. Agent-with-guardrails if it needs runtime flexibility and exceeds the budget — the agent plus the anchors above. Most serious production agents land here.

The "looks wrong but is intentional" move is that a principal engineer deliberately removes autonomy. Junior instinct treats more agency as more advanced; at platform scope, agency is the most expensive and least reliable resource you own, and the correct default is to spend as little of it as the task requires. Reaching for a workflow is not a failure to build an agent — it is the arithmetic winning.

Scaling and capacity: sum the tail, not the mean

Latency capacity for an agent is not the model's per-call latency. Because the loop is sequential (step \(N\) needs step \(N-1\)'s observation), end-to-end latency is the sum of per-step latencies, and the SLO is set at the tail:

$$L_{\text{p95, e2e}} \approx \sum_{i} L_{\text{p95},,i}.$$

Ten steps at a 0.5s-mean but 1.5s-p95 tool is not a 5s system; at the tail it is closer to 15s, and that is what a 1-in-20 user experiences. Summing means blowing an SLO the mean says is comfortable. Two architectural consequences: (1) fewer, larger steps are a latency lever as much as a reliability one; (2) ReWOO's independent workers can run in parallel, collapsing a sum into a max for those steps — a genuine capacity argument, not just a cost one.

Throughput capacity is governed by tokens, not requests. A ReAct agent's \(\Theta(n^2)\) input growth means each additional step consumes disproportionate provider tokens-per-minute (TPM) and context window. Capacity planning that assumes linear per-step cost will under-provision by the triangular factor. When you size a fleet against a provider's TPM quota, you size against the quadratic, and you treat context-window headroom as a first-class capacity dimension that a long agent can exhaust mid-task.

Failure modes and blast radius

The failure mode principals lose sleep over here is silent margin inversion. Recall \(\text{cost/resolved} = \text{unit_cost}/\text{success_rate}\). If you price a resolved task at $0.20 against a $0.125 cost (37.5% gross margin), a reliability regression that drops success_rate from 0.84 to 0.60 raises cost/resolved from $0.125 to $0.175 — margin collapses toward zero and, past a point, goes negative while every per-request dashboard still looks green. The blast radius is the P&L, and the detection surface is not latency or error rate; it is $/resolved-task, a derived metric you have to compute deliberately from cost telemetry divided by eval success. A platform without that metric can be losing money on every successful-looking request.

The second failure mode is trust-boundary blast radius. A single tool granted broader capability than the task needs turns a prompt injection from a nuisance into an incident. Least privilege at the boundary is a blast-radius control: the sandbox, the allow-list, and the per-tenant authz check bound what a hostile proposal can reach once honored. Security here is architecture, not a review checkbox — the boundary is where it is enforced or it is not enforced at all.

Cross-cutting concerns you wire in on day one

• Cost telemetry from commit one. Per-request input/output tokens and dollars, tagged by tenant, route, and agent version, emitted structurally. Retrofitting this after a surprising bill means you cannot answer "which tenant, which agent, which step" — and the quadratic makes "which step" the question that matters.
• Tail-latency observability. Histograms, not averages. A p50 dashboard is actively misleading for a system whose SLO lives at p95/p99; you instrument distributions per step and per end-to-end path.
• Multi-tenant fairness and quotas. One tenant's runaway 40-step agent can exhaust shared TPM and starve everyone. Per-tenant step budgets, token quotas, and concurrency limits are how you keep the quadratic from becoming a noisy-neighbor outage.
• Security as architecture. Covered above — the trust boundary is a platform primitive, enforced in code on the executor side, replicated at every nesting level.

The pessimistic-independence choice, defended

The p^n independence assumption looks wrong to critics — "steps aren't really independent!" — and it is intentionally the pessimistic first model. It is the right architectural default for the same reason you size a bridge for the worst plausible load, not the average one: it gives a conservative budget you can only beat, and it turns a vibe ("it's flaky") into a defensible number that survives a review. Correlations usually help a good plan and hurt a bad one; either way, designing to \(p^n\) and then measuring the real end-to-end rate is the discipline. The number is not a prediction to be precise about; it is a forcing function that puts checkpoints, verifiers, and honest cost math on the whiteboard before you have spent a quarter's token budget discovering the same facts from the bill.