~75% have barely used LLMs ~20% use them casually ~0.2% use frontier models professionally for math and code ~0.00006% have access to frontier systems internally
He writes:
"And finally we get to the ~5,000 people (~0.00006%) with access to frontier-grade systems internally. The external world has seen the preview. It looks like swarms of thousands of agents collaborating over weeks on software mega projects: minting zero days, running cyber attacks and defenses at machine speeds, discovering new science, advancing the frontier of mathematics."
Source: https://x.com/karpathy/status/2109361546505966046
Does anyone have an intuition, or even firsthand experience, of how these swarms of thousands of agents actually work?
I'm already struggling to get 2-3 agents to work together reliably. I can't really wrap my head around how you'd coordinate thousands of them, or what benefits you get from scaling to that many.
Here's what I've tried (and works) for solo/small team dev: - Structured Tasks: LLM's operate extremely well with structured data - try using JSON or YAML for handovers and watch performance level up (genuine Super-Mario mushroom vibes)
- DAG Structures: defining a structured task node <> edge relationship graph can be leveraged directly - great performance boost, particularly for CLI agents, since Claude Opus 4.5
- Task Decomposition: paired with the above, you can easily break down larger epics into smaller tasks - works extremely well for batching, separation of concerns & rapid task delivery
- Task Review Agents: take a decomposed epic, let the distributed work finish, hand the epic definition & completed work over for merge & review - fast, effective
- Agent Identity: this is where things get REALLY interesting (and the space is underdeveloped, building this for consumers @ flocker.md ) - start a chat session by telling the agent what their role is, what it's good at, and load ONLY context useful for the task it needs to do - smaller models suddenly become much more valuable (seriously, try it with GLM Flash 4.7)
- Delegation & Hierarchy: just like people, Agents need authority and delegation channels (with strict bounds) to stay on track - limiting task depth and automated controls seems like the best approach here - delegation feedback loops (effectively task delivery evals) are one of my next implementation tasks for flocker.md (ded)
I've built systems for solo/small teams (let's call them flocks of agents hah) - but thousands of agents would need some seriously well-defined orchestration patterns, and I have yet to see any systems well documented from the big players (probably for good reason).
My genuine guess is it's mostly an (un?)healthy degree of brute force & aggressive culling when isolated context spirals... Let's ask @karpathy: https://x.com/HCJMartin/status/2109963233587015715?s=20
wholeheartedly agree letting them go hog wild with messages is how they got off the rails (claw style)
my first and most important advice is to stay in the loop, I don't expect this to change any time soon
and of course do not humanize them
Most days I am capable of running 15-30 agents across 5 projects; if I had the budget it would scale. Pullboard is more of a methodology, and looking at the components alone does not reveal why it works. It's not just "orchestration" it's more like a coherence, outcomes and judgement over time.
Anecdote: I was trying to find or reproduce two slightly different customer bug reports, in parallel. We get a lot of logs from the customers, but it wasn't enough, so I asked AIs to add logging and create artificial loads on test machines, and do A/B tests on their behaviour before and after the changes.
Problem: I only had two (largish) test machines, and two AIs needing them. I told them to stop when they tried to simultaneously deploy conflicting tests. I copied and pasted their responses so they could coordinate. That worked, but rapidly became tiresome. I whinged about it to one of them and it said "oh there is no need for that, we can just communicate across a unix domain socket". When you do that the harness shows you their internal conversation.
My, there was a lot of it. To cooperate, they told each other the tests they wanted to perform and why, which led to them devising tests that investigated both sets of problems, which of course meant they commented on the other's tests, which rapidly led to an increasingly complex exchange about theories, how likely each was, and the optimal order for tests. There were so many theories and facts they gave each one a short handle so they could refer to them easily later.
I was watching this with fascination, but within 1/2 an hour the conversation consisted of "dd12 conflicts with ea34, so I propose md95: ...". No human could follow at the pace it was being generated. On the downside it was burning tokens at a fantastic rate, and a fair bit of what I could follow were clearly dead ends so those tokens were being wasted. I asked for clarifications, and tried to stop it where I could.
When I did that it got personal, because they started chatting about me. These are verbatim copy and pastes of that chat:
> One optional addition, only if it is cheap and does not delay the main arms. Explaining today's result to him, I had to concede a gap I had not noticed ...
(The other AI did find the time.)
> Heads up: he may contact you directly about the packet-processing side of XXXX. He is not across the detail and told me plainly that most of our exchange went over his head, so short and plain works far better than complete. Two things he found useful when I explained them: that the ZZZZ gets stuck in one socket-drain call because processing a packet triggers the next request so it never runs out, and that the proxied-AP walk is slow only on a small-cache machine, which is why our rigs cannot show it."
Evidently I was not in the centre of their newly created world.
This was a "swarm" of only 2. I shudder when I try to imagine what a swarm of 10,000 would get up to.
Here is what I have learned:
Direct inter-agent communication is tough to scale, tons of messages, agents drift and the cost grows with the square of the agent count. At large scale, agents should almost never talk directly to each other IMHO. Each one gets a small task (a discovery agent runs nmap on a discovered host), executes task, and writes the result to shared state. In my case that state is a knowledge graph and redis. The next agent reads the graph, that was enriched from the tool output HOST --OPEN PORTS-> 443, 80, 22.
Having a discovery agent that knows all about NMAP, understands how to get structured data back and save it, can look for work on the queue that needs a "discovery" agent, can also make a turn if NMAP isn't working.
Having a massive shared toolset that agents can pull from as well, and send to the LLM is key (in my platform, its something akin to everything you'd normally find in Kali linux).
This is where I got creative and have no clue if this is good advice or not, but I treated the SDK I built as a "World" using https://mlange-42.github.io/ark/concepts/. By default every agent emits everything it is doing via OTEL, and most everything is saved using a domain-specific (right now, think NIST, OWASP etc, but can adapt to any business domain) customizable taxonomy and ontology to a knowledge graph, so all the agents basically know what everyone is doing (or at least could query it), and are constantly emitting all it's actions.
After that, the coordination problem is ordinary distributed systems. You need a work queue, leases so two agents do not take the same task, retries, idempotent writes, and a budget for each task. Each agent also needs its own identity and permissions, I stole lots of patterns from kubernetes and just applied them to a fleet of agents via an SDK (has a claude code/opencode plugin, or you can use langchain/any other framework, or just build custom go ones).
In my case I love security, so I built it with bug bounty/devsecops, platform engineering in mind. The benefit of scale is breadth, not intelligence at least for security research IMO. You have thousands of endpoints and many hypotheses for each one, and most are dead ends. A thousand agents can each test one idea in parallel and report what they find (think 1000 agents using the AFL tool to test a binary), then once tested a second round of "deeper" agents that can look at all the produced data, analyze it, triage it etc etc.
The hard part is the output. A swarm produces findings much faster than a person can check them, and many are false. Most of my effort went into deduplication, evidence for each finding, and verification agents that try to reproduce a result (I use a deterministic bayes model in the "brain" to score things that as it learns about a network of systems can improve).
The platform is at https://github.com/zeroroot-ai if you want to read the code or standup K3d and play around with it, its all OSS. Docs: https://docs.zeroroot.ai/docs/
Feel free to email if you ahve any questions (email in my profile).
Each agent does one narrow job and hands off structured output, not prose. Prose handoffs are where the chaos lives: the next agent re-interprets instead of consuming. Every job is idempotent and replayable. A run that dies at step 40 just replays; nobody tries to "resume" a corrupted context. Every action lands in an append-only journal. When the fleet produces something weird, I replay who did what, in order. Without that, debugging 3 agents is already guesswork — with thousands it would be astrology. So my read on Karpathy's "thousands of agents over weeks": same discipline at scale — a pipeline of narrow roles, structured messages between stages, verification gates between them, and lots of replayable logs. A factory, not a chat room. The per-agent intelligence can be mundane; the contracts can't.