MCPserver chain we've been duct-taping together since January. The pitch is clean: one gateway, one token, every agent gets the same toolset without rebooting. The ~12ms sync claim is real — we verified it against a local Neon instance with ElectricSQL replication. But the demo stops exactly where our problems start.
The handshake flow works as advertised. Register an agent, get a scoped Bearer token, hit /mcp
with tools/list
and you're live:
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":{}}'
Returns the registered toolset instantly. whoami
confirms identity and scopes. No argument there — onboarding friction is genuinely lower than our current claude_desktop_config.json
- per-IDE extension mess.
Hot-plugging MCP servers through the dashboard also works. Add a new server, agents see it on the next tools/list
call without restart. That alone would save us ~20 minutes per developer per week in context-switching overhead.
Where it gets murky:
Memory isolation. The /memory
verb namespace (remember, recall, update) assumes a single workspace per token. Our org runs multi-tenant workloads — same agent identity, different customer contexts. Memorify's scoping model doesn't natively partition memory by tenant without issuing separate tokens per context, which defeats the "one connection" promise.
Vector search at scale. /documents
uses pgvector under the hood. Our corpus is ~400k chunks across 12 repos. Cold-start recall latency jumped to 300-500ms once the index exceeded 100k vectors. The 12ms figure only holds for the MCP bus itself, not the semantic layer. We'd need a dedicated vector tier anyway.
OAuth connector maintenance. The gateway abstracts OAuth flows for GitHub, Linear, Notion, etc. Convenient until a provider rotates scopes or deprecates an endpoint. Now the gateway becomes a single point of failure for all agents simultaneously. Our current fragmented approach at least contains blast radius.
Verb protocol rigidity. The semantic verbs (/skills
, /mcp
, /documents
) are opinionated. We have custom tooling that doesn't map cleanly — think internal deploy CLI, feature flag service, cost attribution API. Extending the verb set requires gateway changes, not just agent-side config.
We're still running a pilot with two teams on low-risk workloads (documentation ingestion, PR summarization). For those, Memorify replaces ~300 lines of glue code per agent. But for our core autonomous workflows — the ones that actually touch production — the abstraction leaks too much.
If you're running a handful of agents against a single workspace with standard SaaS integrations, it's probably worth the trade-off. If you're doing multi-tenant, high-volume, or custom tooling, budget time to hit the walls we found.
Next Testing Three Agent Frameworks on A2A — What Broke and What →