Coder Legion - Recent posts tagged aigateway

CData's New AI Gateway Puts Context at the Center — Fixes the Three Reasons Enterprise AI Stalls

Tue, 29 Sep 2026 00:06:14 +0000

Most enterprise AI programs are stuck. Not because the models are bad, but because the underlying infrastructure can't keep up. Costs are climbing, productivity gains are flat, and organizations are locking down access rather than expanding it because they don't have the governance controls they need to feel comfortable.

CData Software has been watching this pattern play out across hundreds of enterprise deployments over the past year. On September 29, the company is announcing what it sees as the fix: CData Connect AI Gateway, a single control point between AI agents and the enterprise systems they need to act on.

Three Problems. One Control Point.

Marie Forshaw, CData's SVP of Product Marketing, laid out the three challenges clearly during a pre-launch briefing. They're likely familiar to anyone who's been building or deploying AI in an enterprise context.

The first is rising costs. AI budgets are burning through faster than organizations can justify. Without fine-grained visibility into who's using what model for what task, finance teams are doing the only thing they can: shutting things down.

The second is stagnant productivity. Some of that is the lockdown. But Forshaw pointed to two other contributing factors: ongoing accuracy and reliability issues with AI responses, and a near-total freeze on write operations. Most organizations have enabled read use cases — querying data, summarizing it, surfacing it. Very few have enabled AI agents to actually take action. The risk is too high, and the controls aren't there.

The third is governance. This is where the developer-versus-leadership tension gets real. Forshaw made the point directly: developers may not care much about centralized control, but CTOs and CIOs absolutely do. And without their sign-off, AI projects don't scale.

Connect AI Gateway is designed to address all three from one place.

What the Gateway Actually Does

The platform has four layers. Two of them — data connectivity and security controls — are existing CData capabilities. The two new layers are the gateway itself and a context engine, and they're where most of the interesting development is happening.

The Gateway Layer handles model routing, MCP traffic, and agent orchestration. It registers models, MCP servers, and agents once, then routes requests based on availability, cost, and latency. Intent-based routing is part of this — the system reads the complexity of a prompt and sends simpler requests to cheaper models automatically. Token budgets can be set at the team, agent, or tool level, giving organizations real cost visibility and control rather than a blunt shutdown switch.

The Context Engine is the more distinctive part of the announcement. CData's argument is that most gateway providers are just routing traffic between models and MCP servers. Because CData owns the connection all the way down to the source system, it can build up and apply business context at every step of a request — and that's what separates useful AI from AI that keeps getting things wrong.

The context engine pulls from four sources: company knowledge (documented processes, SOPs, Slack and Teams conversations), semantic definitions (imported from Power BI, BigQuery, dbt, or built natively in the platform), system context (schema, relationships, and field meanings from connected source systems), and data modeling (cross-source joins and derived views that calculate answers before they reach the model).

Everything gets normalized into Open Knowledge Format and visualized as a context graph that administrators can edit and extend.

The Self-Learning Loop

One of the more forward-looking pieces of this announcement is a self-learning capability CData is calling the self-learning loop. The idea is that every interaction makes the system smarter — prompt patterns become vocabulary, query patterns become join hints, user-level corrections get written back to the knowledge bundle, and facts that multiple users share get promoted to company-wide knowledge.

This capability is pre-beta at announcement. No customers are in production with it yet, so there's no empirical data on how long the improvement curve takes in practice. CData acknowledges that directly. The honest answer is: we'll know more in six months.

Organizations will have control over what gets promoted from personal to shared knowledge. Everything can require human approval before it becomes part of the company context, or you can set specific categories to promote automatically. That configurability matters for teams with compliance requirements.

The Numbers: Accuracy and Cost

CData's accuracy benchmarking from earlier this year showed Connect AI at 98.5% accuracy across 378 enterprise queries, compared to 65–75% for competing MCP providers. That gap matters more as AI moves from read to write operations — a 70% accuracy rate on an agent that's taking action in your ERP is not a productivity tool. It's a liability.

The newer study, published just before this briefing, tested 22 models against live enterprise data — with and without Connect AI's data layer configured. With it, every model answered correctly. Without it, every model made mistakes. The cost spread between the cheapest model tested (Mistral Small) and the most expensive (Claude Fable 5.1) was 175x.

Jared Johnson, CData's Director of Technology Evangelism, explained the mechanism clearly. When you ask an AI to list your five healthiest customers, it has no idea what "healthy" means in your context. You can put that definition in the system prompt, but that doesn't guarantee it gets honored. When you build that definition into a derived view inside Connect AI, the model can't get it wrong — because it doesn't have access to the raw fields. It only gets the calculated answer. The model isn't doing the reasoning. CData is.

That's the architecture. And it's why the same cheap model can deliver the same correct answer as one that costs 175 times more.

Developer Setup: Minutes to Hours

Adobe cut regression test delivery from ten weeks of manual effort to roughly one week by connecting to SAP through Connect AI and running a test automation agent. For developers wondering what setup actually looks like: basic authentication to a source system can be done in minutes. A working agent with governed access typically takes hours to a day. From there, it's an iterative process — start with minimal configuration, dial in derived views and custom tools over time as the workflow becomes clearer.

The path from 70% to 98.5% accuracy isn't a configuration switch. It's a development process. But the starting point is lower-friction than building your own MCP server stack.

The Honest Case for Switching

For development teams already running their own MCP servers, the question is fair: why hand that off to a managed platform? Johnson's answer was practical — it can seem cheaper and faster to manage your own servers when you're working on one system. The complexity compounds when you're trying to manage MCP access across multiple systems with different security models, different permission structures, and different teams using different tools.

What CData is offering is the centralized governance layer that makes it possible to turn on write operations without giving a CIO a reason to shut the whole program down. That may matter less to individual developers in the short run. It matters a lot to the people deciding whether to renew the AI budget.

Bottom Line

CData Connect AI Gateway enters an increasingly crowded market. Several AI gateway announcements have come out in the past few months, and CData is not the only company making the data-layer argument. But the company has a legitimate differentiator in owning the source system connection — not just the routing layer above it — and the cost study is a concrete illustration of what that unlocks.

The self-learning context engine is the most interesting long-term bet in this announcement, and also the one with the least evidence behind it yet. Worth watching as customer data comes in.

Connect AI Gateway is available through an early access program beginning September 29, 2026. More information at cdata.com.

NGINX Is Already in Front of Your AI Workloads. F5 Says That's the Point.

Fri, 13 Mar 2026 02:16:08 +0000

When enterprises start deploying AI workloads, they typically go looking for a dedicated AI gateway. F5 thinks that's the wrong instinct — and they have a straightforward argument for why.

About 50% of NGINX deployments already sit in front of Kubernetes clusters. When AI workloads land in those same clusters, NGINX is already there. It's already trusted. It's already in the traffic path. The question F5 is answering with its NGINX AI gateway strategy isn't "how do we build something new?" It's "why would you add something when what you need is already running?"

Shawn Wormke, SVP of Product Management at F5, put it plainly during AppWorld 2026 in Las Vegas: "It doesn't require people to change. And I think that's the biggest differentiator."

That's the bet. And for developer and platform teams who have spent years standardizing on NGINX, it's worth understanding what that actually means in practice.

What MCP Traffic Is Revealing

One of the more significant things coming out of F5's NGINX work isn't a feature — it's what visibility into MCP traffic is showing enterprises about their own environments.

MCP, the Model Context Protocol, is the emerging standard for how AI agents communicate with tools, APIs, and data sources. When NGINX parses MCP metadata, it gives operations teams a view into AI activity that most enterprises didn't know they were missing.

What they're finding is that more AI is already running than anyone realized. More sensitive data is being accessed. More shadow AI is operating in the background. The visibility problem turns out to be bigger than the security problem — and you can't address the second until you've solved the first.

For platform teams, this is a meaningful shift. The same proxy that handles your web traffic can now surface what your AI agents are actually doing, who they're talking to, and what data they're touching. No new tooling required. No rearchitecting the stack.

NGINX MCP visibility is now generally available in NGINX Open Source. Enterprise support is available through NGINX Plus.

The AI Gateway Argument

The case for a separate AI gateway usually goes something like this: AI traffic is different, AI models need specialized routing, and purpose-built tools handle it better than general-purpose infrastructure.

F5's counter-argument is operational. A dedicated AI gateway means another tool to deploy, another vendor to manage, another configuration surface to maintain, and another potential point of failure between your users and your models. If NGINX is already handling traffic management, TLS termination, and load balancing for the applications sitting next to your AI workloads, adding a separate gateway layer creates complexity without adding capability.

The argument gets sharper when you look at where enterprises actually are in their AI deployments. Wormke was direct about this at AppWorld: the narrative about enterprise AI adoption doesn't always match reality. "If you read everything on the internet about AI, you think all of these customers are doing all this stuff. But the reality is, some are. A lot of enterprises are just trying to figure it out."

For the majority of organizations still in early deployment stages, the last thing they need is infrastructure sprawl. NGINX as an AI gateway works because it's already there.

What NGINX Handles in the AI Traffic Path

Within F5's ADSP platform, NGINX addresses several specific problems in the AI traffic path.

Routing and load balancing for AI model endpoints works the same way it works for any application — with the addition of LLM-specific routing logic that can direct requests based on model type, token budget, or other AI-specific parameters.

Rate limiting and quota enforcement matter more with AI workloads than with traditional applications because token costs are real and variable. NGINX can enforce limits at the gateway layer before requests ever reach the model.

Observability via MCP parsing gives teams visibility into agent behavior — what actions agents are taking, what tools they're calling, and what data they're accessing. This is genuinely new capability. Traditional application observability doesn't capture the semantic content of AI interactions. MCP visibility does.

Security controls apply the same WAF and bot defense capabilities that already protect your web applications to AI traffic — including protection against prompt injection and model abuse.

The Rollout Sequence

F5 is sequencing the NGINX AI gateway capabilities based on where they see the most immediate customer pain. Automated certificate management is first — operationally unglamorous, but a real friction point for teams managing certificates across large NGINX deployments. AI-specific capabilities build on top of that foundation.

The broader NGINX roadmap runs through 2026 and into 2027 as part of F5's ADSP platform expansion. BIG-IP got F5 Insight first. NGINX and Distributed Cloud follow as the platform matures.

For developer and platform teams already running NGINX, the practical implication is straightforward: the infrastructure you have is being extended to handle AI workloads without requiring you to replace it or work around it. That's a different kind of product story than most of what gets announced at conferences. It's not about adding something new. It's about making what you already trust more capable.

And in a period when most engineering teams are already managing more complexity than they'd like, that distinction matters.