Agent Flow
A visual canvas where a node is a live coding agent and an edge is a two-way message bus — with automation triggers and a receipt for every run. Early access.
Early access · In active development — Agent Flow is not yet generally available in the product. The underlying engine (the "fleet" primitives) is built and tested; the visual canvas and in-app surface are being built in the open. Request access on the Agent Flow page. We label what is shipped versus what is on the roadmap and will not describe it as live until it is.
Agent Flow is Bootspring's visual multi-agent orchestration surface. On the canvas, a node is a live coding agent and an edge is a two-way message bus — and the same graph you design on is the cockpit you supervise on. Add automation triggers and a receipt for every run, and you get a category no single tool owns today.
The idea in one line
Most tools own one axis. Automation platforms (Zapier, Make, n8n) have a visual canvas but no live agents. Terminal tools (cmux) drive parallel agents but have no canvas, triggers, or receipts. Graph tools (LangGraph Studio) visualize LLM state, not live terminal agents. Code-first frameworks (CrewAI, AutoGen) have neither a canvas nor triggers. Agent Flow is built to own the intersection.
| Capability | Zapier / Make / n8n | cmux | LangGraph Studio | CrewAI / AutoGen | Agent Flow |
|---|---|---|---|---|---|
| Visual canvas | Yes | — | Yes | — | Yes |
| Live coding agents | — | Yes | — | Yes | Yes |
| Two-way agent comms | — | Yes | — | Yes | Yes |
| Automation triggers | Yes | — | — | — | Yes |
| Receipts / monitor | — | — | Partial | — | Yes |
How it works
Agent Flow is composed of a small set of owned building blocks. Every layer is Bootspring-built and maintained — permissive engines (a terminal multiplexer, a browser engine) sit behind Bootspring APIs, so there is no third-party graph or flow library in the surface.
Live agents (the fleet)
A fleet is a group of live agents running in parallel — Claude Code, Codex, or local models — each doing real work. An orchestrator spawns them, and any agent can be an implementer, reviewer, or specialist. Agents are heterogeneous by design: mix tools and models in one fleet to bring different strengths to the same problem.
Two-way communication
Agents don't just report up a tree. On Agent Flow, any agent can message any agent or the orchestrator — a flat message bus where roles organize responsibility, not the flow of information. A worker can hand a diff to a reviewer directly; a reviewer can escalate to the orchestrator. Delivery works both ways: an agent can check its inbox, or a message can be pushed straight into another agent's input.
Self-verification (Bootspring Browser)
Agents can verify their own web changes. Bootspring Browser is our own browser-automation layer — navigate, read, click, screenshot, and assert — so an agent can open a URL and confirm its change actually landed before reporting success. It runs on a full browser engine when interaction is needed, or a lightweight fetch engine for fast text checks.
Automation triggers
A fleet can be launched by the world, not only by hand: a GitHub pull request, an inbound webhook, a schedule, or a custom event. That turns a fleet from a session you babysit into infrastructure — for example, "pull request opened → spawn a review fleet → post the summary to Slack → wait for human approval → merge."
Receipts and monitoring
Every run produces a receipt: which agents ran, every message on the bus, self-verification verdicts, failures, and the overall outcome — plus a sequenced, timestamped event log and lifecycle hooks you can attach notifications or gates to. This is the "monitor" half of an agent you can't see is an agent you can't improve — the record that makes a run auditable, replayable, and improvable.
What is available today
| Piece | Status |
|---|---|
| Fleet engine (agents, orchestration, two-way comms) | Built and tested in the platform engine |
| Bootspring Browser (self-verification) | Built and tested |
| Triggers, hooks, event log, receipts | Built and tested |
| Streaming transport (live events) | Built and tested |
| Visual canvas in the app | In development |
CLI / MCP exposure (bootspring fleet, bootspring_fleet) | Roadmap |
The foundation is real and merged; the product surface you interact with is being built. Until the in-app canvas and CLI/MCP tools ship, Agent Flow is offered as early access — request access and we will onboard you as surfaces come online.
How it relates to other Bootspring features
- Swarm Intelligence — the server-side multi-agent engine (topologies, consensus, planning). Agent Flow can dispatch into it as one of its presets.
- Visual Workflow Builder — the drag-and-drop automation canvas. Agent Flow extends the same idea to live agent nodes.
- Session Intelligence — efficiency and anti-pattern scoring that feeds the monitor-to-improve loop.
Frequently asked questions
Is Agent Flow available today? Not generally. The engine is built and tested; the visual canvas and in-app tools are in active development. It is offered as early access.
How is it different from Zapier, Make, or n8n? Those automate API calls between apps. Agent Flow nodes are live coding agents that talk to each other and can be launched by the same kinds of triggers — so an automation can spin up a fleet of agents, not just move data.
How is it different from cmux? cmux drives parallel agents in a Mac terminal, but has no visual canvas, no automation triggers, and no run receipts. Agent Flow is cross-platform, adds the canvas and triggers, and records a receipt for every run.
What does "receipts / monitor" mean? A per-run record — which agents ran, what each was asked, who won a race and why, self-verification verdicts, and gate outcomes — plus a full event log. Not generic execution logs.
Does it use a third-party canvas library? No. The canvas is built and maintained in-house. Permissive engines (a terminal multiplexer, a browser engine) sit behind Bootspring APIs, but the surface is our own.