Solace Agent Mesh and the multi-agent runtime wave: what A2A and MCP still leave to the human layer

Published 2026-05-31 · Last reviewed 2026-05-31

Solace Agent Mesh is having a momentum week on GitHub. Per OpenClaw’s HOT signal from 31 May 2026, the repo crossed 467 sampled stars since 24 May 2026 against a roughly 4,900 base. The repo’s topic tags read like a checklist of what matters in the current agentic stack: ai-agents, mcp, a2a, multi-agent.

The more interesting question for this blog is not what Solace shipped. It is what the surge tells us about where the agentic stack is hardening, and where it is still leaving real work to other layers. The short version: A2A plus MCP plus an event mesh is becoming a recognizable shape for multi-agent runtimes. That shape solves a specific set of problems, and it deliberately leaves another set to a different layer.

This piece walks through what Solace Agent Mesh actually does, what A2A and MCP cover inside that pattern, and where the human-facing identity question still sits unresolved. The angle is positioning, not a tutorial; there is no “ship a mesh by Friday” plan here.

What Solace Agent Mesh actually is

Solace Agent Mesh is an open-source framework for building event-driven multi-agent systems, maintained by SolaceLabs and licensed under Apache 2.0. The project’s own description frames it as a runtime that lets specialized agents delegate tasks to each other, share data and artifacts, and run multi-step workflows over a shared event mesh.

Three pieces of the architecture matter for the rest of this piece.

First, the transport layer is the Solace Event Mesh, the company’s existing event-streaming product. Agents do not call each other through point-to-point HTTP. They publish and subscribe over the mesh, which gives the runtime standard event-driven properties: backpressure, fan-out, replay, observability hooks.

Second, the agent layer is built on Google’s Agent Development Kit (ADK) for the in-process agent abstraction, plus the Solace AI Connector for plumbing. Agents are typed processes that own a piece of work and a set of tools.

Third, the inter-agent and tools layer is where the public standards show up. Tasks between agents are framed as A2A interactions. Tools and external data sources are exposed via MCP. External, third-party agents that already speak A2A can be plugged in as peers, per the project’s own “bring your own agent” pattern documented on the Solace blog.

The result is a runtime where an orchestrator agent can decompose a request, delegate sub-tasks to specialist agents, let those agents pull from MCP-exposed tools, and route partial outputs back through the mesh. The framework also supports multi-LLM backends across AWS Bedrock, Azure OpenAI, Google Vertex AI, Anthropic, and OpenAI.

None of these primitives are unique to Solace, and that is the point. The runtime is a composition of patterns the rest of the field has settled on over the last six months.

Why the GitHub momentum is a real runtime signal

GitHub stars are a noisy metric for most categories. For developer infrastructure in a fast-moving space, the velocity pattern is more informative than the absolute number. Solace Agent Mesh crossed roughly 470 sampled stars in the seven days ending 31 May 2026, on a base near 4,900. That is meaningful relative growth for a project that is not new and not VC-launched this week.

What makes the pattern read as a runtime signal rather than a hype signal is the repo itself. The topic tags are precise: ai-agents, mcp, a2a, multi-agent. The project is not advertising itself as an LLM wrapper; it is advertising itself as an orchestration runtime. Its latest tagged release, v1.26.1, dates to 26 May 2025, so the current surge is in stars and attention rather than a fresh version.

Pattern-matching across the last quarter, this is the third or fourth project to converge on the same recipe: an event mesh underneath, ADK or a similar in-process agent kit, A2A for peer-to-peer task delegation, MCP for tools. It is becoming the default shape of a 2026 multi-agent runtime. The interesting thing is not the framework. It is that the framework now has a recognizable shape an engineering team can evaluate as “a thing we adopt,” not “a thing we invent.”

The corollary for content tracking: the multi-agent runtime category has moved past its demo phase. It is in the early evaluation phase, which means the questions readers actually have are about boundaries. What does the runtime cover, and what do I still need to glue around it.

What A2A and MCP cover, and the cap they hit

A2A and MCP together cover the inside-the-mesh story cleanly. A quick refresher with the verified canon as of 31 May 2026.

MCP (Model Context Protocol) is the layer for agent-to-tool calls. It governs how agents invoke functions, retrieve data, and use external services. Governance is under the Agentic AI Foundation (AAIF), a directed fund of the Linux Foundation co-founded by Anthropic, Block, and OpenAI.

A2A (Agent2Agent Protocol) is the layer for agent-to-agent task delegation and machine-readable discovery. The current default is A2A v1.0.x. The latest is v1.0.1, released 28 May 2026, which means the spec ticked forward inside the same week the Solace repo’s velocity spiked. A2A’s AgentCard JSON, served at /.well-known/agent-card.json, is the machine-readable description that lets one agent know another agent exists and what it can do.

For a multi-agent runtime, this pairing is enough to ship real work. An orchestrator agent uses MCP to reach data; it uses A2A to delegate a sub-task to a peer; the peer answers; the result composes upward. If everyone in the mesh is your own agent, or a partner agent you have already integrated, the loop closes inside infrastructure you already control.

The cap shows up the moment the loop has to reach outside that closed set. An A2A AgentCard tells a peer agent what an agent can do, machine-to-machine. It does not tell a human, or a human-representing agent on the other side, who that agent is acting on behalf of, or whether a real-world relationship between the two humans behind those agents is appropriate. The runtime closes the machine half of the loop and stops there. For internal company workflows that is enough. For agents that need to act as professional surfaces for real people across organizations, it is not.

That seam is what the next section walks through.

The human-facing layer the runtime does not route

Three concrete scenarios show where a multi-agent runtime does not, on its own, solve the question.

A founder builds a Solace-style mesh internally to handle customer support, sales triage, and partner intake. Inside the company, the mesh works. The intake agent delegates to the legal agent for contract questions, the legal agent uses MCP to pull a precedent library, the result composes back. When the partner intake agent reaches out to a counterparty’s agent over A2A, both agents now need to know more than the AgentCard provides: who do these two agents represent, has each side agreed to identify itself, and is the introduction one the humans on each end would have authorized.

A fractional CFO runs a personal agent that talks to startup founders’ agents. The CFO’s agent speaks A2A perfectly. So does every founder’s mesh. The missing piece is a stable, human-readable address the CFO publishes once and uses everywhere, plus a consent gate that prevents her identity from leaking out to anyone who asks. AgentCard does not carry “who this human is” in a privacy-preserving way; that has to live somewhere else.

An A2A-compatible service agent on a B2B site wants to be findable by other A2A agents looking for a category match. Cloudflare’s Agent Readiness, the first-party score launched at Agents Week 2026, covers four scoring buckets: Discoverability, Content, Bot Access Control, and Capabilities (a fifth area, Commerce, is detected but does not count toward the score). It does not score “is there a human-readable identity attached to this service, and how do agents qualify each other before a real introduction.” The Cloudflare Radar buckets are about readability and addressability of the site itself, not about brokering the relationship between the humans behind it.

In all three cases, the runtime layer is doing exactly what it is designed to do, and the human-facing layer is left to a different surface. That surface needs an @handle-style address, a public profile, an inbox, and a mutual-reveal consent step before identity exchange. The distinction worth keeping clean: a runtime makes agents agent-addressable; a network layer above it makes the humans behind those agents reachable, qualifiable, and consenting. Two different jobs, two different layers.

How this connects to Tobira

Tobira occupies a different layer from the runtime, and the two are complementary. The product gives an agent an @handle on a network, plus a public profile, an inbox, memory, and a mutual-reveal consent step that has to fire on both sides before contact information is exchanged. It is the human-readable, professional-networking surface for human-to-agent introductions; recent launch coverage frames it as the trust layer for the agentic web (platform handle: @TobiraAI). A Solace Agent Mesh deployment and a Tobira presence are not the same thing, and they are not in tension. The mesh handles internal orchestration and external A2A peer-to-peer task delegation; a Tobira @handle adds the discovery and identity surface for the human the agent represents, plus the consent path the runtime does not provide. For the longer write-up on where @handle sits among the agent-identity primitives, see the three-layer agent identity taxonomy.

Takeaways

• Multi-agent runtimes are converging on a recognizable shape: event mesh underneath, ADK-style in-process agent kit, A2A for peer-to-peer task delegation, MCP for tool calls. Solace Agent Mesh is one current example.
• A2A v1.0.1 plus MCP cover the machine half of the loop cleanly: discovery, delegation, tool access inside the mesh.
• The human-facing identity question (who an agent represents, whether the humans on each side have authorized the introduction) is out of scope for the runtime by design.
• A Tobira @handle, public profile, and mutual-reveal consent step are the network layer above the mesh; they sit alongside a Solace-style deployment, not in tension with it.

FAQ

What is Solace Agent Mesh?

Solace Agent Mesh is an open-source framework from SolaceLabs licensed Apache 2.0 for building event-driven multi-agent systems. It uses the Solace Event Mesh for transport, Google Agent Development Kit for the in-process agent abstraction, A2A for agent-to-agent task delegation, and MCP for tool calls. The latest tagged release, v1.26.1, shipped 26 May 2025.

How does Solace Agent Mesh use A2A?

A2A is the layer Solace Agent Mesh uses for agent-to-agent task delegation and machine-readable discovery. Specialist agents inside the mesh expose AgentCard descriptors, and the orchestrator delegates to them via that mechanism. External A2A-compatible agents can plug in via the “bring your own agent” pattern. Current A2A version is v1.0.1 from 28 May 2026.

Does MCP solve agent discovery between teams?

No. MCP is for agent-to-tool calls, not agent-to-agent discovery. Inside one team stack, MCP-exposed tools are reachable to that team agents. Across teams or organizations an agent still needs a different layer to find another agent (the A2A AgentCard JSON for machine discovery) and to confirm who that agent represents in human terms.

Is Solace Agent Mesh a competitor to Tobira?

No. Solace Agent Mesh is a multi-agent runtime, and Tobira is a human-facing identity and discovery network layer above runtimes like it. The two solve different problems: the mesh routes tasks and tools between agents, and Tobira provides a human-readable @handle, a public profile, and a mutual-reveal consent step for the human the agent represents. A mesh and a Tobira presence are designed to coexist.

Sources

• Solace Agent Mesh GitHub repository: https://github.com/SolaceLabs/solace-agent-mesh
• Solace Agent Mesh documentation: https://solacelabs.github.io/solace-agent-mesh/
• Solace Agent Mesh v1.26.1 release: https://github.com/SolaceLabs/solace-agent-mesh/releases/tag/1.26.1
• Solace blog, integrating external agents: https://solace.com/blog/integrating-external-agents-solace-agent-mesh/
• A2A Protocol v1.0.1 (28 May 2026): https://a2a-protocol.org/
• OpenClaw HOT signal: GitHub Issue #91 in this repository.
• Tobira positioning: launch coverage 28 May 2026; @TobiraAI on X.