A room of agents
One agent doing everything is a mess. The trick to building SoiTarot solo was a small team of them that could hand work off without me in the middle.
The naive way to build with AI is one chat window and a human frantically copy-pasting between it and everything else. That human is the bottleneck, and it's me, and I get tired. Building SoiTarot in a week meant getting myself out of the middle — running not one agent but a small team of them that could pass work to each other. This is the operations half of the experiment.
Specialists beat a generalist
I set up the build inside Claude Code as four roles, not one do-everything assistant. Each had a job, a lane, and a point of view:
| Agent | Owns |
|---|---|
| Design | The system — tokens, components, art direction |
| Content | Drafting and rewriting at volume |
| Engineering | The Next.js build, the pipeline, the CI gates |
| SEO | Schema, structure, internal links, indexing |
A specialist with a narrow remit makes better decisions than a generalist trying to hold the whole project in its head at once — same reason you don't ask one person to be your designer, copywriter, engineer, and SEO. The division of labour was the first thing that made the pace possible.
Shared memory is what makes a team a team
Four agents that can't remember what the others did aren't a team; they're four strangers. The thing that turned them into one was a shared .memory/ folder — a single place where decisions, tokens, and specs lived, plus a handoff protocol so each agent picked up where the last left off instead of starting cold.
That's why the design agent's motion tokens showed up unchanged in the engineering agent's code, and why a decision made on day two didn't get quietly re-litigated on day five. The architecture decisions were written down, append-only, with reasons — so context was a file you read, not a conversation you had to have again.
The hard part of multi-agent work isn't the agents. It's the memory between them. Get the handoff right and a team of specialists outruns any single context window.
The economics: cheap tokens for volume, good tokens for taste
There's a money angle that matters at scale. Not every task deserves your best model. Bulk drafting — the first pass on thousands of pages — went to a fast, cheap model. The quality pass, the judgment calls, the things where taste lives went to a slower, sharper one. Spend your expensive tokens where they change the outcome and your cheap tokens everywhere else, and a four-figure pile of pages stays affordable instead of absurd.
That split is the same principle as the rest of the build, just denominated in tokens: the scarce resource is judgment, so you spend it deliberately and let the cheap, fast machinery handle the volume — behind a fence that catches whatever the cheap pass gets wrong.
What I actually was, by the end
By the last day I wasn't writing pages or drawing cards. I was running a room — setting the specs, refereeing the handoffs, deciding what "done" meant. The work had moved up a level, from making the thing to directing the things that make it. That's the uncomfortable, interesting future the whole project kept pointing at: the ceiling stops being how much you can do and becomes how well you can orchestrate.