Every coding assistant on the market completes the file you’re looking at. That’s a useful autocomplete, and it’s the wrong altitude for the work that actually takes time — breaking a goal into pieces, keeping dozens of changes moving, and getting each one reviewed and merged without losing the thread.
Agentic Flow works at the altitude above that. You describe what you want built. It produces a backlog, runs a fleet of agents against it, and delivers the result as stacked, reviewable pull requests in the repo you already use.
The Idea
Everyone else built a coding assistant. This is closer to an engineering org.
The difference shows up in three places:
Thousands, not a handful. The unit of work isn’t a single prompt-and-response. A goal fans out into many missions running concurrently, which is what makes shipping a whole feature realistic rather than a demo.
A company, not an app. Work is organised the way a team organises it — a backlog, missions, and pull requests that move through review — instead of a chat log you have to babysit.
Yours, not a black box. It’s open source and self-hostable. You can run the whole thing on your own infrastructure and see what it does.
How It Works
Three steps, no onboarding:
- Tell it what you want. One sentence describing the product or feature.
- It builds the backlog. The goal becomes a fleet of missions, each scoped to a reviewable change.
- You review PRs. Work lands as stacked pull requests on GitHub, in the normal review flow your team already runs.
The stacking matters. Large agent-generated changes are hard to review as one blob; splitting them into dependent, individually-readable PRs is what keeps a human able to say yes or no with confidence.
Built to Not Fall Over
The engineering constraints here are the interesting part — running many agents concurrently is mostly a control problem, not a model problem.
| Concern | Approach |
|---|---|
| Scale | Designed for thousands of concurrent missions, not a handful |
| Cost | Local-first, escalating only the hard ~20% to frontier models |
| Safety | Every tool call authorized; explicit spend and action controls |
| Reliability | Built so the control plane stays up |
| Integration | GitHub-native — PR auto-advance and webhook events |
| Extensibility | A skills library, and it runs anywhere |
The local-first split is the part I’d point at. Sending every token to a frontier model is the obvious way to build this and the fastest way to make it unaffordable. Routing most work locally and escalating only what genuinely needs the expensive model is what makes running a fleet economically sane.
Where It Runs
- GitHub-native — stacked PRs, auto-advance, webhook events
- Desktop app — native speed
- Self-hosted or cloud — your infrastructure or theirs
- Open source — run it yourself
Free forever for solo use, no credit card.
Why I’m Building It
The agent tooling I use daily is good at the small unit and weak at the large one. It will write the function; it won’t carry a feature from “we should build this” to “this is merged” without a human holding every thread.
That gap is where the actual work lives. Closing it needs less model cleverness and more of the boring infrastructure a real engineering org runs on: a backlog, parallelism, spend limits, authorization on every action, and review that a person can actually perform.
That’s what this is.