Your memory shouldn't wait for queries. Every agent memory system today does the same two things. It stores facts and it retrieves the right ones when you ask. That design assumes you already know what to ask for. You get back exactly what you queried, and nothing about what the stored data adds up to. Pattern recognition sits outside that loop. It means analyzing the stored facts as a structure and writing down what the structure shows, without waiting for a query to trigger it. Take a project management assistant reading engineering status updates over one week. Alice is blocked on the API migration, waiting on the auth service refactor. Bob is blocked on payments, waiting on that same refactor. Clara is blocked on checkout, which is waiting on Bob's payments work. Every claim gets stored correctly and retrieved correctly. Ask what is blocking the team and all six lines come back, accurately. None of them say that unblocking one task clears all three people. Clara never mentions the auth service, so she sits two hops away from the actual cause. Nobody was going to query for that, because nobody could name it yet. Closing the gap takes a pipeline running on top of retrieval rather than a better retriever, and the visual above lays out its four stages. → Raw episodes are the ingested material, the actual messages, JSON payloads, and documents. A knowledge graph gets built out of them, with entities as nodes and claims as labeled edges between them. → Signatures reduce each edge to its two entities plus the relationship type. Alice's update carries (API Migration, Auth Service), Bob's carries the same one, and that shared pair is the only thing that matters at this stage. → Clusters link episodes that share a signature. Alice and Clara have no entity in common, and they still land in the same cluster because Bob's update touches both sides and bridges them. → Observations are written per cluster by a single constrained LLM call. The model receives the entities and the supporting conversations, then names the pattern and summarizes it. Everything before that last step is plain graph topology, with no embeddings and no similarity scoring. That distinction carries weight, because embedding-based clustering would group all three updates simply for being about engineering work, along with every other update that week. This runs in the background as new data lands, so the pattern is already written by the time anyone thinks to look for it. The real shift is from retrieving what people said to analyzing what their combined data shows. Zep ships this as a feature called Observations, and the graph engine underneath is open source as Graphiti. Observations are read-only, since they are structural properties of the graph rather than notes anyone maintains, so contradicting evidence retires the old one and the pattern reforms around whatever is blocking work now. Check it out on GitHub: github.com/getzep/graphiti I wrote the full breakdown of how the clustering works. The article is quoted below. Stay tuned for more on this!