I spent 8 weeks building a production grade application with an Agent Orchestration tool. I believe I have a strong signal into the future of building software.
Dogfooding is one of the cheapest quality mechanisms a startup has. If you can use your own product to build your own product, or as a tool for any part of your business, do it immediately. Why? Bugs get fixed quickly when the person who has to live with them signs the payroll. Features get cut quickly when nobody internally will use them. Project Management and Marketing tool SaaS companies iterate to success quickly when they use their own product to run the business. The question of whether engineers sit on customer calls and take support rotations usually gets answered with a job title. Teams with an engineering customer support rotation fix bugs and annoyances quickly.
My blog is about agentic engineering methodology, which makes the same test apply to me. There is a fair heckle available here and I have heard it: yes Gene, we can all hear you on agentic best practice, but what have you actually built with it? Reasonable. Writing about agent orchestration without shipping anything through it is commentary, not evidence. So over the last two months I picked a product, picked an orchestration platform, and built the thing properly. I want to be precise about what "built" means, because that word is doing a lot of unpaid work in most posts like this one. Not a demo. Not a prototype with a good screenshot. A deployed application with provisioned infrastructure, three tiers of automated tests, CI gates that block merges, DevEx that spins up a local environment in seconds and a roadmap it is actually being built against.
This is part 1 of what happened.
Yet another forms app
Forms are the connective tissue of business software. Ask for data, validate it, store it, retrieve it, edit it. We call them CRUD screens and treat them as solved. They are not solved. The gap between a bog standard form and one people actually complete is entirely in the UX: how errors surface, how conditional fields appear, whether totals recalculate as you type, whether it works on a phone in a parking lot with one bar of signal.
I have built form systems repeatedly, independently and inside startups, for enterprise customers who all believed their form requirements were unique. In 2008, when Google App Engine opened up, the deployment story was good enough that I built a portfolio product called SohoScheduler. What you would now describe as Calendly meets JotForm: let a small business stand up a bookable, computed form without hiring anyone. In 2026 I chose to rebuild that product. Same problem, eighteen years of hindsight, and an agent factory instead of a text editor.
Small Office, Home Office (SOHO). Three goals, in priority order.
- Simplicity. If my mum cannot use it, it is not done. That line is in the roadmap document as a literal acceptance criterion.
- Speed. The app has to feel instant on a mid-range phone, which rules out most of the obvious architecture choices.
- UX. Computed values, conditional visibility, and repeating groups have to behave correctly and visibly, because that is the entire reason to use this over a PDF and an email address.
Nobody reads eight paragraphs of process on faith, so try it at dev-forms.foursignals.dev. It has bugs and it has rough edges, and that is precisely the point. A real app with real problems is the only honest test of whether Agent Orchestration gets you to an MVP and keeps you iterating afterwards, across all four signals.
Landing page
Form creation, AI inspired
Form authoring
Form filling and testing
What is Agent Orchestration?
In the State of Agentic Tooling report we reviewed The three levels of agentic maturity. This helps identify where you are at as a company and a path to get you to where you need to be. Agent Orchestration is firmly in the Level 3 Autonomous Swarms area with valid side quests into Level 2 Composable Tooling and Level 1 Prompt Engineering.
Gas City is Steve Yegge's et al solution for Level 3 Autonomous Swarms. It is an open source SDK for building what he calls software factories: many coding agents, coordinated, with the work itself treated as the durable object rather than the conversation. The source is on GitHub and the documentation is at docs.gascity.com if you want the reference rather than my summary of it. I first got the pitch properly at an event with Steve Yegge and Ajit Banerjee, and the framing that stuck was the industrial one. You are not chatting with an assistant. You are running a production line.
The Fabrication model is common to modern engineering teams and described brilliantly in the fictional tale The Phoenix Project. Factory describes our engineering future well, smaller teams managing virtual production lines with AI Agents doing most of the work. To achieve this you need a strong foundation with good engineering principles. I spoke briefly about this here in AI Doesn't Fix Your Org. It Amplifies It.
Agent Orchestration Tooling
The concept isn't unique to Gas City. Many of the alternatives are listed on my Github account, github.com/thinkjones. See the Agent Orchestration collection. I have tried four of them and found Gas City to be the closest one I would commit to for a professional team. For complete objectivity here are some alternatives.
Independent and open source-ish. This is where the actual experimentation is happening.
| Tool | Shape |
|---|---|
| Conductor, Vibe Kanban | A board over parallel agent sessions. Cards become tasks, worktrees keep them from colliding. |
| Claude Squad | Terminal UI over tmux and git worktrees. Fast, minimal, no server. |
| Composio Agent Orchestrator | Fleet management across any coding agent, each in its own worktree, each producing its own PR. |
| Ruflo (Claude Flow) | Multi-agent swarms specifically for Claude Code and Codex, with a hive-mind coordination model. |
| Paperclip | Orchestration aimed squarely at the "zero-human company", with a visual workflow builder over agent teams. |
| OpenClaw | Modular always-on agent personas you can swap or upgrade individually. Closer to a persistent workforce than a build pipeline. |
| CrewAI | Role-based crews with defined goals and delegation. The most widely adopted of the Python-native frameworks by some distance. |
| Pi | A deliberately minimal harness that spends its budget on context rather than features. |
The fuller catalogue is awesome-agent-orchestrators, which currently runs to well over a hundred projects across parallel runners, swarms and autonomous loop runners. Two observations from reading it. The list is turning over fast enough that any article naming names, including this one, has a shelf life. And it is almost entirely independent: I count two vendor-backed entries in the whole catalogue.
The vendor stacks. Every major provider now ships an agent framework, and it is worth being precise about what they are, because they are not competing with the tools above.
| Vendor | Product | What it is |
|---|---|---|
| Anthropic | Claude Agent SDK | The primitives behind Claude Code, exposed for building your own agents. Agent teams and subagents cover in-process orchestration. |
| OpenAI | Agents SDK | Multi-agent workflows with handoffs between specialised agents and tool integration. |
| Agent Development Kit (ADK) | Code-first agents with graph-based workflows, across Python, TypeScript, Java and Go. Antigravity is the IDE-side play. | |
| Microsoft | Agent Framework | AutoGen and Semantic Kernel merged into one production SDK, shipped at 1.0. |
| AWS | Strands Agents, Bedrock AgentCore | An open source agent SDK, with AgentCore as the managed runtime to deploy it on. |
Here is the distinction that matters, and I would want a CTO to be clear on it before someone tells them the AWS answer already covers this.
Those five are frameworks for building agent applications: customer support bots, research assistants, internal copilots. They are excellent at that. Almost none of them orchestrate coding agents against your own repository, which is a different problem with different primitives. You need work that outlives the session, a workflow definition you can diff in a pull request, and an audit trail of what a machine did to your codebase at 3am. Your cloud provider's agent SDK does not give you those, because it was never trying to.
Two different layers. Buy the wrong one and you will spend six months discovering it.
Why Gas City?
The speed of change is dizzying and the ability to be flexible is important. Every tool above changes shape regularly. Building on any single one is a bet on a roadmap you cannot see, made by a company that may not exist in three years, and the correct response to that is not to wait. It is to keep the exit cheap.
Three questions decide how cheap:
- Does your work live somewhere you own? Git and plain files, or a vendor's database with an export button nobody has tested.
- Is your workflow definition portable? A file you can read and diff, or a configuration screen you would have to rebuild by hand.
- Can you change model provider without rewriting anything? Not "does it support multiple models" in the marketing sense. Can you actually switch mid-project.
Gas City passes all three, because everything is TOML, markdown, and git. I have run this project across Claude, Antigravity and Kimi, and the switching cost was three lines of configuration. That is not a feature I would have rated highly a year ago. It is the one I would now refuse to give up, and it is why "open source" here is a practical requirement rather than a preference. Teams that are all Microsoft or all Anthropic or all Google, cannot take advantage of pricing, availability or capability and get locked into ways of working that are not necessarily advantageous for them. Elite DevOps teams opt for Cloud Agnosticism to enable cost optimization, performance and availability. The same applies here. There are many, many, model providers, not being tied to any single proprietary process is essential in this era of experimentation.
Orchestrator Design Patterns
Gas City's names for these are Mad Max references, which is charming right up until you try to map them onto another tool. Six primitives, and every orchestrator has to answer the same six questions whatever it calls them.
| Concept | Gas City name | Description |
|---|---|---|
| Who does the work | Agent | A configured worker: name, provider, prompt template, scope. Pure configuration, so define as many as you like. The platform assumes none exists until you declare one. |
| What the work is | Bead | One unit of work: ID, title, status, type. The universal substrate. Tasks, mail, sessions and convoys are all beads, differing only by type. |
| How it gets done | Formula | A reusable, written-down method applied over work. Applying it produces work: a formula materialises as beads that outlive the file and any session. |
| Where it happens | Rig | An external project, usually a git repo, registered with the city. Each rig gets its own bead namespace and its own agent scope. |
| What configures it | Pack | The unit of configuration: declares agents, formulas and orders. The city is itself a pack, the one rooted at this deployment. |
| How you observe it | Event | An outbound notification fired by activity. Fired, not polled. Humans and agents both watch the same stream. |
Adapted from the six primitives in the Gas City docs.
The six primitives and how they relate: Agents, Beads, Formulas, Rigs, Packs, Events. Diagram: Gas City docs.
Three of those six are where tools actually differ. Most have a task list, few have a durable work graph. Most have prompts, few have a workflow definition you can diff in a pull request. Almost none fire events you can audit afterwards. Run any of the tools in the previous section through those three and the gaps are usually where the pain will be. Two primitives are worth expanding, because they are where the leverage is.
Beads are units of work. Beads is a git-backed, dependency-aware issue tracker built for agents rather than humans. Each issue is queryable, has explicit blocks and parent-child relationships, and survives across sessions. It solves what Yegge calls the "50 First Dates" problem: an agent waking up with no memory of what it did yesterday. Markdown plans rot; a dependency graph does not. Underneath it, Dolt gives you a version-controlled SQL database, so every state change an agent makes is both a write and a commit. When an agent closes a work item at 3am, the audit trail is not a log line you hope somebody kept. It is a diff. Gas City sits independently of provider and enshrines portability by ensuring the work item is durable and the session is disposable. That inversion is what makes retry, resume, and audit possible at all, and it is the single thing I would look for first in any of these tools.
Packs are the reusable part: composable directories of agents, skills, formulas, and prompts that you import into a city. They are the interesting primitive, because they are engineering judgment in a form you can install, fork, and version. Most of my eight weeks went into them, which is the subject of the rest of this series.
Everything lives in GitHub. Configuration, work items, prompts, review artifacts. Which means a multi-repo task is not a special case. My city has two rigs attached, work items route by prefix to the right repository, and the whole configuration is one monorepo I can diff.
An eight week adventure
Three fifths of the elapsed time went into learning agent orchestration and building the factory. So call it three weeks of actual product construction. At the end of it: three deployed services, 111 TypeScript test files, 19 Playwright end-to-end specs, 23 Python test modules, five CI tiers gating every merge, infrastructure provisioned from code, and a preview deployment on every feature branch.
Historically I would have called that six to twelve months of work for a small team. Not because the individual pieces are hard, but because the integration between them is where projects go to die, and integration is precisely what a factory with gates is good at. This is the claim I am willing to defend: the multiple is real, it is large, and it is mostly not about code generation speed. It is about the cost of coordination collapsing.
Try the app here - dev-forms.foursignals.dev Sure there are bugs, sure you will find rough edges. I built this alone. With the sharpening blade of a small team and real customers it would be a lot more refined. What I am confident about is the pace of correction: fixing, improving and advancing the product now takes minutes, hours and days rather than weeks and months.
I am enthused to dig into these ideas with the factory :
- Bug fix automation with Gas City
- Feature ranking and semi-automated releases
- Non-Coding Workflows such as marketing, sales funnel and knowledge base maintenance.
- How fast can Product 2 be constructed now the factory is built? Who has an MVP I can experiment with?
- What changes on brownfield projects?
Part 1, Building Production Grade Applications using Agent Orchestration. After eight weeks I built a production grade application. Five weeks spent building and learning the factory, three building the product. Pre-AI this product would have taken at least six months and a team of 3-5 to build. link
Part 2, Architecture. What changes about system design when the primary reader of your codebase is a machine with no institutional memory, and twelve of them are working at once. What are essential foundational elements needed to be autonomous? link
Part 3, Process. The nine-step build workflow, the two human gates, and the thirteen artifacts one feature leaves behind. coming soon
Part 4, People. What is the human's role in this process. How has it changed? What grows, what shrinks, where do we sit? What are the new teams and structure needed to take full advantage? coming soon
Part 5, Measure. How do we measure in this new era? What were the stats of this project? What survives from DORA, and a metrics set for an org where machines write most of the diff. coming soon
This is a portfolio product and a portfolio article. If you want help getting your engineering team or organization onto this footing, from a lunch and learn through to a one to twelve month advisory engagement, fractional CTO work, or engineering leadership for your team, get in touch.