--- title: "Gmeow: your mailbox is agent memory, keep it local" date: 2026-05-24 canonical: https://patrickaudley.com/#post-gmeow-mailbox-agent-memory-local cross-posted-from: https://www.linkedin.com/feed/update/urn:li:activity:7464480186072285184/ source-platform: LinkedIn tags: [open-source, ai-agents, gmail, mcp, local-first, semantic-search, knowledge-graphs, archives] mentions: [https://patrickaudley.com/#proj-gmeow] author: Patrick Colm Audley author-url: https://patrickaudley.com/ license: Creative Commons BY-NC-SA CAv2.5 lang: en --- # Gmeow: your mailbox is agent memory, keep it local > The recurring problem with useful personal agents is that the context they need already exists, but not in the tidy place a demo would like it to be. It is in mail. gmeow makes that mailbox substrate locally useful through loopback REST, MCP, PostgreSQL, semantic search, attachment sidecars, object storage, and a local knowledge graph. The recurring problem with useful personal agents is that the context they need already exists, but not in the tidy place a demo would like it to be. It is in mail. Not just messages, either. It is in labels, half-forgotten attachments, old project threads, invoices, flight changes, account notices, side-channel decisions, introductions, one-off commitments, and all the little “do you remember when...” fragments that make a mailbox closer to institutional memory than correspondence. For a working agent, Gmail is not an inbox. It is a substrate. `gmeow` is my attempt to make that substrate locally useful without turning it into yet another cloud import pipeline. The design is deliberately boring in the places that should be boring: authenticate to Gmail, hydrate the mailbox, cache the useful structure locally, expose a loopback API, and give agents an MCP endpoint they can query without being handed the keys to the entire account. Under the hood it keeps a PostgreSQL catalogue of labels, threads, headers, MIME structure, categories, graph triples, jobs, sync state, and embedding chunks; stores payloads in a BLAKE3 content-addressed object store; builds attachment sidecars; and layers lexical search, semantic search, and graph traversal over the result. The important boundary is this: `gmeow` is not a hosted mail intelligence service. It is for trusted single-user local systems. By default it binds to `127.0.0.1`. It does not pretend to be an Internet-facing application with a half-baked auth layer stapled on afterwards. If you expose it to an untrusted network, you are outside the threat model. That constraint is not an inconvenience; it is the point. The agent-facing surface is the part I care about most. A local coding or research agent should be able to ask questions like: “Find the thread where we decided on the migration plan.” “Show me attachments from this vendor that mention renewal.” “Which people, projects, and topics are connected to this message?” “Summarise the recent unread messages in this category.” “Archive this after recording the relevant metadata.” That is a very different shape from building a mail client. A mail client is an interface for a human sitting at the glass. `gmeow` is plumbing for agents operating beside the human: search, reads, labels, contacts, categories, attachment metadata, archive state, semantic lookup, and graph exploration through REST and MCP. The graph piece is where this starts to get interesting. Mail is full of latent structure: people, organisations, projects, documents, obligations, recurring operational patterns. Some of that structure is explicit in headers and labels. Some of it only shows up once you extract text, classify categories, embed chunks, and let the relationships accumulate. I do not want an agent merely doing keyword search over my mailbox. I want it to build a usable local map. There is also an archival motive here. I have never liked systems where the only complete copy of a working record lives behind someone else's product boundary. `gmeow` keeps the raw RFC822 path in mind, exposes a read-only IMAP service over cached archive objects, and treats attachments as first-class local objects rather than opaque blobs dangling off an API response. If a mailbox is part of your long-term memory, it should be possible to preserve it with some dignity. This is the first member of a pattern I expect to reuse across the Google surface area. Gmail is the obvious starting point because mail is dense with context, but the same local-first shape should work for Drive, Calendar, and the other services agents keep needing to reason about. Each service gets its own small daemon, local cache, object model, MCP tools, and deliberately narrow trust boundary. The cat may end up carrying a different object each time. Current status: early, opinionated, and useful enough to start dogfooding. Python, PostgreSQL, FastAPI-shaped edges, pgvector for embedding chunks, local object storage, optional SOPS-backed secrets, service-account delegation or user OAuth, and compact TOON responses by default for MCP clients that do not need JSON-shaped ceremony. If you are building local agents that need to reason over real mail instead of toy corpora, kick the tires. The repo is open, rough edges included: [gmeow](https://github.com/paudley/gmeow). --- *Originally published 2026-05-24 — [LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7464480186072285184/). Canonical version at . Author: [Patrick Colm Audley](https://patrickaudley.com/). *