Solace Agent Mesh: Agentic AI on an Event Mesh, Explained

Solace Agent Mesh is Solace’s platform for building and running AI agents on top of an event broker. Solace’s documentation calls it “an agent development and runtime platform” that hosts the agents you build, runs the tools they call, and coordinates everything over an event mesh. Instead of agents calling each other directly over HTTP, every task, delegation and result travels as a message on a broker topic. That is the same publish and subscribe model Solace has sold for two decades, applied to software that reasons with a large language model.

The product changed faster than most readers’ mental model of it. It started as open-source Python in January 2025, gained a commercial Enterprise edition in December 2025, a managed cloud service in early access in April 2026, and was rebuilt in Go in September 2026, when the Python repository was archived. This page explains what Solace Agent Mesh is as of October 2026, how it works, what it means for a plant, how it compares, and what is still unclear. For the company and the rest of the portfolio, start at the Solace hub.

What Solace Agent Mesh is

It is an agent runtime, not a model and not a chatbot. You bring the large language model (Solace says “use any model, any cloud”), and Agent Mesh supplies everything around it: the entrypoints people and systems use to ask for work, the executor that runs each agent’s reasoning loop, a sandbox for the tools agents call, session and file storage, access control, evaluations and observability. Agents are defined as configuration, so adding one does not mean deploying another service.

It is also Solace’s main new product. Solace now describes itself as “the real-time data and agentic AI platform for enterprises”, and Agent Mesh is the agentic half of that sentence. The product page frames the lifecycle as build, test, deploy, observe and improve, with human-in-the-loop approvals, RBAC, audit and token spend tracking by agent, model and task.

Solace Agent Mesh history: four versions in 21 months

Date	Milestone	What it changed
January 2025	Open-source Python framework on GitHub, Apache-2.0	Built on the Solace AI Connector and Google’s Agent Development Kit, with an orchestrator agent, gateways and plugins
17 July 2025	Listed in the AWS Marketplace “AI Agents and Tools” category (Solace)	A procurement route through AWS
2 December 2025	Agent Mesh Enterprise GA at AWS re:Invent (Solace)	No-code and pro-code agent builder, SQL, API and MCP connectors, web chat, Slack and Teams gateways, SSO and RBAC, LLM cost management. The open-source edition was named Community
28 April 2026	Agent Mesh Cloud Service, Early Access (Solace)	A managed offering “by invitation or request”
May to June 2026	Workflows, OpenTelemetry observability, evaluations (what’s new)	Structured workflows next to free-form agents, and test tooling
September 2026	Rebuilt in Go (Solace), free desktop app, Python repository archived	Three event-driven workloads, agents as configuration, a single binary on the desktop and three pods on Kubernetes

Read the table as a warning as much as a timeline. Anything written about Agent Mesh before September 2026, including blog posts, tutorials and comparisons, describes an architecture that no longer ships. The Python repository now says the code is “no longer under active development and won’t receive new features, bug fixes or security updates”.

How Solace Agent Mesh works: agents on an event broker

The Go runtime splits the work into three processes that never call each other directly. The architecture overview is explicit: “the Entrypoint Executor does not call the Agent-Workflow Executor over HTTP; the Agent-Workflow Executor does not call the Secure Tool Runtime over HTTP; peer agents do not call each other over HTTP.” Everything goes through the broker.

The three workloads are the Entrypoint Executor (the trust edge, which authenticates every request), the Agent-Workflow Executor (which holds the LLM credentials and runs the reasoning loop for many agents) and the Secure Tool Runtime (which runs each tool in its own sandbox so “a misbehaving or malicious tool cannot reach Agent-Workflow Executor memory”). Solace’s announcement calls the first one the Entrypoint Runtime; the docs call it the Entrypoint Executor. The detail, including sessions, artifacts and deployment shapes, is on Solace Agent Mesh architecture and agents.

Agents find each other by publishing a card. Each agent announces its name, skills and model on a discovery topic, so the runtime can route a task to whichever agent can do it. The protocol on the wire is an A2A-based JSON-RPC 2.0 dialect, and MCP connects agents to outside tools. Both are covered on Solace Agent Mesh MCP and A2A.

Why put AI agents on an event broker at all

Most agent frameworks connect agents with direct HTTP calls. That works on a laptop and gets brittle at scale for the same reasons point-to-point integration always did: the caller must know where the callee lives, both must be up at the same time, and every new consumer means another connection to wire and secure.

An event broker changes three things. First, decoupling: an agent publishes a request to a topic and does not need to know which process, pod or site will pick it up. Second, asynchrony: long-running tasks and streaming status updates fit naturally, and nothing blocks while a model thinks. Third, fan-in from the business itself: an agent can be triggered by a real event, such as a downtime record or a quality hold, not only by a person typing in a chat box. Solace’s argument is that agents need “continuously updated context” and that a broker is the natural way to deliver it. The argument is credible, and it is also what a broker vendor would say.

The counterpoint is complexity. An event-driven agent system has more moving parts than a script that calls an API. If you already run Solace for integration, the broker is sunk cost and Agent Mesh reuses it. If you do not, you are adopting an event broker and an agent platform at the same time. The event mesh page explains what the broker layer brings on its own.

What Solace Agent Mesh means for a plant

The public manufacturing reference is narrow but real. Solace states that Apex Lubrication runs Agent Mesh inside its OmniView conveyor-monitoring platform with Mighty Lube, using on-premises LLMs and routing results to ERP and CMMS systems (Solace, 1 June 2026). That is a monitoring and advisory use: agents read condition data, write reports and raise work, and people act.

That is also where agents belong in a plant today. Consider an illustrative case. A packaging plant already publishes line states and downtime reasons to a broker. An agent subscribes to unplanned stops longer than ten minutes, pulls the last shift’s alarms and the asset’s maintenance history through tools, drafts a probable-cause summary, and posts it to the maintenance team’s channel with a proposed work order that a planner approves. Nothing in that loop writes to a controller. In ISA-95 terms the agent lives at level 3 and 4, next to MES and CMMS, and the control layer stays deterministic.

Data location matters more than features. Agent Mesh runs self-hosted or on Solace Cloud, and works with any LLM, including on-premises models, which is what Apex reports. For plants whose production data may not leave the site, that combination is the deciding question. Our article on keeping manufacturing data local sets out the trade-offs, and the Solace manufacturing page covers where Solace sits above plant MQTT brokers. If the plant events are not on a broker yet, an agent has nothing to subscribe to, and that integration work is the real first step; it is the core of IT/OT integration.

Solace Agent Mesh compared with Confluent Intelligence and Redpanda

Every streaming and messaging vendor now has an agentic story. The three below are the closest comparisons, described from each vendor’s own announcements.

Dimension	Solace Agent Mesh	Confluent Intelligence	Redpanda Agentic Data Plane
Announced	Open source Jan 2025; Enterprise GA Dec 2025; Go runtime Sep 2026	29 Oct 2025 (Confluent)	28 Oct 2025 (Redpanda)
Core idea	An agent runtime: hosts agents, routes tasks, runs tools	Serve real-time context to AI apps, and run agents inside stream processing	Govern and observe agent access to enterprise data
Underlying platform	Solace event broker	Kafka and Flink on Confluent Cloud (IBM-owned since March 2026)	Redpanda (Kafka API), Redpanda Connect, Oxla SQL
MCP	Tools via MCP servers; agents exposed to MCP clients	Real-Time Context Engine serves context over MCP; MCP support in Streaming Agents	Supported
A2A	A2A-based protocol on broker topics, plus a proxy for HTTPS A2A agents	Not stated in the launch announcement	Supported
Status at launch	Enterprise GA; cloud in early access	Streaming Agents in open preview; Context Engine in early access	Available on Redpanda Cloud and BYOC; some governance features scheduled for 2026
Where it fits	Many agents coordinating, triggered by events, across sites	Teams already on Kafka and Flink that need fresh, governed context for AI	Teams on Redpanda that need agent data access control

No winner is declared here, because they solve different halves of the problem. Agent Mesh is closest to an agent orchestration framework that happens to use a broker. Confluent’s approach centres on stream processing and context serving. Redpanda’s centres on governed data access. An enterprise on Confluent could still run Agent Mesh for orchestration, and the Solace alternatives page covers the broker-level comparison. Status lines are as announced in October 2025; check each vendor’s current availability before a decision.

Limits and open questions

• The architecture is one month old. The Go runtime shipped in September 2026. Production references for it, as opposed to the Python framework, are not yet public.
• The open-source path closed. The Apache-2.0 Python repository was archived in September 2026, with its last PyPI release, 1.28.8, on 28 August 2026. As of 9 October 2026 we found no public repository for the Go runtime in the SolaceLabs or SolaceProducts organisations.
• No public Enterprise or Cloud pricing. Solace publishes the free tier terms (individuals and companies under US$25M revenue) and nothing above them. See editions and licensing.
• The Cloud Service is early access. It was opened “by invitation or request” in April 2026; general availability had not been announced as of October 2026.
• The A2A dialect is Solace’s own carriage. The docs describe “a JSON-RPC 2.0 dialect carried over event broker topics” and do not state which version of the Linux Foundation A2A specification it tracks.
• Factory-floor agents are early everywhere. This is not specific to Solace, but maturity claims across the agentic market deserve caution.

How to evaluate Solace Agent Mesh

• Which use case, and does it need agents at all, or would a rule or a workflow do?
• Are the events the agents need already on a broker? If not, cost that integration first.
• Which LLM, where does it run, and what data leaves the site?
• Is our evaluation on the Go runtime, not on Python-era tutorials or demos?
• Does our revenue put us under the US$25M free threshold, and do we have that in writing?
• What does Enterprise or Cloud cost at our expected agent count and token volume?
• Which tools may agents call, who approves new ones, and how are MCP servers allow-listed?
• What does human-in-the-loop look like for any action that changes a system of record?
• How are evaluations run before an agent change goes live, and who owns them?

Deeper

• Solace Agent Mesh architecture and agents: the three workloads, how a request flows, agents as configuration, and event-driven versus request-driven agents
• Solace Agent Mesh MCP and A2A: the two protocols, where each standard now lives, and how Agent Mesh uses both
• Solace Agent Mesh editions and licensing: the free tier, Enterprise, Cloud, the licence terms and what happened to open source

Back to the Solace hub, or across to Event Portal, whose MCP server lets AI assistants read the event catalogue that agents depend on.