Run thousands of agents. Efficient, durable, secure.
Lightspeed is open-source infrastructure for running long-lived agent fleets in production.
Try theDemoright now, there is no sign-up, or take the Source Code and run it yourself.
More agents. More complexity.
Frontier harnesses like Claude Code, Codex, OpenCode, and OpenClaw are excellent, but they assume they own an operating system. That assumption is what makes them hard to scale, hard to secure, and hard to keep running reliably over time. As fleets grow, so does the work of isolating execution, controlling access, and tracking what each agent did.
Traditional: One OS per Agent
An operating system to run and isolate for every agent
Lightspeed: Harness Separated from Compute
Execution environments attached only when needed
Scale your fleet. Keep control.
Lightspeed separates the harness from compute.
The harness is the agent loop, context management, and session state. In Lightspeed it runs as a lightweight, deterministic, event-sourced workflow. Anything that needs an operating system — shells, code execution, full file systems, long-running jobs — happens on machines the agent borrows for exactly as long as it needs them.
The result is less idle infrastructure, sessions that recover after restarts, and explicit boundaries around access, credentials, and execution.
One agent per user, reachable over Telegram or WhatsApp, remembering weeks of context, calling calendars, mail, and internal tools over MCP through configured connections. Nearly all agents are idle at any moment; in Lightspeed an idle agent is a suspended workflow, not a running VM.
A planner agent spawns builders, testers, and reviewers. Each sub-agent uses an approved profile and attached environment, clones the repository, runs the suite, and critiques the others' work. The fleet keeps going for days and picks up where it left off after a worker restart. Separate workspaces and machines let teams compare approaches without sharing live edits.
Point a fleet at an undocumented landscape: dozens of repositories, servers, schemas, and cron jobs nobody fully understands. Agents explore machines and codebases in parallel, reconstruct how the pieces talk to each other, write the documentation that never existed, and keep it accurate as they continue to observe. Sub-agents split the estate; a coordinator merges what they find.
Research Agents Supervising Long Experiments
An agent launches a training run or data pipeline as a job on a GPU box, checks in on progress, adjusts parameters, and writes up the results when it finishes — hours or days later. Credentials for the cluster are injected into the environment outside model-authored tool arguments.
On-call Operations Agent
An alert starts a managed session from your incident workflow. The agent reads dashboards over MCP, inspects the host through the environment daemon, proposes a fix with a deadline, and reports back to the channel. If nobody answers, the workflow cancels it cleanly.
You already run Temporal. Give every customer, order, or ticket its own agent: your workflow starts a managed session, binds tools backed by your own activities, and receives durable emissions back. No separate agent infrastructure to run.
Designed to Perform
Lightspeed is a deterministic agent harness built from the ground up for durable workflow engines, not VMs. Written in Rust and open source, it runs on Temporal today — the same engine behind OpenAI's hosted agents. It also comes with a powerful frontend that makes it a breeze to manage your agents.
Clone theSource Codeand run it yourself, or try the hostedDemoright now.
Reusable session setups, shared across clients and fleets. A profile defines the model, instructions, tools and resource attachments an agent starts with. Workspace and environment attachments carry explicit access levels; MCP selections stay within the registered server’s tool allowance.
Profiles attach existing environments. Machine provisioning, credential bindings and cleanup have their own lifecycle.
Read on
Every session is an event log, and the log is the only truth. Each user message, model response, tool call and tool result is recorded as an event before it is applied; the agent’s state is nothing but a replay of that log.
Because the core is deterministic, replaying committed events reconstructs the recorded session state without asking the model to reproduce an answer or re-executing tools. Referenced provider payloads and tool results preserve the evidence used by that session while its history is retained.
Large payloads — context, tool output, provider-native data — are referenced from the log by content hash. Events attribute requests to an actor, API key or runtime controller within the universe. This session record is distinct from the Platform’s access audit log and from audit records maintained by external systems.
The log lives in Lightspeed’s own event store, separate from the workflow engine’s history, so it survives restarts, redeploys and multi-week sessions.
Read on
Sessions attach existing environments for files, commands and long-running jobs. Bring a machine you manage or provision one through Incus; supported provisioned machines can pause or stop under a configured idle policy and wake when a tool needs them.
The model gets a real machine. The harness never lives on it.
Read on
Channels are the surfaces an agent talks through. One agent can be reachable over Telegram or WhatsApp, post into an incident channel, and hand back to a human with a written summary.
None of those integrations live inside the agent loop, so a session can gain or lose a channel without the harness changing.
Read on
A configurable slice of the universe API, exposed as generated MCP tools over Streamable HTTP. Point an agent at it and it can configure the platform it runs on.
Read on
Cluster credentials, deploy keys and API tokens are resolved when work is dispatched and injected into environment processes and jobs, outside model-authored instructions and tool arguments.
The executing process receives the secret value. Its operating-system permissions, network access and outputs remain part of the security boundary; sharing a machine also shares access to its injected credentials.
Read on
Workflow-backed tools can give outstanding results hard deadlines. A controller can use those outcomes to cancel or close the session when work is no longer needed.
Cancellation requests cleanup at the boundary that owns the work. It does not undo completed side effects, and a timeout on one wait does not itself cancel the underlying job.
Read on
Dedicated VMs connect as universe environment instances, and sessions use them through event-sourced active environment state. The in-repo Incus provider supplies durable full-VM provisioning, explicit takeover of existing VMs, on-demand daemon routes, and pause/stop power control.
Only attached machines are available to a session. Each attachment grants read, edit, command or job access, checked against the selected machine on each call. Model-side selection tools can be enabled separately; selecting a machine does not reserve it for one session.
Read on
At the heart of every agent is a state machine that manages what goes into the model’s context window. In Lightspeed that state machine is an event-sourced, deterministic core: it replays a session’s event log into state, decides the next step, and emits thin effect intents that runtime adapters execute against real providers and tools.
The core performs no I/O itself. The hosted runtime reconstructs its state from committed history after worker restarts and redeploys, allowing sessions to last weeks or months.
Two decisions make this practical
Minimal provider abstraction. Only the information needed to decide and branch is extracted; provider-native data stays opaque and blob-backed rather than being flattened into a fake universal message model.
Offloading to CAS. Everything the workflow logic does not need goes to content-addressed storage, so the payloads crossing between workflow and activities stay thin and the history stays small.
Read on
An AEAD-encrypted secret store, plus an OAuth token broker that refreshes tokens automatically. Secrets are held at the universe boundary and handed to environments and jobs only on use.
Read on
File and process tools always operate on the environment a session has selected — a real machine, reached through the environment daemon. Agents read and write files, run commands and inspect processes exactly as they would on a workstation.
These tools never touch linked virtual file system content; that is a separate tool family.
Read on
MCP servers are configured once for the universe, with API-key and OAuth identities shared by every session that selects that server id. Sessions carry the selection — not the transport configuration, and not the credentials.
Read on
Provisioned environments can use an explicit idle policy based on daemon activity. The Incus provider supports pause and stop, with wake-up when a session tool next needs the machine. Registered and external machines remain under their operator’s power control.
There are no default idle thresholds. A policy that pauses a machine does not continue escalating to later stages while it remains paused.
Read on
A committed schema contract for the whole platform surface. The API reference, the OpenRPC document, the TypeScript client and the Configurator MCP tool descriptions are all generated from the same Rust manifest and schemas.
Read on
Sessions last weeks to months and survive worker restarts and redeploys. A waiting session does not need a dedicated running machine or an open model call.
Active-run control is admitted while work is in flight: cancel a run to request cancellation of its activities and owned work, steer it at a subsequent model-turn boundary, or queue the next message behind it. Cancellation does not reverse completed external effects or universally stop remote processes.
Read on
Trusted workflow controllers can create sessions with durable emissions, keyed completions, deadlines and cancellation. Admitted workflow-tool declarations pin their destinations and completion rules; model arguments cannot redirect a call to another workflow.
A lifecycle controller owns the surrounding session lifecycle. Ordinary tool and resource configuration is separate and can be changed through authorized setup operations.
Read on
Frontier models are optimised to the hilt — via reinforcement learning — on the assumption that they control a full POSIX-compatible machine. An agent with only MCP servers and provider-native tools will underperform one with a real shell.
Take the machine away and you take capability away. Closing that gap without moving the harness back inside the OS is a central goal of Lightspeed.
Read on
Every agent needs its own VM or container, even while it sits idle waiting for a reply. Cost and attack surface scale with the number of agents, not with the amount of work being done.
Frontier harnesses like Claude Code, Codex and OpenClaw are designed to run inside a guest operating system and need an entire OS to themselves. In an enterprise or shared deployment you cannot simply co-locate agents on one machine, so every new agent means new infrastructure.
Read on
The agent is a workflow, not a process. The harness — the agent loop, context management and session state — runs as a lightweight durable workflow instead of inside a guest operating system.
Waiting sessions share worker and storage infrastructure without needing a dedicated running VM for each agent.
Read on
Long-running work that outlives a single turn: downloads, experiments, data pipelines and delegated coding-agent runs, supervised by job workflows and executed by the environment daemon.
Jobs are enabled through an environment attachment’s job access and run on the actual machine, with persisted records and workflow supervision. Agent-state recovery does not replay the operating-system process; a machine or daemon restart can interrupt unfinished work.
Read on
Create a VM from an approved Incus template, then attach it to the sessions that need it. Separate machines give builders and reviewers separate execution environments; selecting the same machine shares its files and credentials.
Machines live independently of sessions. Configure idle policies or close them explicitly after saving the results; closing a session does not release its VM.
Read on
The core includes history-fork and configuration-clone primitives. A history fork can reuse stored conversation history; a configuration clone starts a fresh conversation from copied setup.
Neither copies live workspaces, machine files or external effects. Lifecycle-managed sessions cannot be forked or cloned. For independent comparisons, ordinary sessions can attach the same read-only workspace snapshot and write to separate destinations.
Read on
A job can report back into the session that started it. The agent checks in on progress, adjusts parameters, and writes up the result when the job finishes — hours or days later — without holding a process open in between.
Read on
Agents that start and manage other agents. A planner can spawn builders, testers and reviewers, hand each one its own profile and environment, and merge what they produce.
Because every sub-agent is itself a durable workflow, a fleet can keep working for days and pick up where it left off after a worker restart.
Read on
A generated client that tracks the API contract exactly. Types come from the same manifest as the server, so a contract change surfaces as a compile error rather than a runtime surprise.
Read on
A universe is the tenant boundary used throughout Lightspeed. Database records, blob storage and workflow identities are scoped to it. A universe API key addresses its one universe; a deployment key can select a universe within its allowed method groups.
The Platform checks people’s memberships, roles and session visibility before calling the runtime. Direct runtime keys have their own scope and do not inherit those personal access checks. Tool credentials belong to the universe and its configured connections; starting a run does not make it execute as the signed-in person.
Read on
Dedicated vfs_* tools read and edit linked snapshots and workspaces with no operating system attached at all. Documentation, notes and skills live here and stay available whether or not a machine is currently borrowed.
When enabled, instruction loading and skill discovery use configured roots in attached workspaces or environments. VFS and machine files remain separate: materialize files onto a machine or capture results back through explicit transfer operations.
Read on
External workflows can add durable tools to an agent. A plugin creates and manages a session, provides tools backed by its own workflows, and relies on Lightspeed to deliver calls, wait for results, handle timeouts and cancel work.
Plugins stay independent of the core session worker.
Read on
Most agent SDKs are not designed for workflow engines. They do not separate the deterministic core from effects such as LLM and tool calls, and they pass far too much data between the workflow logic and its activities — often the entire chat history, back and forth.
Histories bloat, determinism breaks, and durability ends up bolted on after the fact.
Read on
One protocol for binding any workflow as an agent tool. If you already run Temporal, your existing activities become tools: your workflow starts a managed session, binds the tools, and receives durable emissions back.
