// case study · agent infrastructure
Give agents work without giving them the keys.
Kerna puts policy, budgets, approvals, isolation, and durable receipts around AI-agent tool use.
Agent frameworks make it easy to call tools. They make it much harder to answer the operational questions that follow: was the action allowed, who approved it, what budget did it consume, and what exactly happened? Kerna treats those questions as part of the execution path rather than an after-the-fact log.
The control loop
- Ask. An agent proposes a tool call with explicit arguments and context.
- Check. Kerna evaluates policy, execution budget, and isolation requirements.
- Decide. The call is allowed, denied, or routed into a human approval queue.
- Receipt. The decision and execution result are persisted as an inspectable trace.
Why fail closed
Missing policy, malformed context, and unavailable approval state all resolve to denial. That is less convenient during setup, but it prevents an integration bug from silently becoming permission to act. Risk cards make the decision visible before a user approves it.
Architecture
- A Rust runtime and CLI own policy checks and execution control.
- SQLite stores local policy state, approvals, and persistent receipts.
- An MCP gateway places the same controls in front of compatible agent clients.
- Plugin processes are isolated so a tool failure does not take down the control plane.
- Python and TypeScript surfaces keep the runtime usable from common agent stacks.
The design boundary
Kerna is not an agent planner and does not claim to make models smarter. It is the narrow control layer between a model's intent and a side effect, designed to make that boundary explicit, reviewable, and recoverable.