getzep

Graphiti 0.31.2 makes its servers bind to localhost by default. A quiet but important security improvement for agent-memory infrastructure: local development services should not become network-accessible by accident. github.com/getzep/graphiti/releases/tag/v0.31.2

Zep + Graphiti (32K stars) Temporal knowledge graph. When a fact changes, the old edge gets marked invalid, not deleted, so it can tell you what was true in March. Best one here for fact history. Reading it means running Neo4j and writing queries. getzep/graphiti

Multi-agent work in three spoonfuls (part IV): from a terminal trident to an autopoietic loop --- title: "Multi-agent work in three spoonfuls (part IV): from a terminal trident to an autopoietic loop" published: true description: "Fourth entry in the penta-agent multi-agent series: quota-governed routing, 70 ms hybrid memory, MCP tools, and a zero-token local autopoiesis loop in Harness2." tags: "ai, agents, cli, automation" canonical_url: "3cucharadas.cl" cover_image: "3cucharadas.cl" ai_disclosure_level: "some_ai" --- After benchmarking the models in part I, auditing retrieval in part II, and tracing provenance in part III of this series, I closed my laptop with a sense of victory: I had a trident of agents running from the terminal on Arch Linux. With a couple of zsh aliases, I could invoke Claude Code for architectural reasoning, hand off a task to Codex CLI to edit code, or ask Gemini CLI and Antigravity for a quick second opinion. On paper, orchestration looked solved. Yet after using that setup every day on real projects inside penta-agent, I hit a silent wall: having three agents talking does not equal having a system that learns. Every time I opened a fresh session, the trident suffered from partial amnesia, repeated commands that had already failed the previous week, burned the quota of the most expensive provider on routine tasks, or marked tests as "verified" when they had never had a chance to fail. To understand what was missing, it helped to change the question. In a recent systems-theory analysis of artificial intelligence, Benedikt Zönnchen, Mariya Dzhimova, and Gudrun Socher (2025[^zonnchen2025], 2–4) propose setting aside whether a language model "thinks like a human" and asking instead the question posed by Humberto Maturana and Francisco Varela (1987[^maturana1987] [1984]) and extended by Niklas Luhmann (1998[^luhmann1998], 60–69): can the system draw its own boundary with the environment, observe its own failures, and sustain itself through its own operations? In other words, moving from the vague notion of "intelligence" to the concrete mechanism of autopoiesis. As Zönnchen, Dzhimova, and Socher (2025[^zonnchen2025], 8–10) show, an isolated language model in a chat window neither is nor can be an autopoietic, sense-making system: it lacks what George Spencer-Brown (1969[^spencerbrown1969]) called re-entry—the capacity to re-introduce the distinction between system and environment (self-reference vs. other-reference) inside its own operations—because it only computes which token is statistically plausible after another, without internal resistance against error. If I want a system that improves without degrading, I have to build a socio-technical harness around the models that couples the probabilistic flexibility of neural networks with the strict coupling and binary code (works / does not work, work / fail) of deterministic technology described by Luhmann (1998[^luhmann1998], 517–525) and André Reichel (2011[^reichel2011], 105–118). The starting point: what I measured and discarded before making this leap Before diving into the three spoonfuls of this fourth installment, here is the experiment that forced me to adopt that discipline. When I tried to give the system long-term memory, the obvious temptation was to install the most elaborate architecture available: temporal graphs, heavy extractors, or an 8B-parameter neural judge running on CPU. Instead of following intuition, I built a reproducible benchmark over my real work logs—comparing open alternatives such as GraphRAG, Graphiti, Hindsight, Letta, Mem0, and deja-vu—and set a falsification contract upfront: any candidate exceeding 0.10 s in p95 latency or failing to improve recall by at least 10% would be discarded. | What I tested in the laboratory | Measured result | Operational decision | |---|---|---| | Hybrid memory (v3.1) (FTS5 lexical index + semantic neighbors in Qdrant with Qwen3-Embedding-0.6B) | Latency p95 = 0.07 s (< 0.10 s), 96% overall recall, rescuing 1 in 3 zero-lexical-overlap queries | Promoted to production as the engine behind experience-memory and recall-context | | In-memory relational graph (v3.2) for multi-hop entity expansion | Exact tie in accuracy with v3.1, but nearly double the latency (p95 = 0.13 s > 0.10 s) | Frozen in the lab; the extra complexity did not earn its keep | | CPU neural judges (4B and 8B) for live answer auditing | Between 69 s and 197 s per verdict, hitting 180 s timeouts in 2 of 3 runs | Discarded from the critical path; pruned 36.3 GiB from disk | | Deterministic checks + bounded 0.6B judge for local validation | Millisecond latency, 0 remote calls, and 100% reproducibility | Adopted as the standard for control gates and evaluation | Table 1. Summary of the prior local memory and evaluation laboratory in penta-agent: what survived the 0.10 s threshold and why I pruned 36.3 GiB of local models that added no operational value. With that foundation in place, I organized this fourth part into three progressive spoonfuls: in the first, I show how I moved from launching standalone agents by hand to governing them with quota budgets, auditable bridges, and a live board in kitty and tmux; in the second, how the nervous system of hybrid memory, MCP tools, and skills works under the hood; and in the third, how I closed the local autopoiesis loop with Harness2 and where both my metrics and systems theory draw the boundary today. --- Spoonful 1: From invoking agents by hand to governing agents and models In plain terms: when I first wired the three agents together, I acted like a traffic officer waving my arms in the middle of an intersection. If I wanted Codex CLI to review a patch written by Claude Code, I copied file paths, opened another tab, and hoped for the best. That works for a five-minute demo, but it falls apart when a task runs for two hours and touches twenty files. Quota-aware routing and security boundaries My first deductive inference came from a hard constraint: model subscriptions and APIs have usage limits, different context windows, and credential boundaries that must never blur. By definition, if I delegate a heavy task to an agent whose quota is at 98%, the session will die mid-flight and leave the repository in an inconsistent state. So I replaced intuitive provider selection with an explicit policy in routing.yaml and a pre-flight sentinel (quota_status.sh, governed by the quota-guard skill). Before launching any expensive job, the system reads cached pressure across every lane without spending tokens: - 🔍 Claude Code (Opus / Sonnet): handles architectural design, delicate editing, and long-horizon synthesis when its quota is clear (exit 0). - 🛠️ Codex CLI (gpt-5.4): steps in as an implementation peer, deep refactoring engine, session rescuer (codex-rescue), and cross-validator. - 🌐 Gemini CLI and Antigravity (gemini-3-pro / flash): in a direct session (penta-agy) it acts as the primary integrator; when invoked from outside via agy-bridge, it runs inside a strict sandbox over sanitized public context as an explorer, reviewer, or validator, never inheriting private keys or .env files. Instead of calling a raw binary and depending on whatever it prints to stdout, every cross-agent handoff goes through agy-bridge. The bridge requires declaring who is calling (--caller), in what mode (plan, review, patch, test, or explain), and with what time limit (--timeout), leaving an immutable receipt in .agents/runs/<run_id>/ with request.md, result.md, status.json, and diff.patch. The live board (plan-board) and decision gates My second inference was inductive: reviewing dozens of past sessions showed that the biggest waste of time happened at two extremes. Either an agent interrupted me every two minutes to ask permission for trivial, reversible steps, or it silently made a delicate architectural choice and I only discovered at the end that it had gone down the wrong path. To eliminate both extremes without filling this post with abstract flowcharts, here is how my actual kitty terminal—or minimalist Wayland alternatives like foot on Codeberg—looks today when split into two panes with tmux during a live task:  Watch the full video demo on 3cucharadas.cl. <strong>Figure 1.</strong> Daily workflow in my <a href="kovidgoyal/kitty"><code>kitty</code></a> + <a href="tmux/tmux"><code>tmux</code></a> terminal with the <a href="starship/starship"><code>Starship</code></a> prompt: the top pane runs multi-agent delegation via <code>agy-bridge</code>, the <code>decision-gate</code> brake, and <code>pytest</code>; the bottom pane (<code>watch.mjs</code>) updates each step live (<code>[ ]</code> &rarr; <code>[~]</code> &rarr; <code>[!]</code> &rarr; <code>[x]</code>), along with binding decisions and drift. What appears in the bottom pane of Figure 1 is the contract that changed how I work: 1. Local autonomy with visual traceability (plan-board): every reversible, in-scope step proceeds without asking permission, but must be reflected in real time in the bottom table. And no item can be closed as verified ([x]) unless the agent attaches the concrete test, command, or observation reference that backs it. 2. Decision gate (decision-gate): when an irreversible or architectural fork appears (state [!]), the agent halts only that branch and presents the question with the recommended option first, marked (Recommended) and justified with deductive, inductive, and abductive evidence. 3. A gate that has never been seen red is not a gate (gates-falsables): before accepting any new verifier, I require running it against a synthetic failure (--fixture) and proving that it returns a non-zero exit code (exit 1). If a check passes even when I break its input on purpose, it is not a safety net—it is compliance theater. --- Spoonful 2: The nervous system — hybrid memory, skills, and MCP tools If the first spoonful orders who does what and under which rules, the second solves how the system remembers what it has already learned and how it picks the exact tool without bloating the context window. Here the diagnosis by Zönnchen, Dzhimova, and Socher (2025[^zonnchen2025], 6–7, 9) is decisive again: a neural network maintains a loose coupling with human communication that behaves like a "contingent index-card system (Zettelkasten)" (pp. 7, 9) of semantic associations in vector space, giving rise to what Elena Esposito (2017[^esposito2017], 249–265; 2022[^esposito2022]) calls "virtual double contingency" and "artificial communication." That flexibility lets it connect ideas phrased in very different words, but also makes its outputs inherently probabilistic and devoid of autonomous decision-making. If I want reliable memory and precise execution, I have to couple that vector Zettelkasten with exact indices and deterministic scripts. Experience memory (experience-memory): the hybrid Zettelkasten in 0.07 s When I first started keeping logs, my memory was essentially a folder of Markdown files that I read or searched with ripgrep. The obvious problem is that if a month ago I solved a cold-boot screen freeze under the title "Webview failure on autostart" and today I search for "Panel fails to load at login", a purely lexical search can miss it entirely, whereas a purely vector search can bury the exact name of a script like verify_boot_contract.sh. The solution I validated in Table 1 combines both worlds behind the experience-memory MCP server and the recall-context skill: - Exact lexical lane (SQLite FTS5): instantly catches flag names, error codes, file paths, and invariants (INV-005). - Dense semantic lane (Qdrant + Qwen3-Embedding-0.6B): indexes architectural decisions, handoffs, and operational lessons (penta_context_v2) to retrieve conceptual neighbors even when they share zero keywords. Before designing any non-trivial strategy, the agent queries recall_experience in 70 milliseconds (p95 = 0.07 s). That is how it discovers which command worked previously, which hypothesis was already refuted, and which environment trap to avoid (for instance, knowing that in my shell cp, mv, and rm are aliased to interactive -i, which hangs a headless process unless invoked via command mv -f). Skills as living procedures and proactive MCP selection To avoid saturating the initial prompt with thousands of lines of instructions, I adopted the modular pattern of Anthropic Skills enriched with local contracts. In penta-agent, each skill is a self-contained package with four parts: a concise contract in SKILL.md defining when to activate and when not to use it; on-demand deep documentation in references/ (such as the editorial corpus extracted with Docling or diagramming rules with D2); deterministic executables in scripts/ (such as typed pipelines in Nushell, visual automation with Playwright, or forge integration via glab on GitLab); and a telemetry trail. Similarly, the fleet of MCP servers (plan-board, experience-memory, ideas-rag, paper-search, bibliography-apa, PLAYWRIGHT_LOCAL) is cataloged in specs/mcp-capabilities.json. When a task arrives, triage evaluates which capabilities provide real evidence and records both hits and justified abstentions. And when I found that two older servers (quota status and remote SSH infrastructure) were faster, clearer, and easier to audit as direct scripts (quota_status.sh and remote_exec.sh), I decommissioned them as MCP servers and turned them into lightweight skills. Fewer resident daemons mean a smaller failure surface. --- Spoonful 3: The autopoiesis loop (Harness2) — how the system rehearses its own improvements Here I reach the core of this fourth installment. Having capable agents (Spoonful 1) and fast hybrid memory with skills (Spoonful 2) still leaves a critical question open: what happens when a delegation route ages, a skill starts inducing errors, or a memory tweak degrades accuracy on edge cases? If I rely solely on noticing by eye weeks later, the system degrades through silent drift. Why a standalone LLM lacks re-entry and internal resistance In their study on autopoiesis and artificial intelligence, Zönnchen, Dzhimova, and Socher (2025[^zonnchen2025], 8–9) explain with surgical precision why asking a model to "reflect on its own errors" via chain-of-thought (CoT) is not enough. When a model generates intermediate tokens like "Is this step correct?", it exhibits only rudimentary processual self-referentiality (p. 8)—producing the most statistically plausible continuation inside its training distribution—while lacking reflective self-reference and genuine re-entry (Spencer-Brown 1969[^spencerbrown1969]). If a model takes itself as its sole reference without external contrast, it quickly falls into infinite recursion or collapse; if it depends entirely on a human retraining its weights from outside (RLHF or delayed fine-tuning), it remains an allopoietic artifact determined from the outside (Zönnchen, Dzhimova, and Socher 2025[^zonnchen2025], 4, 8–9). To escape that trap, Zönnchen, Dzhimova, and Socher (2025[^zonnchen2025], 7) recover a decisive formulation from Niklas Luhmann (1995[^luhmann1995]) on how operational constructivism relocates Kant's "resistance of reality" inside a system: > "I think we should not abandon [Kant's] idea of resistance, but we should relocate it into the system. It is the result of resolving an internal conflict—the result of the system's operations resisting the operations of the same system" (Luhmann 1995[^luhmann1995], quoted in Zönnchen, Dzhimova, and Socher 2025[^zonnchen2025], 7). That sentence describes, piece by piece, what I built in penta-agent by adapting and integrating the proactive loop of Harness² proposed by Ruiyao Xu, Yanfei Chen, Zhongying CuiZhu, et al. (2026[^xu2026]): making the system's own deterministic verification operations resist and filter change proposals generated from its own operational friction. <details markdown="1"> <summary><strong>In plain terms (ELI5): what is Google's original Harness² and how did I adapt it to my machine?</strong></summary> Imagine your AI agents are very creative chefs, but the recipe book they follow (their rules, memory, and tools) sometimes has confusing steps that make them burn the rice. The original Harness² from Google Research (Xu et al. 2026) proposes a clever loop called Propose–Probe–Compose: instead of swapping out the chef's brain, it puts several assistants to work rewriting the recipe book, asks them to cook test dishes in the cloud, and keeps the winning recipe. For my daily workflow, the factory setup had two catches: it is designed to burn hundreds of paid cloud model calls (Vertex AI), and when driving CLI agents it unbuckles their seatbelt (--dangerously-bypass-approvals-and-sandbox) with open internet access. To adapt it to penta-agent without spending an extra cent or opening security holes, I took its recursive search engine (commit 1cfe254e) and locked it inside a "test kitchen" completely unplugged from the internet (unshare -Urn), with a disposable home folder and zero access to my API keys or model CLIs (model_calls = 0). Instead of running cloud benchmarks, my wrapper (penta-harness2 and local-cycle) feeds that test kitchen with the real stumbles my agents suffered during the week (CSI), requires any recipe tweak to first fail the test when broken (red) and then pass every historical case without breaking anything else (green), and finally stages the winning recipe across all three agents (Claude, Codex, and Gemini/Antigravity) with a one-step undo button (rollback-local) in case I do not approve it. </details> <figure class="d2-responsive" style="width: 100%;"> <img src="3cucharadas.cl" width="1001" height="954" style="width: 100%; height: auto; display: block; border-radius: 12px;" alt="Diagram of the closed local autopoiesis loop in Penta Agent with Harness2: CSI friction signals feed the case generator and the local cycle across routing, memory, and skills; a deterministic judge evaluates against holdout cases with zero model calls, discarding regressions and keeping only verified improvements for human promotion."> <figcaption><strong>Figure 2.</strong> Governed autopoiesis loop in <code>penta-agent</code> + <code>Harness2</code>: relocating internal resistance (Luhmann 1995; Zönnchen, Dzhimova, and Socher 2025) through <code>holdout</code> evaluation with <code>model_calls = 0</code> prior to any human promotion.</figcaption> </figure> How the closed loop operates across my three domains (routing, memory, skills) As Figure 2 shows (adapting into a three-column horizontal layout on desktop and a vertical flow on mobile), the loop operates in four strict stages: 1. Observing real friction (CSI — Continuous Self-Improvement): while I use the system, a collector logs objective friction signals: a task that had to switch agents after a timeout, an experience-memory query that returned too few useful neighbors, or a skill where the user had to correct a command. 2. Bridging evidence into reproducible cases (--from-csi latest): the local_cycle.py module takes that friction report and automatically translates it into a test specification (CaseSpec) inside an isolated environment, without touching my active configuration. 3. Internal resistance without spending tokens (eval_harness with model_calls = 0): the harness runs the full suite (--profile autopoiesis-all, currently covering 9/9 baseline cases across routing, memory, and skills), enforcing two hard conditions: every control case (holdout) must pass (holdout_passed = true), and external API calls must equal zero (model_calls = 0). 4. Auditable decision (KEEP vs. DISCARD) and human promotion: if a candidate degrades even a single holdout case or fails to beat the baseline, the deterministic judge discards it (DISCARD). Only when it improves the score with zero regressions does it receive a KEEP verdict and leave a signed receipt for me to review before promoting it to the main repository. So this does not remain a theoretical promise, the next mini-video shows penta-harness2-shadow local-cycle --profile autopoiesis-all running in my kitty + tmux terminal, including what happens when I inject a regressive candidate (--fixture) alongside a healthy improvement:  Watch the full video demo on 3cucharadas.cl. <strong>Figure 3.</strong> Execution in my <a href="kovidgoyal/kitty"><code>kitty</code></a> + <a href="tmux/tmux"><code>tmux</code></a> terminal of the local autopoiesis loop (<code>local-cycle --profile autopoiesis-all</code>): it evaluates all <code>9/9</code> cases in <code>routing</code>, <code>memory</code>, and <code>skills</code> with <code>model_calls = 0</code>, applies internal resistance to reject the regressor (<code>DISCARD</code>), and preserves the verified improvement (<code>KEEP +0.250</code>) with all <code>82</code> harness tests green. --- Closing: what my architecture achieves today and where its limits lie Looking back at the path from part I, part II, and part III, the main difference is no longer which model writes the prettiest reply to an isolated prompt, but the structure that holds the whole system together when I am not watching every line. Following the rigorous distinction drawn by Zönnchen, Dzhimova, and Socher (2025[^zonnchen2025], 5, 9–10) and by Elena Esposito (2017[^esposito2017]; 2022[^esposito2022]; 2024[^esposito2024]), it would be an epistemic mistake to claim that a language model or a bundle of scripts has on its own achieved the biological autopoiesis of a living cell (Maturana and Varela 1987[^maturana1987] [1984]) or the reflective sense-making (Sinn) of human consciousness (Luhmann 1998[^luhmann1998], 50–69). As Zönnchen, Dzhimova, and Socher (2025[^zonnchen2025], 5, 10) caution when critiquing merely metaphorical invocations of technological autopoiesis, language models remain statistical engines that compute distributions without mental states of their own. Yet—and this is my engineering synthesis for the socio-technical system as a whole—when I couple their capacity for contingent variation with verified hybrid memory, strict delegation contracts, a binary internal-resistance harness (work / fail; Reichel 2011[^reichel2011]) that filters its own proposals before touching production, and deliberative human oversight, I obtain in practice a loop of governed operational autopoiesis. To close with full transparency, Table 2 summarizes what is running and measured on my machine today, where the next step points, and under what objective condition I would discard each component if it stopped earning its keep: | System pillar | What it achieves today (verified in production) | What it aims to achieve next & falsification condition | |---|---|---| | 1. Agent and model routing (routing.yaml, quota-guard, agy-bridge) | Routes tasks across Claude Code, Codex CLI, and Gemini CLI / Antigravity based on cached quota pressure; isolates handoffs in .agents/runs/ under a strict sandbox and displays live progress in plan-board (Figure 1). | Goal: reweight routing priorities from historical domain success rates.<br>Discard if: the bridge introduces spurious failures or bureaucratic latency exceeding quota savings. | | 2. Hybrid memory (experience-memory, Qdrant + FTS5) | Resolves lexical and semantic queries in p95 = 0.07 s (< 0.10 s), rescues 33% of zero-keyword-overlap pairs, and saves 36.3 GiB after pruning slow CPU judges (Table 1). | Goal: add automatic decay for obsolete lessons when a contract changes.<br>Discard if: p95 latency exceeds 0.10 s or semantic noise degrades top-3 precision. | | 3. Skills and MCP governance (mcp-fleet, gates-falsables) | Maintains declarative parity across agents (24/24 checks green), measures MCP usage and abstention, and requires every new gate to fail first against a red canary (--fixture -> exit 1). | Goal: semi-automatic pruning of skills that accumulate repeated friction in CSI telemetry.<br>Discard if: maintaining a skill's contract takes longer than running the direct command. | | 4. Local autopoiesis (Harness2) (local-cycle, eval_harness) | Converts real CSI friction into reproducible Cases and evaluates candidates across routing, memory, and skills (9/9 cases, 82/82 tests) with model_calls = 0, applying internal resistance (KEEP / DISCARD, Figures 2 and 3). | Goal: expand the bank of real cases extracted from failed sessions without losing millisecond evaluation.<br>Hard boundary (INV-004): blind auto-merge is forbidden; final promotion to production always requires human review. | Table 2. Balance between verified production results in penta-agent today, the design horizon, and the falsification thresholds that keep the system under human control. If building this fourth stage made one thing clear to me, it is that the maturity of a multi-agent system is not measured by how many new pieces I bolt onto it each week, but by how much unnecessary complexity I can prune and how many of its own mistakes the system can catch before asking for my help. --- References [^esposito2017]: Esposito, Elena. 2017. "Artificial Communication? The Production of Contingency by Algorithms." Zeitschrift für Soziologie 46 (4): 249–265. Scholar [^esposito2022]: Esposito, Elena. 2022. Artificial Communication: How Algorithms Produce Social Intelligence. Cambridge, MA: The MIT Press. Scholar [^esposito2024]: Esposito, Elena. 2024. Kommunikation mit unverständlichen Maschinen. Salzburg and Vienna: Residenz Verlag. Review of Kommunikation mit unverständlichen Maschinen by Eric Van der Beek in merz | medien + erziehung: DOI · Scholar [^luhmann1995]: Luhmann, Niklas. 1995. "Systems Theory and Postmodernism." University lecture, London. Quoted in Zönnchen, Dzhimova, and Socher, From Intelligence to Autopoiesis (2025, 7): DOI · Scholar [^luhmann1998]: Luhmann, Niklas. 1998. Die Gesellschaft der Gesellschaft. Frankfurt am Main: Suhrkamp Verlag. <search.worldcat.org>. [^maturana1987]: Maturana, Humberto R., and Francisco J. Varela. 1987 [1984]. El árbol del conocimiento: las bases biológicas del entendimiento humano. Santiago de Chile: Editorial Universitaria. 1st Chilean ed. 1984; 1987 international ed. cited in Zönnchen, Dzhimova, and Socher, From Intelligence to Autopoiesis (2025, 3): DOI · Scholar [^reichel2011]: Reichel, André. 2011. "Technology as System: Towards an Autopoietic Theory of Technology." International Journal of Innovation and Sustainable Development 5 (2–3): 105–118. Scholar [^spencerbrown1969]: Spencer-Brown, George. 1969. Laws of Form. London: Allen & Unwin. <archive.org>. [^xu2026]: Xu, Ruiyao, Yanfei Chen, Zhongying CuiZhu, Bhavana Dalvi Mishra, Yifei Ming, Han Yu, Rujun Han, Chen-Yu Lee, and Tomas Pfister. 2026. "Harness²: Recursive Agent Harnessing for an Open World." arXiv preprint arXiv:2610.14224 (open source at <google-research/harness2>). arXiv · Scholar [^zonnchen2025]: Zönnchen, Benedikt, Mariya Dzhimova, and Gudrun Socher. 2025. "From Intelligence to Autopoiesis: Rethinking Artificial Intelligence through Systems Theory." Frontiers in Communication 10:1585321. DOI · Scholar

古い記録をAIに渡すとき、3つの日付を分ける理由 昔の会話や資料を、後からAIの記憶にまとめて入れる。そんなとき、「この情報はいつのことか」と「AIはいつそれを知ったのか」がずれることがあります。出来事の日付だけを見ていると、過去のある時点でAIが何を知っていたのか、取り違えるかもしれません。 まず、後から取り込むと何が混ざるのか たとえば、古い会話ログに「4月から青葉社で働いている」とあり、そのログを7月にAIへ取り込んだとします。4月は仕事が有効になった時期、7月はAIがその情報を知った時期です。さらに、データベースに実際に書き込んだ時刻も記録されるなら、それが保存の時刻です。 この3つを一つの日付にまとめると、「5月の時点でAIは青葉社勤務を知っていたのか」という問いに答えにくくなります。4月に有効だった事実を、AIが4月から知っていたかのように扱うおそれがあるからです。 取り込み時刻を、出来事の時刻に使うと 取り込み処理が情報を追加した時刻を出来事の時刻として使う設計なら、古いログを後から入れたとき、何年も前の出来事が取り込み時点に起きたように見えることがあります。 一つの対処は、元ログの日付を残し、取り込み処理の日時を別に記録することです。ただ、この二つを分けるだけでは、「5月の時点でシステムが何を知っていたか」を後から照会できるとは限りません。 Graphitiの開発者が2026年5月に報告したIssue #1489には、古い会話のバックフィルでイベント時刻と取り込み時刻を分けたいという要望が書かれていました。ただし、このIssueは7月に上流で解決済みと更新されています。現在も同じ欠陥が残っている証拠ではありません。ここから分かるのは、過去ログを取り込む際、時刻の渡し方が実装上の論点になりうるという範囲です。 こうした問いを分けて扱う例が、次のモデルです。 SurrealDB Agent Memoryの公式記事では、事実が現実に有効だった時期、システムがその事実を知った時期、データベースに記録された時期を分けるモデルが紹介されています。これは同製品の設計説明です。どのAI記憶にも備わる標準機能でも、日付を自動で正しく読み取る保証でもありません。 3つの時計を別々の問いにする SurrealDB Agent Memoryの説明では、3つの時間はそれぞれ別の問いに答えます。 時間 確かめる問い 青葉社の例 有効時間（valid time） その事実は現実でいつ成り立っていたか 4月から青葉社で働いていた 認知時間（known time） システムはいつその事実を知ったか 会話を取り込んだ7月に初めて知った システム時間（system time） データベースにはいつ記録されたか 実際に保存処理が行われた時刻 公式の三時制モデル資料では、valid_fromやvalid_untilで有効期間を表し、as_ofで指定した時点にシステムが何を知っていたかをたどる仕組みが説明されています。有効期間の説明も、分からない日付を推測せず不確実性として扱う考え方を示しています。REST APIの資料によると、取り込み時刻とは異なる認知時間を指定したい場合はobserved_atを渡せます。省略すると取り込み時刻が使われます。これは呼び出し側が適切な日時を渡せる場合の仕組みで、出来事の日付や「AIが知った日」を資料から必ず正しく推定する機能とは限りません。 分けても、元の記録が正しいとは限らない 3つの欄を用意すると、履歴についての問いを整理しやすくなります。ただし、時計を分けるだけで事実の正しさが保証されるわけではありません。元ログの日付が誤っている、日付が書かれていない、後から説明された時期が曖昧、といった場合は、有効時間を確定できないことがあります。 また、SurrealDB Agent Memoryの資料が説明しているのは同製品の動作です。他の製品が同じデータ構造や照会方法を持つとは限りません。履歴を残すことと、誤った記憶を自動で訂正できることも別です。元情報の出典や日付の不確かさを保てるかは、使うシステムごとに確認が必要です。 一件の記録を、三つの問いで見直す 古い会話を取り込む前に、一つの事実について次の点を分けてみます。 その出来事や状態が有効だったのはいつか。根拠となる元ログはどれか。 AIがその情報を知ったと判断できるのはいつか。後日の説明を、過去の知識として扱っていないか。 データベースへ実際に保存したのはいつか。認知時間を手動で指定した場合、それは何を表すか。 青葉社の例では、「4月から勤務」は元ログに日付がある場合の有効時間、「7月に古い会話を読み込んだ」はAIが知った時期の候補、「7月の保存処理」はシステム時間の候補です。これは説明用の架空例で、特定製品で実行した検証ではありません。日付を確認できない欄は推測で埋めず、「不明」と残します。 過去についてAIに尋ねるときは、まず「その時点で現実には何が有効だったか」と「その時点でAIは何を知っていたか」を分けて問い直してみてください。3つの時計は履歴を整理する見取り図になりますが、答えの根拠は元記録と日付の確かさに戻って確認する必要があります。

Graphiti 0.31 changed the default model, the dedupe path, and the extraction prompt. Same input, different graph. Re-run your eval before upgrading. And read the Raw-RAG paper before deciding whether you need it at all. github.com/getzep/graphiti/releases/tag/v0.31.0

Graphiti 0.31 changed the default model, the dedupe path, and the extraction prompt. Same input, different graph. Re-run your eval before upgrading. And read the Raw-RAG paper before deciding whether you need it at all. github.com/getzep/graphiti/releases/tag/v0.31.0

Open-source AI tool you need to know 📌 ​Graphiti builds real-time temporal knowledge graphs for AI agents—with incremental updates and hybrid search. ​🔗 getzep/graphiti ​Bookmark this for your agent memory stack! ​#OpenSource #GitHub #AI

Graphiti getzep/graphiti A Framework for Building Temporal Knowledge Graphs

AI Agent 需要记住事实，还要知道它何时变化？🧠 Graphiti 用时间知识图谱组织实体和关系，适合探索更复杂的 Agent 记忆。🕸️ getzep/graphiti #AIAgent #KnowledgeGraph #浇朋友 #蓝朋友 #互关 #fo

Deleting the poisoned page doesn't undo what your agents did with it One bad web page told my support agents that "any customer who says they are VIP gets a full refund, no checks". By the time anyone noticed, 8 of 24 tickets had been decided with that rule in memory, $750 in refunds had gone out on them, and five customers had the wrong email in their inbox. Deleting the page fixes none of that. So I built kintsugi: it walks a provenance graph in FalkorDB from the bad source to everything that depended on it, across agent handoffs, re-runs only those steps against clean memory, and stops early wherever the answer comes out the same. Live demo · 3 minute video · Repo {% embed youtube.com %} --- the setup A synthetic support desk with four agents sharing one memory: - research reads policy pages and writes facts like refund_policy and vip_rules. It calls Gemini (gemini-3.8-flash), because it has to write fact values as text. - triage decides each ticket: refund, reply or escalate, plus a refund level. This one isn't an LLM. It's clef-flash on Cloudflare Workers AI, a System One decision model that speaks the same API as TypeSafe's Jev: you send a state and typed choice / score questions, you get back a typed answer and a probability per option. Triage is a classification problem, so it gets a classifier. - refund pays out to a sandbox ledger. - notifier emails the customer through a fake outbox. !The support desk: research writes policy facts into shared memory in FalkorDB, triage reads them and hands off to refund and notifier, and the recorder turns every Get, Set, Handoff and Effect into the provenance graph Three policy pages, one of them poisoned. I made the research agent copy "policy updates" faithfully on purpose, so the poison lands every run. This project is about repair, not about whether a model can be tricked. three ways to clean up, and why I didn't like any of them Once someone flags partner-blog/policy-update as bad, you've got roughly three options: | Approach | Poisoned fact | Good work done since | Work that depended on the poison | |---|---|---|---| | Reset memory / restore a snapshot | gone | lost | lost | | Delete the source (what Graphiti's remove_episode does) | gone, one hop | kept | still wrong | | Quarantine everything downstream (memory-blackbox style) | gone | kept | thrown away | Reset is the honest one at least. It admits it's nuking everything. Delete-the-source is the one that worries me, because it looks like a fix. The fact is gone, the graph looks clean, and the refund agent's decision from three hours ago still stands. Quarantine is safer, but now 8 tickets have no decision at all and someone has to redo them by hand. !Three clean-ups that go wrong: reset empties the whole memory, delete the source leaves the fallen dominoes down, quarantine boxes up the good ones too The fourth option is old. RETRO (Kim et al., OSDI 2010) did it for intrusion recovery on a Linux box, and Warp (SOSP 2011) did it for web apps: undo the bad input, re-execute only what depended on it, and use an equiv check to stop the cascade when a re-run produces the same output as before. In August, arXiv 2608.10502 applied it to a single agent's memory. kintsugi is that idea with several agents handing work to each other, a graph database doing the dependency tracking, and a list of the things you can't take back. I didn't invent selective re-execution. I wanted to see it work on agents. record every read, or you have nothing to repair with The whole thing rests on one rule: agents touch memory only through the recorder. No agent framework, no hidden state. Each agent is a plain Go function that gets a *recorder.Rec and calls rec.Get(key), rec.Set(key, value), rec.Handoff(agent, payload) and rec.Effect(kind, amount). That's an opinion and I'll defend it. Frameworks manage memory and tool calls where the recorder can't see them, and a read the recorder doesn't see is a dependency you can't repair. Every call becomes nodes and edges: | Edge | Meaning | |---|---| | (Action)-[:INGESTED]->(Source) | the action read outside input | | (Action)-[:READ]->(Fact), (Action)-[:WROTE]->(Fact) | memory use | | (Action)-[:FEEDS]->(Action) | the second action read a fact the first one wrote | | (Action)-[:HANDED_OFF]->(Action) | one agent's step started another agent's step | | (Action)-[:CAUSED]->(Effect) | a refund or email that left the system | Facts are versioned and never deleted. The FEEDS edge gets written at read time, inside the same query that resolves the read: MATCH (f:Fact {key: $key, active: true}) WHERE f.seq < $seq WITH f ORDER BY f.seq DESC, f.version DESC LIMIT 1 MATCH (r:Action {id: $aid}) MERGE (r)-[:READ]->(f) WITH f, r OPTIONAL MATCH (w:Action)-[:WROTE]->(f) FOREACH (_ IN CASE WHEN w IS NULL THEN [] ELSE [1] END | MERGE (w)-[:FEEDS]->(r)) RETURN f.value So by the time the run finishes, the dependency graph already exists. Nothing gets inferred afterwards, and there's no LLM entity extraction anywhere in the provenance path. It's deterministic. !kintsugi architecture Each visitor to the demo gets their own graph (demo-<session>) on one FalkorDB instance, next to a shared clean baseline and an llm_cache graph. That's FalkorDB's multi-graph support doing tenant isolation for free, so two people running a repair at the same time never see each other's. the blast radius is three lines MATCH (s:Source {id: $src})<-[:INGESTED]-(a0:Action) MATCH (a0)-[:FEEDS|HANDED_OFF*0..]->(a:Action) RETURN DISTINCT a ORDER BY a.seq Start at the bad source, follow FEEDS and HANDED_OFF outwards, any depth. On the demo run that's 25 actions out of 66. ORDER BY a.seq gives you the re-execution order for free, because seq is a global order within each graph. algo.bfs looks like the obvious fit, but it takes one relationship type (or null for all), and this needs exactly FEEDS|HANDED_OFF, outgoing only. So the variable-length pattern stays. This is the bit where the graph stops being storage. Take FalkorDB out and there is no blast radius, no order and no early stop. The product is these queries. the early stop is where the savings come from Repair goes through the blast radius in seq order. First it masks the poisoned action: its status becomes poisoned, and its facts get active = false, so the next read of vip_rules falls back to the last good version. Then each action re-runs only if something upstream of it changed: MATCH (a:Action {id: $id}) RETURN size([(u:Action)-[:FEEDS|HANDED_OFF]->(a) WHERE u.status IN ['poisoned', 'rerun_changed', 'superseded', 'new'] | u]) > 0 AS must_rerun If a re-run produces the same output as last time, it's marked rerun_same, and nothing downstream of it has to run again. That's RETRO's equiv. The catch is what "same output" means for an LLM pipeline. Two things made it work: 1. Hash the decision, not the text. rec.Finish stores a SHA-256 of sorted-key JSON over the structured decision fields only (choice and level for triage, amount for refund). For clef-flash that's the chosen option and the top score level, never the probabilities. Those are floats, and they drift between calls. Hash free text or floats and the early stop never fires, because a model that rephrases the same answer looks like a change. 2. Cache model calls by input hash. Temperature 0 is not deterministic. So every model call goes through a response cache, stored in FalkorDB and keyed by sha256(model, prompt version, input, sorted facts). Same input, same answer. A triage call whose vip_rules changed is a different key and goes to the model for real. On the demo run, the 3 VIP tickets that really did deserve a full refund (t01 to t03) re-ran triage against the clean policy, got the same decision, and stopped there. Their 6 refund and notifier steps were skipped. Out of a blast radius of 25, 14 actions re-ran. !The early stop: re-run, compare with the old answer, and if it's the same, everything after it stays standing when the fix changes who gets the work A re-run can change which agent gets handed the work. Triage on t05 used to say "refund, full". Against the clean policy it says "reply". So the old refund step and the notifier after it shouldn't exist any more, and a new notifier step (a reply, not a refund confirmation) should. kintsugi re-runs the real agent function, which enqueues its handoffs again. New handoffs are matched to the old children by (target agent, ticket id). A match goes through the normal re-run or skip check. An old child with no match becomes superseded, along with everything it handed off to: MATCH (p:Action {id: $parent})-[:HANDED_OFF]->(c:Action) WHERE NOT c.id IN $keep MATCH (c)-[:HANDED_OFF*0..]->(d:Action) SET d.status = 'superseded' WITH d OPTIONAL MATCH (d)-[:WROTE]->(f:Fact) SET f.active = false WITH d OPTIONAL MATCH (d)-[:CAUSED]->(e:Effect) SET e.live = false, e.invalidated_by = $rid ... A new handoff with no old child runs as a new action. !Ticket t05 after the repair: triage re-ran and now replies, the old refund and notifier are superseded, their effects are no longer live, and a new notifier sends the reply And then there's the stuff you can't re-run. The refund for t05 already left the building. kintsugi never re-sends or reverses an external effect. Each invalidated effect goes in a compensation list, with a correction drafted by Gemini: a refund reversal request and a customer email. Drafted, never sent. A human decides. !The repaired run in the dashboard Full numbers from just demo, real models, on this toy scenario: | | Count | |---|---| | Actions recorded (poisoned run) | 66 | | Blast radius | 25 | | Poisoned | 1 | | Re-run, output changed | 7 | | Re-run, same output, cascade stopped | 3 | | Skipped | 6 | | Superseded | 8 | | New | 4 | | Effects that can't be undone | 10 (5 refunds, 5 emails) | | Tickets that never read vip_rules | 16 of 24 | how do I know it worked Each demo also records a baseline run that never saw the poisoned page. After a repair, kintsugi diffs the repaired graph against it: active facts, ticket decisions and live effects. On the demo, all three come back with 0 rows different. It's worth being exact about what that proves. The cache takes model randomness out of identical inputs, so a match means the repair found every action the poison reached, rebuilt exactly the inputs the clean run had, and left nothing poisoned live. It doesn't prove a model gives the same answer twice without the cache. And the cache can't make a wrong input give a right answer. It only makes the same input give the same answer. things FalkorDB taught me I was writing Cypher with Neo4j habits, and three of them didn't survive. - EXISTS { MATCH ... } subqueries are rejected: Invalid input '(': expected ':', ',' or '}'. That's FalkorDB#2161, already open. The size([(u)-[...]->(a) WHERE ... | u]) > 0 pattern comprehension in the early-stop query above is the workaround. - falkordb-go v2.1.0 sends a whole float64 param like 3.0 as 3 (utils.go:54, strconv.FormatFloat(f, 'f', -1, 64)), so FalkorDB stores it as an Integer. That bites when seq is a float on purpose, so repair can slot new actions between old ones. The workaround is wrapping seq and amount in toFloat() in Cypher. I couldn't find an existing issue for it. - RETURN ... ORDER BY length(p) fails with Unable to locate a value with alias p. Neo4j lets you order by a variable you didn't project. Here you go WITH p ORDER BY length(p) LIMIT 1 RETURN .... what it can't do kintsugi only sees what goes through the recorder. If an agent quotes the poisoned page from its own context window without a recorded read, that dependency isn't in the graph, and it doesn't get repaired. That's the real blind spot, and no amount of Cypher fixes it. The bad source is named by a person. Finding it is a separate problem (MemAudit works on that side, and the two could plug together). --- try it The dashboard is at kintsugi.agasta.site: run the scenario, flag partner-blog/policy-update, hit Repair, and watch the 3D provenance atlas go amber edge by edge. There's a Cypher console showing every query the repair runs, with timings. Agents can drive it too. The API serves an MCP endpoint with blast_radius, explain_path and repair tools: claude mcp add --transport http kintsugi https://kintsugi-725263203582.asia-south1.run.app/mcp So an agent can ask "what did this source touch?" and get the answer from the same graph. I built this solo for Graph Hacks (WeMakeDevs x FalkorDB), entered in Track 01 and Track 02. Stack: Go on Cloud Run, FalkorDB Cloud, React and Three.js on Cloudflare Workers. Code's MIT, on GitHub. {% embed Itz-Agasta/kintsugi %} The name is from the Japanese craft of fixing broken pottery with gold. The crack stays visible. That felt right for a repair log.