CostOps agent
Watches AI, cloud, infra, and SaaS spend. Proposes optimizations with measurable dollar outcomes.
Operating brief
design targetCostOps should ship first because it has clean inputs, reversible actions, and fast ground truth. Its design goal is not "find cheaper things"; it is to tie spend to owner, unit, and outcome so the policy engine can safely let low-risk savings execute.
Every agent uses the same loop: ingest, normalize, analyze, detect, decide, log. The useful design work is deciding what evidence enters the context, which actions exist, which actions stay dry-run, and how the ledger proves that the agent helped.
Agent design diagram
click nodesThe diagram is the high-level system boundary for this agent. Click a node below it to inspect what belongs in that layer and what should stay outside the agent.
CostOps loop
Detect waste, compare against previous actions, retrieve relevant lessons, and emit a typed saving proposal.
Signals, detectors, and outputs
design inventoryThis is the detector inventory to design first. Each detector needs a source signal, a user-visible output, and a measurement that can be written back to the ledger.
Burn-rate anomaly
- Signal
- Spend over baseline by provider, model, feature, or tenant.
- Output
- Spike explanation plus suggested cap or cache.
- Ledger metric
- Spend delta vs 7-day and 30-day baseline.
Autonomy gate
playgroundUse this as a policy-design sketch. The values are not final production thresholds; they show which classes of action should be eligible for auto-execution and which should escalate.
Auto-execute
autoThe action is reversible, confidence is above the floor, and impact stays inside the policy envelope.
- Class
- Reversible config
- Reversibility
- full
- Design note
- Good first auto-action. It saves money, has a local rollback, and the ledger can prove the delta.
Context and memory design
agent envelopeResearch converges on context engineering as the quality lever: keep a stable policy prefix, put fresh evidence near the task, retrieve only relevant lessons, and expose a small tool surface.
Stable prefix
FinOps policy, allocation rules, unit definitions, provider taxonomy, and the current autonomy thresholds.
Per-run evidence
Current billing rows, resource inventory diff, owner mapping, recent deployments, and comparable historical anomalies.
Memory retrieval
Past accepted savings, false positives, rejected commitments, and lessons keyed by provider, feature, and action class.
Tool surface
Read usage, read invoices, inspect resource, propose config change, dry-run vendor action, submit policy envelope.
Evals and rollout
ship safelyBehavior checks
- Allocation accuracyGiven provider rows, the agent assigns spend to the same owner and unit as deterministic allocation.
- Savings proofEvery proposal includes expected delta, baseline window, measurement window, and rollback path.
- Quality gateModel-routing proposals must pass behavior evals before leaving dry-run.
- Policy routingIrreversible or net-spend-positive actions always escalate.
Open design questions
- What is the first official unit: workflow run, agent run, active customer, or all three?
- Which resource tags are required before an action can be eligible for auto-execution?
- Where do model-quality eval results join the cost ledger for routing changes?
Read-only cost spine
Ingest AI usage and cloud bills, allocate to owners and units, and render daily rollups in Mission Control.
Dry-run detector pack
Ship burn, idle, unit-cost, and commitment detectors. Write proposals to the ledger with no execution.
First reversible action
Allow prompt-cache and idle-resource actions through the policy engine under a small impact cap.
Dreaming loop
Compare expected savings to actual spend delta and distill lessons into retrieval memory.
Research inputs
sourcesThese are the sources used to shape the page. The resulting design keeps the vendor-specific advice at the architecture level: tool surfaces, guardrails, context, orchestration, outcome logging, and domain metrics.