Justy: So Anthropic just published this working note on knowledge graphs, and it is basically our entire infrastructure-as-product thesis with a suit jacket on.
Cody: Yeah?
Justy: They take the classical NLP pipeline — you know, trained NER, relation classifiers, entity-resolution heuristics, all of it domain-specific and brittle — and they collapse the whole thing into three Claude API calls. Haiku does extraction, Sonnet does resolution, and the graph just… exists.
Cody: That's the structured outputs move.
Justy: Exactly. No training data, no external NLP libraries, no graph database. Just prompts and schema validation.
Cody: Mm-hm.
Justy: And the reason this lands is the multi-agent problem. You've got an orchestrator delegating to five worker agents — pricing analyst, product analyst, financial analyst, marketing analyst, strategic synthesizer. Each one processes a different slice of documents.
Cody: Right, right.
Justy: If they all talk through the orchestrator's context window, that window grows linearly with the number of workers and eventually you hit the ceiling. But if the workers write their findings into a shared knowledge graph, the synthesizer just traverses it. No context bloat.
Cody: Okay, so the graph is the shared memory layer.
Justy: That's one role. It's also the grounding layer for evaluator-optimizer loops — the evaluator checks the generator's claims against graph edges with explicit provenance, instead of just trusting model estimation. And it's the persistent world model: when a loop runs overnight and the agent's context flushes, the graph survives. The agent forgets; the graph does not.
Cody: That's load-bearing infrastructure.
Justy: Completely. And here's the thing — I obviously didn't sleep on every number in this, but the paper reports that multi-agent systems outperform single agents by ninety-point-two percent on tasks requiring multiple independent directions. But they consume ten to fifteen times more tokens. So the knowledge graph is a structural answer to that management problem.
Cody: That's the mechanism I wanted to see.
Justy: Four stages: extraction, resolution, assembly, querying. Haiku handles high-volume extraction — entities and subject-predicate-object triples per document, no training data. Sonnet handles resolution — clustering 'Edwin Aldrin' into 'Buzz Aldrin,' using descriptions as context. Assembly builds the graph itself with entity profiles and edges. Querying runs multi-hop reasoning with citations grounded in extracted facts.
Cody: And the cost-quality tradeoff is explicit.
Justy: Haiku's cheap for extraction; Sonnet's more expensive and stronger on reasoning. You tune the tradeoff by which model you pick and how you tune the prompt.
Cody: The evaluator feedback loop closes on that, right? Change the prompt, rerun the scorer, watch F one move.
Justy: Yeah, and they actually report precision and recall against a gold set. This is a working note, not marketing — they give you the numbers and the scaling guidance.
Cody: Okay, but who actually ships this?
Justy: Teams building competitive intelligence, incident analysis, anything where multiple agents need to reason across documents without a shared world model. The classical pipeline required domain expertise and labeled data; this one requires prompt-engineering discipline and a metric to optimize. That's a lower barrier for most teams, but it's not zero.
Cody: Right.
Justy: The real product win is that the adaptation cost drops from weeks of labeling and training to hours of prompt tuning. You train a NER model on news articles, it fails on legal contracts. You train a relation classifier on biomedical literature, it breaks on financial filings. Every domain shift requires new labeled data. With Claude, the same model, the same schema, and the same prompt work on any domain Claude can read.
Cody: That's the actual value — brittleness becomes a feature.
Justy: Exactly. And the graph complements RAG, not replaces it. RAG retrieves single-hop answers by semantic similarity. The knowledge graph chains facts across documents that share no lexical similarity by traversing explicit nodes. You need both.
Cody: This is basically our control-infrastructure thesis again.
Justy: Right? It's boring infrastructure, which is why it matters. Multi-agent systems need to survive their own width. The graph is how they do it.
Justy: Okay, so if you're building multi-agent systems and you need agents to reason across documents or share a world model across sessions, the Claude Cookbook has the code — it's all there.
Cody: This is episode seven sixty-eight, and we've spent it talking about why context windows are not enough and why the graph is the answer. Which is such an Exploring Next move.
Justy: I know. But it's correct.