At Ai4 in Las Vegas, I attended a session titled “Is Orchestration the Future?” by Arick Goomanovsky, CEO of BAND, as part of the conference’s Infrastructure: AI Agents track.
The session description nicely captured where the industry seems to be heading: from standalone LLMs handling individual tasks, through orchestrated agentic workflows, toward fully autonomous distributed networks where agents independently reason, delegate and collaborate across organizational boundaries.
That sounds like the natural next step for agentic AI.
It also creates a very different class of engineering problems.
The demo during the session was playful: one agent asked other specialist agents for help, they exchanged information, and together they worked toward a result.
But the interesting part was not the demo. It was the problem hidden behind it.
As soon as you use several agents, the human can easily become the integration layer: copying context between agents, checking one agent’s work with another, restarting tasks, and trying to remember what each agent is doing. Goomanovsky described exactly this pattern in software development: one agent creates a plan, another reviews it, perhaps another writes or reviews code—and the developer ends up manually coordinating the conversation.
That does not scale.
One of the most useful distinctions from the session was simple:
Communication is not collaboration.
Giving two agents a way to send messages to each other does not mean they can reliably execute a business process together.
The protocol layer is finally taking shape
This is where the emerging communication protocols matter.
MCP — the Model Context Protocol — has become an important standard for connecting AI applications to tools, data sources and services.
Conceptually, MCP solves something similar to what standardized peripheral interfaces did for computers: instead of every agent requiring custom integration code for every system, tools can expose capabilities through a common protocol.
MCP was initially mostly about agent-to-tool interaction rather than collaboration between autonomous agents. But it has continued to evolve. The July 2026 specification introduced a stateless protocol core, Multi Round-Trip Requests and an extension mechanism for durable Tasks—features that make MCP increasingly relevant to long-running agentic workflows. (Model Context Protocol)
For communication between independent agents, A2A — Agent2Agent — addresses the problem more directly.
Originally developed by Google and subsequently moved under Linux Foundation governance, A2A defines concepts such as Agent Cards for discovery, Tasks, Messages, Artifacts, streaming and asynchronous notifications. (A2A Protocol)
The distinction is useful:
MCP helps an agent use capabilities. A2A helps agents collaborate with other agents.
The protocols are therefore more complementary than competitive. (A2A Protocol)
There are also signs that the standards landscape is consolidating. IBM’s Agent Communication Protocol, ACP, for example, has been merged into A2A rather than developing into another competing ecosystem. (IBM)
That reduces one interoperability problem.
But interoperability is only the first layer.
Welcome back to distributed systems
The moment agents start operating independently, orchestration becomes a distributed-systems problem.
Interestingly, that was also explicit in Goomanovsky’s talk. The session touched on message delivery, message ordering, recovering an agent after a crash and restoring the state of an existing conversation.
None of these are new problems.
Software engineers have been fighting them for decades.
AI adds another complication: not only can the network or infrastructure behave unexpectedly—the participant itself is probabilistic.
Consider a simple example.
Agent A asks Agent B:
“Execute this transaction.”
B performs the action, but the response gets lost.
A waits.
Eventually it times out.
What should it do?
If it retries, has the transaction now happened once—or twice?
For a weather lookup, this hardly matters.
For “send €50,000,” “cancel the insurance policy,” or “email the customer,” it matters enormously.
Classic distributed systems use patterns such as idempotent operations, unique request identifiers, durable messaging, acknowledgements, retries with exponential backoff, timeouts and circuit breakers to deal with exactly these situations.
Agent architectures will need the same engineering discipline.
Your context window is not a transaction log
State is another fundamental problem.
Imagine an agent executing a workflow consisting of twenty steps. It completes twelve and then crashes.
When another instance takes over, what happens?
Simply replaying the original prompt is dangerous. Some actions may already have happened.
A production system needs to know:
which task is being executed,
which steps have completed,
which external actions have occurred,
what results were returned,
which approvals were granted,
and what remains to be done.
That information needs to exist independently of the model.
An LLM context window is not a durable workflow store.
This is one reason I would be cautious about architectures based entirely on autonomous peer-to-peer conversations between agents.
They look elegant in demonstrations. But the more autonomous the network becomes, the harder it becomes to reconstruct causality when something goes wrong.
For enterprise applications, a hybrid architecture may often be more practical.
Agents can still reason and act autonomously, while a durable orchestration layer owns workflow state, task dependencies, permissions, retries and completion criteria.
In other words, decentralize intelligence without necessarily decentralizing control.
Orchestration also means observability
There is another challenge from the session that I think deserves more attention: once many agents work autonomously, how do you actually know what they are doing?
The transcript describes the problem from a developer perspective. Several agents can continue working while the developer is doing something else. When the developer returns, it becomes difficult to understand where each agent is, what it has done and how much resource it has consumed.
Multiply that by a thousand employees.
Now it becomes an enterprise-management problem.
Agentic platforms therefore need something resembling distributed tracing.
Every business request should ideally carry a correlation or trace ID through the communication chain, from the user over AI agents down to the business system.
That allows the enterprise to answer questions such as:
What happened?
Why did it happen?
Which agent made the decision?
Which model was used?
Which tools were called?
How many retries occurred?
How much did the process cost?
And where did it fail?
OpenTelemetry has already started defining GenAI semantic conventions for tracing model calls, tool executions, token consumption and other AI operations.
This may sound like infrastructure plumbing.
But without it, diagnosing an agent system means reading conversations and hoping to reconstruct what happened.
That is roughly equivalent to debugging a distributed application by reading terminal output from several servers.
The protocol is not the architecture
MCP and A2A are important developments.
They reduce integration friction and make it increasingly realistic that an agent created on one platform can access tools—or cooperate with an agent—created somewhere else.
But protocols do not solve orchestration.
They do not decide which agent should be trusted with a task.
They do not determine who owns the business outcome.
They do not prevent duplicate transactions.
They do not stop two agents from entering an expensive reasoning loop.
They do not decide when a human has to intervene.
And they do not tell management why a swarm of agents consumed €20,000 worth of model tokens last Tuesday.
Those are architecture, operations and governance problems.
This is why the progression described in the Ai4 session—from standalone models to orchestrated workflows and eventually autonomous distributed agent networks—is so interesting.
With every step, we gain autonomy.
But we also inherit more of the complexity traditionally associated with distributed computing.
The first wave of agent development was largely about prompts, tools and reasoning.
The next wave will increasingly be about state machines, message semantics, identity, retries, observability, access control, cost management and recovery.
Which leads to a slightly paradoxical conclusion:
Making agents intelligent may turn out to be the easy part.
Making hundreds of intelligent agents work together reliably is where the real engineering starts.
Quite interesting how IBM is doing good development in this field. : )
Did Goomanovsky in his talk came up about different options and examples on how to use strict harnesses for each type of agent (orchestrator, implementer, reviewer etc.) ?