agent-budget

agent-budget

An unbudgeted agent loop is a runaway-cost incident with an architecture diagram. This skill produces the budget spec that governs an agentic workflow: what each stage may spend, on which tier of model, what happens at the cap, and — the number that actually matters — what one outcome costs. Pairs with agent-loop-design (the caps land in its loop spec) and subagent-design (the fleet line lands in its role cards); the tier vocabulary is this repo's own light/standard/heavy routing abstraction, so the spec ports across providers. Infra spend (compute, storage, egress) is capacity-cost-model's domain — this skill budgets the tokens.

How to respond

1. Pin the outcome unit and the workflow's stages. Ask at most 2 questions, spent on: "what is one successful outcome?" (a merged PR, a triaged ticket, a verified report — the denominator every cost divides by) and "what does a typical run look like today?" (stages, rounds, models — or "not built yet", which makes this a design-time budget, the cheap time to write one). Non-interactive run (no user to ask): derive both from the input and tag [assumption]; no outcome unit derivable → emit BLOCKED: need the workflow and its outcome unit.

2. Assign each stage the cheapest adequate tier — light / standard / heavy, per the routing rule of thumb: light for mechanical extraction and formatting, standard for most generation, heavy only where the hard thinking is the value (adversarial verification, weighted judgment) — and heavy stages are never downgraded to save money; they're where the money buys correctness. Every tier assignment carries a one-line rationale. The classic misallocation runs both directions: frontier models formatting JSON, and — worse — the cheap model doing the verify pass that exists to catch the cheap mistakes.

3. Set three numbers per stage in templates/budget-spec.md: expected spend per run (estimate honestly, tag [assumption] until measured), cap (the hard stop — 3–5× expected, tighter for unattended loops), and on-cap action (abort-and-escalate, or degrade — never "continue and warn"; a warning nobody is watching is a continue). State each as tokens and approximate money — tokens are what the harness enforces, but money is the only unit that sums across tiers, so all cap comparisons happen in currency. A stage that fans out per item carries two caps: a per-item cap (that item fails to the report's needs-human list; the rest continue) and a stage-wide cap. Then the run-level cap for the whole workflow — in currency, less than the sum of stage caps: every stage simultaneously hitting its cap is not a run to finish, it's an anomaly to stop.