Your agents keep working when the signal drops.
Burrow gives your agents a way to keep working when the internet drops. Nothing gets lost while they wait for the signal.
Agents assume the network is always there.
At the edge, it is not. When the line goes down, most agents stop, retry blindly, or do the same thing twice.
Work stops
The agent cannot reach its tools, so the task stops or a person has to take over.
Actions repeat
A retry after a timeout sends the same action twice.
Data goes missing
Work done offline never reaches your systems.
Keep your agent framework. Add Burrow under it.
Agent tools are built for agents that are always online. Each one covers part of the problem. None of them carry the work home after an outage.
LangGraph
Saves your agent's state, so it can resume after a crash. But its tool calls still need the network, and nothing syncs the work to your cloud in order with no repeats.
Claude agents
Plan and act well, but every step calls the Claude API. With no signal, the agent cannot think or act. Burrow holds its actions and inputs until the link is back.
Durable execution (Temporal and similar)
Retries each step until it works. But it needs its server to be reachable, which a device with no signal cannot do.
A local model on the device
Lets the agent think offline. But its decisions still have to reach your systems once, in order, when the link returns. That is the part Burrow does.
A small program on the device, a hub in the cloud.
A small Burrow program runs on the device next to your agent. Your agent sends its messages to it, and Burrow keeps them safe on the device. Whenever there is a signal, even a weak one, it passes them on, most important first. Built on NATS JetStream.
Burrow runtime
A small runtime on the machine where your agent runs. Agents send and receive through it over localhost, online or offline.
Store and forward
Each message is saved to disk, and your agent keeps working. On a weak link, critical messages go first, then bulk data. If the link breaks mid-send, Burrow sends again, and the hub ignores the copy.
Burrow hub
The hub drops duplicates, keeps order per site, and hands messages to your services, queues or APIs.
What you can count on.
No lost messages
Every message is written to disk on the device before your agent gets an OK.
No double actions
Each message carries an ID. The hub drops repeats, and the SDK gives your service a key to catch any that get through.
Know where each message is
Check any message: saved on the device, sending, or delivered. Get a callback when the hub confirms it.
In order
Messages arrive in the order they were sent, per site and per topic.
Important first
Critical and bulk lanes. On a slow link, the messages you mark critical go before bulk data.
1 key per site
Each site has its own credential. Revoke a lost device without touching the rest.
Full audit trail
See which site and which agent sent each message, and when.
The same call, online or offline.
A TypeScript SDK. Your agent does not check the network. Burrow does.
import { connect } from "@burrowmq/sdk"; const site = await connect({ site: "device-01" }); // Written to the device's disk now. Synced to the hub when the link is back. await site.send("critical.task.completed", { task: "t-107", result: "done", }, { id: "t-107-done" }); // Where is it now? "saved" | "sending" | "delivered" const state = await site.status("t-107-done"); site.onDelivered("t-107-done", () => markSynced("t-107")); // Commands from your cloud, delivered once. site.on("cmd.config.update", (msg) => applyConfig(msg.data));
Example API. The SDK is in design.
1 site free. Pay for more.
A site is 1 machine running the Burrow runtime.
- 1 site
- Every feature
- Self-serve signup by CLI or MCP
- Community support
- Everything in Free
- Add as many sites as you need
- Email support
Draft price. We add plans as we learn how people use Burrow.
Join the waitlist.
Burrow is in early access. Tell us what you are building, and we will send you a key for your free site when the SDK is ready.
Questions.
Can my coding agent set this up?
That is the plan. When the SDK ships, your agent can sign up from the CLI or the Burrow MCP server, create a site and send a test message with no sales call. Join the waitlist to get early access.
Do I need to change my agents?
Only how they send and receive. Swap your HTTP calls for the SDK's send and on. Your agent logic stays the same.
What hardware does the site runtime need?
A small Linux machine with some free disk space. Exact needs are not set yet.
What happens if a site is offline longer than the buffer?
Critical messages are kept. Bulk data, such as logs, is dropped oldest first. You get an alert before the disk is full.
Why not just use a cloud queue?
A cloud queue needs the internet to accept a message. Burrow accepts it on site first, so nothing waits on the network.
Is this built on open source?
Yes. Burrow runs on NATS, an open source messaging system. You pay for the managed hub and support.