There's a moment most teams hit a few months after everyone gets a coding agent. Individually, everybody's faster. A task that took 2 days takes an afternoon, the pull requests show up quicker, and Friday's demo looks great. But the project somehow isn't moving any faster.
Look a little closer and you might find out why. The spec for the feature lives in someone's chat window. Two developers (and their agents) made two different reasonable guesses about the same data model. The architecture drifts a little with every pull request, the reviewers are buried, and if you ask what's actually done this week you'll get 3 answers and a shrug.
Nobody did anything wrong here. Teams adopted the tools before anyone had a process for them, which is what teams always do (it's how most of us adopted git, and the cloud, and pretty much everything else). Every developer worked out their own way of pairing with an agent, and for one person on one task that's fine. Across a team and a shared codebase, all those private habits stop adding up to a plan.
We hit the same wall.
What we learned rebuilding our own delivery system
This year we've been rebuilding how Made In Tandem delivers software, around senior engineers (Conductors) working alongside coding agents. The agents probably weren't the hard part. The hard part was everything around the code: what's next, who has it, what "done" actually means, and whether a person really looked at the work before it shipped.
So we wrote that process down, and then we built a tool to hold it. The tool is called Tiller, and as of this week it's open source under Apache 2.0.
What Tiller does
Tiller is a workflow tool for a team of people and coding agents building software together. It holds the plan, the checks, and the state of a project. The agent does the reasoning and the typing, a person makes the calls at each gate, and Tiller keeps track of everything in between.
A handful of opinions sit at the center of it.
The plan lives in the repo. Markdown for intent, YAML for state, and git for history. There's no database and no hosted service, so cloning the repo clones the plan, and a change to the plan gets reviewed the same way a change to the code does. A plan that lives in a separate tool drifts away from the code it describes, usually sooner than anyone expects.
Plan just far enough ahead. Work grows from epics to features to tasks. A feature gets its spec, its acceptance criteria, and its tasks when its turn comes, and not a moment before. Our first design planned the tasks up front, and those plans were stale before anyone built them, so we ripped that part out. (The design history in the repo has the full list of things we tried and threw away. It's longer than you'd think.)
Done means done. Your own build, test, and eval commands become gates, and the required ones block done. Tiller records what passed and which revision it ran against. And if an approved spec quietly changes later, Tiller flags the drift before more work piles on top of it.
A person merges, every time. An agent can carry the work right up to the line and turn every check green. Only a human merge gets it across, and Tiller learns about that merge by watching git rather than taking anyone's word for it. That's the one boundary that holds no matter how an agent behaves, so we built everything else around it.
Bring any agent. The whole surface is a CLI, plain files, and a set of skills the binary serves to whatever agent you run. Claude Code, Codex, Pi, and a plain shell all see the same instructions. People on the same project use different tools (ours certainly do), and a team's process can't depend on everyone picking the same one.
There's also a local, read-only console (tiller serve) with a board everyone can read, the whole plan as a tree or a mind map, and a report you can hand to a client without scheduling a status meeting.
What it isn't
Tiller doesn't run your agents, and it doesn't pretend to control them. It never makes a model call. It ranks the next legal moves, records the gates, keeps the state, and that's about it. The developer drives, and the developer answers for the result. The name is the point here; a tiller steers the boat, but somebody's hand has to be on it.
It's also not for everything. Spikes, prototypes, and research code don't need it, and a solo project still finding its shape probably doesn't either. Tiller earns its keep when more than one person is on the work and someone outside the team needs to know where things stand. And it's young. The current release is v0.21, the console doesn't write yet, and the roadmap in the repo is plain about what's built and what isn't.
Why give it away?
We could have kept Tiller as a quiet internal advantage. But a delivery method nobody can inspect is just a claim, and there's no shortage of AI claims floating around right now. Putting the tool in the open means anyone can check our work. Read the specs, read the design history, and run it on a real project. If it holds up for your team, wonderful. If it doesn't, tell us why, because issues and pull requests are open and we'd genuinely like to know.
Try it on one feature
Resist the urge to roll it out across your whole project. Pick one feature this week, write one spec, and get to one merge.
brew install --cask madeintandem/tap/tiller
There's also a one-line installer for macOS and Linux, and the quickstart walks a scratch project from install to a merged task. The docs are at madeintandem.github.io/tiller and the code is at github.com/madeintandem/tiller.
And, if you'd rather bring your team through it with the people who built it, we run hands-on training called Building Software With Agents. Your team takes a real feature from its own backlog from plan to merge, in its own repo, with the agents it already uses.
Agents made writing code cheap. They haven't done the same for deciding what to build or knowing it's right, and those are the jobs a team actually shares. Tiller gives that work a place to live, in the repo, right next to the code.