Use case · Agent spending limits

A limit the agent cannot raise.

One envelope across model calls, paid tools and real payments, held outside the agent and drawn down by every run and every sub-agent. Ask before the spend, get allowed, needs a person, or denied, and get the rule that decided.

Cap an agent in test mode See the budget

Tools and payments in one ceiling
Survives sub-agents

POST /v1/agent/actionsthe agent asks

{
  "action_type": "tool.invoke",
  "resource": "api.openai.com",
  "cost_cents": 900,
  "currency": "USD"
}

Kordio answers

{
  "decision": {
    "outcome": "denied",
    "rule": "run_budget_exhausted",
    "headroom": { "budget_remaining_cents": 0 }
  }
}

The eleventh sub-agent gets the same answer as the first one would have, because they share the envelope.

Inside Kordio

Know what each agent can spend.

See the policy, available budget, and decision together in the Kordio console.

Why the usual answers stop short

Four limits that are not a limit.

Every one of these is real enforcement of something. None of them is a ceiling on what this agent, across this run, may spend in total.

A provider cap is per provider

A hard limit on one model vendor does not know about the other three, the search API, the scraper, or the payment the agent is about to make. Your exposure is the sum, and nothing sums it.

An in-process check ships with the agent

A limit inside the orchestrator is real enforcement, and it lives inside the thing it constrains. Whatever compromises the agent compromises the check, and changing the number needs a deploy.

Sub-agents each inherit the whole ceiling

Fan out to five workers with a per-call limit and you have multiplied the limit by five. Budgets have to be delegable and drawn down from one envelope, or they are not budgets.

Dashboards report, they do not deny

Cost observability tells you what happened yesterday. That is useful and it is not a control. By the time the chart moves, the money is spent.

The longer versions: versus an if statement in your orchestrator and versus card limits.

The envelope

One budget, delegated down, released on the way back.

A budget is a task-scoped envelope with a ceiling. Sub-agents draw from the parent rather than each getting their own, reservations are held while work is in flight, and anything unspent releases automatically instead of stranding.

policy.jsontools and payments together

{
  "mode": "allowlist",
  "rules": [
    { "kind": "spend_window", "max_cents": 25000,
      "window_seconds": 86400 },

    { "kind": "rate_limit", "max_actions": 200,
      "window_seconds": 60, "action_types": ["tool.invoke"] },

    { "kind": "cost_cap", "max_cents": 5000,
      "action_types": ["payment.create"] },

    { "kind": "condition", "effect": "require_approval",
      "rule_name": "unknown_vendor",
      "when": { "not": { "field": "resource", "operator": "in",
        "value": ["api.openai.com", "api.anthropic.com"] } } }
  ]
}

The daily window covers every action type at once, so a runaway loop on tools eats the headroom the payment would have needed.

The part that is not a config flag

An allowed decision comes back signed.

Every yes returns a short-lived ES256 signature over the agent, the action, the resource and the amount. Whatever executes verifies it against the public JWKS with no callback and no shared secret, so an agent that skipped the check has nothing to present. That is the difference between a limit the agent respects and a limit it cannot route around.

Honest limit, stated plainly: a control layer only binds the paths you route through it. More on what that means in what an agent control layer is.

Questions

What engineers ask before wiring it in.

Does this replace the guardrails in my agent framework?

No, and keep them. They catch things Kordio never sees, like what the model is about to say. The difference is that a framework hook holds no budget across runs and cannot produce evidence that anything was authorized.

Does Kordio add latency to every tool call?

One call before the action. Use simulate for a dry decision when you want to check without reserving anything. The ledger projection is deliberately outside the decision path, so books can never slow a decision down.

What if Kordio is unavailable?

You decide the failure mode: fail closed and the agent stops, or fail open and you accept the exposure for that window. We would rather you make that choice explicitly than discover it during an incident.

Can one budget cover model spend and real payments together?

That is the point. Action types are dotted strings, so tool.invoke and payment.create draw down the same envelope. Spend on one consumes headroom for the other.

Does an agent need a card or a wallet for this?

No. Kordio holds no funds and issues nothing. It decides and it signs. Whatever executes the action still executes it.

Give one agent a ceiling and try to break it.

Test mode is the whole engine, with no card. Fan out sub-agents against a shared budget and watch the envelope hold.

Get API keys Read the API docs