{"id":"2090080031355617351","url":"https://x.com/Sprytixl/status/2090080031355617351","text":"https://x.com/i/article/2089716811688202240","author":{"name":"Sprytix","username":"Sprytixl","avatarUrl":"https://pbs.twimg.com/profile_images/2042845392757309440/Go9SGJcZ_200x200.jpg"},"createdAt":"Wed Aug 19 14:14:45 +0000 2026","engagement":{"replies":11,"retweets":17,"likes":89,"views":319972},"article":{"title":"Context Graph Engineering + Kimi K3 = 85% token savings and 6x better results. Here's the system.","previewText":"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.\nThe problem isn't","coverImageUrl":"https://pbs.twimg.com/media/HQAqalXX0AIOgzC.jpg","content":"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.\n\nThe 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.\n\nKimi 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.\n\nHere's how to build this system and why it changes everything.\n\nWhy the standard approach breaks\n\nA typical LLM workflow looks like this:\n\nYou 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.\n\nAnthropic documented this problem directly.\n\n> anthropic.com/engineering/effective-context-engineering-for-ai-agents\n\nAn agent accumulates dozens of types of information within a single session:\n\nYou 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:\n\nMost people answer none of these questions. They paste everything they have and hope for the best.\n\nContext Graph Engineering is the architecture that answers all six automatically.\n\nWhat a Context Graph actually is\n\nIn July 2026 a paper came out that defines this concept directly.\n\narxiv.org/abs/2607.07721\n\n![](https://pbs.twimg.com/media/HQB2UXxXEAI6pgw.jpg)\n\nThe authors propose Context Graph as a live relational data structure that knows not just facts but how they connect and when they were true.\n\nInstead 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.\n\nBut the most interesting part is proactivity.\n\nRegular AI:\n\nContext Graph Agent:\n\nThe 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.\n\nWhy similarity doesn't equal relationship\n\nMost 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.\n\nThe problem: similarity is not the same as relationship.\n\nMicrosoft GraphRAG documented this most clearly.\n\n> github.com/microsoft/graphrag \n\n> microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data\n\nImagine 100,000 corporate documents. The question:\n\nThe answer might require this chain:\n\nVector 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.\n\nGraphRAG builds the full structure:\n\nKimi 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.\n\nGraphiti: when the graph lives in real time\n\nMicrosoft GraphRAG works well for documents. But business isn't static. People change projects. Decisions get reversed. Facts become outdated.\n\nGraphiti solves this.\n\ngithub.com/getzep/graphiti\n\n![](https://pbs.twimg.com/media/HQB2kGpWYAAwa71.jpg)\n\nThe difference is critical:\n\nAn example of why this matters:\n\nA bad memory system leaves:\n\nThe agent doesn't understand what's currently true. It might assign Dan a task on Project A that was already cancelled.\n\nGraphiti uses a temporal model where each fact has a validity window:\n\nThis is real agent memory. Not just storing facts but understanding when each fact was true.\n\nAnd Graphiti already has an MCP server - meaning direct integration with Kimi Code:\n\nZero-Mem: memory without extra tokens\n\nMost memory architectures work like this:\n\nEvery step costs tokens and time.\n\narxiv.org/abs/2607.29377\n\n![](https://pbs.twimg.com/media/HQB2xaxXYAIjhkm.jpg)\n\nZero-Mem proposes a different architecture:\n\nThe LLM is called only for final QA. All memory operations are deterministic algorithms without neural networks.\n\nThe authors report 57.6% lower time cost for memory operations compared to the fastest baseline in their experimental setup.\n\nFor K3 this means a fundamental shift:\n\nOne million tokens doesn't mean you should fill them. It means K3 can process any subgraph you give it.\n\nTwo graphs: what the agent knows and what it does\n\nIt's important to distinguish two types of graphs that together give the complete system.\n\nKnowledge Graph - what the agent knows:\n\nExecution Graph - what the agent does next:\n\ngithub.com/langchain-ai/langgraph\n\nLangGraph provides infrastructure for stateful agents:\n\nTogether the architecture looks like this:\n\nOne graph manages actions. The other manages knowledge. Kimi K3 sits between them and makes decisions.\n\nLangMem: memory that learns by itself\n\n> github.com/langchain-ai/langmem\n\nLangMem gives agents the ability to learn from every interaction.\n\nTwo paths for storing memory:\n\nFor K3 this means:\n\nEvery interaction makes the system smarter. That's compounding.\n\nThe full architecture: K3 Context OS\n\nPut it all together:\n\nKimi K3 stops being a chatbot and becomes:\n\nWhat Skills add to this system\n\n> kimi.com/code/docs/en/kimi-code-cli/customization/skills.html\n\nIt's important to separate what lives in the graph versus what lives in Skills:\n\nA real example:\n\nK3 knows simultaneously what is happening and how to act correctly. Without repeating these instructions every session.\n\nHow Context Graph creates proactivity\n\nThe most powerful part of this architecture is a system that surfaces information on its own.\n\n > arxiv.org/abs/2607.07721\n\nThree components:\n\nA real scenario:\n\nMean time to surface: from 47 minutes down to under 30 seconds in the studied case studies.\n\nHow to build this in a week\n\nWhy this matters more than a bigger context window\n\nMost discussions about Kimi K3 focus on one thing: one million tokens of context. That's genuinely impressive.\n\nBut Context Graph Engineering says something different.\n\nDon'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.\n\nThe difference between these two approaches is the difference between a model that answers questions and a system that understands your business.\n\nMost 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. \n\n/ If this was useful - follow, the next one drops here first."},"adhxContext":{"savedByCount":1,"publicTags":[],"previewUrl":"https://adhx.com/Sprytixl/status/2090080031355617351"}}