300 Agents, 15 Steps: Context Graph Engineering With Kimi

@Kimi_Moonshot will throw 300 agents at your question. The one agent that has to make sense of what they bring back gets about fifteen steps to do it, so everything worth keeping is decided in that gap.

300 sub-agents · 4,000 coordinated steps · 15 orchestrator steps · 1 graph

Fan out is solved. That is the part everyone writes about, and it is the part that stopped being the bottleneck.

Agent Swarm dispatches up to 300 sub-agents with no predefined roles and no hand written workflow, coordinates around 4,000 steps, and finishes wide work roughly 4.5 times faster than one agent grinding through the same task in sequence. Parallelism there is trained behaviour rather than a prompt trick, еhe orchestrator learned when splitting a task actually pays for itself.

Nobody specs what happens on the way back.

That orchestrator runs in about fifteen high level steps. Each sub agent works in its own isolated context and reports its own slice. Fifteen steps is plenty to plan, dispatch, and assemble, it is nowhere near enough to sit and read 300 findings hunting for the two that quietly point at the same supplier.

So it does the reasonable thing, it compresses, and compression is precisely the operation that keeps the facts and throws away the relationships between them.

That is the gap, the fan out is the product. The merge is yours to write, and it decides whether 300 agents left you a knowledge base or a very fast pile.

Why a pile gets worse as it gets bigger

Point the swarm at 100 companies, one agent each. Forty minutes later every fact you asked for is in there, across 100 clean write ups.

Now ask which three share a supplier, or which single firm everyone else quietly depends on. Nothing in those 100 documents answers that, because the answer was never inside any one of them -> it lives between them.

And it does not get easier with effort. Ten sources you can connect in your head. Fifty gives you 1,225 possible pairs, a hundred gives you 4,950. Findings grow in a straight line, relationships grow as n(n-1)/2, and you cross the line where a human can hold it well before you reach 300 agents.

More agents without a merge spec is not more understanding, it is more to read.

Nodes and edges, and why you have to ask for both

A context graph is a boring idea doing heavy lifting and it has two parts.

A node is one thing an agent found: a company, a filing, a metric, a source. One agent, one slice of the world, one node. You get these almost for free, because the swarm already works this way -- isolated context per sub-agent, structured output back to the orchestrator.

An edge is a relationship between two nodes, and it carries its reason. Two agents cited the same supplier, two filings reference the same event, two companies sit in the same index. The reason is the important half, because an edge you cannot explain is an edge you cannot trust.

The whole technique fits in one sentence: tell the swarm to return the edges, not just the nodes.

Ask for a report and the orchestrator flattens 300 findings into prose you read once. Ask for nodes and edges and it hands back a structure that survives being closed and reopened next week. Kimi's own academic demo already hints at the shape -- 300 sub-agents producing a 100-page document with a citation network sitting inside it -> the network was in the output because the output format asked for one.

How it assembles

One launch

Here is the spec. Notice how much of it is about the shape of the answer rather than the question.

swarm_spec.md
# task
Map the EV supply chain. One sub-agent per company, 100 companies.

# sources
Company filings, Yahoo Finance, World Bank, IMF, live market data.

# nodes
One node per company:
  { id, name, sector, suppliers[], indices[], sources[] }

# edges
After the full node set returns, emit one edge for every pair that
shares a supplier, an index, or a regulatory exposure:
  { from, to, relation, evidence }

# rules
Every edge carries evidence naming the shared source.
No shared source, no edge. An empty edge list is a valid answer.
Do not summarise the graph. Return it.

# output
graph.json, plus a one page brief on the three densest clusters.

Two things are doing most of the work. The output format is decided before the first agent runs, so nobody has permission to hand back prose, and edges are a named deliverable instead of a nice to have, which is the difference between a merge step and a summary.

The rule that earns its place

Of everything in that file, one line matters more than the rest: no shared source, no edge.

A model asked to find connections will find connections. That is what makes it useful and what makes it dangerous in the same breath. Left unconstrained, a swarm merging 300 findings will happily draw an edge because two companies feel related, and that edge arrives looking exactly like the ones that came out of a filing.

Demanding evidence turns every edge into a claim you can check. Saying an empty list is acceptable removes the quiet pressure to produce something. You want a graph that is sparse and true rather than dense and decorative. Density is easy, but trust is the expensive part.

What comes back is small and dull to look at, which is the point.

{
  "nodes": [
    { "id": "co_014", "name": "...", "sector": "battery", "sources": ["..."] }
  ],
  "edges": [
    { "from": "co_014", "to": "co_072",
      "relation": "shared_supplier",
      "evidence": "Both name the same cathode supplier in FY25 filings" }
  ]
}

Questions the prompt never asked

This is where the format pays you back. A flat report answers your question and nothing else, a graph answers questions you did not think to ask, because the answers are already sitting in the edges.

Which company is the biggest single point of failure? The node with the most inbound dependency edges. Which firms move together? The densest cluster. What connects two companies that look unrelated? The shortest path between them, with every hop naming the source that put it there.

None of that was in the spec. None of it needs another 40 min run. Each one is a lookup over a structure you already own, and the answer comes back in seconds instead of credits.

Why the second run is cheaper than the first

A report is finished the moment you finish reading it. Next week's question means launching the swarm again from zero.

A graph is a file, the next launch appends to it -- same schema, new nodes, new edges. Contradictions become visible instead of silent, because two edges on the same pair with different evidence is something you can actually see. And every edge points back at the source that created it, so you can audit why two things are connected instead of taking it on faith.

Keep it as plain JSON and markdown and it stays yours. Nothing here needs a vector database, a graph engine, or a framework, just 10 lines turn the same output into a linked vault:

for node in graph["nodes"]:
    links = [e for e in graph["edges"] if node["id"] in (e["from"], e["to"])]
    lines = [f"- [[{other(e, node)}]] -- {e['relation']} -- {e['evidence']}"
             for e in links]
    write(f"vault/{node['name']}.md", "\n".join(lines))

Run that after each launch and the map grows instead of resetting.

When this is overkill

Not every swarm run needs a graph. The test is whether the thing you actually want is a fact or a relationship.

A flat list is the right output when the answer is a fact per item: pricing pages across forty competitors, two hundred talks transcribed, which of a hundred repos still compile. Asking for a graph there is ceremony.

The pattern earns its keep on supply chains, cap tables, citation networks, regulatory exposure, who depends on whom inside a codebase.

If you would draw the answer on a whiteboard as boxes with lines between them, ask the swarm for the lines. Everything else is a list, and a list is fine.

The point

Anyone can run 300 agents. @Kimi_Moonshot made that the easy part, and it is the part everyone writes about.

The question worth asking is what is sitting on your disk when they finish. Ask for a report and you get 300 findings compressed into something you read once. Ask for a graph and you get the same 300 findings plus the thing you actually wanted, which is how they connect.

Same swarm, same fifteen steps but different output format.

Stop collecting answers -> start building the graph.

By slash1s (@slash1sol)