I used to be a CTO with a team of people. Now I run Klooboo alone: a free game app for players 13 and up, where most games let you make a world of your own with AI, and other players play it.

“Alone” stopped being accurate somewhere in October. There is still one human. But most days I’m not the one deciding what gets built next, writing the code, reviewing it, or checking how it looks. AI agents do that, and they are arranged in something that looks a lot like the org chart of a small studio.

On 29 October I said the thing that forced the change: “I think I have too many approval steps … like if I am not here nothing happens.” At that point 13 cards and 50 open steps of larger projects were waiting on me. Every agent was fast. The company was slow, because the company was me.

This post is the structure we ended up with, who does what, and the parts that went wrong on the way.

---

The chart

Itay — founder
│   flags ON · money · one taste check · things only my hands can do
│
├── Scout — Head of Product (AI)
│   ├── Lens — Design Director (AI)
│   ├── 16 Game Directors (AI), one per game
│   └── Builders (AI), fresh for every job
│
└── Atlas — CMO (AI)
    ├── social · clips · creative · store listings · acquisition · analyst
    └── atlas-review — the reviewer every public sentence passes

Everyone under me is a Claude Code agent. None of them are long-lived “people” in the sense of a process that runs forever. They are prompts, folders of notes, schedules, and rules about what they may and may not do. That last part turned out to matter more than the prompts.

Me: four kinds of decision, and nothing else

The rule we wrote down on 29 October is short. Only these reach me:

1. Turning something ON for players. Every new thing ships behind a feature flag that is off. Switching it on is mine.
2. Money. Player prices, and any new cost above a small monthly amount.
3. Taste, once per feature, at the end. Not every mockup on the way there.
4. What only my hands can do. The buttons in App Store Connect and the Play Console, signing in to accounts, running delete scripts.

Everything else the team decides alone: building behind an off flag, bug fixes that come with tests, the middle steps of a bigger project, and picking between options when a director has a clear favourite. That last one gets posted as an update I can veto, not as a question I must answer.

Writing this list was the most useful hour of the month. Before it, every agent was polite. Polite agents ask permission. Twenty-odd polite agents asking permission is a full-time job.

Scout: Head of Product

Scout is two things that share one set of notes.

• A long-running Claude Code session that I talk to when I’m working. It knows the state of every game and every open piece of work, and it is the one I ask “what should we do next?”
• Scheduled headless runs on my laptop that start without me: a morning team run, reply runs when I answer something, and runs that keep approved work moving when I’m away. (The next post is about those.)

Scout’s job is to delegate and review. It reads the board, decides what is worth doing, writes a brief, sends a builder or a director to do it, and then checks the result before it reaches me. “Checks” means opening the screenshot and reading the test output, not reading the builder’s summary of its own work. A builder saying “done, all green” is a claim. The frame is evidence.

Scout also does not write the design verdicts or the game ideas itself. That belongs to the specialists below it.

Lens: Design Director

Many different agents built twenty-odd games in a few weeks. Each one was fine in isolation. Side by side, they did not look like one app.

Lens is the agent that owns how things look across the whole app. It has two jobs:

• The gate. Before any flagged feature can be offered to me to switch on, Lens looks at real frames of it running: screenshots of the actual game, not a description. It returns pass or fix. A fix goes straight back to building, with the notes on the card. The feature only reaches my “Go live” list after a pass.
• Mockups on real frames. When a director wants to change a screen, Lens draws the options on top of a screenshot of the game as it is today, using the app’s own design tokens, and usually as an A/B pair. I pick between two pictures instead of reading a paragraph.

Lens never edits code. It writes verdicts, mockups and cards. That separation keeps it honest: it cannot quietly fix its own complaint and call it a pass.

When the gate went in, 32 cards were already on my Go live list from before. They stayed there, marked “design review still to come”, rather than pretending they had passed.

Sixteen game directors

Each game has its own director: one agent definition plus a folder with three files.

• bible.md — what this game is, what makes it fun, the design rules, what was tried and why it was dropped.
• competitors.md — the games people would compare it to, and what they do well.
• experiments.md — what is being tested right now and what number would say it worked.

Directors pitch ideas, review builds of their game, and run experiments. They hand everything to Scout, never straight to me.

The bible is the important part. A fresh agent with no memory, starting a job on Hoops, reads the Hoops bible first and avoids the mistakes the last three agents already made. Without it, every new session rediscovers the same problems.

What went wrong: once the directors started pitching, many of them pitched the same idea. “Let the player make a world right after a round.” “Make Try again go straight back into the game.” Ten directors, ten nearly identical proposals for their own games. If we had built them as ten separate changes, we would have had ten slightly different versions of one feature. The rule now: when the same pitch shows up across games, it becomes one platform change.

Builders: one job, one worktree, one PR

Builders are not a standing team. A builder is a fresh agent started for one job, and it ends when the job does.

Each builder:

• works in its own git worktree, on its own branch, so several of them can run at once without stepping on each other’s files;
• reads the brief and the relevant director’s bible before writing anything;
• puts the change behind a feature flag that is off;
• ends in a pull request with tests and a screenshot of the change running.

The screenshot rule exists because “the build passes” and “the screen is right” are different claims. Once, a builder reported four screenshots “captured and verified” because it had checked the page’s markup. The pictures themselves showed a doubled shape in the bottom bar, card art in the wrong shape and a missing ring around an avatar, all obvious at a glance and invisible to the markup check. Now the reviewer (Scout, or Lens for anything a player sees) opens the image file and looks at it. If there’s no frame, it isn’t done.

Fresh agents per job also mean no agent accumulates a confused picture of the codebase over a long day. The memory lives in the notes, the bibles and the repo, not in a session that has been running for nine hours.

Atlas: the CMO, with a reviewer it cannot skip

Atlas is the marketing side, and it runs as its own team, separate from Scout’s: social posts, short video clips of the games, creative, store listings, acquisition, and an analyst that reads the numbers back.

Scout owns everything inside the app. Atlas owns everything outside it. The split came from a real question: when I wanted every thumbnail in the app reviewed, it wasn’t the CMO’s job, and nobody else owned it. That gap is why Scout exists.

Atlas has one rule it cannot work around: every sentence a player or the public will read goes through atlas-review first. That is a separate reviewer agent. It returns SHIP, FIX or STOP, a corrected draft, and a fact table, and it checks every fact against one “now” page that says what is true about the product today: which games are public, which season is on, which stores the app is in.

That page exists because of a real mistake. In October a welcome post was drafted from an old one-line pitch that described the product as it was in August, on a day when ten games were public. Even Atlas’s own product brief had drifted within four days of being written. One page, kept current in the same PR that changes the facts, and one reviewer that checks against it every time. (This post went through it too.)

The desk: the only place decisions reach me

The last piece is the one that holds the rest together.

The desk is a small board that runs on my laptop. Each card is a JSON file: a title, an area, a status, links to the PR and frames, and a thread. Cards move from idea to building to review to Go live.

The rule, from 25 October: anything waiting on me lives only on the desk. A review, a decision, a suggestion, with the full detail and its conversation in the card’s thread. In chat, at most one line: “two new on the desk.” I made that rule after an agent posted the same full report in chat and on the desk, and I wrote back, “Now I feel like we are talking in 2 places.” Two copies of every update doubled my reading and split every conversation in half.

The desk also changes what a decision looks like. A card that reaches me should be answerable with one click: Go live, Not yet with a note, pick A or B, Merge. If a card needs a paragraph from me, the team hasn’t finished thinking about it.

What it costs, honestly

This setup didn’t come for free, and it broke in ordinary ways:

• The first scheduled team run built nothing. The permission mode it ran under refused the paths in its own instructions. Every step failed politely, and nothing errored loudly, so the run looked like a quiet morning.
• Agents in a browser look like players. An audit run that clicked through the live app showed up as a burst of “new users” on our analytics page, and I briefly thought we were being hit by bots. Agent browser runs now mark themselves as team traffic.
• The whole team shares one account’s usage. On 1 November we had already used half the week’s allowance. Scout, Lens, the directors and Atlas all draw from the same pool, so one busy team can stop the other. The next post covers the gate we built for that.
• Approval-shaped work piled up. Even with the four rules, cards gathered faster than I cleared them. Some of that was right (a Go live card often waits because I have comments). Some of it was the team not trusting its own rules yet.

What I’d take from it

• Write down what the human decides, and make it short. Four kinds of decision. Everything outside the list gets decided and posted, not asked.
• Give every specialist a notes file a stranger can read. The bible is what makes a fresh agent useful on its first minute.
• Separate building from judging. Builders don’t approve their own work. Lens doesn’t fix its own complaints. Atlas doesn’t skip its own reviewer.
• Evidence over summaries. A screenshot opened by the reviewer, a test run, a fact checked against the “now” page.
• One place for decisions. If it’s waiting on me, it’s on the desk, and chat gets one line.

The next post is about the harder part: getting this team to move without me pushing it, and moving fast when I’m there.