PilotSwarm: The Agent Runtime That Remembers How to Wake Up

A durable execution layer for GitHub Copilot SDK agents, built to survive crashes, sleep through long waits, and resume exactly where they left off.

8 min read • View on GitHub • More from affandar

A clockwork agent sleeps inside a sealed chamber while a storage vault and scheduler wheel sit around it. One side of the chamber is lit by a terminal glow, while the other shows the same agent restored and ready to continue. This illustrates the article's core idea: agents as durable processes, not fragile chat sessions. — PilotSwarm treats an agent like a process that can pause, persist, and wake back up without losing its place.

We've built PilotSwarm from the ground up in Go, leveraging its powerful concurrency model and performance characteristics to deliver a framework that can scale with your needs.

Affan Dar, Creator of PilotSwarm · Announcing PilotSwarm: Orchestration for Multi-Agent AI

Key Takeaways

PilotSwarm's real trick is not orchestration, but durable execution for agents that need to survive waits, crashes, and restarts.
Its replay-based model turns agent work into a recoverable session, which is a very different promise from a normal chat loop.
The runtime splits execution from persistence on purpose, using workers, PostgreSQL, and Blob Storage as one contract.
Markdown-defined skills and shared UI layers make the system easier to extend, but also make clear operational writing part of the product.

The Strange Part Is Not the Chat, It Is the Sleep

Most agent tools start with conversation. PilotSwarm starts with continuity. An agent can pause, dehydrate, survive a restart, and later resume from the exact logical point it left off, which makes it feel less like a chatbot and more like a background process with memory.

That matters because the hard cases are never the short ones. DevOps runs, recurring monitors, approval loops, and long external waits are exactly where ordinary agent stacks get brittle. PilotSwarm is trying to make those cases first-class.

The key design choice is the threshold between a lightweight pause and a full dehydration cycle. That split is what lets PilotSwarm stay efficient without giving up recovery.

From Stateless Turns to Durable Sessions

The runtime is built around replay. That means the system can reconstruct what happened by re-running the same execution path, which is why the ordering of yield calls becomes version-sensitive. Change the order, and you can break recovery.

That is a serious systems choice. It tells you the project is not treating state as an afterthought. State is the contract.

// Conceptual shape of a durable wait
if (waitTime < SHORT_WAIT_THRESHOLD) {
  await setTimeout(waitTime)
  continueExecution()
} else {
  await dehydrateSession()
  releaseWorker()
  await resumeLater()
}

The Runtime Is a Split Brain on Purpose

PilotSwarm divides responsibility cleanly. One side executes turns. The other stores session state. That sounds ordinary until you notice the runtime is optimized for recovery, not just persistence.

System type	State persistence	Long waits	Crash recovery	Primary abstraction	Operational complexity	Best fit
Stateless agent loop	Weak or implicit	Consumes compute	Fragile	Chat turn	Low	Quick demos and prototypes
Traditional workflow engine	Strong	Handled well	Strong	Job or workflow	Medium to high	General automation
PilotSwarm	Strong and agent-native	First-class	Strong	Durable session	Medium	Long-running AI tasks and recoverable agent work

The worker polls PostgreSQL for tasks, hydrates from Blob Storage, runs the next turn, and then decides whether to stay in memory or dehydrate again. That is not just saving progress. It is an execution contract between compute and storage.

Markdown Becomes Behavior

The project's `.github/skills/` and `.github/agents/` pattern is one of the sharper ideas in the repo. It turns Markdown into something operational. A skill file is not just documentation for humans. It is input the runtime can use to shape behavior.

A WSJ-style hedcut portrait of Affan Dar, the creator of PilotSwarm, rendered in black ink on a white background. The portrait serves as a source-linked editorial reference for the project's origin story and design intent.

That lowers the barrier to extension, but it also raises the quality bar for authors. If the docs are unclear, the behavior is unclear too. The upside is that the system stays readable. The downside is that the system asks you to write like the runtime will actually use what you wrote, because it will.

A close-up shows a ledger passing a sealed envelope toward a storage vault while a thin thread remains connected to a waiting terminal. Two small clocks show a short pause and a long pause, and the long path bends into storage. This explains the runtime's threshold between an in-memory wait and a durable dehydration cycle. — Short waits stay lightweight. Long waits become durable. That threshold is the system's most important efficiency choice.

One UI, Two Surfaces

The CLI and the portal are not separate products pretending to be related. They share core UI logic, which keeps the operational model consistent whether you are inside a shell or in a browser. That matters more than it sounds.

Surface	Strength	Weakness	Best use
CLI	Fast for operators	Dense for newcomers	Local debugging and hands-on control
Portal	Clearer for monitoring	Less immediate than a terminal	Remote supervision and session review
Shared UI core	Keeps behavior consistent	Requires careful abstraction	One mental model across both surfaces

If the session model changes, both surfaces change together. That is a subtle but important design choice. It keeps the system from fragmenting into a terminal tool on one side and a dashboard on the other.

Why This Feels More Like Infrastructure Than an App

The repo reads like infrastructure, not a demo. It is a TypeScript monorepo with workers, portal code, shared UI packages, Docker, Kubernetes, Azure Bicep, and GitOps-oriented deployment scripts. The emphasis on integration and durability testing reinforces the same message.

That stack tells you who this is for. It is for teams that want agent behavior to survive the real world, not just impress in a notebook. PilotSwarm is trying to be the substrate beneath agent products, not the product itself.

What PilotSwarm Is Up Against

The comparison is philosophical as much as technical. Stateless agent loops are easy to start and easy to lose. Feature-heavy frameworks offer breadth, but they often leave durability as an application concern. Workflow engines are durable, but they can be heavy for agent-native work.

Approach	What it optimizes	What it leaves to you	Where PilotSwarm differs
Stateless chat wrapper	Speed of setup	Recovery and persistence	PilotSwarm makes recovery native
Feature-heavy agent framework	Integrations and breadth	Operational discipline	PilotSwarm narrows the scope to runtime behavior
Traditional workflow engine	Durability and routing	Agent semantics and conversational turns	PilotSwarm keeps the agent model in the center

That is why PilotSwarm is interesting even if you already know the agent framework landscape. It is not competing on breadth. It is competing on whether the runtime itself can remember how to continue.

The Trade-Offs

Durable execution is not free. It adds mental overhead, especially when replay-sensitive ordering becomes part of the API surface. That can feel brittle if you are used to ordinary imperative code.

But the alternative is worse for the use cases PilotSwarm is aiming at. If the agent must wait, crash, or resume across time, then pretending state is incidental will eventually cost you the session. The project is early, but the trade-off is coherent.