I started with a simple assumption: if one coding agent was useful, several coding agents working in parallel would be even better.
Like most, I figured out that works until a point where you are just copying and pasting outputs between sessions, and sessions would get worse on delivering as time and context grew.
Codex, Claude Code, and GitHub Copilot could each write, research, review, or test a bounded piece of work. The problem was everything between those pieces.
Agents duplicated effort, missed repository-specific instructions, reviewed stale changes, and returned individually plausible results that did not form a coherent whole.
I had created more execution capacity, but I had also made myself the scheduler, message bus, status dashboard, and integration queue.
That problem eventually became Agentflow: an open-source, provider-neutral CLI for coordinating coding agents around an approved goal.
The first failure mode was easy to spot. If I divided one content creation task among several writers, every individual edit could look reasonable while the complete experience lost its voice, transitions, or teaching sequence.
My issue was the lack of true shared state between agents and models that I was running.
A long-running piece of work was spread across: the controller's chat history; Markdown plans and handoff files; agent sessions and terminal panes; Git branches and worktrees; pull requests and CI; and whatever I could remember when an agent stopped or a chat disconnected.
None of those was a reliable workflow graph. A terminal output could tell me that an agent had exited, but not that its result was accepted. A claimed task did not prove that a worker was alive. A passing test did not prove that every acceptance condition had evidence.
The natural response is often to write a larger prompt, which was never going to solve the issue. It made the controller more expensive and turned its context window into an increasingly fragile database.
Agentflow uses Beads as durable task state: goals, dependencies, claims, decisions, review stages, and acceptance evidence. Agentflow adds the control plane around that graph: one approved root goal; one persistent, resumable controller lease; exact, atomic task claims; bounded provider-neutral handoffs; model, skill, base-commit, scope, and budget preflight; structured worker results and review dispositions; deterministic waiting for CI or other external state; and explicit completion or human-action-required outcomes.
The coding agents remain disposable execution contexts. Git and GitHub remain the integration boundary. Repository instructions and domain skills remain the source of truth for the work itself.
Agentflow is not trying to become another coding agent, and it does not replace project expertise. It decides what is ready, who may own it, what evidence must come back, and whether the overall workflow may advance.
Originally I wondered if just having beads was enough, but unfortunately I needed that external harness outside of all the model specific tooling, that could become a co-ordinator. Plus some other features.
Native subagents are useful, and observable terminal sessions are useful. I use both, but found neither is durable project state.
Agentflow can launch observable external sessions through Herdr, or work with native provider capabilities, but a session is only an execution lane. The controller still has to validate the launch, reconcile the result, disposition review findings, and decide whether the root goal is complete.
This also means a dropped IDE connection, a sleeping laptop, or a provider error does not require a new plan. A fresh chat can reattach to the same root, inspect the durable state, reconcile completed work, and continue without replaying the old transcript.