When 15 AI agents work at once, the most likely collision point isn't the model

Addy Osmani wrote on X: "Delegate the task, never the judgment." When Viv Trivedy reposted it, he added the five setup choices he is currently using; the theme is how to make an always-on, proactively working multi-agent system actually run.

The original is here: Viv Trivedy's tweet. Addy's article is here, and the quote tweet is here.

The replies are more worth reading than the main post, because everyone is filling in the same problem: agents can run in parallel, but judgment bandwidth is insufficient.

The five that Viv lists

Reduce the friction of understanding an agent's work and giving the agent feedback. Viv says many operations today are done from an iPhone. The entry point needs to be short; viewing results and giving feedback should not be roundabout.
Run agents in parallel with independent slices of work. Adam Wright says in a reply that he runs about 15 agents, each keeping only one task plus a very short never-list; otherwise they collide on the same batch of files and logins. He asks Viv how to slice things so that two agents do not share tools. This question is more practical than "multi-agent architecture."
Give agents self-management tools: communicating with the owners of other agents, self-verifying, and when necessary procuring limited additional infrastructure. The key word is limited.
Use swarms to scale compute, but the results are limited by whether the goal can be clearly specified and whether it can be self-verified. Viv says much of the magic and chaos in swarms comes from being able to scale toward a task with a clear scope, verifiability, and extreme difficulty, such as a Lean proof. A Lean proof can be understood as a mathematical proof that a machine can check step by step.
Context must be easy to fetch. Frontier models today are to a large extent limited by context and human judgment. When context is fragmented, it is harder for agents to do the right thing. Use centralized storage, such as GitHub, a centralized drive, or Slack, so that agents can fetch context no matter what device they start from.

The tougher details added in the replies

Franze M says that delegating code does not eliminate defining done. A useful ticket needs observable behavior, constraints, and a way to check the result. Agents make missing requirements surface faster.

Mister SnowCrash adds an artifact requirement for bug fixes: a new regression test should fail on the old code and pass after the fix. This prevents tests from simply agreeing with the implementation. He asks whether this should be enforced in the harness or left to review.

pasandida(:)aura suggests adding a small test for every workaround in claude.md to determine when it can be removed. Otherwise, after upgrading the model, you are still managing the mistakes made by the old model.

Aayan says he is more like a supervisor than a manager. Mahir Şentürk says choosing the IC track was to avoid becoming a manager; the agents did not get the memo. Ryan Wong says that in the past people operated on top of compilers and CPUs and assumed they would finish; when agents and harnesses are good enough, it is time to let go.

These discussions pull AI agent management back to engineering questions: work slicing, definition of done, verification artifacts, context storage, and feedback entry points. Ordinary users do not need to set up 15 agents. They can start with one thing: write the task clearly, write down the completion criteria, and leave behind the verification method. Developers should be careful: the more agents there are, the more conflicts there are, and the scarcer judgment becomes. The point of Addy's sentence is: do not outsource judgment too.