Govern Long-Running Agents

A chat has one control: close the window. An agent that reconciles a ledger every night for a year, or shepherds a migration through a dozen quarters of change freezes, needs the controls of any other production system: someone owns it, something bounds it, it can be stopped without damage, it gives up when nobody answers, it can be seen, and it can be tested before it changes. Lightspeed supplies all six, and none of them are bolted onto a chat loop after the fact: they are properties of an agent being a durable workflow.

Ownership

The governing question for any long-lived automation is who is in charge of it, and the answer in Lightspeed is: a workflow you already run. A trusted controller creates a managed session and declares its tool bindings, its deadline and its lifecycle at creation. The bindings are immutable; the agent cannot re-bind its own tools, cannot grant itself a new capability, cannot outlive the workflow that started it. Results come back as durable emissions with keyed completions, so the controlling workflow can wait for exactly the answer it asked for. Your incident process, your close process, your onboarding process stays the process; the agent is a step inside it.

Limits

Delegation is where fleets go wrong: a planner spawns builders, a builder spawns helpers, and by the third generation nobody set a budget. Lightspeed’s sub-agents are governed from the root. A session may only run children from an allowlisted set of profiles, and the root carries limits on depth, on total descendants, on concurrency and on deadline that every descendant inherits. Refusal is immediate: a spawn that would exceed the root limit is rejected at admission, not discovered in the bill. Proactive agents on triggers carry a daily run budget, and descendants count against it.

Interruption

Stopping a running agent must be safe, and safe means no half-finished side effects and no farewell turn spending tokens on a summary nobody asked for. Active-run control in Lightspeed is admitted live, not between turns: cancel aborts the in-flight model call and every pending tool call and resolves them as cancelled in the log; steer delivers a message the model sees on its very next turn; queue lines the next message up behind the current run. An operator can stop, redirect or re-prioritise a session that has been running for weeks without restarting anything, because there is no process to restart.

Deadlines

Every workflow-backed tool call can carry a deadline, and the deadline belongs to the caller, not to the agent. An on-call agent proposes a fix and asks for approval; if nobody answers within the window, the controlling workflow cancels the session cleanly. The alternative, an agent holding a lock or a connection open for a weekend because a human was on leave, is the failure mode governance is for.

Visibility

A fleet is a tree, and it should be seen as one. The session list groups sub-agents under their parent; a session view carries its lineage: the parent, the pinned profile, the depth, the live children. Every session has an origin. A reviewer can answer “what is running under this migration right now, and who started it” from the console rather than from logs, and can answer “what did it do” from the event log, which is the subject of the audit piece.

Tests

Long-lived agents change: a prompt is refined, a tool is upgraded, a model is swapped. Lightspeed ships an eval harness for regression-testing agent and tool workflows, and the deterministic core makes it meaningful: the same inputs replay to the same decisions, so a changed decision is a real change and not noise. Treat it like any other test suite gating a deployment.

Why these controls come for free

All six controls rest on one property: the agent is a workflow, not a process. A process must be signalled, drained and restarted; a workflow is a log that can be appended to with a cancel, a steer, a deadline or a limit, and a deterministic core that applies them on the next step. That is why governance in Lightspeed is not a feature layered over the agent loop. It is the agent loop.

Read next: Secure Agent Fleets for the isolation boundaries these controls sit inside.

Rests on: managed sessions, workflow-backed tools, deadlines and cancellation, sub-agents, long-running sessions, the eval harness.