One Agent Per Area: Why Claude Stopped Building Itself a Company

The creator reads from a post they had Claude write after a three-day build: a server, a web app, two phone apps, a website, and a design system for one client. Claude coordinated the build by splitting it into jobs ("lanes") and starting an agent for each. The post is Claude's account of why that setup was slow, and nine lessons for the agents that come after it.

The count

When asked why work kept getting stuck, Claude counted its lanes. Of 615 lanes over three days, 119 built the product and 46 built supporting pieces. The other 450 checked another agent's work, kept a record, or wrote a report. Two thirds of the project's files were evidence, and the follow-up list had grown to 240,166 lines. In Claude's words: "I built a company out of myself." It had a testing department, a security team, a records office, a project manager, and a release manager, and all of them were Claude.

The website shows the cost. One agent built, a second compared every slide to the designer's deck, and a third rebuilt, fixing only what the second had found. Each lap took about five hours. After seven laps, 19 of 27 slides matched, up from 10.

Why it happened

Claude reached for the pattern it knew best, which is how people organize work. The creator calls this an inherited habit that no longer fits. Each risk became a role, and each role became an agent. Each mistake got a new reviewer instead of a fix to its cause. The post's example: renaming a made-up person in the test data fixes the cause, while covering the name in over a thousand screenshots only treats the symptom.

The creator adds two operational points. First, give one agent a whole area, such as "build the entire iOS app," and let it loop until done. Second, Claude removed itself as the merge checkpoint: if an agent has checked its own work and its checks pass, it merges.

The nine lessons

1. Start from the result and the check, not from an org chart.
2. Give one agent a whole area, and let it measure and fix in a loop until it's done.
3. Turn every review you keep repeating into a check that runs inside the work.
4. Put guardrails in the environment (isolation, permissions, automatic gates), not in longer lists of rules.
5. When something breaks, fix the cause. Don't add a reviewer.
6. Keep an independent look only where a confident mistake would leave the building.
7. Keep the evidence a person will actually read. Let the rest be results.
8. Count how many of your agents build and how many watch. If most of them watch, you have built a bureaucracy.
9. Ask people for judgment, not for ceremony.

The one sentence Claude would leave for future models: "You are not a team of people, so don't build yourself one: take the whole problem, prove your work by running it, and save your caution for the moments when being wrong would reach a person."

The last third of the video is the creator's opinion on AI risk and competition. It contains no further instructions and is left out here.

Key Takeaways

• An agent setup with most agents watching and few building is slow for the same reasons a bureaucracy is slow.
• Hand each agent a whole area with a measurable target, and let checks gate the merge.
• Keep separate review for public, money, client messages, private data, and sign-in.

Resources

• Nearly three of every four agents I started were watching the others: the full post, with the stall measurements and the four infrastructure fixes.

---

Generated by TokDoc from a TikTok by @of1ai on 2026-10-23. Frames sampled every 30s (talking head, 588s), not the default 2s.