Krelvan: AI Agents You Can Actually Own, Inspect, and Trust
Building an AI agent that looks impressive is easy. You write a good prompt, wire up a tool or two, and the demo lands. Building one you’d actually trust to run unattended is a completely different job, and it’s the job most agent tooling quietly skips.
Because the moment you want an agent to run on a schedule, touch real tools, spend money, or email a customer, the questions change. What exact program got built from my request? Which tools was it allowed to use, and which did it actually call? What happens if it crashes between asking to send an email and recording that it sent one? Can I stop it before it does something irreversible? And can someone else verify the record without trusting my dashboard?
A prompt can’t answer any of those. Krelvan is my attempt to build the thing that can. It’s a self-hosted operating environment for AI agents: you describe an outcome or install a pre-built agent, inspect the program it produces, run it through real tools and models, stop consequential actions for human approval, receive the output in an Inbox or an external channel, and keep a record you can replay and check. This post walks the whole product, what each part does, why it works the way it does, and where it’s headed.
And the framing that runs through all of it: Krelvan is self-hosted. You run it, your data lives in your directory, your keys sign your records. You’re not shipping your whole operating environment to a hosted black box and hoping.
Seven products, one runtime
The easiest way to understand Krelvan is as seven cooperating products that share a single runtime. It’s not only an agent builder, or only a canvas, or only an automation runner, or only an audit system. It’s all of these, and each one is a real surface. Together they’re what turns “a model in a loop” into something you can actually operate.
The architecture, in lanes
Here’s how those pieces stack. The important thing to read here is the direction of dependency: everything points inward toward a small, pure core. And one design choice ties it together: rather than keep a pretty UI history alongside a separate reality, Krelvan derives the canvas, run state, approvals, timeline, accounting, replay, and proof from one append-only signed record. The interface shows what the runtime actually recorded, which is what makes the trust claims real rather than decorative. It’s one part of the design, not the whole story, but it’s the part that makes the rest trustworthy.
That purity boundary is the trick that makes the rest possible. The core decides what should happen next using only the signed history and the agent’s program. It can’t reach out and do things. A separate impure shell does the actual reaching out, and then records what it observed, signed. Model output, by the way, is always treated as data: it’s parsed, validated against a schema and the caller’s authority, and signed. No generated text is ever executed as code.
An agent is a signed program, not a prompt
When you describe an outcome, Krelvan doesn’t just stash your prompt. It compiles your intent into a manifest: a declarative program with a name, an entry point, a bounded number of steps, nodes (each with a role, an autonomy level, and the exact capabilities it’s allowed to use), and edges between them that can be guarded by typed conditions.
Here’s the creation flow, and note the loop in the middle: if the compiler doesn’t like what the model proposed, it feeds the validation errors back and tries again, within bounds.
The conditions on edges use a small, bounded, typed expression language, comparisons and boolean logic over the run’s state, nothing that can turn into arbitrary code execution. Your agent’s control flow is legible and safe by construction.
Running it: fold, decide, append
Execution is a small loop repeated until the run finishes, halts, or fails. It’s deliberately boring, and boring is the point.
That last part matters more than it looks. If the ledger shows an effect was requested but has no recorded result, Krelvan calls it a crash hole and halts rather than pretending it knows whether the outside world acted. It won’t cheerfully assume the email went out. That honesty about the boundary between “what we did” and “what a remote system did” is rare, and it’s deliberate.
Every action is classified, and permission is deny-by-default
An agent node can only call capabilities its signed manifest declared. And every capability is tagged with what kind of consequence it has. This is how Krelvan knows when to pause for you.
| Side-effect class | Meaning | Example |
|---|---|---|
| read | Observes without changing anything external | Search, retrieval, a GET |
| write-reversible | Changes something you can normally undo | Store a memory, update a draft |
| write-irreversible | Can't safely be assumed reversible | A destructive or final action |
| spend | Moves or commits money | A payment or refund |
| message-human | Communicates with a person | Email, Slack, Telegram |
| identity-mutation | Changes standing identity or authority | The agent's persistent soul or credentials |
And when an action does run, it goes through a three-part protocol that keeps permission, intent, and observed outcome separate. The key detail: a plugin never signs its own success. A trusted supervisor observes what happened and signs the result.
An ecosystem, not a walled garden
The core is useful alone, but the point is that it grows. Capabilities are the unit of behavior, and there are three ways to add one: a YAML definition for a simple HTTP wrapper, a sandboxed TypeScript plugin for custom local behavior, or an MCP connection to plug in an existing tool server. MCP isn’t a second runtime bolted on: discovered MCP tools become normal Krelvan capabilities, subject to the same admission, approval, and signing.
All of it is discoverable through a Git-backed registry, the same shape as a mature open software platform: browsable, forkable, installable.
Connectors carry secret references, not secrets. Code plugins install disabled and require an explicit trust choice, then run in a locked-down subprocess with scrubbed environment and brokered network access. The ecosystem is open, but it’s open with the safety model intact.
What’s under the “trust” claim, precisely
I try hard not to overclaim here, because trust language is easy to inflate. So, precisely: every event binds its type, causal parents, previous event, payload, timestamp, and author into a canonical form, content-addressed with SHA-256 and signed. Fresh installs get per-install Ed25519 keys, and a standalone, dependency-free verifier can recompute and check the whole chain offline, against a keyring you obtain independently.
What that proves: that the events form the signed chain they claim to, and, with an independently trusted key, who issued them. What it does not prove: that an external API told the truth, that a model’s answer is factually correct, or that a compromised host observed honestly. The ledger proves what Krelvan recorded and how it linked it. Factual accuracy still needs grounding, capable models, and independent checks, exactly the hallucination toolkit I wrote about separately.
Where this is headed
Krelvan today is a strong single-install product. You own the runtime, build and run agents, connect tools, gate consequential actions, and export proof. Version 0.1.2 ships as npm, a container, and a signed release artifact.
The honest edges, and the direction: it’s single-install today, so multi-tenant databases, roles and SSO, and distributed workers are a direction, not a current claim. The next engineering work I care about is closing the remaining seams so the design’s strongest statements become fully true: making operational memory a rebuildable projection of the ledger rather than a parallel store, giving remote connectors the one complete network policy the built-in paths already have, adding an owner-level “always gate these classes” switch, and supporting independently signed registry publishing so the ecosystem can safely accept untrusted contributors.
The takeaway
Most agent tools are betting that the model gets good enough that you won’t need to look under the hood. I’m betting the opposite: that as agents do more consequential things, the ability to see exactly what was built, control what it’s allowed to do, recover honestly when it breaks, and hand someone a signed record they can verify without trusting you, becomes the whole game.
That’s Krelvan’s defensible claim. Not that the model is always right, nobody can promise that. But that agent creation and operation are made inspectable, bounded, and genuinely yours. You can try it at krelvan.com.
If you want the concepts underneath this: what an agent really is, designing an agent that doesn’t go off the rails for the authority and approval thinking, and single vs multi-agent for the delegation model Krelvan’s sub-agents use.