The agent team

The problem

By November I had ten projects, and every one had a growing list of things that could be better: bugs, design, search visibility, new features and upkeep. I could not keep track of it all, and I did not want to be the bottleneck for work that does not need my judgement.

I wanted to act as the product owner, the person who decides, while a team does the finding, the building and the testing and brings me only the decisions that are really mine, in plain language.

What I built

Nine agents, each with one job and a written purpose. A Researcher studies comparable products. A Polisher audits design, accessibility, speed and security. A Code reviewer checks the code, and an SEO Optimiser works only from real search data. A Product owner merges everything into one backlog. A Developer builds, a QA tester checks, a Personal assistant prepares my daily brief, and a Coach reviews how the others are performing.

They share a small set of plain files: a register of the projects, standing rules, a log of my decisions and one backlog per project. Every agent reads the rules and my past decisions first, so nothing I have rejected comes back without new evidence.

Scheduled tasks run the routine: a discovery run on Mondays, a daily run that prepares my brief each weekday morning, and a build check several times a day. They run only while my PC is on and Claude Code is open.

How AI was used

Roles with lanes

Each agent has a written purpose, an expected output and a lane, so two agents do not do the same job. The Polisher audits what a visitor would notice, the Code reviewer checks the code itself, and the SEO Optimiser uses real traffic data and stops with a one-line note when there is none.

Findings in, plain-English decisions out

The Product owner merges duplicate findings into one backlog and scores each item. Each decision is then written as a card: the problem, the suggested change, the alternatives, the cost and a suggested answer. A card asks one question, and Approve always means do the suggested change. Small routine changes are bundled, so I am not asked about every typo.

Build, then test, in small batches

The Developer builds only items I have accepted, up to five at a time, on a separate branch and with tests. A QA tester then checks every acceptance criterion, runs a regression pass and ends each report with a list of what it did not test. Neither can commit, publish, spend money or touch live data.

A coach for the team

A Coach agent compares what each agent does with what it is for, using a run log of the cost and output of every run. Its recommendations come to me as the same kind of decision card, and it may not repeat advice I have rejected.

A coordinating session

The main Claude session I talk to launches the agents, checks their tools before each run, records my decisions with a fixed set of statuses and relays anything an agent needs from me. Agents cannot ask questions mid-run, so they stop and write a clear section saying what they need.

What I think is clever

Decisions are the product. The team's output is not code but well-formed decisions: one question per card, a suggested answer, and a flag when a card revisits something I have already rejected.
Memory in plain files. Standing rules, a decisions log, a backlog for each project and a run log let every agent start fresh each time and still behave consistently.
Hard limits by design. Agents never commit, publish or spend without my explicit approval, and a commit is never treated as approval to go live. A separate list flags work that is built but not yet live.
Private data stays private. Agents working on the financial project may use only a made-up sample, never a real plan, and every project has a short profile of the files and commands agents must never touch.
Gates on its own appetite. A preflight check confirms the tools work before each run, discovery is skipped for a project that already has too many undecided items, and a build waits while earlier work is uncommitted.
Cost is measured, not guessed. Every run is logged with its tokens and minutes, so the Coach can show what each accepted idea cost.
It improves the site you are reading. The team built and tested changes to this site, including the copy checks that stop a stray dash, number or name reaching it.

What I learned

Wording a question is a design problem. Five of my first answers were ambiguous because ‘approve’ could mean ‘approve the suggestion to reject’. Making Approve always mean do the change fixed it.
Match the researcher's evidence to the job. Its first ideas for this site were rejected as a batch because the evidence was mostly career blogs. When it studied the competing products themselves, more of its ideas were accepted.
Overlap between agents is wasteful, but it caught a false all-clear. One agent said all text on a page was safely escaped, and the code reviewer found a place where it was not.
Use a small, strict vocabulary for decisions. One item was recorded as built when I had asked for it to be deleted, so the tester would have tested work that did not exist. A ‘closed’ status, and a rule that the coordinator never sets build or test statuses, fixed it.
Do not discover faster than a person can decide. The first cycle produced far more open items than I had decided, so a gate now skips new research on a project with a large undecided backlog.
Suggested answers need context. The assistant's suggestions matched my choice on fewer than half of the first questions, because some reversed earlier decisions. Every card now carries a flag for that.
What I would do differently: write each agent's purpose and success measures before its first run. The table of lanes that stopped the overlap was added after the pilot.

It is early. The first cycle ran on 4 November 2026, so the figures describe a pilot, not a track record. They come from the team's own run log and decision record.