Back to Blog
· Kevin

IBM Just Paid $11 Billion to Prove the Data Layer Is the AI Agent Bottleneck

IBM closed its $11B Confluent acquisition to make real-time data the engine of enterprise AI agents. Oracle rebuilt its database for agents. Google shipped 42-database MCP tooling. Databricks reports 327% multi-agent growth. Big tech is spending billions solving a problem you can fix with a single binary.

ai-agentsdatabasemcpenterpriseibmconfluentinfrastructure

On March 17, 2026, IBM completed its $11 billion acquisition of Confluent. Not for Kafka. Not for event streaming. The press release said it plainly: to make real-time data “the engine of enterprise AI and agents.”

Eleven billion dollars. For a data pipe.

That same month, Oracle announced agentic AI innovations baked directly into its AI Database 26ai — including an “AI Agent Factory” that lets agents run queries on production data without moving it to a separate compute environment. Google quietly expanded its MCP Toolbox for Databases to support 42 data sources. And on March 31, a startup called Datris launched the first data platform built with MCP as its primary interface.

Every major vendor is converging on the same conclusion: the bottleneck for AI agents isn’t the model — it’s getting structured data in and out of databases.

The Numbers Tell the Story

The scale of this shift is hard to overstate. Databricks reported that multi-agent workflows on their platform grew 327% in under four months. Gartner tracked a 1,445% surge in enterprise inquiries about multi-agent systems from Q1 2024 to Q2 2025. MCP — the protocol that connects agents to tools and data — crossed 97 million SDK installs in March 2026.

These aren’t pilot numbers. These are adoption curves that look like the early days of cloud computing or containerization. And just like those waves, the infrastructure layer is where the real battle is happening.

Here’s the problem: every one of those agents needs to read from and write to a database. Not a vector store. Not a knowledge graph. A plain, relational database with tables, rows, and columns — the same PostgreSQL, MySQL, or SQL Server instances that have been running your business logic for years.

The Enterprise Approach: Spend Billions, Build Data Fabrics

IBM’s thesis is straightforward. They’re combining Confluent’s Kafka-based streaming platform with watsonx.data, IBM MQ, and their hybrid cloud stack to create what they call a “unified, governed data fabric.” The goal: eliminate the latency issues that hamper large-scale AI agent deployments.

It’s a reasonable approach if you’re a Fortune 500 company with 6,500 microservices, a dedicated platform engineering team, and a budget that starts with a B. You need real-time event streaming because your agents are coordinating across dozens of systems, each with its own data model and latency requirements.

Oracle’s approach is different but equally heavyweight. Their AI Database 26ai embeds agent capabilities directly in the database engine. The Autonomous AI Database MCP Server is a multi-tenant, built-in feature — no separate MCP infrastructure needed. Agents can explore multiple solution paths, request additional data during analysis, and iterate on queries autonomously.

Google’s MCP Toolbox for Databases takes the cloud-native route. It supports 42 data sources (if they’re on Google Cloud), handles connection pooling and IAM auth out of the box, integrates with Vertex AI Agent Engine, and ships with OpenTelemetry observability. It’s genuinely impressive engineering — locked inside Google’s ecosystem.

Each of these solutions solves a real problem. But they all share the same assumption: you need a significant infrastructure investment to connect AI agents to your data.

What If You Don’t?

Here’s the thing about that 327% growth in multi-agent systems: most of those systems aren’t running at IBM scale. They’re teams of 3-15 engineers building agents that need to query a PostgreSQL database with 50 tables, or a MySQL instance with customer data, or a SQL Server warehouse with inventory records.

These teams don’t need a data fabric. They don’t need a cloud-native MCP toolbox that requires Vertex AI Agent Engine. They don’t need to rebuild their database on Oracle 26ai.

They need their existing database to speak HTTP and MCP. That’s it.

This is the gap that keeps showing up in production deployments. Pinterest’s MCP ecosystem — the one saving 7,000 engineering hours a month — works because they built domain-specific MCP servers that wrap their existing data stores. They didn’t replace their databases. They put a protocol-aware API layer in front of them.

The pattern is universal: existing database → structured API layer → agent-ready endpoint. The question is how much infrastructure you need to make that happen.

The Single-Binary Approach

Faucet exists because we believe the answer is “almost none.”

Point Faucet at your database. Get a REST API and MCP server instantly. No cloud provider lock-in, no data fabric, no separate infrastructure to deploy and maintain.

# Install Faucet
curl -fsSL https://get.faucet.dev | sh

# Point it at your PostgreSQL database
faucet serve --db "postgres://user:pass@localhost:5432/mydb"

That’s it. Your database now has:

  • A full REST API with CRUD operations, filtering, pagination, and sorting for every table
  • An MCP server that AI agents can connect to directly
  • RBAC so you control which agents can read, write, or modify which tables
  • OpenAPI 3.1 documentation automatically generated from your schema

No Kafka. No event streaming. No cloud-specific SDKs. One binary, one command.

What This Looks Like in Practice

Say you’re building an agent that helps your support team look up customer orders. With the enterprise stack, you’re looking at:

  1. Set up a data streaming pipeline (Confluent/Kafka)
  2. Configure IAM roles and service accounts
  3. Deploy an MCP server (or configure your cloud provider’s managed one)
  4. Write custom tooling to map your schema to agent-readable endpoints
  5. Set up observability (OpenTelemetry, Grafana, etc.)
  6. Hope it all works in your staging environment before touching production

With Faucet:

faucet serve --db "postgres://readonly:pass@prod-replica:5432/orders"

Your agent can now query the orders table through either REST or MCP:

# REST: Get recent orders for a customer
curl "http://localhost:8080/api/orders?customer_id=eq.12345&_sort=-created_at&_limit=10"

# The MCP server is available at the same endpoint for agent frameworks

Need to restrict the agent to read-only access on specific tables? Faucet’s RBAC handles that:

roles:
  support_agent:
    tables:
      orders: [read]
      customers: [read]
      products: [read]
    # No access to billing, internal_notes, or admin tables

The agent gets exactly the data it needs, nothing it doesn’t, and you can see every query it runs through Faucet’s request logs.

Why the Data Layer Matters More Than the Model

IBM didn’t spend $11 billion on a model. Oracle didn’t rebuild its database to be a better LLM. Google didn’t expand MCP Toolbox because GPT-5 needed it.

They all invested in the data layer because that’s where agent deployments actually fail.

The MCP 2026 roadmap — published by the protocol’s maintainers in March — makes this explicit. The four priority areas are:

  1. Transport scalability — making MCP servers scale horizontally without holding state
  2. Task management — handling long-running jobs, retries, and result expiry
  3. Governance — streamlining the specification process
  4. Enterprise readiness — closing gaps in auth, observability, gateway patterns, and configuration portability

Notice what’s not on the list: model improvements, prompt engineering, or agent framework features. The protocol’s own maintainers agree — the infrastructure connecting agents to data is what needs work.

The Convergence Is Real

Let’s step back and look at what happened in a single month:

  • March 17: IBM closes $11B Confluent deal for AI agent data infrastructure
  • March 24: Oracle announces AI Database 26ai agentic innovations and Agent Factory
  • March 31: Datris launches open-source MCP-native data platform with 30+ tools
  • March 2026: MCP crosses 97 million SDK installs
  • March 2026: MCP 2026 roadmap published, focusing on enterprise readiness

And in the background: Databricks reports 327% multi-agent growth. Gartner reports 1,445% surge in multi-agent inquiries. Accenture and Databricks launch a joint business group specifically for AI agents on enterprise data.

This isn’t a trend. It’s an inflection point. The industry has collectively decided that connecting AI agents to databases is the most important infrastructure problem to solve in 2026.

Where This Goes

The companies spending billions are solving for the Fortune 500. They’re building data fabrics, managed MCP endpoints, and cloud-native agent platforms that make sense when you have 10,000 employees and a Chief Data Officer.

But the vast majority of AI agent deployments aren’t happening at that scale. They’re happening at startups with one PostgreSQL instance. At mid-size companies with a MySQL database and a SQL Server data warehouse. At teams that need their agent to query an order table, not orchestrate a data mesh across three cloud providers.

For those teams, the path from “database” to “agent-ready API” should take 30 seconds, not 30 sprints.

Multi-Database, Single Binary

One of the things the enterprise vendors don’t advertise is how painful it is to support multiple database types. Google’s MCP Toolbox supports 42 sources — but they’re Google Cloud sources. Oracle’s MCP server works with Oracle databases. IBM’s Confluent integration is optimized for their stack.

Faucet supports PostgreSQL, MySQL, SQL Server, SQLite, Oracle, and Snowflake out of the same binary. Same API shape, same MCP interface, same RBAC model, regardless of which database you’re running.

# PostgreSQL
faucet serve --db "postgres://user:pass@localhost/mydb"

# MySQL
faucet serve --db "mysql://user:pass@localhost/mydb"

# SQL Server
faucet serve --db "sqlserver://user:pass@localhost?database=mydb"

# SQLite (great for development and edge deployments)
faucet serve --db "sqlite:///path/to/data.db"

This matters because real companies don’t run one database. They run three. And their agents need to query all of them.

Getting Started

If your agents need database access and you don’t have $11 billion to spend, here’s how to start:

# Install Faucet (single binary, no dependencies)
curl -fsSL https://get.faucet.dev | sh

# Start serving your database as a REST API + MCP server
faucet serve --db "postgres://user:pass@localhost:5432/mydb"

# Your API is now live at http://localhost:8080
# Your MCP server is available for agent frameworks

Faucet is open source, deploys anywhere (your laptop, a VM, a container, the edge), and takes less time to set up than it took you to read this paragraph.

The big vendors are right that the data layer is the bottleneck. They’re just wrong about how much infrastructure you need to fix it.