The Audience I Didn't Know I Had — Part One
There is a lot of conversation right now about one developer coordinating forty coding agents.
I am not going to pretend I know whether that is good or bad. It is clearly a real model of working, and there are people doing remarkable things with it. But I keep coming back to a more ordinary question: what does agentic development look like for a team of ten developers, each working with one or two agents, while still staying in sync with one another?
For most organizations, that is probably the more immediate problem.
There is a familiar failure mode in software development: the hero coder. One person understands the system, carries the context, makes the impossible things happen, and becomes a bottleneck whether anyone intends it or not. Forty agents may make that person more productive. It may also turn the same problem up to eleven.
This is not an argument against the hero-coder version of agentic development. Organizations tend to know whether they can handle that kind of operating model. An organization that cannot handle a hero coder is probably not ready to depend on one engineer coordinating forty agents either.
I am more interested in the team that already exists: several developers, several codebases, and people who are just beginning to figure out what coding agents mean for their day-to-day work.
That is the problem I built Crypts and Commits for.
The influence was Beads
The most important influence on Crypts and Commits was not the whole Gas Town model. It was the underlying idea of Beads: a git-backed record of work to be done.
That idea landed for me right as I was working through a separate realization: documentation was becoming less of a thing I wrote for another human engineer and more of a thing an AI coding assistant could actually use. I had already been using extensive Markdown files to plan work. Git-backed units of work felt like a natural next step. The planning was no longer just a document I hoped someone would read. It could become durable context that an agent could pick up and work from.
The freeing part was that Beads did not try to become a Jira board.
Jira has a job. It helps a project communicate status and priorities to people beyond the developer doing the work. Crypts and Commits is not trying to compete with that. The context it captures is for the developer and the agent: the deeply technical why behind a change, the plan, the decisions made along the way, and the receipts left once the work is done.
The other influence was the use of metaphor. Gas Town showed me that a metaphor outside the usual software vocabulary can shorten the conversation with an AI. You do not have to re-explain every relationship from first principles if the system has a coherent world for the agent to work inside.
That is part of why Crypts and Commits is built around tabletop gaming. The human is the game master. The agents are the players. The terminology is not just a cute theme; it gives the project a vocabulary for how work should happen without immediately falling back to tickets, epics, and other words that carry a whole different set of expectations.
Crypts and Commits is influenced by Gas Town and Gas City. It is not a fork, a replacement, or a smaller version of either one.
A useful correction from Steve Yegge
That distinction matters even more after Steve Yegge’s recent essay, “The Shape of Things to Come.”
In it, he describes Gas Town falling apart as the models changed and says he has given up on building reusable harnesses. His current work is a personal harness called Wheelhouse, tightly built around his decades-old game, Wyvern. His argument is that harnesses need to become bespoke — chemically bonded to the application they serve.
I agree with that much more than I disagree with it.
I saw the same thing early while building Chi-Town for work and Crypts and Commits for my own projects. You cannot take a generic process, drop it into a repository, and expect it to understand what matters about that project. Someone has to define the world: how the system is organized, what its boundaries are, which decisions matter, and how the agents should behave when they encounter the parts that are unique to this codebase.
For me, that happens through skills and the configuration that drives them. Once you start doing that seriously, I am not sure there is a clean line between “the harness” and “the project configuration.” The configuration is part of the harness. It changes what the agents know and how they work.
So Crypts and Commits is trying to hold a middle ground.
The package itself is reusable. It gives a project common structures for skills, documentation, encounters, and repository-backed receipts. But every project’s actual use of it should become bespoke. You still have to define the game world. You still have to document what is particular about your system. You still have to decide how you want agents to work inside it.
Crypts and Commits does not define your harness for you. It helps you document what is bespoke about your project and gives your agents the tools to use that configuration.
A different scale of agent work
This comparison is reductive, and I want to be clear about that up front. Gas Town and Gas City have a much richer set of ideas than I can summarize in a paragraph. But the reduction is still useful.
Gas Town and Gas City are largely concerned with orchestrating agents as workers in a larger system. Crypts and Commits is concerned with a developer and an agent working together as reasoning partners.
In the pattern I am using, the human describes the work. The AI creates an encounter: a record of the requirement, the rationale, the plan, and the verification. Then the human and the AI refine that encounter until the human believes it will get them to the end state they actually want.
The human is not delegating a ticket and walking away. The human is still doing the reasoning. The agent is helping make that reasoning explicit, explore the codebase, and keep the context from disappearing when the session ends.
At team scale, the important part is that everyone can work from the same pattern. Each developer can use the agent they prefer while the repository holds the shared context and the receipts behind the work. No single engineer has to become the one person who remembers how every agent, every prompt, and every private chat thread fits together.
I can see where multi-agent orchestration might become useful for me someday. I got Gas Town running locally and quickly realized it was more than I was ready to take on. That is not a criticism of the tool. It is an admission about where I am.
It is also about the teams I work with and advise. Many of the clients I work with are only beginning to use coding agents. Rolling out a multi-agent orchestration project right now would be getting too far ahead of them. A shared pattern for developers working with one or two agents each feels like a better next step.
Why I am publishing it
I wrote Crypts and Commits for myself.
That is probably the most honest way to introduce an open-source package. I did not start with a market survey or an argument that every team needs this exact tool. I was trying to create a framework for how I wanted to work with agents, then realized it might be useful to share because so few people are talking in depth about what their day-to-day agent work actually looks like.
Crypts and Commits is intentionally easy to add to an existing repository and just as easy to strip out. It can guide Claude or Codex through the framework and help you customize the project’s own world. If you try it and decide you can build something better in a few days, honestly, I would love that.
The package itself may have a short shelf-life. I think that is probably measured in months, not years. But I do not think that means anyone should wait for the stable answer to arrive. We need to work with these tools, form our own opinions, and learn enough to evaluate the next round when it comes.
The only way you are going to find the harness you want on your own projects is to explore what is already out there.
If you want to try Crypts and Commits, try it. If you want to borrow the idea and make it your own, please do. The interesting outcome is not that everyone winds up using my package. It is that more developers start thinking deliberately about the context their agents need and the harness they want to build around their own work.
Crypts and Commits did not begin as a product idea or an attempt to copy a framework. It grew out of a documentation and handoff habit I had been building for years. Part Two explains that underlying habit and why AI agents changed its value. Part Three explains how that habit became a more formal package and a shared team practice.
That is where the real story begins.
