LanternDOCS

The runtime for production AI agents

An agent demo takes an afternoon; agents in production take a year — durable execution, a cost cap finance will sign, an eval gate in CI, real isolation for untrusted code, and the channels your users actually live on.Lantern is the runtime that solves the production half — in your own cloud. Your prompts, tokens, and data never leave your VPC. Open-source, Apache-2.0 — one command boots the whole stack.

The same primitives power a headless backend worker and a personal agent that texts on your real number — so you build the runtime once and get both.

git clone https://github.com/dshakes/lantern && cd lantern
lantern dev      # Postgres + Redis + API + dashboard + a live agent

How it works

Run an agent

One authenticated call kicks off a run — from your shell, your app, or a script.

curl -X POST http://localhost:8080/v1/runs \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"agentName": "support", "input": {"prompt": "Summarize ticket #4821"}}'

Why developers choose Lantern

Crash-proof
Every step is journaled. A run resumes exactly where it died — no double side-effects.
Any model
Address models by capability (auto, reasoning-large); the router picks the vendor.
Your cloud
Agents execute in your VPC over an outbound-only tunnel. Your keys, your data.
Governed
Per-agent budgets (402), eval-in-CI gates (422), Ed25519-signed receipts.

Core concepts

  • Agent — named, versioned config: instructions, model tier, tools, guardrails.
  • Run — a single execution; journaled step-by-step, replayable after a crash.
  • Session — a long-lived conversation; survives disconnects, streams over SSE.
  • Connector — links external services (Gmail, Slack, GitHub) via OAuth or API key.
  • Surface — an inbound channel: WhatsApp, Slack, Telegram, web chat.
  • Data plane — your VPC; agent code and data never leave it.