We were at Current 2026 in London last week. Between booth conversations and recorded interviews on the floor, here's what stood out.
First, IBM anyone?
Six months after IBM acquired Confluent for eleven billion dollars, we expected acquisition takes to dominate. They didn't. Here's what we did hear.
The doomers were vocal. A data engineering lead at a major US bank described himself as one. He named Kafka and Cassandra as his two favorite open source projects. Both are now part of IBM. He sighed.
"It's a shame because I do feel some of that community buzz goes away with an acquisition from IBM." — Data engineering lead at a major US bank
The optimists were quieter. A staff engineer at a streaming platform vendor had been at the Computer History Museum on a day off when the news broke, surrounded by old IBM hardware. Fitting!
"I keep hearing rumors they'll merge things together. The AI team at Confluent will work with the Watson team. It makes total sense." — Staff engineer at a streaming platform vendor
Most attendees did neither. "I try to concentrate on the tech side." "I don't know enough to comment." They moved on. The acquisition was in the air but rarely vocalized.
Kafka costs are on everyone's mind
In April we published an analysis of where Kafka costs come from, and bucketed the root causes into six structural patterns:
- Partition overprovisioning
- Retention mismatches
- Cluster proliferation
- Orphan and duplicate topics
- Inefficient client patterns
- Static capacity per resource
Practitioners at Current named all six.
Benjamin Franklin once said only two things in life are certain: death and taxes. He missed a third: Kafka infrastructure accumulation. Topics get created for experiments and never deleted. Clusters get stood up for individual teams and never consolidated. Partition counts get inherited from templates tuned for a different workload. Each one is defensible on its own. Together they are the third certainty.
Sometimes you don't even need an event-driven architecture in the first place.
"Kafka resource costs should not be taken for granted. Maybe I need sub-second or millisecond latency, or maybe daily is enough or hourly. These are considerations you must make up front, before it's too late." — Data engineer at a German energy consultancy
We spoke to people solving different problems across various industry verticals. We heard things like:
- Twenty MSK clusters running multi-region
- Six years of unmanaged topics inherited during a Confluent Cloud migration
- MSK, Confluent, and Red Panda running in parallel, looking for a single control plane
Running Kafka should not be this operationally expensive.
"I heard somebody earlier say we have deep pockets because we're using Confluent platform. I don't think that's the case." — Lead streaming data engineer at a major African bank
To get costs right, you must set guardrails at topic creation, retention defaults that reflect reality, and ownership at the source. We typically see 25 to 40 percent of infrastructure costs come back this way. You don't drastically reduce costs by changing the infrastructure. You do it by fundamentally changing how you use Kafka at scale.
We compiled all this in our field guide. For more on why platform teams cannot fix this alone, see Your Platform Team Can't Fix Kafka Costs Alone.
Discussions around Kafka costs are often focused on the past, when the focus should be on auditing the broken usage patterns driving the spend.
Self-service provisioning is the start. Federated ownership is the answer.
Self-service provisioning came up at almost every booth. Teams want developers to create topics, request permissions, and onboard use cases without filing a ticket. The platform teams want to provide it. Most are stuck on how.
A senior engineer at a Danish financial firm told us he was too busy managing tickets to work on the system that would have made the tickets unnecessary. An architect at a UK telecom said his organization had no self-service in place, and relied on Jira tickets. A senior developer at a UK bank told us her biggest frustration was waiting on the ticketing system while her platform team built custom tooling to compensate.
A CTO at a German consultancy gave us the broader pattern.
"Internal IT is the bottleneck. They don't manage to build all the requirements coming from business units." — CTO at a German tech consultancy
The teams that have self-service working got the operating model right first.
Self-service resource provisioning is a capability. Federated ownership is what produces it. The platform team sets standards and guardrails. Project teams operate within them with full autonomy. Authority and visibility on both sides.
Companies who try to build this in-house usually stop at provisioning. "We can create topics" is the easy part. The rest is the hard part: schema registry, Kafka Connect, public topic and data catalogs, and visibility into the development lifecycle and the messages actually flowing through the system.
This is a pattern we've been writing about for months. Practitioners kept echoing it back.
"The key thing for us is approval gates. Guardrails. If somebody goes onto the tool and adds in something ridiculous, like a thousand partitions, we need someone to have eyes on that. That's something we've learned we can't let go of." — Lead streaming data engineer at a major African bank
Self-service without federated ownership ends up as either a free-for-all the platform team cannot govern or a tightly controlled environment nobody uses. Either way the platform team is the bottleneck, and the cost patterns keep getting written.
The deeper layer: infrastructure ownership and data ownership are not the same thing. A team can know which cluster a topic lives on without knowing who owns the schema, who depends on the data, or who to call when something breaks. Federated ownership requires that those answers are clear and visible to the people who need them.
For our framework on federated ownership for Kafka, see our overview page.
Self-service is the capability. Federated ownership is what produces it.
You can do what with a proxy?!
Kafka proxies came up in more conversations than any other architectural topic at our booth. The interest is there. The education is not. Most practitioners still think a proxy does one thing.
We met one practitioner running a Kafka proxy in production at a European ISP. Legacy systems sent messages through the proxy on their way to the cluster. We asked whether the proxy did anything else, like encryption, masking, or transformation.
"We see a proxy as more of a routing tool." — Backend integration manager at a European ISP
He's not alone. The largest group of attendees thinks of a proxy as a bridge for legacy or non-native clients.
A second group has connected proxies to disaster recovery and provider migration. A third has connected proxies to security. This is where the most consequential conversation of the conference happened. An engineer at a UK building society told us his team had an encryption requirement for personally identifiable data. They built it in the application layer, as most do, and had not known that a proxy could handle it at the message level, which would have saved them hours of per-application encryption work. Plenty of teams are paying the same tax right now.
A fourth and smaller group has connected proxies to the full policy enforcement layer. The whole shebang! At our booth, a VP at a global bank walked us through his gateway requirements: topic aliasing for migration, schema and payload validation, virtual clusters for multi-tenant isolation, data transformation, field-level encryption and masking, and audit and policy enforcement without touching the broker or the client. That's not theory. That's one bank's checklist.
Proxies have sat outside event-driven thinking for years. In most people's heads they belong to the HTTP world. So Kafka practitioners, and end users especially, don't reach for one. We think they should. A proxy is where policy and control can live when they don't belong in the cluster or the application.
Our December piece on the IBM acquisition argued that proxy layers decouple applications from clusters, and that this matters more after the acquisition than before. The conversations at Current confirmed it.
For our overview of what a Kafka proxy actually does, see our gateway page.
What people think a proxy does is pass packets. What one actually does is hold the policy.
AI on Kafka is an ownership problem
Most keynotes pitched agentic AI: real-time context engines, streaming agents, and MCP integrations. The vendor floor was selling the future of agents on Kafka. Practitioners were talking about something else.
A staff engineer at a UK retailer was direct about it.
"Spinning up infrastructure and writing code is rarely the bottleneck in a full end-to-end business solution, so I'm hesitant around some of these fancy tools for now." — Staff engineer at a UK retailer
The agent demos compress the easy part of the workflow into the spotlight. The hard parts sit upstream.
We met a senior software engineer at a major social platform building on-call AI agents at scale. Her team has Kafka, real-time infrastructure, and extensive telemetry. None of that is the bottleneck.
"Building the AI agent isn't the difficult thing. The data needs to be in the right structure." — Senior software engineer at a major social platform
The bottleneck is data quality, which sits downstream of governance, which sits downstream of the operating model. A software engineer at a UK challenger bank gave us the concrete version. He had been trying to feed an AI agent enough context to reason about a system spanning around forty microservices.
"You have to give it the entire Java classes of all those microservices. That's a lot of context. That's usually when it starts hallucinating." — Software engineer at a UK challenger bank
The hallucination is a legibility problem. Nobody has exposed that architecture to the agent in a way it can reason about.
Every prerequisite practitioners named is something we have been writing about for months. Ownership, schema discipline, topic-level visibility, federated governance, and cost-conscious provisioning. The AI conversation runs through these, not around them. A streaming platform nobody can govern will not become a streaming platform agents can operate on. The plumbing has to come first.
Conduktor is not in the AI vendor business. We are in the business of making Kafka infrastructure legible enough that what runs on top of it has a chance of working. The teams that will run AI on Kafka in 2027 are the teams getting their ownership and governance right in 2026.
For our December piece on Kafka as the substrate for AI workloads, see the IBM acquisition post.
AI on Kafka is not a streaming problem. It is an ownership problem. The plumbing has to come first.