Solace Agent Mesh Architecture: Entrypoints, Executors and Agents

Solace Agent Mesh architecture answers one design question: how do you run many AI agents, their tools and their users’ sessions so that each piece can scale, fail and be secured on its own? Solace’s answer, after the Go rewrite of September 2026, is three separate workloads that never call each other directly. An Entrypoint Executor takes requests in, an Agent-Workflow Executor runs the agents, a Secure Tool Runtime runs their tools, and a Solace event broker carries every message between them. This page explains each part as of October 2026, how a request flows, and where the design gets hard.

It belongs to the Solace Agent Mesh overview in the Solace cluster.

The three workloads in the Solace Agent Mesh architecture

The architecture overview describes three workload classes plus a control plane:

Workload	What it does	How it scales	Trust position
Entrypoint Executor	Terminates web chat, Slack, Teams, email, MCP and event mesh inputs; authenticates the user (OIDC), attaches a session, publishes the task	Single replica on Kubernetes, because sessions need affinity	The only workload facing untrusted input
Agent-Workflow Executor	Loads agent configurations, runs the LLM loop, dispatches tool calls, executes workflows	Horizontally, stateless, many agents per process	Holds LLM credentials and reasoning state; reachable only through the broker
Secure Tool Runtime	Runs Python scripts and Go binaries as sandboxed subprocesses	Horizontally	Isolated so a bad tool “cannot reach Agent-Workflow Executor memory or the session”
Platform Service	Manages agents, deployments, RBAC and audit over HTTP APIs	Separate from the request path	Control plane

Why split it three ways? Because each part fails differently. The entrypoint faces the internet or the corporate network, so it is where identity is checked and where an attacker arrives first. The executor holds the LLM API keys and every agent’s reasoning state, so it should be reachable by nothing except the broker. The tool runtime runs code that someone other than Solace wrote, sometimes code an LLM chose to call with arguments it generated, so it is the part most likely to misbehave. Putting those three concerns in one process, as many agent frameworks do, means a bad tool can read the keys. Solace’s design applies the same thinking a plant applies to zones and conduits: separate what you trust differently, and make every crossing explicit.

Two stores sit beside them. Sessions (conversation history and checkpoints) live in SQLite, PostgreSQL or memory, and are owned by the entrypoint. Artifacts (documents, images, datasets) live in a filesystem, S3, Google Cloud Storage, Azure Blob or memory, and all three workloads can read and write them.

How a request flows through the Solace Agent Mesh architecture

In words, using the topic names from Solace’s A2A protocol page:

1. The entrypoint publishes. A user asks a question in Teams. The entrypoint checks identity and scopes, signs a per-task token carrying them, and publishes a message/stream request to <namespace>/a2a/v1/agent/request/<agentName>.
2. An executor picks it up. Whichever Agent-Workflow Executor hosts that agent receives the message and starts the reasoning loop. The agent verifies the token’s signature instead of running its own RBAC.
3. Tools run in the sandbox. Each tool call is executed by the Secure Tool Runtime. If the result is large, Smart Context Management stores it as an artifact, and the model gets “a reference, a schema, and the tools to operate on it” (Solace).
4. Agents delegate. If the task needs another skill, the agent sends a subtask to a peer it learned about from the discovery/agentcards topic.
5. Results stream back. Status updates move through submitted, working and a final state, and the entrypoint relays them to the user.

Agents are configuration, not code

This is the biggest change from the Python framework. In the Go runtime, Solace says “a single executor commonly runs dozens of agents, bound only by available CPU”. An agent is a definition: a model, instructions and a list of tools. Adding an agent is a configuration change, not a new deployment, which matters when a team wants twenty narrow agents rather than one general one.

Logic lives in tools. The tools documentation lists five kinds: built-in tools, MCP tools, remote Python or Go tools built with Solace’s tool SDKs, OpenAPI tools generated from a specification, and SQL tools for PostgreSQL, MySQL, SQLite, SQL Server and Oracle. Remote tools declare a timeout and run under an isolation mode; bwrap is the production choice on Linux, and direct is for development only.

Event-driven versus request-driven agents

A request-driven agent waits to be asked. Someone types a question; the agent answers. Most agent products work this way, and Agent Mesh supports it through chat, API and MCP entrypoints.

An event-driven agent is started by something that happened. Agent Mesh lists the event mesh as an entrypoint, so a business event, such as a quality hold published by MES or a downtime record, can start a task with no human in the chat. That is the pattern a broker vendor is best placed to offer, and the one with most value in a plant, because events arrive whether or not anyone is watching. It also needs most care: an agent that fires on every event needs filters, rate limits and an owner. Topic design decides what an agent can subscribe to, which is why Solace topics and wildcards is worth reading before building one.

Deployment shapes

Shape	What runs	Fit
Desktop app	One process with an in-memory broker and the UI	Evaluation and building only
Distributed	Separate processes per workload, joined by a real Solace broker	Testing the production topology
Kubernetes	A Helm chart, one pod per workload, external PostgreSQL and object storage	Solace’s recommended production shape

Two container images ship on separate version cycles: one for the entrypoint, executor and Platform Service, and a heavier one for the tool runtime, which bundles LibreOffice, FFmpeg and ImageMagick. Self-hosted and Solace Cloud options are compared on editions and licensing.

What changed from the Python architecture

The archived Python framework combined the Solace AI Connector, Google’s Agent Development Kit and A2A, with an orchestrator agent that broke tasks down, gateways for REST, web and Slack, and plugins. The Go runtime keeps the broker-centred idea but renames gateways as entrypoints and moves task routing into the runtime. Whether a distinct orchestrator agent survives in the Go version is not clear from the public docs as of October 2026, so ask.

Where it gets hard

• The broker is a hard dependency. Every hop crosses it. Size, monitor and make it highly available like any production broker; see Solace high availability.
• The entrypoint is a single replica on Kubernetes. Ask how failover and session recovery behave.
• Agent sprawl. Agents are cheap to add, so they multiply. Without naming, ownership and review, nobody knows which agent touched what.
• Tool permissions are the real security boundary. Access to an agent implies access to its built-in tools. Scope custom tools with required_scopes and keep write tools rare.
• Network placement. An executor that reaches plant systems must cross the plant’s zones and conduits. That design belongs in an OT network assessment.

---

Related: Solace Agent Mesh overview · Solace Agent Mesh MCP and A2A · Solace event mesh · Solace hub