Every IT Agent Program Needs a Streaming Agent. A2A Connects Them.

Stéphane Derosiaux November 10, 2026 8 min read

Ask about this post

On the left, a loose cloud of small wireframe cubes drifts in disorder toward a large wireframe cube lit from inside by a soft lime glow. From the cube's right face, three parallel lanes run to the right edge, each led by a small cube and a short row of tiles, with packets streaming along them on a dark teal starfield.

Ask about this post

Should you care about A2A? I discussed it recently with an industry analyst, who described agent-to-agent as still embryonic. I think we'll soon see more enterprise adoption. Most platform teams I talk to are already part of a company-wide AI agent program. It just takes time to organize and implement properly. Once a company runs dozens of agents, no single agent can hold every tool, and they'll start handing work to each other. That's why I'd design for it now.

In two years, MCP became the default way to connect an AI assistant to a system. You start with one MCP server, then two, then twenty in no time.

Then enterprise governance kicks in: how do you identify and control MCP?

Each MCP tool is an intent: an action, a description, a schema. An agent with hundreds of MCP tools is the one deciding whether to use them or not. Companies solved this for people long ago: nobody works with a hundred direct reports. Agents will be organized the same way:

Left, the shape MCP grows into by default. Right, the shape companies already use for people.

A2A is the protocol that lets one agent pass a request to another. For a company that runs its business on Kafka, a streaming agent will be critical to help general IT agents do their job. To be useful, it connects to every cluster, on every provider, and knows every resource and who owns it.

An MCP tool is an intent

Say a Kafka MCP server exposes a tool to reset a consumer group's offsets. By default, the agent knows very little about it: a name, a short description and a schema:

{
  "name": "reset_consumer_group_offsets",
  "description": "Reset the committed offsets of a consumer group on a topic",
  "inputSchema": {
    "type": "object",
    "properties": {
      "group": { "type": "string" },
      "topic": { "type": "string" },
      "offset": { "type": "integer" }
    },
    "required": ["group", "topic", "offset"]
  }
}

When the agent calls it, the server checks the caller's permissions, then calls the Kafka Admin API to reset the offsets. The MCP spec makes MCP tools "model-controlled", with "a human in the loop with the ability to deny tool invocations." But in the end, the model decides what to call and how:

The tool definition defines	The agent has to find out
A name and a description	Whether the consumer is stuck, slow or rebalancing
The parameters	Which offset skips the bad record and nothing else
Permissions	Whether the skipped records can be replayed
Optional hints such as "destructive"	Who has to agree before it runs

Depending on the server, access is granted tool by tool: this agent may call reset_consumer_group_offsets, that one may not.

You could write finer rules, such as "only when the consumer is stuck on a record it can't read, and once the team that owns it agrees." Even with a gateway that supports such policies, only a Kafka expert can write them.

🚫 "Once the gateway filters tools per agent, we're covered."

An AI gateway only decides which tools an agent may call.

An incident agent allowed to reset offsets can move a consumer it knows nothing about, on clusters whose owners never designed its access.

Nobody works with a hundred direct reports

An organization chart limits three things for each person. Agents need the same three limits:

For a person	For an agent
What they keep in mind: one area, a handful of systems	A small set of tools for one domain
What they're responsible for: a mission they can finish	A task it can complete and answer for
Who answers for a decision: the owner of that area	Its own identity, permissions and audit trail

A head of engineering doesn't review every pull request. They ask the team that owns the service, and the team answers for the result. An agent with every tool in the company works the other way: it can do anything, and when it breaks something, no team is responsible.

Agents try to pick the best tool. Anthropic's documentation says selection "degrades once you exceed 30–50 available tools", and that loading tools on demand keeps it accurate "even across thousands of tools."

Unfortunately, everything those tools return stays with the agent: every consumer group it has listed, every offset it has checked and every record it has read fills its context window and can degrade its reasoning.

When a general IT agent hands the Kafka question to a dedicated streaming agent, the work happens in the streaming agent's own context. If it reads a hundred offsets, it sends back one sentence to the agent that asked.

Say payments slow down during the day. The SRE team's incident agent asks each domain agent what changed, gathers the evidence and reasons across it:

Each agent answers for its own systems. The incident agent puts the answers together.

Only the streaming agent's answer explains the incident, and the incident agent got it without touching Kafka:

Goes back to the incident agent	Stays with the streaming agent
`payments-sync` stuck since 09:12 on a record written by v4.2	The record itself, read only under the platform team's rules
A proposed fix: send the record to a dead-letter topic and move the group past it	Credentials for each cluster
Links to the evidence	The Kafka tools and the judgement to use them

Platform teams already want one place to ask, and Kafka is only one of the domains behind it:

"I need a Kafka topic, a file transfer, an MQ queue. Just ask for it in a prompt."
Middleware platform lead at an airline

A2A standardizes the hand-off between agents

A2A lets one agent ask another to do work. It now sits next to MCP in the Linux Foundation's Agentic AI Foundation, funded by AWS, Anthropic, Google, Microsoft and OpenAI, which says a lot about where adoption is heading. The spec defines three pieces:

What a streaming agent publishes, and what a caller sends it. Values are illustrative.

MCP connects an agent to its tools and data. A2A connects agents to each other:

A2A between agents. Each agent reaches its own systems through its own MCP tools.

A2A is useful when different teams own different domains

Delegating doesn't always call for A2A. A higher-level MCP tool or a sub-agent is often enough:

Situation	What fits
One team owns the caller and the domain	A higher-level MCP tool, such as a `diagnose_consumer_group` that returns a finding
One team owns both, and the work needs its own reasoning and context	A sub-agent in the same runtime
Another team owns the domain, tools, and their credentials	A separate agent, called over A2A

The streaming agent usually needs A2A: the platform team owns the clusters, and the agents calling it belong to other teams.

Since June 2026, AWS DevOps Agent accepts third-party sub-agents "via A2A" and can itself be called "via A2A or MCP protocols."

Every company that runs Kafka needs one streaming agent

Everyone thinks of the technical questions first, like fixing a stuck consumer or a rebalancing group. But most questions an IT agent asks about Kafka are about process, people, and teams:

Kafka stores the topic. Everything an IT agent asks around it lives somewhere else.

Kafka doesn't store any of this, and a Kafka admin API can't answer it. In the payments incident, the incident agent also needs to know that payments-sync belongs to the payments team and who to reach there, that the stuck record holds card data it shouldn't read, and that the payments team has to approve the skip and its consequences.

A streaming agent is useful mostly for these questions, and they're the ones Conduktor answers: federated ownership, data lineage and access control across every cluster.

A company's Kafka also runs on several providers: MSK for one team, Confluent Cloud for another, a self-managed cluster for the oldest workloads. One streaming agent is the entry point for all of them, with access scoped per cluster and per caller.

Give each domain its own agent

Two things you can do now, whatever A2A becomes:

Give every agent its own identity. On a person's token or a shared admin account, the audit log can't tell the agent's actions from the person's.
Grant actions one at a time. Start read-only. Restarting a failed connector can run on its own long before resetting a production consumer group can (how to grade each action).

Companies check every person's rights action by action, and still never give one person every right. They split the work by team, and each team answers for its part. AI agents will be split the same way, and every company that runs Kafka will need one agent in charge of streaming.

That's the role Conduktor takes. Console already connects to every Kafka cluster you run, whatever the provider, with ownership, schemas, lineage and audit in one place.

Conduktor's agents run on your own LLM provider, with their owner's rights narrowed to the tools each task needs, checked on every call. A proposed fix waits in the owner's approval inbox. Your IT agents reach the same tools through Console's MCP server, under the same identity, RBAC and audit. When they need an answer about Kafka, Conduktor is the agent they ask.