Mission Control
One screen for the whole company - cost, revenue, product and CI - watched by a fleet of agents that explain what they see, propose actions, and act within a guardrail envelope. Every action is measured, which is what lets the system close its own loop and improve overnight.
Why mission control
tl;drAn AI-native company runs on a small team with a large fleet of agents. The leverage only compounds if you can see everything in one place and let the agents act, not just alert. Mission control is that surface: a read layer over a fleet that detects, explains, proposes and - within limits - executes.
The 2026 consensus is human-on-the-loop, not full autonomy: agents operate inside a policy envelope and escalate past it. This design takes that literally - the policy engine in layer 3 is the spine everything else hangs from.
Five-layer architecture
click a layerRead top-down. The one rule that makes autonomy safe: agents never touch the world directly - every action passes through the governance layer. Click any layer to expand it.
The canonical agent loop
interactiveAll four agents run the same six-step skeleton. Build it once, instantiate four times - only the connectors and detectors differ. Step through it, or press play to watch it cycle. The last step feeds the first.
Ingest
Pull raw signals from connectors - token usage, invoices, Stripe events, CI runs, Sentry releases. Direct API for core vendors, wrapped FinOps tool for the long tail.
The policy engine
playgroundThis is what "autonomous with guardrails" actually means. An agent emits a typed action envelope; the engine routes it to auto-execute, escalate, or block. Drag the inputs - or load a scenario - and watch the verdict flip.
Agent acts now. Logged to the ledger with an undo handle.
class: reversibledollar_impact: -120blast_radius: 2freeze_window: falseThe dreaming loop
verifiability gateOvernight, each agent reflects on its own ledger - expected outcome vs actual - and distills lessons and skills back into memory. But self-improvement only works where the outcome is objectively measurable. So dreaming is gated per agent. Pick one to see why.
Did the action drop spend? Measured directly against the next billing window. Clean ground truth, so it learns aggressively every night.
With no ground truth, a self-improving loop would reinforce whatever it already believes. It surfaces insights for humans first; only once there is a labeled good vs bad insight dataset does it earn a loop.
The four agents
fleetSame loop, different lenses. CostOps ships first - it is the most verifiable and the fastest to a dollar number.
CostOps
first slice- Ingests
- AI APIs, Heroku, Supabase, R2, SaaS invoices
- Detects
- Spend spikes, waste, idle resources
- Proposes
- Route / cache / cancel, dollar savings
- Verifiable
- Strong
RevenueOps
- Ingests
- Stripe, subscriptions, churn signals
- Detects
- MRR moves, churn risk, failed payments
- Proposes
- Dunning, expansion flags
- Verifiable
- Partial
ProductAnalytics
- Ingests
- App usage events, Amplitude / Pendo
- Detects
- Drop-off, gaps, dead features
- Proposes
- Experiments, ticket ideas
- Verifiable
- Weak
CIOps
- Ingests
- GitHub Actions, Sentry releases
- Detects
- Flaky tests, slow pipelines, fail rate
- Proposes
- Retry / pin / quarantine
- Verifiable
- Strong
Guardrails & the ledger
safetyEvery action - auto or approved - lands in an immutable ledger with its envelope, executor, timestamp, undo handle and measured outcome. It is both the audit trail and the dataset the dreaming loop learns from.
| Action | Agent | Verdict | Outcome |
|---|---|---|---|
| Enable prompt cache on chat route | CostOps | auto | saved $312/mo |
| Quarantine flaky import spec | CIOps | auto | flake rate 11% to 0% |
| Buy 1yr reserved capacity ($1.8k) | CostOps | escalate | approved by human |
| Retry 4 failed subscription charges | RevenueOps | auto | $540 recovered |
Decisions & open questions
statusLocked in the design session. The forks that are still open sit below.
| Fork | Decision |
|---|---|
| Home | New ac-mission-control repo + this design doc in ac-docs |
| Service shape | One service - FastAPI + thin Vue dash, design-system as npm dep |
| Autonomy | Autonomous with guardrails (policy engine + ledger + kill switch) |
| Connectors | Own vendor clients; direct Supabase reads for business data; no runtime dep on ac-python-api |
| Ingest | Hybrid - direct for AI / Stripe / CI / Sentry, wrap a FinOps tool for the infra long tail |
| First slice | CostOps - verifiable, immediate dollar value, proves the whole pattern |
- Which FinOps tool to wrap for the infra long tail (Finout / Vantage / Amnic)?
- Per-agent autonomy thresholds - start every agent at the same caps, or tune per agent from day one?
- Does the dashboard live on its own subdomain behind Cloudflare Access, like ac-docs?
- When does ProductAnalytics earn a dreaming loop - what is the labeled-insight dataset that unlocks it?
Build sequence
roadmapSubstrate first, then one agent end to end to prove the loop, then clone. Nothing acts for real until the policy engine is trusted in dry-run.
Data backbone + ledger schema
Stand up the event store, metric rollups and the action ledger. No agents yet - just the substrate every layer reads and writes.
Policy engine + kill switch
Implement envelope evaluation and the guardrails in dry-run mode. Prove auto vs escalate verdicts before any action touches a real vendor.
CostOps as the full vertical slice
One agent end to end - connectors, detectors, real actions through the policy engine, and the dreaming loop closing on spend delta.
Dashboard + Slack for CostOps
The read surface and the approve / reject card path, scoped to one agent so the loop is observable before it multiplies.
Clone the pattern
CIOps, then RevenueOps, then ProductAnalytics (dreaming off). Same skeleton, new connectors and detectors each time.