What I saw at AI Engineer: collaborative AI is here. The architecture question isn't settled.

I spent last week at the AI Engineer World's Fair in SF - four days, 29 tracks, 300 speakers, and roughly 6,000 people at Moscone West. If the last two years were about making a single agent good, this year had a very different center of gravity: nobody's building lone agents anymore. Everyone's building AI that works together - with other agents, and with us.

You could see it across the whole floor:

• Context sharing - how agents pass state to each other without dumping full conversation histories into every prompt. Context engineering has gone from a talk title to a discipline: compaction, sub-agent context isolation, structured handoffs instead of "here's everything I know."

• Collaborative docs and shared workspaces - agents and humans editing the same artifact concurrently, with the interesting problems being conflict resolution and attribution, not the editing itself.

• Organizational knowledge - making what the company knows available to every agent, not just the one you happened to prompt. Vector stores were table stakes two years ago; now it's knowledge layers with access control and freshness guarantees.

• Distributed infra and virtualization - agents as workloads. Sandboxed execution, microVMs, agents spun up and torn down like containers, scheduled across clusters. The infra track felt more like KubeCon than an AI conference, and that's a compliment.

• And of course: orchestration and communication - the layer that decides who does what. Almost everything here is built on top of the protocols the industry has already converged on - MCP, A2A, ACP. Some of these systems handle execution, some let you define workflows. But watching the workflow-definition side, something felt incomplete. Like the stack is still missing a piece - another protocol, or something close to it.

That last category is where most of the energy - and most of the startups - landed. It's also where I think the industry is about to hit a wall, and where that missing piece comes in.

The orchestration graph problem

The default answer to "how do agents collaborate" today is an orchestration graph. Define nodes (agents), define edges (handoffs), define conditions (what and when to route where). Most of the popular frameworks make this explicit: your workflow literally is a graph. It works, and it demos beautifully.

The problem shows up at scale, and it's a math problem, not a tooling problem.

Take a support triage system. Version one: a router agent, a classifier, a retrieval agent, a resolver. Four nodes, a handful of edges. Clean.

Now product asks you to add a billing specialist. In a graph architecture, that's not one change - it's a change to the router's decision logic, new edges into and out of the billing node, updated fallback paths for when billing fails, and a regression pass on every flow the router touches, because the router's prompt just changed and prompts don't have type systems.

Add a compliance reviewer. Add a second team's agents. Add a "sometimes escalate to a human" path. Every agent you add can, in the worst case, need an edge to every existing agent - the wiring grows quadratically while the agents grow linearly. And unlike a compiler catching a broken import, a broken edge in an agent graph fails at runtime, probably in production, probably subtly.

Orchestration graph vs. mesh: edges grow quadratically with the graph, connections grow linearly with the mesh

We've seen this movie before in distributed systems. In the early microservices era, teams hardcoded service call graphs - service A knows service B's address, retries, and failure modes. It collapsed under its own maintenance weight, and the industry answered with service discovery and the service mesh: services announce themselves, the mesh handles routing, retries, and failover, and adding service #50 costs the same as adding service #5.

Agents are hitting the same inflection point. In a mesh architecture, agents join, advertise their capabilities, and discover each other at runtime. Adding the billing specialist means the billing agent registers "I handle billing disputes" - and that's it. No router rewrite, no edge audit, no redeploy of the graph. The size of the coordination problem stays constant while the number of agents, tasks, and flows keeps growing. That's the property that matters.

Workflows aren't deterministic, and pretending otherwise is expensive

The second issue is quieter but bigger.

Orchestration assumes you can know the workflow in advance. Agentic workloads violate that assumption constantly:

• Agents fail mid-task. Rate limits, context overflows, a model provider having a bad day.

• Better agents show up. You swap a research agent for one built on a different framework because it's faster or cheaper - a normal Tuesday in 2026.

• The path itself is decided at runtime. The whole point of using a reasoning model is that it picks the next step; a rigid graph fights the model's core capability.

In an orchestrated system, every one of these is a configuration change. An agent replacing another agent means someone updates the graph definition, adjusts the routing conditions, redeploys, and hopes nothing else breaks. The system's flexibility is capped by how fast a human can edit YAML.

In a mesh, replacement is a runtime event, not a deployment event. An agent drops out; another agent that advertises the same capability picks up the task, automatically and autonomously. The A2A project got this right at the protocol level with capability advertisement via Agent Cards: agents describe what they can do, and discovery happens dynamically. A mesh takes that idea and makes it the architecture, not just the wire format - capability-based routing, automatic failover, and agents built on different frameworks (or no framework at all) participating in the same fabric, because coordination lives in the mesh, not in any single agent's code.

The system routes around change instead of breaking on it. That's not a nice-to-have; for anything running in production with real SLAs, it's the difference between an incident and a non-event.

Agent failure handling: a deployment event in a graph, a runtime event in a mesh

Governance belongs in the fabric, not in every graph

There's a third argument that matters less to the demo and more to whoever signs off on production.

In an orchestrated system, governance is per-workflow. Every graph needs its own audit logging, its own policy checks, its own human-in-the-loop gates - implemented by whoever built that graph, in whatever way they chose. Multiply that by every team building workflows, and you get the same control implemented five different ways, drifting apart with every release. Ask "which agents touched customer data last week, and under whose authority?" and the answer is a forensics project.

In a mesh, every interaction crosses the fabric - so every interaction is governed and observable by construction. Identity, policy, and audit are properties of the mesh itself, defined once and enforced everywhere. New agent joins? It inherits the rules. New workflow emerges at runtime? Already covered, because the coverage was never attached to the workflow in the first place.

For enterprises, this is often the argument that actually decides things. Scaling pain is an engineering problem. Ungoverned agent-to-agent traffic is a compliance problem - and compliance problems are the ones with deadlines.

The vibe was right. The architecture question is open.

The industry converging on collaborative AI is the right instinct. Agents that share context, share organizational knowledge, and coordinate work is obviously where this goes - the conference floor made that undeniable.

But collaboration through a hand-drawn graph is collaboration that stops scaling the moment it succeeds. The lesson from every previous generation of distributed systems is the same: static wiring loses to dynamic discovery, every time, once the system gets big enough to matter.

That missing piece I felt on the expo floor? It isn't another workflow definition language. It's a mesh: coordination that stays simple as the system grows, adapts on its own when the system changes, and is governed by construction. That's what we're building at BAND.