Fleet routing & loop contracts
How work is routed across model tiers and how recurring autonomous loops are governed.
LiveChecked against
starlight-agent-config/core/doctrine/SYSTEM-SPINE.md, TRUTH.md, OBJECTIVES.mdCapability-based model routing (SYSTEM-SPINE.md §4)
Agents are selected for the specific job rather than running a single model for every task:
| Tier | Responsibility | Execution rule |
|---|---|---|
| Strategic synthesis | Architecture, doctrine, threat modeling, and evaluation rubrics | High-reasoning frontier model |
| Maker | Implementation inside a verified write sandbox and explicit file allowlist | Repo-capable coding harness (claude, codex, antigravity, opencode) |
| Independent verifier | Adversarial code review, test audit, and pr-gate.mjs sign-off | Different execution context and model family from the maker, with zero overlapping write lane |
| Mechanical | Schema checks, index generation (gen-skills-graph.mjs, handover.mjs), and deterministic lints | Deterministic Node/PowerShell scripts first; fast tier only when language parsing is required |
The .loop/<name>/ contract standard (SYSTEM-SPINE.md §6)
Every recurring autonomous loop in starlight-agent-config/.loop/ requires:
- Objective & non-goals: A testable condition to make true, plus explicit forbidden paths.
- Actor separation: One maker + one independent verifier + explicit human gate for irreversible actions.
- Hard budgets: Maximum iterations, elapsed wall-clock limit, provider-% burn ceiling (
OBJECTIVES.md: ≤10% Claude + ≤8% Codex per run, 15% reserve floor), and a no-progress stop trigger. - Durable receipt: Every run appends
{ts, loop, exitCode, durationMs}toruns.jsonl, monitored byStarlightTaskHealthWatch.
Akamoto fleet overview
The multi-harness agent fleet and the operating rules every coding agent inherits across the estate.
Security headers, verification, and sovereign research
HTTP security headers in akamoto/next.config.ts, crawler rules in app/robots.ts, fail-closed waitlist capture, and Node test verification.