Three announcements this week point to a recurring problem in modern infrastructure: how to control systems that are inherently distributed, elastic, and agent-driven. Citrix, AWS, and Cloudflare each published details about how they manage scale, isolation, and consistency in environments where the old boundary of a single server no longer applies. The solutions are different, but the underlying pattern is the same.
The Citrix announcement is about governing AI agent traffic. The ProGlove case study is about isolating serverless tenants at scale. The Cloudflare Meerkat service is about distributed consensus without leader elections. Each of these is a specific answer to a specific problem. None of them is a silver bullet. But together they show where infrastructure engineering is headed in 2026.
Citrix NetScaler MCP Gateway: one control plane for agent and LLM traffic
Citrix added MCP Gateway to NetScaler. MCP, or Model Context Protocol, is becoming a standard way for AI agents to connect to enterprise applications. The problem Citrix is solving is that organizations adopting MCP end up with multiple servers, inconsistent access controls, and no visibility into what agents are doing. NetScaler MCP Gateway gives them a single entry point that handles authentication, rate limiting, and session persistence for agent traffic.
What makes this interesting is not the gateway itself. API gateways are not new. What is new is the combination of MCP governance and LLM governance on the same platform. NetScaler AI Gateway already handled model routing and token-level usage tracking for LLM traffic. Now MCP Gateway extends that to the agent layer. From a single dashboard, teams can enforce per-user tokens, OAuth flows, tool-based rate limiting, and server allow/block lists. They can also route chat requests to different models based on policy.
Citrix is running this internally for its own AI assistant, Citrix Aidrien. That matters because it means the same governance that customers get is already handling production traffic at scale. NetScaler's single-pass architecture does traffic management, authentication, security inspection, rate limiting, and observability in one pass through the data path. That is important for AI workloads because performance is sensitive to additional hops. Chaining separate proxies adds latency at exactly the wrong point.
The use case Citrix highlighted in private tech preview is Claude Code. NetScaler AI Gateway sits in front of Claude Code, acting as a single control point for developers accessing Anthropic models through a service provider. The benefit is that administrators do not have to enforce identity twice. They get centralized authentication and provider-agnostic routing for thousands of developers.
For regulated industries, this is non-negotiable. Financial services, healthcare, and public sector need auditable access controls for agents that touch sensitive systems. The MCP Gateway gives them a governed entry point without forcing teams to manage fragmented endpoints.
ProGlove: one million Lambda functions, one account per tenant
ProGlove makes industrial wearables for warehouse scanners. They run a SaaS platform that needs strict tenant isolation. Their solution is one AWS account per customer. That gives each tenant a hard security boundary, separate service quotas, and clean cost reporting. The downside is operational overhead. Each account needs identity configuration, networking, service quotas, logging, alarms, and deployment state.
ProGlove automated account creation using AWS Organizations, Step Functions, and CloudFormation StackSets. They pushed StackSet throughput limits to deploy changes across thousands of accounts. Each tenant account runs five to 15 Lambda functions, coordinated by Step Functions. Scanner events enter the tenant environment, data lands in DynamoDB, and business events go to a shared EventBridge bus for analytics.
The interesting part is what happens when you multiply this pattern across thousands of accounts. A small design inside one tenant becomes a control-plane problem across the fleet. ProGlove had to address synchronized workloads that triggered Lambda functions across many accounts at the same time. They replaced fixed schedules with jittered windows and event-driven triggers.
Observability created another cost problem. One million Lambda functions can produce a large bill even when each function emits a small stream. ProGlove cut idle spend by consolidating high-priority failures into a central dead-letter queue and removing unused SQS queues. AWS said they brought idle cost below $1 per month per account.
That cost detail is worth repeating. Serverless pricing often lures teams with the promise of zero idle compute. But logs, queues, metrics, alarms, and deployment artifacts can remain even when compute usage stops. A true scale-to-zero design has to include observability and integration resources, not just Lambda execution.
The account-per-tenant model adds real operational work. Step Functions can coordinate account creation and StackSet rollouts, but StackSets move at a different pace than single-account deployments. A change that lands fast in one account can take longer when fanned out across thousands. Teams that adopt this model need rollout windows, failure handling, and clear rules for partial deployment.
ProGlove's architecture shows that serverless scale requires control-plane design as much as data-plane capacity. Many teams focus on function concurrency and database throughput. Account-per-tenant SaaS adds another layer: create accounts, apply guardrails, roll out templates, manage quotas, detect drift. The automation reduces the burden but does not remove the need for governance.
Cloudflare Meerkat: consensus without leader elections
Cloudflare introduced Meerkat, a consensus service that helps its internal services read and modify control-plane state from across more than 330 data centers. Meerkat uses a consensus algorithm called QuePaxa, which does not require a single authoritative leader.
Most consensus algorithms (like Raft or Paxos) elect a leader. When the leader fails, the system runs an election. During that election, writes may be unavailable. Cloudflare calls this the tyranny of timeouts. QuePaxa avoids leader elections entirely. All replicas can perform writes continuously as long as a majority remains functioning.
Cloudflare ran proofs of concept with up to 50 globally distributed replicas. They repeatedly failed leaders and the cluster continued operating without an increase in error rate. The tradeoff is latency. Consensus algorithms require round-trips between replicas. If multiple replicas make proposals at the same time, it can take more. Proposal decision latency is proportional to the latency between some majority of replicas. So geographically distributed replicas will have higher latency. There is no way around that.
Cloudflare is clear that Meerkat is not in production and will remain internal. It is also not designed for general-purpose databases. It is a consensus service for specific control-plane needs where availability during failures matters more than absolute latency.
The naming is a bit silly, but the engineering is not. Cloudflare has attacked the leader election problem before with other approaches. Meerkat is another attempt to reduce the failure modes that plague distributed systems. Whether the latency cost is acceptable depends on the use case.
Practical takeaways
All three announcements share a common theme: control and isolation at a layer that used to be simple. AI agents need gateways because they hit multiple backends. Serverless tenants need account boundaries because isolation at the application level is not enough. Distributed consensus needs leaderless algorithms because leader elections cause availability gaps in a global network.
The Citrix approach is interesting because it combines two governance problems into one platform. That matters for organizations that are deploying both LLMs and agents. If you already have NetScaler, the new capabilities are included in existing licenses. That removes a cost barrier. For regulated industries, this is a concrete path to auditable AI traffic.
The ProGlove case study is a model for any SaaS platform that needs strong tenant isolation. The one-account-per-tenant pattern is expensive in terms of operational overhead, but it solves security, quota, and cost attribution problems cleanly. The key insight is to automate account creation before manual work becomes a bottleneck. Also, treat observability costs as a first-class design constraint. If you do not plan for idle resource costs, they will surprise you.
Cloudflare's Meerkat is not ready for production use outside of Cloudflare, but the algorithm choice is worth watching. QuePaxa is not new, but its application to a large-scale global network is. The elimination of leader elections removes one class of failure mode. The latency tradeoff is real and may limit the use cases, but for control-plane state that needs availability over speed, it is a viable option.
I am most interested in the Citrix announcement because it addresses a real problem that is only going to grow. AI agents will talk to many tools. Giving those agents a single governed entry point is better than letting them connect directly to every backend. The MCP Gateway approach is pragmatic. It does not try to reinvent security. It applies existing identity and access control patterns to a new traffic type.
The ProGlove case study is a reminder that serverless is not free. The operational cost of managing thousands of accounts is real. The automation exists, but you have to build it. If you skip that step, you will hit a wall at a few hundred tenants.
Cloudflare's Meerkat is a research project that may become a product. For now, it is a demonstration that leaderless consensus can work at scale. That is useful for the rest of us to know, even if we cannot use it yet.
The common thread: as systems get more distributed, the control plane becomes the bottleneck. Whether you are routing agent traffic, isolating tenants, or maintaining consistent state across data centers, the hard work is in the orchestration layer. The application code is the easy part.