After a year of building projects from scratch through direct human/AI interaction — loops, prompted sessions, the usual — I’m trying the current default: stand up an agent harness and see what a team can do on its own.
I’m not sure this is the right thing to do. There are already several multi-agent harnesses, and more coming. Mine is bad. The best I can say is we’re making progress, and I understand the problem of getting agents to work together autonomously much better than I did a few days ago.
The init was Steve Yegge’s “Continuous Thunderdome” essay from a few weeks ago. I paused, reread it, and thought. I had looked at Gas Town and decided it was heavy, and I wasn’t ready. That turned out to be the right call. The tooling and your readiness for the tooling have to match for value. Im more confident of that now.
I’m not here to litigate stack choices. I landed on Beads — Yegge’s git-backed issue tracker and agent-memory graph — so for now I can call this graph engineering, among other things. Your tooling should probably be different. I’ve already gone from native tmux to Herdr, the agent-aware multiplexer, and I’ll probably move to Superlogical when Mitchell Hashimoto thinks it’s ready. The point is that the tooling will change. I’m learning the problem space. I’m collecting the toe-stubs. And I’m learning that a team of agents can bootstrap its way through ordinary scaling problems surprisingly fast if you let it.
The starting prompt was roughly: I need a multi-agent harness that runs in multiple sessions inside one pane, probably tmux. I want a core memory system, and agent personas based on my friend Nate’s Discover Framework.
From there the agents started bootstrapping themselves. They stood up basic personas and a task list, and we’ve been grinding code and tightening the system ever since. An architect wrote ADRs. A developer built the thing. QA and Security attacked what shipped and sent work back. I’ve gone back to the architect more than once, on both process and simplification. Over the top of that, a chief of staff kept the team moving by constantly rebuilding and tuning the (deterministic) dispatcher.
There were toe-stubs. We ran out of tokens. We blew up the laptop. We upgraded the plan, rebuilt the dispatcher, and I mildly yelled at the agents for load-testing the same box we were developing on. Next is scalable workers on cloud and other machines.
When I started, I wasn’t sure what I was building. I knew I wanted a team of agents that could work together on my projects, and I needed that team to be portable — different contexts, different runtimes. That’s a tall ask. It’s also useful, and it has already paid for itself a little.
Right now I’m building a very light team-builder on top of some industry primitives. I think the idea is portable. Treat my work-in-progress as a reference for what you might be trying, not as a template.
If you go down this path, the journey of building what you need — light or heavy — is the valuable part, even if much of it, or all of it, ends up as throwaway code.
The only thing I’m sure of: anyone who says they know the right way to do this is full of it.