The control layer ยท Versus your own code

Your orchestrator cannot constrain itself.

A limit expressed as an if statement in your own orchestrator is real enforcement, and for one agent with one ceiling it is the right call. It also lives inside the thing it constrains, so changing a limit means a deploy and anything that compromises the agent compromises the check with it.

Credit where it is due

An if statement is real enforcement.

The honest competitor to this product.

It runs before the money moves. It costs nothing. It has no dependency and no network hop, and it is right there in the code with everything else. For one agent, one ceiling, one team, and nobody asking who approved what, keep it. It is cheaper than Kordio and it is correct.

The argument on this page is not that your engineers cannot build this. It is about where the logic lives.The value of moving it out is not that the logic is better. It is that the logic is somewhere the agent cannot reach.

Every decision is recorded in an append-only audit trail, linked by trace id, on every tier. See what comes back

Keep it when
One agent, one environment, one ceiling that rarely moves, and no auditor asking who permitted a payment six weeks ago.
It stops being enough when
The second agent ships, a sub-agent spends without passing through it, a limit needs to change without a release, or someone outside engineering has to answer for the spend.

One trust domain

The check and the spend share a blast radius.

The problem is not the quality of the condition. It is that the condition and the thing it governs are the same process, running with the same credentials, changed by the same deploy.

Out of reach

The logic is not better. It is somewhere else.

POST /v1/agent/actionsIdempotency-Key required
{
  "action_type": "payment.create",
  "resource": "vendor.example.com",
  "cost_cents": 50000,
  "currency": "USD",
  "session_id": "ses_01HXKJZM2"
}
Kordio answers
{
  "decision": "denied",
  "rule": "spend_window.daily_vendor_cap",
  "remaining_cents": 0,
  "trace_id": "trc_01HXKJZM2Q"
}
The rule that decided, and the headroom left, in the same response your agent already had to wait for.

Policy is data, not a deploy.

The same limit becomes a typed rule that validates when you write it rather than when an agent is waiting. It diffs in review, any UI can render it, and the decision it produced is still on record months later naming the exact rule.

Because the state lives outside the run, a budget a parent hands to twenty sub-agents is drawn down by all of them together. And because the answer is signed, an executor that requires a signature cannot be talked past by an agent that skipped the check.

See a full decision

Build against buy

When writing it yourself is still the right answer.

Is this a network call in the path of every action?+

Yes, and that is a real cost you should weigh. It answers in the same request rather than queueing. Ordering, retries and what happens during an outage are documented in the guarantees page.

We already have an approval step. Is that enough?+

If a person genuinely reviews each one, often yes. It stops being enough when the volume means approvals get rubber-stamped, or when sub-agents spend without passing through it.

Can we keep our own checks as well?+

Yes, and most teams should. Keep the cheap local check for obvious cases. The point is that the binding limit lives somewhere the agent cannot rewrite.

What does this actually replace in our code?+

The scattered limit constants and the branch that reads them. What replaces them is one call that returns a decision, the rule that made it, and the headroom left.

Run the check your agent cannot skip.

Sandbox keys in five minutes, no card, running the same policy engine as live mode. Live tiers from $49/mo.