How to Build Your First Knowledge Graph With Claude Opus 5

Graph Engineering - Turn your notes, conversations, and project history into a persistent memory your AI agent can search, update, and reason over

Claude can read a million tokens in one request. That still does not mean it remembers your business.

Start a new session, and Claude may no longer know why you rejected a tool, which customer requested a feature, who approved a decision, or whether a fact is still current.

You can paste everything back into the conversation, but that becomes slow, expensive, and unreliable. The model has to reread your history before it can do useful work.

A knowledge graph solves a different problem.

Instead of storing information as disconnected text, it stores the things in your world and the relationships between them:

• Project A depends on Tool B

• Customer C requested Feature D

• Research report E supports Claim F

• Decision G replaced Decision H on July 22

• Agent I created Artifact J

This structure gives Claude something ordinary chat history cannot provide: persistent, searchable, time-aware memory.

In this guide, you will build a small working graph using Claude Opus 5, Graphiti, an open-source graph-memory framework, and a local graph database.

No graph theory degree required.

What you are actually building

The system has five parts:

1. Episodes: Your notes, conversations, documents, decisions, and project updates.

2. Extraction: Claude Opus 5 identifies entities, relationships, dates, and claims.

3. Storage: Graphiti saves the extracted information in a graph database.

4. Retrieval: The system pulls only the relevant part of the graph when you ask a question.

5. Reasoning: Claude examines those facts and produces an answer.

The flow looks like this:

Raw note → Opus 5 extraction → temporal graph → relevant subgraph → Opus 5 answer

A temporal graph records when a fact became valid and, when known, when it stopped being valid.

That matters because businesses change.

A normal database might overwrite “We use Notion” with “We use Obsidian.” A temporal graph can preserve both facts and show when the change happened.

Graphiti is designed for this type of time-aware agent memory. Its experimental MCP server can add episodes, search entities, retrieve facts, trace provenance, and connect the graph to AI clients. MCP, or Model Context Protocol, is a standard that lets an AI application connect to external tools and data. Graphiti’s documentation explains the available tools and setup.

Why use Claude Opus 5?

Claude Opus 5 was released on July 24, 2026. It supports a one-million-token context window, structured JSON outputs, prompt caching, batch processing, and five reasoning-effort levels from min to max.

Anthropic prices the model at $5 per million input tokens and $25 per million output tokens. Its API model ID is claude-opus-5. Anthropic’s Opus 5 documentation confirms the specifications and pricing.

The important feature for graph engineering is not merely the large context window.

It is the ability to separate two different jobs:

Job Frequency Recommended effort Extract entities and relationships High Low Resolve duplicates and ambiguous facts Medium Medium Answer difficult multi-hop questions Low High Investigate contradictions or major decisions Rare Max

Extraction is mostly structured pattern recognition. It does not need maximum reasoning on every call.

Querying the graph is different. A question such as “Which product decision changed after the customer interview, and which source supports the change?” may require several graph hops and careful judgment.

Use cheap thinking for repetitive work. Save expensive thinking for questions where intelligence matters.

Step 1: Choose one useful question

Do not begin by modelling your entire life or company.

Start with one question you regularly struggle to answer.

Examples:

• What are my active projects, and what is blocking each one?

• Which sources support the claims in my next article?

• What did this customer request, and what did we promise?

• Which tools have we tested, rejected, or adopted?

• What decisions changed during this project, and why?

• Which agent created each research result?

For this guide, our use case is:

Help me track Think AI research projects, the sources behind each claim, the tools being used, and the decisions that change over time.

If your graph cannot answer one useful question, adding more nodes will not rescue it.

Step 2: Define a small schema

A schema describes which types of things and relationships your graph should contain.

Use six entity types for the first version:

Entity: What it represents?

Project: A newsletter, product, campaign, or research task.

Person: A customer, collaborator, expert, or decision-maker.

Tool: Software, model, service, or framework. Source: An article, report, interview, document, or dataset.

Claim: A factual statement that should have evidence.

Decision: A choice, rejection, approval, or change of direction

Start with a short relationship list:

• USES

• DEPENDS_ON

• SUPPORTS

• CONTRADICTS

• REQUESTED_BY

• DECIDED_BY

• REPLACES

• CREATED_FROM

• BELONGS_TO

Every important fact should also carry basic metadata:

• source_id

• observed_at

• valid_from

• valid_to

• status

The source is essential. A graph is not automatically true because the information has been converted into nodes and lines.

Claude can extract an incorrect relationship. A document can contain an outdated statement. Two sources can disagree.

Store claims together with their evidence so you can inspect where an answer came from.

Step 3: Install the graph layer

The simplest starting point is Graphiti’s bundled FalkorDB setup. Neo4j is a better choice when you need a more mature production graph database, but FalkorDB keeps the first build lighter.

You need:

• Docker and Docker Compose

• Git

• An Anthropic API key

• An MCP-compatible client

• Python 3.10 or newer if you run Graphiti outside Docker

Clone Graphiti:

git clone https://github.com/getzep/graphiti.git
cd graphiti/mcp_server
cp .env.example .env

Open .env and add:

ANTHROPIC_API_KEY=your_key_here
SEMAPHORE_LIMIT=5
GRAPHITI_TELEMETRY_ENABLED=false

Never place the real API key in a public repository.

Graphiti processes multiple model calls during ingestion, including extraction, deduplication, and summarization. Starting with a concurrency limit of five is safer than launching a large backfill immediately. Graphiti’s documentation recommends roughly five to eight concurrent episodes for a standard Anthropic API tier.

Now edit config.yaml:

server:
  transport: "http"

llm:
  provider: "anthropic"
  model: "claude-opus-5"

embedder:
  provider: "sentence_transformers"
  model: "all-MiniLM-L6-v2"

database:
  provider: "falkordb"
  providers:
    falkordb:
      uri: "redis://localhost:6379"
      password: ""
      database: "think_ai"

Claude does not provide an embedding model. Graphiti still needs embeddings for semantic and hybrid search, so this configuration uses a small local Sentence Transformers model.

Start the server:

docker compose up

The MCP endpoint should become available at:

http://localhost:8000/mcp/

The health check is:

http://localhost:8000/health

Graphiti also supports Neo4j if you need a full graph interface or production deployment. Its current documentation recommends Neo4j 5.26 or newer and provides a Docker Compose configuration. The setup options are available in the Graphiti MCP README.

Step 4: Connect Claude to the graph

For an HTTP-capable MCP client, the connection has this basic shape:

{
  "mcpServers": {
    "graphiti-memory": {
      "transport": "http",
      "url": "http://localhost:8000/mcp/"
    }
  }
}

Restart the client after adding the server.

Ask Claude:

Check the status of the Graphiti memory server. List the graph tools you can access, but do not write anything yet.

You should see tools including:

• add_memory

• add_triplet

• search_nodes

• search_memory_facts

• get_episode_entities

• get_episodes

• delete_episode

• clear_graph

If Claude cannot see these tools, stop. Do not continue adding data until the MCP connection works.

Step 5: Add your first ten episodes

Do not dump your entire Google Drive into the graph.

Start with 10 to 15 short, real notes. Each note should describe one event, decision, resource, or project update.

For example:

On July 28, 2026, the Think AI newsletter project selected the title “How to Build Your First Knowledge Graph With Claude Opus 5.” The earlier “in 30 minutes” promise was removed because the complete technical setup may take longer for beginners. The article should remain practical, easy to follow, and focused on real implementation.

Give Claude this instruction:

Use add_memory to store the following as a text episode. Set the reference time to July 28, 2026. Preserve the source description. After ingestion, use get_episode_entities to show which entities and facts were created.

The reference_time is not optional if you want useful temporal memory.

Without dates, your graph knows that something happened but not when it was true.

Good first episodes include:

• One project description

• Two decisions

• Two research sources

• One person or customer request

• Two tool evaluations

• One project update

• One rejected approach

Ten focused episodes are more useful than 1,000 unreviewed documents.

Step 6: Test the graph before expanding it

Run four tests.

Test 1: Entity retrieval

Ask:

Search the graph for the Think AI knowledge graph project. Return the matching node and related tools.

Test 2: Fact retrieval

Ask:

Find facts explaining why “in 30 minutes” was removed from the title.

Test 3: Temporal retrieval

Ask:

What title was being considered before July 28, and what title replaced it?

Test 4: Provenance

Ask:

Which episode created the fact that the 30-minute promise was removed?

A graph is not successful because it looks attractive in a visualizer.

It is successful when it retrieves the correct fact, date, relationship, and source.

If the answer is wrong, inspect the episode and extracted edges before adding more data.

Step 7: Force retrieval before reasoning

Do not allow Claude to answer graph-memory questions from its general knowledge or conversation history.

Add a routing rule to your project instructions:

For questions about projects, decisions, people, tools, claims, or history:

1. Search the graph for relevant entities.
2. Retrieve the connected facts.
3. Apply date filters when the question is time-sensitive.
4. Reason only from the retrieved subgraph.
5. Cite the source episode or edge used.
6. If the graph does not contain enough evidence, say so clearly.
7. Never invent a missing relationship.

This is the difference between having a graph and actually using one.

The model should retrieve first, reason second.

The Opus 5 cost configuration that matters

Opus 5 normally costs $5 per million input tokens. Cached input costs $0.50 per million, and Batch API input costs $2.50 per million. Anthropic says batch and prompt-caching discounts can stack, although batch cache hits are best-effort rather than guaranteed. See Anthropic’s current pricing table and batch-processing guidance.

Thinking is on by default, and it bills at the output rate

Before you touch effort levels, understand where the money actually goes on Opus 5.

Opus 5 runs adaptive thinking by default. Those thinking tokens are billed at the output rate of $25 per million, not the cheaper input rate. On the same task at matched effort, developers are reporting roughly twice the output tokens of Opus 4.8. In practice, the effort level you choose moves your bill more than the model choice does.

This is exactly why the extract-cheap, answer-expensive split matters. Every ingestion call you run at high effort is spending output-rate thinking tokens you do not need. So the pattern is simple:

• Ingestion: low

• Normal graph queries: high (the API default for Opus 5)

• Rare investigations: max

The rule is not only about latency. It is about the $25 output meter running during every thinking pass, on every call, whether you asked for that depth or not.

Keep the extraction prompt stable

Place entity definitions, relationship rules, examples, and the output schema at the beginning.

Put changing content, such as the episode text and timestamp, at the end.

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=2000,
    system=[{
        "type": "text",
        "text": EXTRACTION_SYSTEM,
        "cache_control": {"type": "ephemeral"}
    }],
    messages=[{
        "role": "user",
        "content": (
            f"reference_time: {reference_time}\n"
            f"source_id: {source_id}\n\n"
            f"{episode_text}"
        )
    }],
    output_config={
        "effort": "low",
        "format": {
            "type": "json_schema",
            "schema": GRAPH_JSON_SCHEMA
        }
    }
)

The correct Opus 5 parameter is:

output_config={"effort": "low"}

It is not an extra_headers setting.

Structured outputs ensure the response matches your JSON schema. Anthropic documents the current output_config.format syntax here.

Check that caching is really activated

Opus 5 requires at least 512 cacheable prompt tokens.

A tiny extraction instruction will not qualify, even if you add cache_control.

Inspect these response fields:

• cache_creation_input_tokens

• cache_read_input_tokens

• input_tokens

If the two cache fields remain zero, you are not receiving a cache benefit.

The default cache lasts five minutes. Anthropic also offers a one-hour cache at a higher cache-write price. The prompt-caching documentation explains the thresholds and usage fields.

Do not change effort inside a cached conversation

Changing output_config.effort invalidates message-level prompt caches and may also invalidate system or tool caches.

Use separate workloads:

• Ingestion session: low

• Normal graph queries: high

• Difficult investigations: max

Anthropic explicitly recommends keeping effort constant inside conversations that depend on caching.

A realistic cost calculation

Assume you backfill 5,000 episodes.

Each episode contains:

• 600 tokens of reusable schema and instructions

• 800 tokens of changing text

A naive ingestion pass sends seven million input tokens:

5,000 × 1,400 tokens = 7,000,000 tokens
7 million × $5 = $35

With batch processing and an ideal cache-hit scenario:

Variable text:
4 million tokens × $2.50 = $10.00

Cached schema:
3 million tokens × $0.25 = $0.75

Idealized input total = $10.75

The $0.25 rate on the cached schema is not a mistake against the $0.50 cache-read price quoted earlier. It assumes the batch and cache discounts stack, so the Batch API halves the $0.50 cache-read rate down to $0.25. Anthropic allows this stacking, but batch cache hits are best-effort, so treat $0.75 as an ideal floor rather than a number you will hit on every run.

That is the best-case input estimate, not the complete Graphiti bill.

It excludes:

• Output tokens, including adaptive thinking tokens billed at the $25 rate

• Cache misses

• Initial cache writes

• Entity deduplication calls

• Summarization calls

• Embeddings

• Database infrastructure

• Failed or retried requests

Graphiti states that each episode can involve multiple model calls. Anyone promising that every episode requires only one extraction call is simplifying the real pipeline.

Also, do not claim that a temporal graph is automatically cheaper than a vector store. Graphiti itself can use embeddings, so the actual comparison depends on your models, database, corpus, cache-hit rate, and ingestion workflow.

When you should not build this

Do not build a knowledge graph because the diagram looks impressive.

Stay with Obsidian, Notion, or ordinary search if:

• You have fewer than 50 notes

• Your information rarely changes

• You do not need to trace sources

• You only need keyword or semantic search

• You will not maintain the graph

• Your questions do not depend on relationships

Build a graph when your work repeatedly depends on connections, history, provenance, and multi-step questions.

Five mistakes that will ruin the project

1. Treating extracted facts as truth

Store sources and review important claims.

2. Adding everything immediately

Begin with one project and 10 episodes.

3. Omitting timestamps

Without reference_time, you are building a static graph, not useful temporal memory.

4. Paying maximum-effort prices for extraction

Start with low effort and measure quality using your own notes. Remember that thinking tokens bill at the output rate, so high effort on routine extraction is money spent on reasoning you did not need.

5. Never test retrieval

Create five questions with known answers. Run them after every schema or model change.

The honest verdict

Claude Opus 5 is not necessary for every graph operation.

For a production system, you should test a cheaper model for routine extraction. Opus 5 is most valuable when the text is ambiguous, the graph contains conflicting evidence, or the answer requires careful multi-hop reasoning.

For your first build, using Opus 5 throughout reduces the number of moving parts. Once the graph works, optimize the repetitive ingestion layer.

The winning architecture is simple:

• Use low effort to extract.

• Keep the schema stable and cacheable.

• Batch historical data.

• Store timestamps and provenance.

• Retrieve the smallest relevant subgraph.

• Use high effort only when the question deserves it.

• Test every important answer against known facts.

A large context window gives Claude more information for one request.

A well-engineered knowledge graph gives it a memory it can return to tomorrow.

That is the real upgrade.

If you want more practical guides on AI agents, persistent memory, graph engineering, and real-world AI systems, subscribe to Think AI.