Originally published at lumbox.co
Every agent framework now ships a memory module. Vectors, summaries, reflection loops, graph-based recall. They all miss the simplest and most reliable memory primitive on the internet: the email inbox.
What email gets right as memory
- Append-only by default. You don't lose history.
- Addressable. Every message has a stable ID and thread ID.
- Searchable. Full-text search is built in.
- Structured where it matters. Sender, subject, date, attachments — all first-class fields.
- Pull model. The agent reads when it needs, not streaming 24/7.
- Interoperable. The rest of the world writes to the inbox without you asking.
The agent-memory pattern
Give the agent an inbox. When the agent takes an action, send a record email to itself summarizing what it did. When it needs to recall, query the inbox. Lumbox's API gives you list, search, thread, and filter — the full memory surface.
// agent acts
await lumbox.inboxes.send(self.inbox_id, {
to: self.address,
subject: "[memory] signed up for stripe",
text: "Account created with card ending 4242, verified at 14:22Z",
});
// later, agent recalls
const memories = await lumbox.inboxes.search(self.inbox_id, {
subject: "[memory]",
since: "2026-05-01",
});
When it beats a vector store
When you need verbatim recall, temporal ordering, and cross-agent handoffs. Vector stores excel at fuzzy semantic similarity. Inboxes excel at "what did I do last Tuesday and who did I talk to about it."
Hybrid is fine
Use the inbox for durable, addressable, audit-able memory. Use a vector store for similarity search over summaries. They complement each other. lumbox.co.
Top comments (1)
Email-as-memory is a delightfully lateral idea, and it's smarter than it first sounds: email is already a durable, timestamped, threaded, searchable, universally-accessible log that every agent/service can read and write without you standing up a database. Threads give you natural conversation grouping, the inbox is the queryable store, and it's portable across tools. For a lightweight agent memory it's genuinely clever - you get persistence and an audit trail basically for free.
The limits worth naming so it doesn't surprise you later: email search is keyword, not semantic (no embedding/relevance ranking, so "find the memory about X" is fuzzy), there's no structured schema, and latency/rate-limits make it wrong for hot-path retrieval. So it shines as a durable long-term/audit memory layer, less as the fast working-context store. The pairing I'd reach for: email (or any durable log) for the system-of-record, plus a real retrieval layer for "surface the relevant bit now." That deliberate-context instinct is core to how I build Moonshift, the thing I work on - a multi-agent pipeline that takes a prompt to a deployed SaaS, where what an agent gets is selected/verified, not just whatever the store returns. Multi-model routing keeps a build ~$3 flat, first run free no card. Genuinely creative. Are you adding any semantic index on top, or leaning on email's native search for recall? Recall quality is where this either holds up or needs a retrieval layer.