Layover

A local-first framework for running a lights-out agent factory.

Layover does not call LLMs. It is a supervisor: it spawns headless agent CLIs, gives them a way to talk to one another, persists what they learn, and stops them from running away.

You describe a factory in a single layover.toml — which agents exist, what each one is for, which agents may trigger which others, and how work gets in. Layover then runs it unattended.

The idea

Picture an airport grid.

Each agent is an airport. A message is a Flight. A chain of flights originating from one trigger is an Itinerary, and it carries the two things that keep the network sane: Hops (how many legs remain) and Fuel (how much budget remains). The Tower is air traffic control. One supervised CLI execution is a Run; each agent keeps its own notes in its Hangar and shares what everyone should know in the Logbook. Work an agent sets down to pick up later is a Layover. When everything needs to stop, you call a Ground Stop.

How it works

flowchart LR
    you([you]) -->|POST /flights| tower[Tower]
    tower -->|spawns| cli["claude -p<br/>copilot<br/>codex exec"]
    cli -->|"MCP: layover_send(...)"| tower
    tower -.->|routes · meters · persists| store[("hangars<br/>logbook")]

    classDef t fill:#eaf2fb,stroke:#3f6fa3,color:#12263a
    class tower t

• Sending a message is what starts an agent. There is no separate spawn step.
• Agents talk over MCP. Claude Code, Copilot CLI and Codex CLI reach Layover natively.
• Every run is a clean slate. Nothing carries over implicitly between runs, which makes an agent's memory exactly what it chose to write down.
• The route map is a directed graph. No edge means the flight is refused.
• Runaway swarms are bounded by construction — every itinerary burns Hops and Fuel, and the Tower, not the agent, holds the counters.

Status

Released, and proven unattended. 1.0 shipped on 23 September 2026 after a 48-hour soak driving the real Copilot CLI — one process, no intervention, 1,501 runs, all succeeded — and semantic versioning applies from there.

layover serve runs the factory. It fires scheduled pipelines, runs agent CLIs — up to max_concurrent_runs at once — watches them, times them out if they wedge, reads what they cost and writes each run to history, and serves the MCP endpoint they call back into. After a restart it settles whatever the last Tower left running before it starts anything new. The dashboard on the same port shows the route map, each chain on its own, every agent's output live, cost and the Reserve, help requests you can answer, and learnings.

Agents reach one another. Each run gets a token minted for it alone. An agent that calls layover_send queues a real flight; the same drain picks it up and runs the next agent. Every hop is charged to the one itinerary that began the chain, so Hops, Fuel and the run cap bound the whole conversation rather than each message in it. The route map is enforced against the live child.

Work waits at a rendezvous. A joined agent's flights are parked, and it wakes once, with every verdict it was waiting for. A barrier nothing can complete is given up and named rather than left to hang.

What is not built is isolation between agents: access and workspace are declared, and every agent still runs in the same work_dir.

The README carries the built and not-built list, kept in one place so the two cannot disagree.

Where to start

• Install — a single binary, no toolchain needed
• Your first factory — three agents, and the commands that run them
• The dashboard — layover serve, and what it shows while a factory works
• The reference factory — everything awkward at once, with the arithmetic that sizes its rails

Download

The latest release carries builds for Linux x86-64 and ARM64, macOS Intel and Apple silicon, and Windows x86-64, with a sha256.sum covering every artifact. The install page has the one-line installers.