Every multi-agent system eventually hits the same wall: you have Cursor running one agent, Claude Code in the terminal, and a browser assistant, and none of them share context. You re-authenticate, re-index files, and manually sync state across isolated MCP servers. The plumbing is fragile and does not scale.
Memorify is a unified context gateway that solves this by sitting between agents and their tools. It exposes a single MCP endpoint, handles OAuth, vector storage, and memory, and synchronizes state across frameworks in roughly 12ms. Here is how the architecture works and where it breaks.
The Framework Fragmentation Problem
Agent frameworks do not talk to each other. Each IDE, terminal tool, or browser assistant maintains its own:
- Authentication tokens
- File indexes
- Vector embeddings
- Tool configurations
- Conversation history
When you switch contexts, you lose state. When you run multiple agents, they cannot share knowledge. The typical workaround is to run local MCP servers for each tool and manually configure each agent to connect. This creates N×M connection overhead (N agents, M tools) and no shared memory layer.
Architecture: Single Gateway, Replicated State
Memorify centralizes the plumbing. Agents connect once via MCP. The gateway handles:
- Authentication: OAuth tokens stored server-side, scoped per agent
- Vector storage: Embeddings in Neon Postgres with pgvector
- Memory: Persistent conversation and tool state
- Replication: ElectricSQL syncs state to connected agents in real time
The flow looks like this:
- Agent registers and receives a scoped Bearer token
- Agent connects via MCP JSON-RPC over HTTPS
- Gateway returns available tools (identity, memory, vector search)
- Agent calls tools, gateway updates Postgres
- ElectricSQL replicates changes to all connected agents
The 12ms Sync Path
The latency claim depends on three choices:
Postgres as the source of truth
Neon Postgres stores all state. No separate vector database, no Redis cache. Embeddings live in pgvector columns. This eliminates cross-service latency.
ElectricSQL for replication
ElectricSQL is a Postgres-to-client sync engine. It watches the write-ahead log (WAL) and pushes changes to connected clients over WebSockets. The gateway does not poll. Agents receive updates as soon as Postgres commits.
MCP over HTTPS with persistent connections
Agents maintain long-lived HTTPS connections. Tool calls are JSON-RPC POSTs. No connection setup overhead per request.
The 12ms figure assumes:
- Agent and gateway in the same region
- Postgres commit latency under 5ms
- ElectricSQL WAL propagation under 5ms
- Network RTT under 2ms
This is best-case. Cross-region latency adds 50-200ms. Postgres under load can spike to 20-50ms.
Connection Handshake
Agents connect by sending a standard MCP tools/list request:
curl -X POST https://memorify.dev/mcp \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $MEMORIFY_AGENT_TOKEN" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/list",
"params": {}
}'The gateway responds with available tools:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"tools": [
{
"name": "identity_verify",
"description": "Verify agent identity and retrieve profile"
},
{
"name": "memory_store",
"description": "Store conversation context"
},
{
"name": "vector_search",
"description": "Semantic search across indexed documents"
}
]
}
}Once connected, agents call tools via tools/call with the same Bearer token. The gateway handles OAuth refresh, vector embedding, and state writes.
State Conflict Resolution
When multiple agents update the same context simultaneously, the gateway uses last-write-wins at the Postgres level. No distributed locking. No CRDTs.
This works for most agent workflows because:
- Agents typically operate on different slices of context (different files, different conversations)
- Tool calls are atomic (OAuth refresh, vector insert, memory append)
- Conflicts are rare in practice
When conflicts do occur, the last committed write wins. If Agent A and Agent B both update the same memory entry, whichever commit reaches Postgres second overwrites the first. ElectricSQL propagates the final state to all agents.
For workflows that need stronger consistency (collaborative editing, shared task queues), this model breaks. You need optimistic locking or a coordination layer.
Failure Modes
| Failure | Impact | Mitigation |
|---|---|---|
| Gateway down | All agents lose tools | Deploy multiple gateway instances behind a load balancer |
| Postgres down | No state reads or writes | Use Neon’s HA setup, accept downtime during failover |
| ElectricSQL sync lag | Agents see stale state | Expose sync lag metric, retry on conflict |
| Bearer token leak | Unauthorized tool access | Rotate tokens, scope per agent, audit logs |
| Cross-region latency | Sync time jumps to 100ms+ | Deploy regional gateways, accept eventual consistency |
The gateway is a single point of failure. If it goes down, agents cannot call tools. If Postgres goes down, the gateway cannot serve requests. If ElectricSQL lags, agents see stale context.
For production use, you need:
- Multiple gateway instances
- Postgres replication
- Sync lag monitoring
- Token rotation policies
Observability Hooks
The gateway exposes:
- Sync latency: Time from Postgres commit to ElectricSQL delivery
- Tool call duration: Per-tool execution time
- Token usage: OAuth refresh rate, embedding API calls
- Conflict rate: How often last-write-wins triggers
These metrics surface in the agent dashboard. You can see which tools are slow, which agents are out of sync, and where conflicts occur.
For debugging context drift, the gateway logs every state transition: tool call, Postgres write, ElectricSQL propagation. You can replay the event stream to see why an agent has stale data.
When to Use This Pattern
This architecture makes sense when:
- You run multiple agents across different frameworks (Cursor, terminal, browser)
- You need shared memory and tool access without per-agent configuration
- You can tolerate last-write-wins conflict resolution
- You operate in a single region or accept cross-region latency
It does not make sense when:
- You need strong consistency (use a coordination service like Zookeeper)
- You run agents in air-gapped environments (no central gateway)
- You have sub-10ms latency requirements (use local state)
- You need custom conflict resolution (implement CRDTs or operational transforms)
Technical Verdict
The 12ms sync claim is real but fragile. It depends on low Postgres latency, fast ElectricSQL propagation, and regional proximity. Cross-region deployments will see 50-200ms. Postgres under load will spike to 20-50ms.
The architecture is simple: Postgres as the source of truth, ElectricSQL for replication, MCP for the agent interface. This eliminates the N×M connection problem and gives agents a shared memory layer.
The trade-off is a single point of failure and last-write-wins conflicts. For most agent workflows, this is acceptable. For collaborative editing or shared task queues, you need stronger consistency.
Use this pattern when you want to unify agent tooling across frameworks without building custom SDKs. Avoid it when you need strong consistency or sub-10ms latency guarantees.