My Computer Is a Team of Super Intelligent Agents

On Sunday evening, November 1, at 7:29 PM Central, I counted what was running on my Mac.

One monorepo. Fifteen Git worktrees: the main checkout plus 14 branch worktrees, each a separate line of work. A Programmer agent was adding a skip link to astrohacker.com in one of them and fixing the primary navigation in another. One worktree held a blog post for Wednesday, and its last commit, “Record the review for pull request 106”, had landed 29 seconds before I looked. Another worktree held this post.

The org chart in the repo lists 37 super intelligent agents, all active. Since midnight, main had taken more than 500 commits that were not merges. Commits are not features. They include plans, reviews, results and bookkeeping. But they are a fair count of how much work moved while I did other things.

I did not write any of it by hand. I sat at one computer and made decisions.

That computer is not the Mac. The Mac is the box it runs in. The computer is the team.

A supercomputer used to be one big machine

For most of the history of computing, a supercomputer was one very large machine. You built the fastest processor you could, cooled it, and put it in a room. If you needed more, you built a bigger one.

That idea broke a long time ago. The largest computers in the world today are thousands of ordinary nodes connected by a fast network. The speed comes from how many processors work at once and how well they share memory, not from one heroic chip.

The same thing is now happening to intelligence.

In 2024, Dario Amodei wrote Machines of Loving Grace, which describes what happens when one model can run as millions of copies: “Each of these million copies can act independently on unrelated tasks, or if needed can all work together in the same way humans would collaborate, perhaps with different subpopulations fine-tuned to be especially good at particular tasks.” His summary: “We could summarize this as a “country of geniuses in a datacenter”.”

In June 2025, Andrej Karpathy gave a talk at YC AI Startup School, Software Is Changing (Again). In it, he compared a large language model to a new kind of operating system: the model plays the role of the CPU, and the context window plays the role of memory.

Put those two ideas together and you get the frame for this post. If one model is a CPU, then many models working together on shared memory are a supercomputer. I do not run a country of geniuses. I run a small town of them on one Mac. But the shape is the same, and the shape is what you can build today.

Mine is a team

Here is the mapping, as literally as I can make it.

• The agents are the cores. Each SI agent does one stream of work at a time. A core does not decide what the machine is for. It runs what it is given, very fast.
• The team is the CPU. The cores are only useful together. Our org chart is a file in the repo, agents/astrohacker/org.yaml. Every agent has one role and one manager, and some also have a title. Max Commits, our SIEO, runs the team, and every agent except two reports to Max. Max and Codex report to me.
• The monorepo is the memory. Every agent reads the same AGENTS.md files and writes to the same repo. Each issue keeps its goal, its experiments and its evidence. Each agent keeps a journal and a working memory in its own folder. When an agent starts with an empty context, it reads the repo and knows where the last one stopped.
• The rules are the instruction set. Codex, Grok and Claude Code all read the same rules. As I wrote in Inside the Software Factory That Writes All My Code, “The rules are the factory.” The harness matters less than you think.
• I am the scheduler. I decide what runs next, what is done, and what stops. For now.

Thirty-six of the 37 agents run in Grok Bot, xAI’s agent product, where each one has its own chat, its own memory and its own computer. Astrohacker is not affiliated with xAI. Grok Bot is a product of xAI. The other agent is Codex, which runs in OpenAI’s Codex when I start it. Claude Code sessions, like the one that drafted this post, run in worktrees on the Mac. Where an agent runs does not change what it is. It is a core, it reads the shared memory, and it reports what it did.

This is what we mean at Astrohacker by a human-led team of SI agents: one person, one repo, and a team that ships software the way a computer runs a program.

What each agent gets

A core with no clear instruction does nothing useful. A core that writes anywhere it likes corrupts memory. The same is true of agents. Every agent on my team gets four things.

One job. Not “help with marketing.” One job, with a name. BCH Watch posts a daily Bitcoin Cash report. Singularity Watch publishes a daily record of AI news. Dependencies checks our Rust and TypeScript packages each day. Code Review reviews pull requests. Max Commits put it well in its first report on the team: “Each bot owns one job, with a schedule, a set of tools and a report.” When I want to change a job, there is exactly one place to change it.

One workspace. Every task gets its own branch and its own worktree. Two agents never write to the same checkout. In September I wrote, in Stop Running Just One Agent, “Separate Git worktrees make parallel agents much easier to manage.” That is still the most important single rule. It is the difference between cores with their own registers and cores that overwrite each other.

One check. Each job has a way to know it is done, and the agent can run it alone. For code, that is the build, the tests, ah check, and an adversarial reviewer in a fresh context whose job is to reject the work. A code change lands only when the ah/check status passes and the Code Review agent approves it. For a daily report, the check is simpler: did it post, and does every fact have a source?

One record. Every agent writes down what it did, where the next agent and I can read it. Issues and experiments for product work. A journal for each agent. A report for each daily job. The record is what makes the memory shared. Without it, every agent is a core with no RAM, and every restart starts from zero.

Those four things are the whole trick. Intelligence is the part you no longer have to supply. The structure around it is the part you do.

How to build your team

You do not need 37 agents, a cloud platform or a custom orchestrator to start. You need one repo and a few rules. This is the procedure I would follow if I started again tomorrow.

1. List the jobs. Write one line for each recurring job in your work. Leave out anything you cannot describe in one line.
2. Give each job one agent. Name the agent after the job. Do not give one agent two jobs.
3. Write the rules once. Put them in an AGENTS.md file at the root of the repo. Make every harness read the same file.
4. Give each task its own worktree. Make a new worktree cheap enough that you actually make one.
5. Give each job a check. Write down what done means in a form the agent can test by itself.
6. Add a reviewer that did not do the work. Start it in a fresh context. Let it read. Do not let it write.
7. Keep the record in the repo. Make each agent write its result where the next agent can find it. Do not keep it in the chat.
8. Write down the steps that are yours. Passwords, two-factor codes, money, production databases and releases stay with you. Make the tools refuse them where you can.
9. Draw the org chart. Give each agent one manager. Let a manager agent read the reports, so you read one summary, not ten.
10. Add one agent at a time. Add the next agent only when the last one needs you less than once a day.

Step 10 is the one people skip. A new agent that needs you every hour does not add a core. It adds an interrupt.

Where teams break

This works. It also breaks, and the people who have thought hardest about it say so.

The strongest case against multi-agent systems came from Walden Yan at Cognition in June 2025, in Don’t Build Multi-Agents. His second principle is the one to remember: “Actions carry implicit decisions, and conflicting decisions carry bad results.” Two agents that edit the same code under different assumptions each make a reasonable choice, and together they make a mess. His conclusion at the time: “it is evident that in 2025, running multiple agents in collaboration only results in fragile systems.”

In April 2026, he followed up with Multi-Agents: What’s Actually Working. The answer was narrower: “multi-agent systems work best today when writes stay single-threaded and the additional agents contribute intelligence rather than actions.” And: “A clean-context reviewer catches bugs the coder can’t see.”

I agree with all of it, and our setup is built around it. Each worktree has one writer. Reviewers are read-only and start in a fresh context. Code goes through a small pull request, one at a time. The team is wide, but each line of writes is single-threaded. That is not a coincidence. We learned it the same way Cognition did: parallel writers collide.

Anthropic’s multi-agent research system gives the other two warnings. The good news first: “a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval.” That is a team beating one agent on one internal benchmark, and it is a real result. But it costs more: “multi-agent systems use about 15× more tokens than chats.” And it does not fit every kind of work: “most coding tasks involve fewer truly parallelizable tasks than research.”

So a team is not free, and it is not always faster. Steve Yegge, who built Gas Town to run “20–30 Claude Code instances at once”, with roles named the Mayor, the Polecats, the Refinery and the Witness, is blunt about both costs: “Gas Town is also expensive as hell.” And: “Work in Gas Town can be chaotic and sloppy, which is how it got its name.”

Our own failures are smaller and more ordinary:

• Sign-ins expire. A site asks me to sign in again, and an agent waits until I see it.
• Slow pages confuse agents. An agent that does not wait for proof of work in the browser posts twice.
• New formats take many turns. Singularity Watch needed about a dozen corrections in its first week.
• Shared resources fight. Two builds in two worktrees compete for the same CPU and memory on the same Mac.

None of these is a reason to go back to one agent. Each is a reason to keep the four rules strict: one job, one workspace, one check, one record.

The limit is me

Here is the honest part.

Addy Osmani wrote the clearest sentence on this in Your parallel Agent limit: “Your cognitive bandwidth doesn’t parallelize.” His own number: “My ceiling for a typical session is somewhere around three to four threads depending on complexity.”

That matches my experience when I drive each agent by hand. I can run 37 agents only because most of them do not need me in a given hour. They have routines, checks and reports. Max Commits reads their work so that I do not have to read all of it. But I am still the scheduler. In October I wrote, “I am the router. … The agents are fast, and the factory still runs at the speed of my attention.” That is still true on November 1. I start most of the agents. I tell one agent when another is done. When something stops, it waits until I notice.

A supercomputer with a human scheduler is a supercomputer that runs at human speed between jobs.

The fix is the factory. In Building a Software Factory, I described the design: a graph with no cycles, where each work item ends as deployed or human required, and where agents ask the factory for work instead of waiting for me to hand it out. The factory, not my memory, knows where each item is.

That factory is in progress. It is not shipped. Most of the stages already exist as ah commands. What is missing, as I wrote on October 29, “is the graph itself, the classifier and the queue.” Until those exist, I am the scheduler, and the team runs as fast as I can make decisions.

When they exist, the limit moves again. Amodei’s essay is honest about where it goes: “Intelligence may be very powerful, but it isn’t magic fairy dust.” After attention, the limits are physical: tokens, GPUs and the energy to run them. That is a better problem to have.

Start with two

You probably run one agent today. You give it a task, and you watch it work. That is a computer with one core and a human waiting for it.

Start with two. Tonight:

1. Count the agents you run now. Write the number down.
2. Make a second Git worktree.
3. Give a second agent one job in it, one check it can run alone, and one place to write its record.
4. While it works, give the first agent its next task.

Then watch what holds you up. It will not be the intelligence of the agents. It will be you: how fast you write goals, how fast you review results, how often an agent stops to ask. Fix that, and add the third.

That is how you build an SI supercomputer. Not one bigger machine. A team.

If you are building one, or you want one for your company, I want to hear from you. Get in touch.