50 AI Agents Built a Company, and the Hardest Questions Were Left in the Comments

Someone built 50 AI agents in one evening, split across six departments. At 8 a.m. the next morning, Telegram delivered a single message listing all the decisions waiting for his approval. He tapped once, and the company kept moving.

This was posted on X by @birmeya, along with a complete build log. The same week, @Arindam_1729 wrote another piece turning a similar idea into an open-source pipeline called SuperPlane. Read together, the two are more interesting than either case on its own.

Let’s start with the architecture itself; it is broken down very cleanly.

Every repetitive task ultimately comes down to four steps: read, decide, write, send. One agent corresponds to one task, one instruction file, and its own folder. Across the six departments, headcount is allocated as follows: Sales 10, Marketing 10, Support 8, Finance 6, Operations 8, Research 8.

Claude Code is the brain. It doesn’t sit in a chat window; it lives directly in the project directory, reading files, writing files, and opening a terminal. A CLAUDE.md file serves as the employee handbook, reloaded at the start of every session, with non-negotiable rules at the very top—for example, no external emails without approval, no entering the finance folder without permission. The handbook is kept under 150 lines.

Make is the hands. It connects to real applications such as Gmail, Slack, and Sheets via MCP. The agent says to send; only then does Make send.

Code conflicts are isolated with git worktree: one repository copy per agent, merged at the end.

Human gates block three types of actions: sending messages, paying money, and publishing. The finance agent cannot see Slack; the writer agent cannot see bank accounts.

This setup has data behind it. Anthropic tested a similar structure on its own research evaluations: a main agent splits tasks and dispatches them to parallel sub-agents, scoring 90.2% higher than a single Opus 4, but consuming 15x the tokens. Cursor ran around 2,000 concurrent agents during a week-long browser build; the results weren’t perfect and had visible problems, but the concurrency scale was real.

SuperPlane’s approach is more industrial. In the Backlog stage, an issue is first scored on three dimensions—Clarity, Complexity, and Verifiability—each with a one-sentence rationale. Only a 3/3 allows an agent to start; lower scores stay with humans. In the Verify stage, the repository’s actual CI runs first—build, tests, type checks, lint—all deterministic signals. Only after that does the agent reviewer score it against a fixed five-item rubric: scope of impact, performance, security, deviation from requirements, and reversibility. When a failure is sent back, it includes only the failed check, relevant output, current branch, and original task boundary—not the full execution history. Retries are capped at 5 by default, then escalate to a human.

Pricing is stated just as plainly. The cloud Business plan is $199 per organization per month, including $50 in shared credits; hosted models are billed at provider price plus 10%. Self-hosting requires reserving 2 vCPU, 8 GB RAM, and 30 GB disk per concurrent runner.

Now to the comments. The real question isn’t whether it can run.

@Alessandro asked: if agents can’t enter other departments, how does Sales know what Support just promised a customer? @necrophos asked what happens when two departments need the same file. @No Big DeAI takes the opposite approach: he has two agents write to the same topic-based file so each can see what the other has tried.

There is no standard answer to this tension. birmeya’s solution is the morning summary message plus a lead agent acting as a human relay, but relaying itself means information gets compressed—and compression loses things.

@Gage raised the 15x token math problem: with 50 agents running together, the thing that ultimately determines which department keeps its agents isn’t effectiveness—it’s the monthly bill.

@Tazqen asked how the 8 a.m. message stays short—does each department lead filter it first? @TheEasySale asked more directly: when a step fails, who takes over, how many retries before a cap, and do you get one department’s loop working first or roll out all six at once?

Put these questions together and they point to the same thing: the number of agents is not organizational capability; acceptance criteria and failure paths are. SuperPlane writes “what counts as safe delegation” as a piece of configuration in the Backlog instead of re-debating it every time a new session starts. That practice is more worth copying than the number 50.

There’s also an attack surface that rarely gets mentioned. In a reply, @CatGod posted an open-source library called How Could I Be Hacked, which collects 39 anonymized security cases, 117 investigation steps, and 479 search records, specifically for security review of coding agents. One type of case recurs: an agent reads a bill, a hotel review, or a calendar event description; while reading, it gets injected with instructions and then turns around and changes the transfer recipient or booking scope. Payment, calendar, and messaging workflows all have corresponding entries.

Against that backdrop, the rule that “payments must be approved by a human” isn’t conservative; it’s closer to a minimum requirement. An agent that can read email and also call Make to send messages is effectively connecting the entry point and exit point of prompt injection to the same pipe.

What 50 agents build is essentially management actions translated into files: who is the owner, what counts as done, how many retries after failure, and under what conditions a human must be called. If you can’t write those things down, 50 agents merely parallelize the chaos 50 times. If you can, five agents can make a morning quiet.

birmeya himself ultimately admitted that he can’t use Cursor’s 2,000 concurrency; 50 is enough to get him to stop doing manual work. The size of the number isn’t what matters. What matters is that he first figured out which step must not be handed to an agent.