Skip to content

You're viewing the Nimbus templateget the full source code, from $79.

Blog

Jul 1, 2026 · Elin Kovač · 1 min read

Guardrails that make autonomous refunds boring

The goal of guardrail design is not to prevent the agent from acting. It is to make every action so bounded and so logged that nobody worries about it.

"The AI issued a refund on its own" sounds terrifying until you look at what actually bounds the action. Good guardrails don't make agents timid — they make autonomy uneventful.

The four layers

Every autonomous action in Nimbus passes through the same stack:

  • Eligibility rules — which intents may act at all. A refund rule might read: duplicate charge verified against the invoice, amount under the per-action limit, customer tenure over 30 days.
  • Spend limits — per action, per customer, per day. When a limit would be exceeded, the action converts to a handoff with the evidence attached.
  • Approval mode — route any category of action through a human click first. Teams typically start refunds here and lift it after a quiet month.
  • Audit log — every action records what the agent saw, which rule authorized it, and what it did. Immutable, exportable, one click from the conversation.

Boring is the benchmark

The healthiest sign in a deployment is that the finance team stops asking about the agent. That happens when three things hold: limits they set themselves, an audit trail they can read without help, and a reversal path (every automated refund can be undone by a human within the same interface).

Notice what is not on the list: model confidence scores. Confidence is an input to eligibility, not a guardrail. A 99%-confident action outside its spend limit still converts to a handoff — because the point of the system is that the boring rules win every argument with the clever model.

Elin Kovač

Nimbus team

Command Palette

Search for a command to run...