01 · AI Circularity Ledger

The Astra Escalation Ladder

Relationship map for The Astra Escalation Ladder

A commercial loop with a scoreboard.

Default is a product choice

The conclusion is direct: Astra should replace Robin as the escalation desk before it replaces Sol as the routine worker. Sol can handle bounded work with a clear finish line. Astra should enter when the job has crossed a defined failure gate and the expected value of rescue exceeds the added cost. Tests, receipts and public evidence decide whether the rescue worked.

Codex CLI 0.153.4 made Astra the bundled default when no model is explicitly configured. That is a useful product choice for a general audience. It is weaker as an operating policy for a one-person company. A product default optimizes for a broad mix of users, tasks and support costs. RobinOS needs to optimize for verified outcomes, founder interruption, recovery probability, elapsed time and the full cost of every attempt. Codex changelog.

OpenAI reports a large Astra advantage over Sol on some tool-heavy evaluations: 57.9% versus 37.3% on Terminal-Bench 4.0, 41.4% versus 18.1% on AutomationBench and 72.6% versus 65.7% on OSWorld. DeepSWE is much closer at 74.1% versus 72.7%. These are vendor-reported evaluation results, rather than RobinOS production results. They suggest where to test a premium model; they do not establish a universal winner. Astra launch and evaluations.

The pricing gap is equally concrete. The published model pages list Astra at $10 per million input tokens and $50 per million output tokens, compared with Sol at $4 and $20. Each Astra token category therefore costs 2.5 times the corresponding Sol category at the listed standard rates. Actual task cost also depends on caching, tool use, retries, context length and how many tokens each model needs. Astra model page. Sol model page.

The operating question is simple: which tasks deserve that premium, and what evidence earns an earlier escalation next time?

Price the rescue rather than the model

Token price is procurement data. Cost per verified outcome is operating data. Robin needs the second.

A cheap attempt can become expensive when it fails twice, corrupts the working state, consumes an hour of review and still leaves Robin to finish the job. An expensive attempt can be economical when it receives a precise rescue packet, repairs the hard part in one pass and closes with external verification. The unit of analysis must include the entire chain from assignment to accepted receipt.

Every task record should preserve at least six numbers: total model and tool cost, elapsed time, founder intervention minutes, founder interruption events, number of repair loops and verified completion. A seventh field should record whether recovery created a duplicate consequence. A retry that publishes twice, sends twice or overwrites a newer source is a control failure even if the final artifact looks correct.

This is the distinction behind the September 4 essay Capability Is Not Authority. A stronger model does not receive a larger mandate merely because it can reason farther. The task keeps the same files, destinations, permissions and stop gates. Escalation changes the worker and context, not the authority envelope.

The September 6 Four Loop Test added finish, recover, remember and improve. The September 7 Three Agent Workdays Still Need a Founder added founder attention and an empty ten-task ledger. The present ladder supplies the missing handoff rule inside that loop.

No production route changes through this publication. The ladder is a research and operating specification. Its twenty-task scorecard starts empty. Missing observations remain UNKNOWN.

Four triggers justify escalation

The first trigger is architectural ambiguity. Sol may finish a local edit while missing a contract spread across components, schemas, deployment rules and durable state. Escalate when the worker can describe the conflict and the required evidence, yet cannot form a coherent change boundary after inspecting the relevant sources. “The task is large” is too vague. The trigger should name the unresolved interfaces and explain why another local attempt would repeat the same uncertainty.

The second trigger is two failed repair loops. One failure often reveals ordinary information: a test name, a missing dependency or a stale assumption. The worker should diagnose and repair it. A second failure of the same acceptance gate signals that the current approach is stuck. Before escalation, preserve the two observed failures, commands, changed files and last known good state. Two different cosmetic complaints do not qualify. Two failed loops against the same frozen finish line do.

The third trigger is difficult computer use or cross-system execution. OpenAI’s reported OSWorld and AutomationBench gaps make this the clearest empirical candidate for Astra. The gate still depends on the task. A deterministic shell edit with a strong test belongs in the routine lane. A fragile sequence across browser state, local files and remote records may justify escalation earlier because each manual reconstruction costs time and increases duplicate risk.

The fourth trigger is final evidence review where a silent defect is expensive. This is a review lane rather than a rescue lane. Astra receives the finished artifact, authority boundary, expected evidence and change manifest. It checks contradictions, missing proof, scope drift and rollback. It does not rewrite the deliverable for stylistic preference. Deterministic checks run before and after review so model judgment never becomes the sole acceptance gate.

These four triggers are narrow on purpose. False escalation spends more without improving the result. Delayed escalation spends founder time and may damage recoverability. The ladder should make both errors visible.

The handoff packet is the control surface

Astra should receive a rescue packet, rather than a conversational summary. The packet contains the task identifier, exact objective, frozen finish line, permitted scope, prohibited changes, confirmed artifacts, relevant source versions, observed failures, attempted repairs, last known good state and the next safe verification step.

The packet excludes hidden reasoning and confident stories about why Sol failed. It records observable events. “The SEO check failed because three locale routes are absent” is useful. “Sol is confused by Astro” is speculation. The distinction protects the rescuer from inheriting an unsupported diagnosis.

The packet also states what Astra may change. If the failure sits in one component, the rescue should begin there. If remote state may already have changed, the first step is read-only confirmation. If the task involves publication, messaging, payment, deletion or another consequential side effect, the packet carries its idempotency evidence and the authority already granted. A missing response never proves that a remote action failed.

After rescue, Astra returns a compact receipt: files changed, commands run, tests passed, unresolved facts, external effects, rollback point and whether the original finish line was met. That receipt is checked outside the model. A fluent explanation is diagnostic material, not proof.

OpenAI’s own research-workflow report offers a useful reason to build this control surface. The company reports approximately 3.1 agent-workdays per human workday, while more than half of successful four-to-eight-hour tasks still required intervention. The numbers are internal to OpenAI and cannot be transferred directly to RobinOS. They show that more agent labor and less human coordination are separate outcomes. OpenAI research workflow evidence.

Score twenty real tasks

The first comparison uses twenty real RobinOS tasks, frozen before outcomes are reviewed. Synthetic benchmarks can test a tool. Real tasks reveal coordination cost, stale instructions, dirty worktrees, publication boundaries and recovery under uncertainty.

Divide the set into four equal classes. Five routine tasks should have a narrow edit and deterministic acceptance. Five architecture tasks should span files or contracts. Five recovery tasks should include an interrupted process, stale source or failed external dependency. Five evidence tasks should require reconciliation, public verification or final red-team review. Each task keeps one identifier across attempts so rescue cannot create a fresh denominator.

Record which lane closed the task: Sol alone, Sol followed by Astra rescue, or Sol followed by Astra evidence review. Include Astra-first only if the frozen routing rule assigned the task there before results. Retrospective relabeling would contaminate the experiment.

The primary metric is verified completion per assigned task. The second is founder intervention minutes and interruption events. The third is full cost per verified outcome, including every failed attempt, tool call and review. Report elapsed time, repair loops, autonomous recovery and unauthorized-change findings alongside them. Averages should be split by task class before a portfolio total is shown.

The scorecard needs negative evidence. Record false escalations where Sol likely would have finished, missed escalations where Robin had to intervene, Astra rescues that expanded the change surface, and lessons that failed on replay. A premium model that closes more tasks while widening permissions or corrupting durable memory is an operational regression.

Do not prefill the outcome columns. The published evaluations support the experiment design. Only RobinOS receipts support a RobinOS routing change.

Turn rescue into routing evidence

A successful rescue becomes a candidate lesson with source, date, task class, trigger, result, cost and verification. It remains probationary until a second comparable task confirms it. “Astra repaired this cross-file schema conflict after two Sol failures” is an observation. “Always use Astra for schemas” is an overgeneralization.

If a trigger repeatedly predicts successful rescue, the router can escalate earlier for that class. If Sol repeatedly clears a class without intervention, keep it there. If Astra’s final review finds no material defects over a meaningful sample, reduce the review frequency while retaining random checks. The policy follows marginal evidence instead of model prestige.

Every routing update needs a reversible version. Store the previous rule, the evidence that changed it, the effective date and the review threshold. A later failure should be able to identify which rule made the assignment. The system learns from reality because it can replay the decision, rather than because a memory says the newer model felt better.

Murphy testing belongs inside this loop. Feed the ladder an attractive false trigger, an expensive infinite repair path, a rescue that proposes unrelated changes, a remote timeout after a successful write and a plausible lesson built from one anecdote. The correct system refuses scope expansion, checks remote state before repeating effects, caps repair attempts and keeps the anecdote probationary.

The ladder succeeds when Robin receives fewer ordinary interruptions and more accepted outcomes without weaker evidence or broader authority. Astra earns its premium one verified rescue at a time. Sol keeps the routine lane until evidence moves it. Robin keeps the decisions that genuinely require Robin.

Decision rules

Keep Sol as the routine executor while the twenty-task ledger is unfilled. Escalate only on one of the four named triggers and send the complete rescue packet. Require deterministic verification or a separately evidenced human judgment before acceptance. Preserve unresolved facts as UNKNOWN.

Expand Astra rescue for a task class when repeated verified rescues improve completion or reduce founder interruption enough to exceed full incremental cost, with no material regression in scope control, duplicate prevention, provenance, rollback or memory quality. Keep samples and task classes visible.

Pause the ladder when assignments are moving, source versions are unclear, the authority envelope conflicts, remote state cannot be confirmed after a consequential action, or the verifier is controlled by the same unreviewed output. Those conditions require state repair before another model attempt.

The policy is intentionally modest. A default model is a product decision. An escalation ladder is an operating decision. The first can change in a release note; the second changes only when receipts prove that a different route returns more of Robin’s time.

Until those receipts exist, the current route remains the honest baseline. Restraint preserves a comparable experiment and prevents model enthusiasm from becoming an invisible operating expense.

Categories and keywords

Categories: Artificial Intelligence; Agent Systems; Operating Models; One-Person Company

Keywords: GPT-6 Astra; GPT-5.6 Sol; escalation ladder; rescue packet; founder interruption; verified outcomes; cost per rescue; deterministic verification; model routing

Hashtags: #AI #AgentSystems #RobinOS #OnePersonCompany #VerifiedOutcomes