“You should not be prompting Claude, you should be building systems that prompt Claude.”
Overcoming Orchestration Overhead
I noticed that I was spending a lot of time arranging handovers between agents to get access to fresh context windows. After a time I started writing scripts to launch agent harnesses in sequences. Many of us have gone this route. Many of us have personal tooling for this kind of thing. Gantry is my solution.
By nature, a tool like this is highly opinionated. It comes with the territory, that it is uncharted. No one knows how to do these things. Thousands of directions are being explored. No one can sensibly say that they know the best way to do it, people can hardly agree on what 'it' is.
For my own part, I find that my personal solution works better for me than anything else I can find out there. I daily drive Gantry for agentic execution because I feel it performs better than Claude Code. I don't think this is unique in any way. I have several friends who have their own personal meta-harnesses that work really well and Gantry is inspired by these private tools much more than by any commercial service or open source project.
Here are some of my biases that shape Gantry:
I am Martin Eriksson (Github, HN, X). I started programming as a kid in the late 80s, I started my first software company in 2008. Since 2022 I have tried to get good at building with coding agents. Sometimes doing things using agents when it would have been easier to do it myself, because my main focus has been getting better at working with agents. Built my first own ambitious agent harness in 2024. Built another harness, an agent multiplexer in 2025. Now building long-running meta-harness Gantry since 2026.
I work in terminals and I enjoy text-based user interfaces. I loved the DOS-environments of my childhood, with rich text-based interfaces with menus, tabs, status bars, modals etc. It ain't my meta-harness if it ain't got a great TUI. I have my own personal TUI toolkit for various complex components like menus, tables, editors etc, which i vendor in Gantry.
I am mainly trying to get good at setting up long-running autonomous execution runs. Large software projects implemented in a single multi-hour or multi-day run, loops that iterate for days targeting some goal. That's not for everyone. If you're not into that kind of thing, Gantry is not for you. Go try some other esoteric meta-harness or have fun with Copilot.
“And now we’re back to hyper-waterfall … I’m not ruling out that there’s some magician out there who can actually make that work.”
Meta-Harness for Hyper-Waterfall
Gantry is built to support spec-driven development with extensive upfront planning and long-running autonomous execution. Whenever you would launch a large number of subagents, consider using Gantry for a more structured approach.
Gantry provides rich interfaces for keeping track of agents and directing them during ongoing runs. But if your style of working is being in the loop, reviewing the work of agents step by step, Gantry is not for you.
I spend most of my time working on plans – hours, days or weeks working to create the initial planning documents for something, often large plans like detailed roadmaps. I then feed the plans to systems, primarily Gantry, which executes plans. I will sometimes give a plan to Claude Code, Codex or OpenCode, but if it's extensive enough that I expect more than a handful of subagents to be used, I give it to Gantry.
Gantry does not provide a workflow for making plans. You can do it with the built-in assistant system, but personally I mostly use Claude Code running Fable and Opus to do analysis and planning. Gantry comes into the picture once the plan is done, i.e. when most of my work is done. Once I hand it to Gantry, it runs itself for a long time and only stops to contact me if it runs into something serious that multiple trouble-shooting agents have failed to resolve.
Once I have to resolve some issue, I often fall back to Claude Code. The practical step is
gantry enter my-current-run && claude to launch Claude in the Gantry worktree. But increasingly
I'm dogfooding and using the built-in Gantry assistant instead, which is a chat interface to
Gantry's own agent harness. My favorite is using GPT-5.3-codex-spark as the driver. But the work
I do on running Gantry jobs largely happen outside Gantry.
Gantry is not really a tool I work in. It's something I monitor as it runs, through the TUI. I often have 3-5 Gantry TUI instances open. The amount of actual interaction with Gantry as it runs is limited and arguably the TUI is overkill. But it gives me great joy. Similarly, Gantry will spend a good amount of agent calls to e.g. Haiku and other mini-models to decorate the TUI and logs with neat natural language names and descriptions. It's not necessary but I really enjoy it.
Patterns for agent sequencing
Of course, the reason I use Gantry is the agent sequencing. Instead of thinking about agent handovers and loop scripts, I use ready-made patterns implemented in Gantry's control flow:
Break big plans into milestones. Then break milestones into sprints.
Build->Test->Review loops with agents dispatched to fix problems or re-plan as needed.
Map jobs where agents execute the same prompt with some parameter iterating over some set.
Loop jobs where I define a goal and the entire Gantry build machinery runs again and again until the goal is achieved.
An experimental flow for doing web design work based on worked-through design systems.
Planning on multiple levels
Gantry launches coding agents in structured sequences with careful use of planning at multiple levels. The basic metaphor is breaking work into milestones and sprints. A sprint is an agent-sized chunk of work. A milestone is a set of sprints. The metaphor is arbitrary, the point is to steer intelligence through the project on multiple levels.
What has Gantry actually worked on?
At the time of this writing, I have used Gantry in 17 code bases. 203 jobs have run from start to finish, inlcuding 96 for developing Gantry itself. 42 in a procedural music generator I am working on, 16 in a complex Rails app, 11 in a Godot game and 8 in an investigative journalism project.
Over the 203 runs, 10,680 agents have been launched, 59.2 million output tokens have been generated and 22,831 file edits have been made. In total agents have been running for 630 hours.
A great number of agent sessions are launched, but their per-agent token usage is lower. That's the core idea of Gantry, to break work up into agent-sized units.
The average peak context window size for execution agents is 109,733 for Claude (n=734) and 99,257 for Codex (n=674).