// exploration · mcp-knowledge · building
Where should an agent's memory live so it can be trusted?
What I'm building now: a knowledge core for AI agents — documents, memory and structured records, reached worker-to-worker via a service binding instead of a public API. The architecture holds; I'm still working out the rest.
The problem
Agents need somewhere durable to read and write — notes, documents, lists, records. But giving an agent a database means exposing a data store, and exposing it to the internet means another public surface, more keys to leak, and no human-meaningful structure.
The naive answer, and why it falls short
Hand the agent a hosted database or a public API behind an API key. You get reach — and key sprawl, a new attack surface, and a blob store with no shape a person can reason about or approve.
The approach
A dedicated knowledge worker reached only worker-to-worker via a service binding — never on the public internet. It holds documents, memory and a generic records wrapper (lists, todos, freeform) with item-granular access by ID. Paired with mcp-approval, every write or delete can be gated by a human.
Decisions & trade-offs
- Service binding, not public API. The core is unreachable from the internet — defense in depth, no key to leak.
- Generic records over rigid schemas. One lists/todos/freeform wrapper with JSON bodies, addressable per item — flexible without a migration for every new shape.
- Search deferred on purpose. Storage and item-granular access first; full-text/semantic search is a later phase, not a half-built feature now.
Built with
Cloudflare Workers · D1 · R2 · Vectorize · service bindings · MCP (Model Context Protocol) · TypeScript
Status & roadmap
Where it stands: in progress. The architecture and the records wrapper are built and tested; it already backs other tools via service binding.
Next: search (full-text / semantic), and a documented public surface for the records model — only once it meets the same production bar as mcp-approval.