How the pieces fit

Culvii is four things working together.

Surface	What it is	Who uses it
Culvii Kit  @culvii/kit	A TypeScript SDK. You install it as an npm package and import primitives — agent(), tool(), model(), workflow() — to define what your agents and workflows do.	Developers
Culvii CLI  culvii	A command-line tool. You use it to log in, develop against the cloud, deploy your code, trigger runs, and tail logs.	Developers
Platform APIs	The HTTP API that Kit and CLI both talk to. Eventually public; not yet documented for direct use.	Internal — everyone reaches it through Kit or CLI
Culvii Console  app.culvii.com	The web app. It's where you watch your runs, approve human-in-the-loop gates, manage workspaces and keys, review audit logs, and govern agents at scale.	Developers and operators

The flow, in one paragraph

You write a workflow in TypeScript using Kit. You log in once through the CLI (culvii login). You run culvii dev to push your code to your dev environment in real time and watch it execute. When it's ready, you run culvii deploy to ship a versioned snapshot to sandbox, then production. From the Console, an operator approves the human-in-the-loop gates, watches the runs, and exports the audit log when compliance asks for it.

Where things actually run

There's no local engine. There's no Docker container. There's no port-forwarding. Your agents and workflows run in Culvii's cloud across three environments — dev, sandbox, and prod — each backed by its own database. The CLI's culvii dev command keeps a live connection between your editor and your dev environment so the changes you save appear in the Console immediately.

To reach data your organization keeps internal, you have two paths:

• Write a tool — code that calls into your data through whatever interface you already expose: an HTTPS endpoint, a connector to a SaaS system, a query against a database your network allows from the public internet.
• Connect via MCP — the Model Context Protocol. If your data source already speaks MCP (Jira, Linear, Notion, GitHub, your own MCP server), you can plug it in directly.

Tool code runs on Culvii, not in your data center. If you need code to execute inside your network, that's the Smart Client Worker pattern — on the roadmap, not in v1.

The diagram

flowchart LR
    A[Your editor<br/>TypeScript + Culvii Kit] -->|culvii dev<br/>culvii deploy| B[Culvii CLI]
    B -->|HTTPS / WebSocket| C[Platform APIs<br/>dev · sandbox · prod]
    C <-->|HTTPS| D[Culvii Console<br/>developers + operators]
    C -.->|outbound HTTPS / MCP| E[Your internal systems]

Note for setup: this site uses Mermaid diagrams, which require the @docusaurus/theme-mermaid plugin to be enabled in docusaurus.config.js.

What you don't have to think about

A short list of things Culvii handles so you don't:

• Where the engine runs and how it scales.
• Storing run state, retries, and resumption after restarts.
• Streaming logs and traces somewhere a human can read them.
• Issuing every agent a verifiable identity.
• Cryptographically signing the audit trail.
• Pausing a workflow at a human-in-the-loop gate and resuming it cleanly when the gate is approved.

Each of these has a Concepts page that explains the model, and a place in the SDK or Console where you can opt out or override.