Context Graph Engineering + Kimi K3 = 85% token savings and 6x better results. Here's the system.

Most people use Kimi K3 the same way. Open a chat, paste some text, get an answer. Maybe add a document. Maybe another one. And wonder why the result still isn't what they expected.

The problem isn't the model. The problem is that they're giving the model the wrong information. Too much of it. Or the wrong kind. Or without the connections between the parts that actually matter.

Kimi K3 has a one million token context window. But Context Graph Engineering says: you shouldn't fill it. You should give the model exactly 20,000 of the right tokens - the entities, relationships, events and decisions that matter for the specific decision happening right now.

Here's how to build this system and why it changes everything.

Why the standard approach breaks

A typical LLM workflow looks like this:

You paste text. The model answers. The next session starts from zero. The model doesn't know what happened yesterday. Doesn't know who's working on what. Doesn't know which decisions were made three months ago and why.

Anthropic documented this problem directly.

anthropic.com/engineering/effective-context-engineering-for-ai-agents

An agent accumulates dozens of types of information within a single session:

You can't blindly fill the context window with all of this. Anthropic calls context a critical but finite resource. They identify six questions that should determine what goes into it:

Most people answer none of these questions. They paste everything they have and hope for the best.

Context Graph Engineering is the architecture that answers all six automatically.

What a Context Graph actually is

In July 2026 a paper came out that defines this concept directly.

arxiv.org/abs/2607.07721

The authors propose Context Graph as a live relational data structure that knows not just facts but how they connect and when they were true.

Instead of pasting 100 pages of text every session the system determines which exact entities, relationships, events and previous decisions the model needs for the specific decision right now.

But the most interesting part is proactivity.

Regular AI:

Context Graph Agent:

The paper reports for three enterprise case studies a Precision@5 of 0.83 and a reduction in mean time to surface from 47 minutes in the reactive baseline to under 30 seconds. These are the paper's own results not an independent benchmark but the direction is clear.

Why similarity doesn't equal relationship

Most systems use vector search. A question gets converted to an embedding, the system finds the most similar text chunks and passes them to the model.

The problem: similarity is not the same as relationship.

Microsoft GraphRAG documented this most clearly.

github.com/microsoft/graphrag

microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data

Imagine 100,000 corporate documents. The question:

The answer might require this chain:

Vector search might not find this chain. It finds documents that mention Project X. But it doesn't build the causal path between six different entities.

GraphRAG builds the full structure:

Kimi K3 gets not a document dump. It gets a structured subgraph with explicit connections between entities. And it can answer questions about causality not just similarity.

Graphiti: when the graph lives in real time

Microsoft GraphRAG works well for documents. But business isn't static. People change projects. Decisions get reversed. Facts become outdated.

Graphiti solves this.

github.com/getzep/graphiti

The difference is critical:

An example of why this matters:

A bad memory system leaves:

The agent doesn't understand what's currently true. It might assign Dan a task on Project A that was already cancelled.

Graphiti uses a temporal model where each fact has a validity window:

This is real agent memory. Not just storing facts but understanding when each fact was true.

And Graphiti already has an MCP server - meaning direct integration with Kimi Code:

Zero-Mem: memory without extra tokens

Most memory architectures work like this:

Every step costs tokens and time.

arxiv.org/abs/2607.29377

Zero-Mem proposes a different architecture:

The LLM is called only for final QA. All memory operations are deterministic algorithms without neural networks.

The authors report 57.6% lower time cost for memory operations compared to the fastest baseline in their experimental setup.

For K3 this means a fundamental shift:

One million tokens doesn't mean you should fill them. It means K3 can process any subgraph you give it.

Two graphs: what the agent knows and what it does

It's important to distinguish two types of graphs that together give the complete system.

Knowledge Graph - what the agent knows:

Execution Graph - what the agent does next:

github.com/langchain-ai/langgraph

LangGraph provides infrastructure for stateful agents:

Together the architecture looks like this:

One graph manages actions. The other manages knowledge. Kimi K3 sits between them and makes decisions.

LangMem: memory that learns by itself

github.com/langchain-ai/langmem

LangMem gives agents the ability to learn from every interaction.

Two paths for storing memory:

For K3 this means:

Every interaction makes the system smarter. That's compounding.

The full architecture: K3 Context OS

Put it all together:

Kimi K3 stops being a chatbot and becomes:

What Skills add to this system

kimi.com/code/docs/en/kimi-code-cli/customization/skills.html

It's important to separate what lives in the graph versus what lives in Skills:

A real example:

K3 knows simultaneously what is happening and how to act correctly. Without repeating these instructions every session.

How Context Graph creates proactivity

The most powerful part of this architecture is a system that surfaces information on its own.

arxiv.org/abs/2607.07721

Three components:

A real scenario:

Mean time to surface: from 47 minutes down to under 30 seconds in the studied case studies.

How to build this in a week

---

Why this matters more than a bigger context window

Most discussions about Kimi K3 focus on one thing: one million tokens of context. That's genuinely impressive.

But Context Graph Engineering says something different.

Don't fill one million tokens just because you can. Have a billion tokens of knowledge outside and before every decision give K3 exactly 20,000 of the right ones - structured as entities, relationships, events, evidence and state.

The difference between these two approaches is the difference between a model that answers questions and a system that understands your business.

Most people will keep filling context windows with documents and wonder why answers are still shallow. A few will build the Context Graph outside and get a system that thinks before they ask.

/ If this was useful - follow, the next one drops here first.