Why a Plain MCP Gateway Isn't Enough Anymore
A plain MCP gateway is a real improvement, and we should start there. One endpoint instead of ten configs, credentials in a vault instead of scattered files, an audit trail instead of a shrug: if you run more than a couple of MCP servers, a gateway makes your setup better, full stop. If you have none, [get one](/blog/do-you-need-an-mcp-gateway), plain or not.
Here is the argument of this essay: the plain gateway solves the cheap problems and leaves the expensive one untouched. Your agent still wakes up every morning with amnesia, and the gateway, the one component that watched everything it did yesterday, does nothing about it.
The expensive problem is not routing
Look at where an agent-heavy team actually bleeds money. Not on misrouted calls; routing was never hard. The bleed is repetition. Every session, the agent re-establishes what it already knew: re-reads the project, re-fetches the records, re-asks about decisions that were settled weeks ago. Then the session ends, the knowledge evaporates, and tomorrow the meter runs again.
We have itemized [where the token bill comes from](/blog/where-your-llm-token-bill-comes-from): the two structural drivers are tool schemas loaded on every turn and context re-established every session. A plain gateway can help with the first. It does nothing about the second, and the second is the one that grows with how much your agents actually matter to your work.
Meanwhile the plain gateway processes every one of those repeated calls, bills them if it meters, and forgets them. It is a tollbooth with perfect eyesight and no notebook.
The gateway is the one component positioned to fix this
This is the design observation that we think decides the argument. Memory needs two things: to see what is worth keeping, and to be reachable when it is needed again.
The gateway has both, uniquely. It sees every tool call in structured form (the invoice ID coming back, the database name in the query, the decision the user dictated), across every client the agent runs in. And it is reachable from everywhere by construction, because it is the endpoint everything already connects to. Client-side memory is locked to one app. Framework memory is locked to agents you build. The gateway is the only place in the stack where memory automatically follows the protocol, and therefore follows you. The mechanics of that are laid out in [MCP gateway with memory](/blog/mcp-gateway-with-memory).
A stateless gateway occupies this exact position and uses it for routing only. That is not a small omission. It is the best seat in the house, used to watch.
"Stateless is a feature" and the other fair objections
The infrastructure argument: gateways should be stateless because stateless scales; state is for databases. True for the transport layer, and MCP v2's stateless-first design is right about it. But nobody argues an API gateway should not keep audit logs because logs are state. Memory is the same class of thing: state about the traffic, kept beside the pipe, not session stickiness inside it.
The trust argument: a gateway that remembers holds more of your data than one that forgets. Correct, and it deserves straight answers (where it lives, who reads it, export, deletion) rather than dismissal. Our answers are EU hosting, scoping, in-app export. Ask everyone the same questions and disqualify vague answers, ours included.
The maturity argument: routing and governance are proven; memory at the gateway is young. Also correct. We are in early beta and say so. But young is not the same as optional, and the market is already telling you which part is commodity: there are at least nine [open source gateways](/blog/open-source-mcp-gateways) that route and govern perfectly well, many free. When the plain version of a product is abundant and free, the plain version is not the product for long.
What to demand from any gateway going forward
Not our gateway. Any gateway. Add one question to the [twelve you should already ask](/blog/how-to-choose-an-mcp-gateway): what does this gateway do with what it sees?
- Can the agent store a decision today and recall it next week, from a different client?
- Does task state survive a session end or a compacted context?
- Is memory scoped per project and client, exportable, deletable?
- Are memory calls free, or does the meter punish the exact behavior that saves you money?
If the answer is "we are a pipe", that is a legitimate answer, priced accordingly, and the abundant free options above set that price. As of our July 2026 market check, every other gateway we verified is that pipe. We built [Tulimoa](/gateway) because we think the vantage point is too valuable to waste on watching, and the memory tools are free on every plan because charging for remember would be charging against your own savings.
A plain gateway organizes your agent's tools. A gateway that remembers organizes your agent's work. The first was worth building. The second is what the position was for.