Inside Anthropic’s New Graph Engineering Methodology for Multi‑Agent Systems

1. Why Context Windows Are Insufficient

A concrete competitor‑intelligence example shows five workers (pricing, product, finance, marketing, strategy) each lacking the full fact chain; relying on orchestrator context would cause the window to grow linearly and eventually explode. Storing discovered entities and relations in a shared knowledge graph lets the strategy agent traverse the graph without any intermediate context.

2. Four‑Stage Claude API Pipeline

Traditional KG pipelines require training NER models, relation classifiers, and hand‑written coreference rules for each domain. Anthropic collapses the entire pipeline into a series of structured Claude calls where the "training data" is a Pydantic schema.

Stage choices:

Extraction – uses Haiku for high‑throughput, schema‑constrained extraction.

Resolution – uses Sonnet to balance evidence and prioritize reasoning quality.

Summarization – also uses Sonnet for cross‑document synthesis.

Query – Sonnet serializes triples for multi‑hop reasoning.

3. Extraction: Schema as Contract

The API call client.messages.parse(output_format=ExtractedGraph) returns a strongly‑typed object or raises an error, eliminating regex, JSON parsing errors, and defensive checks. Robustness of the pipeline hinges on this interface.

Four extraction prompt rules:

"Extract only entities important to the document" – controls recall and reduces noise.

"Write a one‑sentence description for each entity" – provides disambiguation signals (e.g., distinguishing "Armstrong – the first moon‑walker" from "Armstrong – the jazz trumpeter").

"Use short verb phrases for predicates" – avoids vague predicates like "was involved with" that hinder reasoning.

"Every relation must connect two extracted entities" – prevents dangling edges.

4. Entity Resolution: Beyond String Similarity

Surface forms such as "NASA" vs. "National Aeronautics and Space Administration" or "Neil Armstrong" vs. "Neil Alden Armstrong" are merged, but cases like "Edwin Aldrin" vs. "Buzz Aldrin" (zero character overlap) require clustering by type and using the extraction‑stage description as disambiguation context.

Results: 24 surface forms compressed to 22 canonical entities. Two failure modes were observed:

Missed matches – names that fall into no cluster disappear from the graph; production systems should fallback to a singleton cluster.

Over‑merging – e.g., "Gemini 12" merged into "Project Gemini", losing precision.

The paper stresses that the disambiguation power comes entirely from the description written during extraction.

5. Assembly and Summarization

After alias cleaning, relationships are stored in a NetworkX MultiDiGraph (multiple edges allowed, direction matters). Each edge carries a predicate and provenance.

Graph health metrics for the Apollo example:

22 nodes, 34 edges, edge/node ratio 1.55 (within healthy range)

1 connected component (single component indicates successful resolution; fragments signal missed merges)

Hub nodes: "Apollo program" and "Apollo 11" (degree 9 each)

Summarization runs Sonnet on high‑degree nodes (degree ≥ 3), feeding all mentions and graph neighborhoods to generate 2–3 paragraphs of profile, 3–5 traceable key facts, and a time span (e.g., Apollo program: 1960‑1973). No single document contains all this information.

6. Multi‑Hop Querying

Querying extracts a k‑hop neighborhood around seed entities, serializes each triple as (source) --[predicate]--> (target), and feeds them to Claude for reasoning. k = 2 works for most multi‑hop questions; larger k risks context overflow.

Grounded vs. non‑grounded answers:

Without the graph, Claude can produce plausible answers based on pre‑training (e.g., Armstrong’s birthplace). With the graph, answers are constrained to extracted edges, providing provenance, explicit missing facts, and verifiable statements.

7. Graph Role in Five Agent Modes

Anthropic defines five modes where the graph integrates differently:

Augmented LLM : Graph serves as a retrieval source for multi‑hop reasoning.

Prompt chaining : Graph provides gating signals to detect entity conflicts between steps.

Routing : Entity types and degrees from the graph feed a classifier that routes to the appropriate expert, saving an LLM call.

Orchestrator‑workers : Workers read/write the shared graph, keeping the orchestrator’s context clean.

Evaluator‑optimizer : The evaluator checks claims against the provenance‑rich graph, turning it into a fact‑checking layer.

Shared‑memory pitfalls include accidental overwrites; the solution mirrors prior work: typed schemas, explicit write permissions, and checkpointing.

8. Evaluation: Cost of Perfect Precision

Extraction precision reaches 1.00 (Haiku is conservative), but recall suffers (missed "Purdue University" mentions and cross‑document scope mismatches). The trade‑off is intentional to avoid false positives.

9. Scaling and Dual‑Model Economics

Model choices per stage:

Extraction – Haiku (high volume, schema‑constrained, cost‑driven).

Resolution – Sonnet (conflict reasoning, quality‑driven).

Summarization – Sonnet (cross‑document nuance).

Query – Sonnet (triple‑serialization for multi‑hop inference).

Cost breakdown: extraction scales linearly with token count (e.g., 10 k docs × 2 k tokens costs a few dollars); resolution batches by type; summarization runs only on high‑degree nodes; query cost depends on subgraph size. Storage is cheap with NetworkX up to hundreds of thousands of edges; larger graphs can migrate to Neo4j, Neptune, or three PostgreSQL tables with recursive CTEs without code changes.

10. When Not to Use a Knowledge Graph

Decision matrix (excerpt):

Single‑document QA → use RAG or direct context.

Multi‑document, single‑hop → RAG + reranking.

Multi‑document, multi‑hop → knowledge graph (requires entity‑level links).

Multi‑agent shared state → knowledge graph (provides persistent world model).

Evaluator needs ground truth → knowledge graph (provides provenance).

Overnight loops / persistent memory → knowledge graph (graph persists across sessions).

Simple classification/routing → single agent suffices.

Rule of thumb: employ a graph when agents must link facts across sources, share structured state, or base decisions on traceable evidence; otherwise, simpler retrieval or classification tools are sufficient.