I don't run one AI chat. I run a small team.

Late one night I connected a Claude Code session to my phone, "for random stuff tomorrow." Shortly after, I had a random idea: what if a Storyblok user could describe a custom field type in one sentence and get a working plugin back?

About two hours later the result included:

• four field types built, tested and deployed
• a browser test suite that had found and fixed four bugs
• an installable plugin
• two article drafts with charts
• a Storyblok-powered blog to publish them on

That didn't come from one long chat. It came from a setup I now use for almost everything: one coordinator, many hands.

I first used it on Dekiro, my yearly game challenge. In this third year, AI took it from 2D to a working 3D game. There I wrote about the coordinator and its sub-agents: 70 of them over three days. This night was the same pattern on a smaller project.

• The coordinator is one Claude Code session, and the only one I talk to. It holds the plan, owns the repo and the commits, keeps a memory of decisions, and checks everything that comes back.
• Sub-agents are fresh agents with one job each: generate a field, test a prompt, click through the UI, draw the charts, draft an article. They start with nothing but the brief, run in parallel and report back.
• Peer sessions are other Claude Code sessions that own other projects, like my website. The coordinator never touches their repos. It sends them a brief.
• Me, on my phone, making the calls.

Its job isn't the typing. Its job is making sure the work is right. It reruns the tests before every deploy, looks at every chart and opens the screenshots. It's also the only one that commits, which is a rule I took straight from Dekiro.

Once a sub-agent reported a padding fix as done. The screenshot showed the content still touching the edge. The coordinator found the real cause, a stylesheet loading in the wrong order, and fixed it in the template for every future field. A summary would never have caught that.

A sub-agent knows its brief and nothing else. So every brief states the goal, what to read first, what's off limits and what to report. One line mattered most:

If you think GUIDE.md is missing something important, say so in your report instead of editing it.

An agent with no context is a poor partner for a long conversation, but a perfect stand-in for a first-time user.

• The three field generators reported gaps in the written guide they were given, and every gap went into the next version.
• A fresh agent in an empty folder, with only the copy-paste prompt meant for other developers, listed nine places where it had to guess.
• Every field passed its unit tests, and an agent clicking through the real Storyblok sandbox still found four bugs.

When agents work in parallel, give them one source of truth. The chart agent and the writing agent read their numbers from the same data file, so they couldn't invent different ones.

The handoff to my website's session was a file: the goal, the content model to reuse, where the material lives, what "done" means, and the boundaries: work on a branch, never push, keep tokens out of git, leave stories as drafts. It reported back with the branch, how to run it, screenshots and open questions.

When I changed my mind there, switching the blog to my site's own typeface, the coordinator read it in the report and re-rendered every chart to match. Neither session needed the other's chat history.

The coordinator kept one review page current for my phone: results, screenshots, charts and numbered questions. I answered eleven of them in one message. Everything else it decided, logged in a journal and committed in small steps.

The setup isn't fixed. I adapt it to the data I'm working with. A field plugin built on dummy data can go to any model. For sensitive topics, like customer data, internal numbers or anything confidential, I switch to local AI models running on my own machine.

The pattern stays the same: a coordinator, focused briefs, results that get checked. What changes is which model sits behind each role and what is allowed to leave the machine. Deciding that is part of writing the brief.

On Dekiro I called it "gate on taste, not on code." Taste, product judgment, and deciding what an experiment is and isn't stay with me.

The leverage isn't that agents type faster. It's that clear delegation scales and a single chat doesn't. Start with one sub-agent, one well-scoped job and one proper brief, then read what comes back. You'll quickly see where your instructions were vague. That's the point.