Skip to main content

Governance is the differentiator

If there's one page in these docs you should read before deciding whether Culvii fits your stack, this is it.

The case in one paragraph​

Most agent frameworks treat governance — audit trails, identity, policy, human approvals — as something you wire up around the framework after the fact. The framework's job is to make agents fast to build; everything else is your problem. That works for proofs of concept. It doesn't survive a security review, an internal audit, or the question "who told this agent to do that, and when, and on whose authority?" Culvii is built so that governance is the architecture, not a layer on top. The defaults make audit, identity, and approval work out of the box; the escape hatches let you change behavior when you need to.

If you don't need any of that, Culvii is overkill. If you do, the cost of bolting it onto a framework that wasn't designed for it is much higher than the cost of starting with one that was.

What "first-class governance" means​

Four things we treat as primitives, not features:

1. Identity per agent​

Every agent gets a verifiable identity at creation — specifically, a W3C Decentralized Identifier (DID) issued automatically by Culvii.

The DID is what shows up in audit events. Not a shared API key, not the application that started the agent, not the human who ran the deploy. The agent itself.

This matters because the alternative — ambient API key trust — does not survive scrutiny. If three agents share an API key, the audit log says "the API key called the model"; it doesn't say which agent did. Identity-per-agent is the only way to make per-agent audit and per-agent revocation meaningful.

In v1: DIDs are auto-issued. Programmatic identity APIs (custom keystores, BYO identity providers, manual DID rotation) are on the roadmap.

See Identity and signed traces.

2. Audit by construction​

Every action an agent or workflow takes — every model call, every tool call, every gate, every approval — is captured in an append-only audit log. You don't add audit by importing a logging library; the platform writes it.

The audit log records:

  • Who initiated the action (human user, API key, or agent DID).
  • What the action was (model called, tool invoked, workflow deployed, etc.).
  • When it happened (UTC timestamp).
  • The result (success / failure, error code).
  • The correlation ID that links related events across systems.

It is append-only. There is no UPDATE or DELETE. Compliance teams can export the log as needed.

In v1: the audit table is written to from day one, but the developer-facing query API and culvii audit command are on the roadmap. Operators can read the log via the Console.

3. Human in the loop, in the workflow​

Human approvals are not a sticky note next to your code. They are a primitive — gate() — inside the workflow itself.

gate('go-no-go', {
  condition: (state) => state.assessment.recommendation !== 'GO',
  message: (state) => `Approve to proceed with ${state.projectId}`,
})

When a workflow hits a gate(), the engine pauses the run and emits an item to the operator's Inbox in the Console. An operator approves or rejects. The engine resumes from where it paused.

The gate could pause for thirty seconds or thirty days; the engine's persistent state model handles it the same way.

This is not the same thing as "the agent will email someone for approval." That requires the agent to be honest about asking. gate() is part of the workflow; it cannot be skipped by the agent.

See Human in the loop.

4. Operator surface, separately designed​

Most frameworks build a developer surface and assume operators will figure out their own tooling. We don't. The Console is built for operators as a primary persona — the people who manage agents at runtime, approve gates, review the audit log, and answer compliance questions.

This isn't a "developer dashboard with extra tabs." Operators have a different mental model from developers. They don't care what code is in vendorAnalyst.ts; they care which agent is running, which version, with what permissions, and what it's done in the last 24 hours.

The Operator's Guide covers this surface in full.

What we don't do​

Worth being clear about:

  • We don't make claims of compliance. Culvii is built in a way that supports compliance work — SOC 2, ISO 27001, EU AI Act high-risk obligations — but compliance is your organization's process, not a feature you turn on.
  • We don't replace your IAM. Tenant identity, SSO, and human user management federate to your existing IdP (Google in v1; SSO via Cognito federation on the roadmap).
  • We don't pretend governance is free. Adding human approvals to a workflow slows it down. Audit logs grow. Identity-per-agent means more state. We think the cost is worth it; you should evaluate that for yourself.

Why "primitive" and not "feature"​

The word matters. A feature is a flag you flip — turn on logging, configure an approval webhook, add an audit middleware. A primitive is part of the type system; you cannot build the rest of the SDK without it being there.

Governance as a feature means: the framework runs the agent; you bolt on the audit. If you forget, no audit. If a third-party plugin doesn't emit events, gap in audit. If the framework's runtime crashes mid-run, partial audit.

Governance as a primitive means: the engine writes the audit; the SDK can't bypass it; the agent's identity is tied to the run from the moment it's created. If you want to disable any of it, you do so explicitly — and that disable is itself audited.

That's the architectural commitment behind the product, and it's where Culvii is opinionated whether you want it to be or not.

When governance gets in your way​

We're aware that for a 10-line proof-of-concept, this all feels like overhead. It is. Culvii is not built for the 10-line PoC; it's built for the 10,000-line production system that needs to survive an internal audit.

If you're early in your journey, prototyping fast in something lighter and migrating later is a reasonable plan. We'd rather you reach for Culvii when the governance properties matter than fight them when they don't.