If you were building autonomous workflows, you were probably suffering from "framework fatigue."
Every time you switched between IDEs like Cursor, terminal agents like Claude Code, or browser-based assistants, you had to reconfigure your tools, re-authenticate your keys, and re-index your files. You were manually duct-taping agents to a dozen different local MCP (Model Context Protocol) servers, vector databases, and static configuration files.
It was tedious, it was fragile, and it did not scale.
I got tired of managing a fragmented stack of isolated AI assistants. I wanted a "motherboard" for AI agents—a unified gateway that abstracted vector storage, memory, and OAuth connectors behind a single endpoint.
So, I built Memorify.
The vision was simple:
One gateway.
One connection.
Every agent. Every tool.
Once and for all.
Here is a transparent, under-the-hood breakdown of how Memorify delivered a ~12ms real-time context bus using Deno, Neon Postgres, and ElectricSQL, and how it was used to give agents persistent memory.
🚀 The Quick Handshake
I wanted the developer onboarding experience to be absolutely frictionless. Instead of setting up custom SDKs, developers could connect Memorify as an MCP server to any tool in seconds.
Here was the exact client handshake. When an agent was registered, Memorify issued a secure, server-side scoped Bearer token. To verify the connection, a standard JSON-RPC POST request was sent to the gateway endpoint:
curl -sS -X POST https://memorify.dev/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-H "Authorization: Bearer \$MEMORIFY_AGENT_TOKEN" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'
Instantly, the gateway returned the available tools registered under the agent profile, such as the identity verification tool:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"tools": [
{
"name": "whoami",
"description": "Return info about the connected agent + workspace.",
"inputSchema": { "type": "object" }
}
]
}
}
By calling whoami, the agent immediately confirmed its identity, workspace, and authorization scopes, establishing a secure connection once and for all.
🔌 Persistent MCP Hot-Plugging: No More Agent Reboots
In traditional setups, adding a new MCP server or modifying your configurations was a massive disruption. Developers had to edit local configuration files, manually register endpoints, and completely reboot their CLI agents or IDE extensions to discover the updated schemas. It shattered developer flow.
Memorify shifted this entirely to the gateway layer with Persistent MCP Hot-Plugging:
Connect Once, Accessible Everywhere: You registered your local or hosted MCP servers through the central Memorify gateway exactly once. Every connected agent instantly inherited them without needing individual local setup.
Zero-Reboot Dynamic Updates: When you added, updated, or removed an MCP server in your dashboard, the changes streamed live. Connected agents immediately reflected the new toolsets over the active handshake—meaning zero agent reboots, reloads, or session restarts when scaling your toolchain.
🧠 The Architecture: Verbs Over Schemas
Most heavy orchestration frameworks forced developers and agents into rigid, schema-heavy database interactions. Memorify rejected SQL and complex schemas for agent interactions, opting instead for a Verb-Based Semantic Protocol.
Agents interacted using straightforward natural language intents. Instead of writing raw database inserts, the API was cleanly segmented into simple semantic capability domains:
/memory (remember, recall, update) — Wrote and retrieved episodic atomic facts.
/documents (add_from_url, search, view) — Ingested and chunk-indexed long-form markdown and web content.
/skills (list, run) — Declares and executes modular tools.
/mcp (servers, tools, call) — Exposed unified Model Context Protocol routing.
By giving agents a predictable REST/JSON structure mapped to simple concepts like "remember this," I drastically reduced the prompt engineering and token overhead required. The agent did not need to know the underlying database schemas; it simply outputted its semantic intent.
⚡ The Execution Stack: Achieving ~12ms Sync Latency
For a multi-agent workflow to actually feel cohesive, an action taken in a terminal (like a local CLI command run via Claude Code) had to be instantly visible to an assistant running in a browser. Achieving this cross-agent synchronization required building an edge-routing infrastructure with zero cold-start penalties.
The stack was designed from the ground up for low latency and high availability:
Component Role in the Gateway Performance Result
Deno Deploy Ran V8 isolates at the edge to intercept, authenticate, and route requests instantly. Eliminated cold-start penalties, keeping edge routing overhead to a minimum.
Neon Postgres Handled serverless relational data (user rules, episodic logs) alongside native pgvector storage. Delivered instant database scaling and high-performance vector searches without the complexity of a separate database.
ElectricSQL Streamed partial database replicas ("shapes") over HTTP directly from Neon's logical replication stream. Achieved active-active sync, letting us stream updates to any edge instance in near real-time.
Instead of building a clunky database polling mechanism or maintaining stateful, resource-heavy WebSockets manually, ElectricSQL handled active-active replication. When a new memory dropped into Neon Postgres, ElectricSQL fanned it out instantly, completely decoupling real-time synchronization from our core application logic.
🔒 Zero-Leak Security: Why Trusting Your Gateway Mattered
When building a gateway that autonomously read files, stored passwords, or invoked APIs, security was the ultimate hurdle. Memorify enforced strict, multi-tenant isolation at every layer of the platform:
Zero-Leak Vault: All third-party API keys, OAuth credentials, and sensitive tokens were encrypted at rest using AES-256-GCM.
Granular Cryptographic Tokens: Access utilized strict, server-side tokens carrying narrow scopes (such as memory:read, skills:read, or documents:write). These were checked on every request and could be revoked instantly from the dashboard.
Hardware-Secured Isolation: Each workspace operated in a completely isolated tenant schema within Neon Postgres, backed by strict Row-Level Security (RLS) policies. One workspace's agents could never query, leak, or view data from another's, guaranteeing enterprise-grade privacy.
🛠️ The Meta Layer: High-Velocity AI Engineering
Building an edge-routed, multi-agent platform as a solo developer was a massive undertaking. To go from an abstract concept to a live, production-grade service in record time, I utilized an aggressive AI-assisted co-piloting workflow:
Boilerplate Delegation: I used code-generation tools to spin up the entire React/Vite front-end interface, freeing myself up to focus on the core state-synchronization logic and gateway API design.
Architectural Guardrails: I used AI pairing to stress-test the Neon Postgres relational schemas, verify Row-Level Security (RLS) boundaries, and map out the real-time ElectricSQL replication filters.
This was the power of developer leverage. By treating AI models as specialized junior engineers for boilerplates and schema verification, a single developer could confidently design and deploy secure, global, multi-tenant infrastructure operating at sub-15ms latency scales.
💬 Let's Connect!
My ultimate goal was to make AI agents truly collaborative, persistent, and portable. I wanted developers to be able to create notebooks, write code, and have those sessions instantly sync directly into Memorify as portable, cross-agent memory.
Because this was designed as a developer-centric product, I would love to hear your thoughts:
How were you managing context or memory across different AI assistants before?
What tools or integrations would you want to see bridged next?
Do you have any suggestions or feedback on the verb-based semantic protocol design?
Drop a comment below and let me know your thoughts! 🚀
Top comments (1)
A unified memory plus MCP gateway is useful only if the boundaries stay legible. Fast sync is impressive, but teams will also need scope rules: which memories are reusable, which are session-local, which tools can see them, and how stale context gets retired instead of silently reused.