惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Jina AI
Jina AI
S
SegmentFault 最新的问题
D
DataBreaches.Net
H
Help Net Security
有赞技术团队
有赞技术团队
M
MIT News - Artificial intelligence
Martin Fowler
Martin Fowler
IT之家
IT之家
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
腾讯CDC
罗磊的独立博客
Y
Y Combinator Blog
阮一峰的网络日志
阮一峰的网络日志
云风的 BLOG
云风的 BLOG
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
WordPress大学
WordPress大学
Microsoft Security Blog
Microsoft Security Blog
J
Java Code Geeks
Vercel News
Vercel News
Hugging Face - Blog
Hugging Face - Blog
aimingoo的专栏
aimingoo的专栏
Stack Overflow Blog
Stack Overflow Blog
Recent Announcements
Recent Announcements
博客园 - 三生石上(FineUI控件)

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
Push vs Pull Memory: A Better Way to Think About AI Agent...
hendrixx-cnc · 2026-06-18 · via DEV Community

Push vs Pull Memory: A Better Way to Think About AI Agent Memory

Pull memory is a store you query. Push memory is a loop your agent runs: it reads what it knows before acting, does the work, and writes back what changed, and the substrate reconciles that write so a stale fact gets superseded instead of lingering. Most agent memory today is pull. This post is about the other half of the design space, and when it is the one you actually want.

How agents remember today

Almost everything sold as "agent memory" right now is pull. You write facts into a store: a vector database, a document store, or a managed memory service. Later, at read time, the agent sends a query and gets back the closest matches by similarity. That is it. The store is passive. It answers when asked and does nothing in between.

Pull is simple, and it is the right tool in plenty of cases. If your agent answers one-off questions over a corpus that does not change much, or the session is short, or approximate recall is good enough, a vector store is fine and you should not overthink it.

The trouble starts when a fact can be wrong later.

Say your agent stored "the connection pool cap is 20." Weeks pass and the cap is raised to 50, so the agent stores that too. Now both facts live in the store. A similarity search can return either one, and nothing in the system knows that the second supersedes the first. The agent has no signal that one of these is stale. The job of noticing the conflict falls on the reader, on every single read, forever. In practice nobody does that reliably, so the agent quietly acts on outdated facts and you find out when something breaks.

This is not a bug in any particular vector database. It is a property of the pull shape itself: reconciliation happens at read time, if it happens at all, and the responsibility for it sits with whoever is reading.

Push memory: reconcile at write time instead

Push closes the loop. The contract is read, then work, then write:

read current memory  ->  do the work  ->  write a correction
        ^                                        |
        +------  substrate supersedes + flags  --+

Before the agent acts, it consults what it already knows. After it acts, it writes back what it learned. The key difference is what happens on that write. It is not an append. When the new fact corrects an old one, the agent writes it as a correction, and the substrate demotes the superseded value and records the link between the two. From then on, every read sees the current value first, with the old one flagged as contradicted, and no one had to ask.

Reconciliation moves from read time to write time, and from the reader to the substrate. You pay the cost once, when you write, instead of every time you read. Stale facts do not pile up silently, because the moment a contradiction is written, it is resolved and recorded.

The axis

Pull memory Push memory
Shape A store you query A loop you run
Reconciliation At read time, by the reader At write time, by the substrate
Stale facts Linger until a reader notices Superseded and flagged automatically
The write An append A correction, with provenance
Best when Facts are stable, sessions short Facts change, agents long-lived, correctness matters

Why push memory is only buildable now

The push shape is not a new idea. Truth-maintenance systems and belief revision were studying write-time reconciliation decades ago. The reason memory got built pull-first is that push needs something pull does not: a reliable author. Something has to consult memory before acting and write a principled correction afterward, every time, without being told. For most of computing history that author did not exist at scale. You were not going to get a human to do it on every write.

A capable LLM agent is that author. It can read before it acts and write a structured correction after, as a normal part of its loop. That is what makes push memory practical today and not five years ago, and it is why the idea is worth a fresh look now even though the underlying theory is old.

Which one do you need

Be honest about it. If your agent answers questions over a mostly static corpus and does not live very long, pull is fine and simpler. Reach for push when your agent runs over days or weeks, accumulates decisions, and has to stay correct as the world changes underneath it. The deciding question is whether a fact can be wrong later. If it can, read-time similarity is not enough on its own, and you want write-time reconciliation.

A quick test for what you already have: does your memory flag a contradiction without being asked? Store two facts that conflict, then query the topic. If you get back whichever is more similar with no signal that they disagree, you have pull. If the system surfaces the conflict and tells you which one is current, you have push.

Where this lands

The honest framing is a spectrum, not a binary. Plenty of systems can be read either way, and some sit closer to the push end than others. The useful question is not "which store has the best search," it is "where does reconciliation live: in every reader, or in the substrate, once."

I am building Recall, an open-source, local-first push memory substrate, to take the push end seriously. The agent consults a compiled context packet before acting and writes structured corrections back through an admission layer. Supersession is built in. It runs on local SQLite, every fact carries provenance, and there is a one-command undo. No server, no account, no cloud. There is a short screencast of a live supersession in the README, and a benchmark called SENTINEL that measures whether a memory system catches its own contradictions.

If you think the push vs pull split is wrong, or that your system is push and I have it filed under pull, I want to hear it.

FAQ

What is pull memory? A passive store you query at read time, where reconciling stale or conflicting facts is the reader's job.

What is push memory? A loop where the agent reads before acting and writes corrections back, and the substrate reconciles at write time, superseding stale facts automatically.

Is RAG push or pull? Pull. Retrieval-augmented generation fetches similar chunks at read time and does not reconcile across writes.

Are Mem0, Zep, or Letta push or pull? Mostly pull in the sense above, though they differ. Zep's bi-temporal graph does some write-time reconciliation and sits closer to the push end than a plain vector store. The cleanest way to tell is the contradiction test: does it flag a conflict without being asked.

When should I not bother with push memory? Short-lived agents over a static corpus, where approximate recall is enough. Pull is simpler and fine there.