LanternDOCS

The production runtime for AI agents

Durable runs.
Hard budgets.
Fail-closed isolation.

Your prompts, tokens, and data never leave your VPC. The control plane orchestrates by metadata — your cloud executes.

What is Lantern? It's the infrastructure that runs your AI agents in production — so you don't have to build crash recovery, spending limits, sandboxing, or audit trails yourself. You write the agent; Lantern makes sure it finishes what it started, never overspends, can't escape its sandbox, and can prove what it did.

lantern dev      # Postgres · Redis · API · dashboard · a live agent
Get started in 5 minutes →How the runtime works →
Runs complete or resume.
Every step is journaled to Postgres before it executes. A process restart resumes at the first incomplete step and skips the rest — no re-spent tokens, no double webhooks.
Isolation is declared, not guessed.
Agents set manifest.isolation at publish time. Untrusted code, browser automation, and package installs land in a microVM — Firecracker or Kata. The runtime never downgrades silently.
Every run leaves evidence.
A SHA-256 chain over the full journal is Ed25519-signed at completion. Verify the receipt offline with the key fingerprint from /.well-known/lantern-receipts — no server required.
17connectorsOAuth + API-key; install with POST /v1/connectors/install
5isolation backendsrunc · gVisor · Kata · Firecracker · Wasm — declared at publish time
402hard-budget HTTP statusblocked before a single token is billed
30 scrash-recovery sweepLANTERN_RECOVERY_INTERVAL default; resumes from the journal
Ed25519signed receiptsverify offline — no server, no SDK, just the key fingerprint
2 + 1tiers, one journalshared tier · microVM tier · same durable Postgres event log
The life of your run read top to bottom: gated → executed → tracked → proven 1 · THE GATES — before anything runs Your request POST /v1/runs Who are you? auth · everything tenant-fenced Can you afford it? over budget → HTTP 402, no spend How sandboxed? the manifest decides: shared or microvm — caller can't override 2 · EXECUTION — one of two tiers SHARED TIER — your own code, fast first token in ~50–200 ms · tokens stream live • workflow graph or plain LLM loop — every step journaled • risky steps can wait for a human — parked at zero compute • crash-safe: resumes at the last completed step MICROVM TIER — untrusted code, walled in its own virtual machine per workload • separate kernel · internet access only by allowlist • tools run inside the VM: shell_exec · http_fetch • tier down? the run fails loudly — never quietly downgraded 3 · STATUS — where your run is right now queued running succeeded failed waiting cancelled a crash re-drives within 30 s — finished work is never re-billed 4 · YOUR EVIDENCE — what you hold afterward journal_events — every step on the record, streamed live Ed25519 receipt — signed proof anyone can verify, no account needed OTel traces — tenant · run · step on every span Shared tier MicroVM tier Durable execution — crash-safe resume Verifiable receipts
POST /v1/runs → auth + budget gates → shared or microVM tier → journal → signed receipt. Every box is real code.

What the runtime gives you

Six things every production agent needs and almost nobody wants to build: the ability to survive a crash, a safe place to run untrusted code, live output as it happens, visibility into what ran, a spending cap that actually stops a run, and a way to catch quality regressions before your users do.

Durable execution
Crash mid-step? The recovery sweep re-drives the run from the journal and skips completed steps. Idempotency key sha256(run_id|step_id|attempt) blocks double-execution at the provider.
→
Isolation ladder
Five classes: runc → gVisor → Kata → Firecracker → Wasm. Declared in the agent manifest. Never a bare pod for untrusted code — and if the microVM tier is unavailable, the run fails explicitly.
→
End-to-end streaming
Token deltas flow runtime → gateway → SDK the moment they arrive. Subscribe with GET /v1/runs/{id}/events (SSE). No buffering points, no polling, no extra infra.
→
Observability built in
Every OTel span carries tenant_id, run_id, and step_id. Emit lantern.run.* metrics to any OTLP endpoint. No-op when LANTERN_OTEL_ENABLED is unset — zero overhead until you need it.
→
Budgets that block
PUT /v1/agents/{name}/budget sets hard limits on cost/day, cost/run, tokens/day, and per-tool rates. A run that would exceed the limit returns HTTP 402 before a single token is billed.
→
Eval-in-CI + rehearsals
Pin a branch baseline and gate merges on regression — a score drop returns HTTP 422. Replay past failed or low-score production runs as synthetic tests before promoting a new version.
→

Five modules, one runtime

Every module — the personal agent, the eval suite, the marketplace, the voice channel — is a lens on the same durable, budgeted, multi-tenant core. Nothing is a bolt-on.

Five modules, one runtime every module is a lens on the same durable, budgeted, multi-tenant core — nothing is a bolt-on 1 Agent Runtime THE CORE Durable workflow engine · capability-based multi- LLM router · K8s-default substrate with the fail- closed isolation ladder (runc → gVisor → Kata → Firecracker) · crash-replay with no re-spent tokens · one W3C trace per spawn · Ed25519 instance identity two tiers: shared inline · microVM — one journal 2 Personal Agent — "Jarvis" LIVE WhatsApp + iMessage assistant that texts AS you — owner-only, learns your real voice · agentic macOS actions · cross-channel memory · life-events engine · skill forge · event scout · time-travel recap · immigration deadline sentinel · draft-and-confirm the dogfood: 16 agents running the founder's life 3 Trust & Governance Policy-as-code budgets (hard-fail 402) · eval-in-CI + rehearsals (replay real failures pre-merge) · Ed25519 verifiable receipts · RBAC scopes · gRPC service-token trust boundaries · OTel with tenant/run/step ids · AES-256-GCM secrets · RLS on every tenant table provider idempotency keys 4 Channels & Reach WhatsApp · iMessage · Slack · Telegram · Discord · voice (Twilio / LiveKit) · embeddable webchat (/widget.js, one script tag) · email — signature-verified, naturally paced, all riding the same sessions API a channel is an entry point, not a fork of your agent 5 Developer Experience TS · Python · Go SDKs · agentic CLI — lantern onboard (description → running agent), lantern doctor, lantern agents dev (hot reload → smoke run → live waterfall) · visual workflow editor that EXECUTES · MCP registry · A2A cards · forkable agent marketplace with signed settlement one command boots the whole stack: lantern dev THE SHARED SUBSTRATE UNDER ALL FIVE durable journal_events log · capability model routing · budgets · tenant isolation · observability every module runs on the same core: budgeted, journaled, receipted
Agent Runtime · Personal Agent · Trust & Governance · Channels & Reach · Developer Experience — all event-sourced through the same journal.

Control plane orchestrates. Your cloud executes.

The control plane authenticates, budgets, and dispatches via an outbound gRPC tunnel — no inbound ports on your side. Agents run in microVMs on your nodes. Keys, prompts, and run data stay in your cluster.

Control plane · SaaS
Orchestrates
Schedules runs, routes model calls by capability, enforces budgets and eval gates. Speaks gRPC to your data plane over an outbound tunnel — no inbound ports opened on your side.
outbound tunnel
no inbound ports
Your VPC · data plane
Executes
Agents run in microVMs on your nodes — Firecracker or Kata for untrusted code, runc for trusted workflows. Keys, prompts, and run data stay in your cluster.
Ed25519
signed receipt
Verifiable proof
Attests
Every completed run gets an Ed25519 signature over its journal hash. Verify offline with POST /v1/runs/receipts/verify — no live server required.
Get started in 5 minutes →·Runtime deep dive →·GitHub ↗