Start with an outcome
Ask for a bounded result. Kerna can retrieve relevant local context and discover configured MCP tools.
A visible control loop
Kerna sits between an AI model and MCP tools. It owns orchestration, policy checks, budgets, approval decisions, and the evidence of what occurred.
What happens in one task
Ask for a bounded result. Kerna can retrieve relevant local context and discover configured MCP tools.
The model proposes a call. The proposal does not become an action merely because a model requested it.
Permissions fail closed. Kerna evaluates the allowed tool, routine scope, approval policy, and hard budget before invocation.
MCP plugins run as child processes. A hung plugin is bounded and reaped instead of quietly taking over the task.
Approval-required work waits in a local queue. Approve once or deny; a background routine will not silently bypass a required choice.
Trace the task afterward: policy result, approval decision, budget event, tool lifecycle, and redacted structured records.
A proposed write
A reviewed policy can allow safe reads to proceed while making a write wait. The person sees the proposed effect, decides once, then inspects the finished task receipt.
Try it locallyTask event trail
✓ a denial never starts the action
What Kerna does not do
Kerna deliberately keeps domain logic in MCP plugins. That means calendar, notes, search, and other capabilities can evolve independently while the trust boundary stays consistent.
Task history, policies, and receipts live in the workspace you initialize.
External plugins provide domain work through a constrained process boundary.
Choose a provider or use local/demo modes; policy remains outside the model.
Inspect the decision trail instead of relying on an opaque “done.”