Agent Mesh Terminology

Term	Definition
A2A	Agent-to-Agent (A2A) is the messaging protocol that agents use to communicate with each other over the event broker. Every message follows the same standard format, so any Agent Mesh component can understand messages from any other. The format is based on JSON-RPC 2.0. For more information, see Agent-to-Agent Protocol.
Agent	An agent is an AI worker that uses a large language model (LLM) to complete a task. It runs an LLM loop, in which the model decides which tools to call, and it can delegate parts of the task to peer agents. For a process whose steps are fixed in advance rather than chosen by a model, see Workflow, which is discovered and invoked like an agent. Agents are created in the Agent Mesh UI (Builder > Agent Management) or defined as YAML resources in declarative configuration. For more information, see What Is an Agent?
Agent card	An agent card is a description of an agent that tells other agents and entrypoints what the agent can do, so they can discover it and delegate to it. An agent publishes its card to the event broker when it starts, and publishes it again whenever its capabilities change. A card includes the agent's name, description, version, and the abilities and input and output formats it supports. In the Agent Mesh UI, you set the abilities and the input and output modes (text or files) when you create the agent. Entrypoints publish a similar entrypoint card. For more information, see Creating Agents.
Agent Mesh CLI	The Agent Mesh CLI is the command-line tool for managing an Agent Mesh deployment. You use it to apply configuration that is kept as YAML files (declarative configuration), send tasks to running agents, run evaluations, create and package tools and skills, sign in to the platform service, and check your environment before you start. The command is `sam`, so it is also called the sam CLI. The desktop bundle includes it. For more information, see CLI Reference.
Agent-Workflow Executor	The Agent-Workflow Executor is the process in which agents and workflows run. It loads agent configurations, runs each agent's LLM loop, dispatches tool calls, and runs workflows. Helm keys, pod names, and log fields abbreviate its name as `awe`. For more information, see How Agent Mesh Manages Workloads.
App	An app is one configured instance of an Agent Mesh component, such as a single agent or a single entrypoint. Each app is an entry in the `apps` list of a runtime configuration file, with a `name` and an `app_config` section that holds the app's own settings, such as its namespace. The component types are agents, entrypoints, Secure Tool Runtime workers, and the platform service. For more information, see Helm Values Reference.
Artifact	An artifact is a named, versioned file, such as a document, image, or data set, that an agent produces or consumes during a conversation. Artifacts are created by an agent's tools, by the agent from content it writes, or from files that users upload or attach, and they remain available after the tool call finishes, so later turns of the conversation can read them. Each change to an artifact creates a new version, and the previous versions remain readable. In the Agent Mesh UI, the artifacts for the current session appear in the Files tab. Artifacts can be stored on a filesystem, in S3, Google Cloud Storage (GCS), or Azure Blob Storage, or in memory. For more information, see Artifacts.
Artifact handling mode	Artifact handling mode is an agent setting, `artifact_handling_mode` in the agent's `app_config`, that controls what the language model sees about an artifact that one of the agent's tools creates. The conversation history is what the model reads on each turn. With `ignore` (the default), the artifact is saved but its content is not added to the history, and the agent can still load it when needed. With `reference`, the history includes a short reference to the artifact, and with `embed`, the history includes the artifact's content. For more information, see Artifacts.
Artifact scope	Artifact scope is a setting that controls whether the components in a deployment, such as agents and entrypoints, share one pool of artifacts or each keep their own. By default, all components in the same namespace share artifacts, so an artifact that one agent writes can be read by the other agents in that namespace, for example an orchestrator agent and the peer agents it delegates to. Alternatively, each component can keep its artifacts separate from every other component's. Separately, giving a filename the `user:` prefix makes that one artifact available across all of the same user's sessions. For more information, see Artifacts.
Compaction percentage	Compaction percentage is a history compaction setting that sets what fraction of the oldest conversation history is condensed into a summary. The default is `0.25`, so about 25% of the history is summarized and the rest is kept as is. It is one of an agent's `auto_summarization` settings, set with the `auto_summarization.compaction_percentage` key. The manual compaction API uses the inverse value, `targetPercent`, which is the percentage of the conversation to keep. For more information, see Sessions.
Correlation ID	A correlation ID is a unique identifier that matches a response to the request that prompted it. The agent generates one for every tool call or peer-agent call that is waiting for a reply, and it ignores any response that does not match a pending call, so the call times out instead of accepting the wrong reply. A correlation ID applies to a single hop between two components, whereas a trace ID is carried across the whole task. In logs, it appears as `corrID` for tool calls and `subTaskID` for peer-agent calls.
DAG	A directed acyclic graph (DAG) is an arrangement of steps, called nodes, in which each node depends on earlier nodes and the order of execution follows those dependencies. Directed means each connection points from one node to a later one, and acyclic means the connections never form a cycle. In Agent Mesh, a workflow is a DAG: a node runs after all the nodes it depends on have completed, and nodes that do not depend on each other run in parallel. For more information, see What Are Workflows? (Early Access).
Declarative configuration	Declarative configuration is the set of YAML files that describe Agent Mesh resources, such as agents, entrypoints, workflows, models, toolsets, and connectors, kept in a directory under version control. The `sam config` commands apply these files to the platform service, which changes the running state to match them. The directory has one folder per resource kind and a top-level manifest. In contrast, runtime configuration is read directly by each process at startup. For more information, see Managing Configuration as Code (Early Access).
Default behavior	Default behavior refers to whether a session is persistent or run-based. Agent Mesh chooses it automatically: tasks that a user submits directly run persistent, and tasks that one agent delegates to another, or that are scheduled, run run-based. It is not a setting that you configure. For more information, see Persistent Versus Run-Based Sessions.
Deployment	A deployment is the step that pushes the stored configuration of an agent, workflow, or entrypoint to the component that runs it, so that it starts running, is updated, or is stopped, and the record of that step. You deploy from the Agent Mesh UI (for example, with the Deploy button for an agent) or through the platform service API. Whether a deployed agent is running at a given moment is tracked separately, as its runtime status. For more information, see Platform Service.
Desktop mode	Desktop mode is the way Agent Mesh runs when you install the desktop bundle, which provides the Agent Mesh desktop app, on your own computer. The Agent-Workflow Executor, the Entrypoint Executor, the Secure Tool Runtime, and an in-memory event broker all run together in a single process, and the Agent Mesh UI opens in its own application window. It needs no event broker setup, and it is intended for evaluating Agent Mesh and for local development, not for team or production workloads. For more information, see Installing the Desktop Bundle.
Distributed deployment	A distributed deployment runs the Agent-Workflow Executor, the Entrypoint Executor, and the Secure Tool Runtime as separate processes that communicate through an external Solace event broker. Each can be scaled on its own, and this is the form used for production, for example on Kubernetes. In contrast, desktop mode runs all of them in a single process. The platform service runs with the Entrypoint Executor or as its own process. For more information, see How Agent Mesh Manages Workloads and Deploying with Kubernetes.
Embed	An embed is a placeholder in text, written as `«type:params»`, that Agent Mesh replaces with other content when the text is processed. Most often it stands for the contents of an artifact, for example `«artifact_content:report.md»`. Other embeds insert an artifact's metadata, a status update, a calculated value such as a date and time or a UUID, or a rendered template. Embeds can appear in an agent's response and in the arguments passed to a tool. For more information, see Artifacts.
Entrypoint	An entrypoint is how people and other systems reach agents in Agent Mesh. It receives a request from an external system such as the Agent Mesh UI, Slack, or Microsoft Teams, authenticates the caller, ties the request to a session, passes it to an agent as a task over the event broker, and returns the agent's response. You can create entrypoints for Slack, Microsoft Teams, event mesh, MCP, and webhook on the Entrypoints page of the Agent Mesh UI (Builder > Entrypoints). All entrypoints run inside the Entrypoint Executor. For more information, see What Is an Entrypoint?
Entrypoint Executor	The Entrypoint Executor is the long-running process that hosts one or more entrypoints. It is one of the three Agent Mesh workload classes, together with the Agent-Workflow Executor and the Secure Tool Runtime, and it is the only one exposed to the outside world. It is the process you operate, scale, and monitor. In Helm keys (for example, `samDeployment.gwe.*`), deployment and pod names, and log fields, it is identified by the legacy name `gwe`, short for Gateway Executor. For more information, see How Agent Mesh Manages Workloads.
Event broker	In Agent Mesh, the components send all of their messages to each other by routing them through an event broker. Production and distributed deployments connect to a Solace event broker, while desktop mode uses a built-in in-memory event broker. For the general concept, see Event Broker in the Glossary. For more information, see The Event Mesh Communication Layer.
Event mesh	An event mesh is a network of connected event brokers, so a single event broker is one part of an event mesh. In Agent Mesh, agents, entrypoints, and tools communicate over the topics of an event mesh, and one event mesh can carry several independent Agent Mesh deployments, each separated by its own namespace. For the general concept, see Event Mesh in the Glossary. For more information, see The Event Mesh Communication Layer.
History compaction	History compaction replaces the older part of a conversation with a short summary, so that the conversation keeps fitting within the context window, which is the limit on how much text a large language model (LLM) can read at once. Agent Mesh creates the summary with one extra LLM call, then continues the conversation using the summary in place of the older messages. Compaction happens automatically when the model reports that its context limit was exceeded, or on demand from the compact button in the Agent Mesh UI or with `POST /api/v1/sessions/{id}/compact`. For more information, see Sessions.
LLM loop	An LLM loop is the repeating cycle an agent uses to complete a task. The agent sends the task, its instructions, and its available tools to a large language model (LLM), and the model replies with either a final answer or requests to call tools. The agent runs each requested tool and sends the results back to the model, and the cycle repeats until the model produces a final answer. The Agent-Workflow Executor runs the loop. For more information, see What Is an Agent?
Manifest	A manifest is the `manifest.yaml` file at the root of a declarative configuration directory. It tells the `sam config` commands which platform service to apply the configuration to and which resources to apply, and it can define variables for use in the resource files. It is not the same as a skill's `SKILL.md` file or a tool manifest. For more information, see The Manifest.
Namespace	A namespace is a prefix that begins the name of every topic and queue an Agent Mesh deployment uses on the event broker. Each deployment uses its own namespace (`solace-agent-mesh` by default), which lets several independent deployments share one event broker without seeing each other's messages. The namespace is set for each app in its runtime configuration and must be the same for every process in a deployment. For more information, see The Namespace as a Tenant Fence.
Orchestrator agent	An orchestrator agent is an agent that coordinates a task by delegating parts of it to other agents over the Agent-to-Agent (A2A) protocol. Agent Mesh installs a built-in agent named Orchestrator by default, which answers directly or delegates work to other agents. It appears in the Deployed tab of Builder > Agent Management, and it is the default agent for Slack, Microsoft Teams, and `sam task send`. For more information, see What Is an Agent?
Peer agent	A peer agent is an agent that another agent delegates part of a task to over the Agent-to-Agent (A2A) protocol. The term describes the relationship from the delegating agent's point of view, so any agent can be a peer agent to another. Agents find their peers through agent cards. For how to turn on delegation for an agent, see Creating Agents with the CLI.
Persistent	A persistent session is kept after its task finishes, so the next message in the same conversation loads the earlier history and continues from it. Persistent is one of the two session modes, and it is the mode that a task submitted directly by a user uses; the other is run-based. For more information, see Persistent Versus Run-Based Sessions.
Platform service	The platform service is the service that stores the configuration of agents, entrypoints, and other Agent Mesh resources and deploys them to the components that run them. It provides an HTTP API that the Agent Mesh UI and the Agent Mesh CLI use, and it also handles role-based access control (RBAC; see RBAC Reference), audit logging, evaluations, and the AI Assistant. Agent Mesh deployments normally run it, but it is optional: the Agent-Workflow Executor can also load agents from YAML files at startup. For more information, see Platform Service.
Project	A project is a workspace in the Agent Mesh UI where you add your own documents so that an agent can answer questions from them. A project also holds instructions and a default agent, which apply to every chat started in the project. Projects are managed in the Agent Mesh UI, under Projects in the sidebar, and they require a database to be configured. For more information, see Managing Projects.
Remote tool	A remote tool is a tool written as code, either a Python script or a Go binary, rather than declared in configuration alone. Remote tools are used when built-in, MCP, and OpenAPI tools cannot provide the behavior an agent needs. A remote tool runs in a sandbox in the Secure Tool Runtime, isolated from the agent, and the agent calls it over the event broker. Remote tools are written with the Go package `pkg/samtoolsdk` or the Python package `sam-tool-sdk`. For more information, see Extending Agent Mesh: Configuration or Code.
Role provider	A role provider is the part of role-based access control (RBAC) that maps an authenticated user to roles. The only role provider today is `idp_claims`, which assigns roles from group claims that a user's identity provider (IdP) issues through OpenID Connect (OIDC), so that you do not need an entry for each user. It is selected with `user_to_role_provider` in the `authorization_service` configuration. For more information, see Enabling Role-Based Access Control (RBAC) and IdP Claim Mapping.
Run-based	A run-based session is limited to a single task, and its history is not reused by later tasks. This mode suits one-shot agent invocations that must not carry over stale context. When one agent delegates a subtask to another, the agent that receives the subtask starts with no prior history, even if the calling agent's own session is persistent. Scheduled tasks also run as run-based sessions. For more information, see Persistent Versus Run-Based Sessions.
Runtime configuration	Runtime configuration is the set of YAML files that a server process reads when it starts, such as the Agent-Workflow Executor, the Entrypoint Executor, or a Secure Tool Runtime worker. The files specify settings such as the event broker connection and the apps (one per component instance) that the process runs. Each process reads its files directly, and they are not applied through the platform service, unlike declarative configuration. On Kubernetes, the Helm chart supplies these files, so you usually set Helm values instead of editing them. For more information, see Helm Values Reference.
Secure Tool Runtime	The Secure Tool Runtime is the process that runs remote tools, which are tools written as Python scripts or Go binaries, in a sandbox, separate from the agents that call them. Running them separately helps keep a tool that fails or is not fully trusted from affecting the agent. Helm keys, pod names, and log fields abbreviate its name as `str`. For more information, see How Agent Mesh Manages Workloads.
Session	A session is the conversation thread between a user and an agent, which Agent Mesh stores so that the agent can remember earlier messages from one turn to the next. A session holds the message history, the identity of the user, and task checkpoints, and it is stored in SQLite, PostgreSQL, or memory. For more information, see Sessions.
Session key	A session key is the identifier that an entrypoint uses to match an incoming message to an existing session, so that follow-up messages are added to the same session. Most entrypoint types derive it from something different; for example, Slack uses the channel and thread, and Teams uses the conversation and the date. Event mesh and webhook messages each start a new session. For more information, see Session Keying: How Each Entrypoint Type Derives a Session ID.
Skill	A skill is a reusable package of instructions that an agent loads only when a task calls for it. A skill can also include tools and reference documents. Skills let an agent stay small while still reaching a large library of capabilities. In Agent Mesh, a skill is a directory with a `SKILL.md` file that follows the open agentskills.io format. A skill is uploaded on the Skills page in the Agent Mesh UI or through the platform service, and attached to an agent by name. For more information, see Skills and Creating Skills.
Soft-subset assert	Soft-subset assert is a check, performed as part of the Trust Manager's verification, that compares the claims in a message body with the claims signed in the task's JSON Web Token (JWT). The claims in the message body are accepted only if they are a subset of the signed claims. A claim that narrows the signed claims is allowed, and a claim that widens them is dropped and logged as a warning, which helps prevent a compromised agent from claiming more capability than it was granted. It is built in and runs automatically when the Trust Manager is enabled, so there is nothing to configure. For more information, see JWT Signing and Trust.
Task ID	A task ID is the unique identifier of one task that a user submitted. You can give it to the Activity Monitor to ask, for example, "Why did task `<taskID>` fail?" The entrypoint creates it when the user submits the task. Agent Mesh sends it in the `id` field of every A2A message about the task and uses it in the names of the topics that carry that task's status and responses, for example `<namespace>/a2a/v1/gateway/response/<gatewayID>/<taskID>`. A task ID is different from a trace ID, which you use to search logs rather than to identify messages. For more information, see Chatting with the Activity Monitor (Experimental).
Tool	A tool is a single capability that an agent can call, such as running a SQL query, searching the internet, or posting a Slack message. The agent's language model decides when to call a tool. In an agent's configuration, tools are listed under `tools:` with a `tool_type` of `builtin`, `builtin-group`, `mcp`, or `openapi`. The documentation also uses these names for kinds of tool. A built-in tool runs inside the Agent-Workflow Executor, or inside the Secure Tool Runtime when it needs isolation or ships as a separate program. A Model Context Protocol (MCP) tool is served by an external MCP server, and an OpenAPI tool is generated from an OpenAPI specification. A remote tool is a Python script or Go binary that runs in the Secure Tool Runtime. A skill-bundled tool ships inside a skill. For more information, see What Are Tools?
Tool manifest	A tool manifest is a file that lists the tools provided by a skill or a toolset. For each tool, it gives details such as the tool's name, timeout, sandbox profile, and the executable that implements it. The Secure Tool Runtime reads tool manifests so that the Agent-Workflow Executor knows which tools it can call, and it gets each tool's parameter schema from the tool itself. A skill keeps its tool manifest at `tools/manifest.yaml`, and a toolset keeps it at `manifest.yaml` in the root of the package. For more information, see Creating Skills and Creating Toolsets.
Toolset	A toolset is a package of custom tools that is uploaded once and can then be reused by any agent or workflow. Because a toolset is managed separately from the agents that use it, it can be updated without editing an agent. A toolset is created with `sam toolset init` and packaged with `sam toolset package`. It is then uploaded through the platform service, either on the Toolsets page in the Agent Mesh UI or with the `/api/v1/platform/toolsets` API, and attached to agents and workflows by name. A toolset has a discovery status (`created`, `pending`, `ready`, `failed`, or `removed`), and an agent that uses it can be deployed only when the status is `ready`. The tools in a toolset are remote tools. For more information, see Toolsets.
Topic	A topic is a hierarchical address that components publish messages to and subscribe to when routing messages through an event broker. In Agent Mesh, every topic starts with the configurable namespace, followed by the A2A path, for example `solace-agent-mesh/a2a/v1/<service>/...`. For the general concept, see Topic in the Glossary. For more information, see Topic Conventions.
Trace ID	A trace ID is a unique identifier that follows one user task from start to finish. The entrypoint generates it when the user submits the task, and every component the task touches (the entrypoint, agent, Secure Tool Runtime, and tools) writes the same trace ID to its logs. The trace ID never changes during the task, even when a message is republished, so searching your logs for it (for example, `grep traceID=<uuid>`, or `@traceID:<uuid>` in Datadog Logs) returns every log entry for that task. It is a UUIDv7 and is separate from the distributed tracing feature of the event broker (see Trace in the Glossary), because it has no span hierarchy and does not link into APM tooling. For more information, see Monitoring Your Agent Mesh.
Trust Manager	The Trust Manager is a deployment-wide capability that lets Agent Mesh components verify each other's signed tokens (JSON Web Tokens, or JWTs). It does not use certificates or certificate authorities. Each component generates its own signing key and publishes the matching public key in a signed trust card, and an agent uses those published keys to check that an incoming task was signed by a legitimate entrypoint before it acts on a user's behalf, which helps ensure that agent-to-agent delegation is safe. The Trust Manager is off by default. It is enabled in the `trust_manager` section of the runtime configuration for every component (or for none), typically by setting the `TRUST_MANAGER_ENABLED` environment variable to `true`. It runs in the background, and there is no page or command for viewing it. For more information, see Enable the Trust Manager.
Workflow	A workflow is a multi-step process whose steps and order are defined in advance, so the same input follows the same path every time. Use a workflow instead of an agent when a repeatable process matters more than letting an agent decide each step, for example a regulated process, a scheduled batch job, or a report-generation pipeline. A workflow is built as a DAG of typed nodes that the Agent-Workflow Executor runs, and its nodes can call agents, call tools, or nest other workflows. Workflows are created with Quick Build in the Agent Mesh UI or as YAML in declarative configuration, and a deployed workflow appears on the Workflows page. For more information, see What Are Workflows? (Early Access).

A2A

Agent-to-Agent (A2A) is the messaging protocol that agents use to communicate with each other over the event broker. Every message follows the same standard format, so any Agent Mesh component can understand messages from any other. The format is based on JSON-RPC 2.0. For more information, see Agent-to-Agent Protocol.

Agent

An agent is an AI worker that uses a large language model (LLM) to complete a task. It runs an LLM loop, in which the model decides which tools to call, and it can delegate parts of the task to peer agents. For a process whose steps are fixed in advance rather than chosen by a model, see Workflow, which is discovered and invoked like an agent. Agents are created in the Agent Mesh UI (Builder > Agent Management) or defined as YAML resources in declarative configuration. For more information, see What Is an Agent?

Agent card

An agent card is a description of an agent that tells other agents and entrypoints what the agent can do, so they can discover it and delegate to it. An agent publishes its card to the event broker when it starts, and publishes it again whenever its capabilities change. A card includes the agent's name, description, version, and the abilities and input and output formats it supports. In the Agent Mesh UI, you set the abilities and the input and output modes (text or files) when you create the agent. Entrypoints publish a similar entrypoint card. For more information, see Creating Agents.

Agent Mesh CLI

The Agent Mesh CLI is the command-line tool for managing an Agent Mesh deployment. You use it to apply configuration that is kept as YAML files (declarative configuration), send tasks to running agents, run evaluations, create and package tools and skills, sign in to the platform service, and check your environment before you start. The command is sam, so it is also called the sam CLI. The desktop bundle includes it. For more information, see CLI Reference.

Agent-Workflow Executor

The Agent-Workflow Executor is the process in which agents and workflows run. It loads agent configurations, runs each agent's LLM loop, dispatches tool calls, and runs workflows. Helm keys, pod names, and log fields abbreviate its name as awe. For more information, see How Agent Mesh Manages Workloads.

App

An app is one configured instance of an Agent Mesh component, such as a single agent or a single entrypoint. Each app is an entry in the apps list of a runtime configuration file, with a name and an app_config section that holds the app's own settings, such as its namespace. The component types are agents, entrypoints, Secure Tool Runtime workers, and the platform service. For more information, see Helm Values Reference.

Artifact

An artifact is a named, versioned file, such as a document, image, or data set, that an agent produces or consumes during a conversation. Artifacts are created by an agent's tools, by the agent from content it writes, or from files that users upload or attach, and they remain available after the tool call finishes, so later turns of the conversation can read them. Each change to an artifact creates a new version, and the previous versions remain readable. In the Agent Mesh UI, the artifacts for the current session appear in the Files tab. Artifacts can be stored on a filesystem, in S3, Google Cloud Storage (GCS), or Azure Blob Storage, or in memory. For more information, see Artifacts.

Artifact handling mode

Artifact handling mode is an agent setting, artifact_handling_mode in the agent's app_config, that controls what the language model sees about an artifact that one of the agent's tools creates. The conversation history is what the model reads on each turn. With ignore (the default), the artifact is saved but its content is not added to the history, and the agent can still load it when needed. With reference, the history includes a short reference to the artifact, and with embed, the history includes the artifact's content. For more information, see Artifacts.

Artifact scope

Artifact scope is a setting that controls whether the components in a deployment, such as agents and entrypoints, share one pool of artifacts or each keep their own. By default, all components in the same namespace share artifacts, so an artifact that one agent writes can be read by the other agents in that namespace, for example an orchestrator agent and the peer agents it delegates to. Alternatively, each component can keep its artifacts separate from every other component's. Separately, giving a filename the user: prefix makes that one artifact available across all of the same user's sessions. For more information, see Artifacts.

Compaction percentage

Compaction percentage is a history compaction setting that sets what fraction of the oldest conversation history is condensed into a summary. The default is 0.25, so about 25% of the history is summarized and the rest is kept as is. It is one of an agent's auto_summarization settings, set with the auto_summarization.compaction_percentage key. The manual compaction API uses the inverse value, targetPercent, which is the percentage of the conversation to keep. For more information, see Sessions.

Correlation ID

A correlation ID is a unique identifier that matches a response to the request that prompted it. The agent generates one for every tool call or peer-agent call that is waiting for a reply, and it ignores any response that does not match a pending call, so the call times out instead of accepting the wrong reply. A correlation ID applies to a single hop between two components, whereas a trace ID is carried across the whole task. In logs, it appears as corrID for tool calls and subTaskID for peer-agent calls.

DAG

A directed acyclic graph (DAG) is an arrangement of steps, called nodes, in which each node depends on earlier nodes and the order of execution follows those dependencies. Directed means each connection points from one node to a later one, and acyclic means the connections never form a cycle. In Agent Mesh, a workflow is a DAG: a node runs after all the nodes it depends on have completed, and nodes that do not depend on each other run in parallel. For more information, see What Are Workflows? (Early Access).

Declarative configuration

Declarative configuration is the set of YAML files that describe Agent Mesh resources, such as agents, entrypoints, workflows, models, toolsets, and connectors, kept in a directory under version control. The sam config commands apply these files to the platform service, which changes the running state to match them. The directory has one folder per resource kind and a top-level manifest. In contrast, runtime configuration is read directly by each process at startup. For more information, see Managing Configuration as Code (Early Access).

Default behavior

Default behavior refers to whether a session is persistent or run-based. Agent Mesh chooses it automatically: tasks that a user submits directly run persistent, and tasks that one agent delegates to another, or that are scheduled, run run-based. It is not a setting that you configure. For more information, see Persistent Versus Run-Based Sessions.

Deployment

A deployment is the step that pushes the stored configuration of an agent, workflow, or entrypoint to the component that runs it, so that it starts running, is updated, or is stopped, and the record of that step. You deploy from the Agent Mesh UI (for example, with the Deploy button for an agent) or through the platform service API. Whether a deployed agent is running at a given moment is tracked separately, as its runtime status. For more information, see Platform Service.

Desktop mode

Desktop mode is the way Agent Mesh runs when you install the desktop bundle, which provides the Agent Mesh desktop app, on your own computer. The Agent-Workflow Executor, the Entrypoint Executor, the Secure Tool Runtime, and an in-memory event broker all run together in a single process, and the Agent Mesh UI opens in its own application window. It needs no event broker setup, and it is intended for evaluating Agent Mesh and for local development, not for team or production workloads. For more information, see Installing the Desktop Bundle.

Distributed deployment

A distributed deployment runs the Agent-Workflow Executor, the Entrypoint Executor, and the Secure Tool Runtime as separate processes that communicate through an external Solace event broker. Each can be scaled on its own, and this is the form used for production, for example on Kubernetes. In contrast, desktop mode runs all of them in a single process. The platform service runs with the Entrypoint Executor or as its own process. For more information, see How Agent Mesh Manages Workloads and Deploying with Kubernetes.

Embed

An embed is a placeholder in text, written as «type:params», that Agent Mesh replaces with other content when the text is processed. Most often it stands for the contents of an artifact, for example «artifact_content:report.md». Other embeds insert an artifact's metadata, a status update, a calculated value such as a date and time or a UUID, or a rendered template. Embeds can appear in an agent's response and in the arguments passed to a tool. For more information, see Artifacts.

Entrypoint

An entrypoint is how people and other systems reach agents in Agent Mesh. It receives a request from an external system such as the Agent Mesh UI, Slack, or Microsoft Teams, authenticates the caller, ties the request to a session, passes it to an agent as a task over the event broker, and returns the agent's response. You can create entrypoints for Slack, Microsoft Teams, event mesh, MCP, and webhook on the Entrypoints page of the Agent Mesh UI (Builder > Entrypoints). All entrypoints run inside the Entrypoint Executor. For more information, see What Is an Entrypoint?

Entrypoint Executor

The Entrypoint Executor is the long-running process that hosts one or more entrypoints. It is one of the three Agent Mesh workload classes, together with the Agent-Workflow Executor and the Secure Tool Runtime, and it is the only one exposed to the outside world. It is the process you operate, scale, and monitor. In Helm keys (for example, samDeployment.gwe.*), deployment and pod names, and log fields, it is identified by the legacy name gwe, short for Gateway Executor. For more information, see How Agent Mesh Manages Workloads.

Event broker

In Agent Mesh, the components send all of their messages to each other by routing them through an event broker. Production and distributed deployments connect to a Solace event broker, while desktop mode uses a built-in in-memory event broker. For the general concept, see Event Broker in the Glossary. For more information, see The Event Mesh Communication Layer.

Event mesh

An event mesh is a network of connected event brokers, so a single event broker is one part of an event mesh. In Agent Mesh, agents, entrypoints, and tools communicate over the topics of an event mesh, and one event mesh can carry several independent Agent Mesh deployments, each separated by its own namespace. For the general concept, see Event Mesh in the Glossary. For more information, see The Event Mesh Communication Layer.

History compaction

History compaction replaces the older part of a conversation with a short summary, so that the conversation keeps fitting within the context window, which is the limit on how much text a large language model (LLM) can read at once. Agent Mesh creates the summary with one extra LLM call, then continues the conversation using the summary in place of the older messages. Compaction happens automatically when the model reports that its context limit was exceeded, or on demand from the compact button in the Agent Mesh UI or with POST /api/v1/sessions/{id}/compact. For more information, see Sessions.

LLM loop

An LLM loop is the repeating cycle an agent uses to complete a task. The agent sends the task, its instructions, and its available tools to a large language model (LLM), and the model replies with either a final answer or requests to call tools. The agent runs each requested tool and sends the results back to the model, and the cycle repeats until the model produces a final answer. The Agent-Workflow Executor runs the loop. For more information, see What Is an Agent?

Manifest

A manifest is the manifest.yaml file at the root of a declarative configuration directory. It tells the sam config commands which platform service to apply the configuration to and which resources to apply, and it can define variables for use in the resource files. It is not the same as a skill's SKILL.md file or a tool manifest. For more information, see The Manifest.

Namespace

A namespace is a prefix that begins the name of every topic and queue an Agent Mesh deployment uses on the event broker. Each deployment uses its own namespace (solace-agent-mesh by default), which lets several independent deployments share one event broker without seeing each other's messages. The namespace is set for each app in its runtime configuration and must be the same for every process in a deployment. For more information, see The Namespace as a Tenant Fence.

Orchestrator agent

An orchestrator agent is an agent that coordinates a task by delegating parts of it to other agents over the Agent-to-Agent (A2A) protocol. Agent Mesh installs a built-in agent named Orchestrator by default, which answers directly or delegates work to other agents. It appears in the Deployed tab of Builder > Agent Management, and it is the default agent for Slack, Microsoft Teams, and sam task send. For more information, see What Is an Agent?

Peer agent

A peer agent is an agent that another agent delegates part of a task to over the Agent-to-Agent (A2A) protocol. The term describes the relationship from the delegating agent's point of view, so any agent can be a peer agent to another. Agents find their peers through agent cards. For how to turn on delegation for an agent, see Creating Agents with the CLI.

Persistent

A persistent session is kept after its task finishes, so the next message in the same conversation loads the earlier history and continues from it. Persistent is one of the two session modes, and it is the mode that a task submitted directly by a user uses; the other is run-based. For more information, see Persistent Versus Run-Based Sessions.

Platform service

The platform service is the service that stores the configuration of agents, entrypoints, and other Agent Mesh resources and deploys them to the components that run them. It provides an HTTP API that the Agent Mesh UI and the Agent Mesh CLI use, and it also handles role-based access control (RBAC; see RBAC Reference), audit logging, evaluations, and the AI Assistant. Agent Mesh deployments normally run it, but it is optional: the Agent-Workflow Executor can also load agents from YAML files at startup. For more information, see Platform Service.

Project

A project is a workspace in the Agent Mesh UI where you add your own documents so that an agent can answer questions from them. A project also holds instructions and a default agent, which apply to every chat started in the project. Projects are managed in the Agent Mesh UI, under Projects in the sidebar, and they require a database to be configured. For more information, see Managing Projects.

Remote tool

A remote tool is a tool written as code, either a Python script or a Go binary, rather than declared in configuration alone. Remote tools are used when built-in, MCP, and OpenAPI tools cannot provide the behavior an agent needs. A remote tool runs in a sandbox in the Secure Tool Runtime, isolated from the agent, and the agent calls it over the event broker. Remote tools are written with the Go package pkg/samtoolsdk or the Python package sam-tool-sdk. For more information, see Extending Agent Mesh: Configuration or Code.

Role provider

A role provider is the part of role-based access control (RBAC) that maps an authenticated user to roles. The only role provider today is idp_claims, which assigns roles from group claims that a user's identity provider (IdP) issues through OpenID Connect (OIDC), so that you do not need an entry for each user. It is selected with user_to_role_provider in the authorization_service configuration. For more information, see Enabling Role-Based Access Control (RBAC) and IdP Claim Mapping.

Run-based

A run-based session is limited to a single task, and its history is not reused by later tasks. This mode suits one-shot agent invocations that must not carry over stale context. When one agent delegates a subtask to another, the agent that receives the subtask starts with no prior history, even if the calling agent's own session is persistent. Scheduled tasks also run as run-based sessions. For more information, see Persistent Versus Run-Based Sessions.

Runtime configuration

Runtime configuration is the set of YAML files that a server process reads when it starts, such as the Agent-Workflow Executor, the Entrypoint Executor, or a Secure Tool Runtime worker. The files specify settings such as the event broker connection and the apps (one per component instance) that the process runs. Each process reads its files directly, and they are not applied through the platform service, unlike declarative configuration. On Kubernetes, the Helm chart supplies these files, so you usually set Helm values instead of editing them. For more information, see Helm Values Reference.

Secure Tool Runtime

The Secure Tool Runtime is the process that runs remote tools, which are tools written as Python scripts or Go binaries, in a sandbox, separate from the agents that call them. Running them separately helps keep a tool that fails or is not fully trusted from affecting the agent. Helm keys, pod names, and log fields abbreviate its name as str. For more information, see How Agent Mesh Manages Workloads.

Session

A session is the conversation thread between a user and an agent, which Agent Mesh stores so that the agent can remember earlier messages from one turn to the next. A session holds the message history, the identity of the user, and task checkpoints, and it is stored in SQLite, PostgreSQL, or memory. For more information, see Sessions.

Session key

A session key is the identifier that an entrypoint uses to match an incoming message to an existing session, so that follow-up messages are added to the same session. Most entrypoint types derive it from something different; for example, Slack uses the channel and thread, and Teams uses the conversation and the date. Event mesh and webhook messages each start a new session. For more information, see Session Keying: How Each Entrypoint Type Derives a Session ID.

Skill

A skill is a reusable package of instructions that an agent loads only when a task calls for it. A skill can also include tools and reference documents. Skills let an agent stay small while still reaching a large library of capabilities. In Agent Mesh, a skill is a directory with a SKILL.md file that follows the open agentskills.io format. A skill is uploaded on the Skills page in the Agent Mesh UI or through the platform service, and attached to an agent by name. For more information, see Skills and Creating Skills.

Soft-subset assert

Soft-subset assert is a check, performed as part of the Trust Manager's verification, that compares the claims in a message body with the claims signed in the task's JSON Web Token (JWT). The claims in the message body are accepted only if they are a subset of the signed claims. A claim that narrows the signed claims is allowed, and a claim that widens them is dropped and logged as a warning, which helps prevent a compromised agent from claiming more capability than it was granted. It is built in and runs automatically when the Trust Manager is enabled, so there is nothing to configure. For more information, see JWT Signing and Trust.

Task ID

A task ID is the unique identifier of one task that a user submitted. You can give it to the Activity Monitor to ask, for example, "Why did task <taskID> fail?" The entrypoint creates it when the user submits the task. Agent Mesh sends it in the id field of every A2A message about the task and uses it in the names of the topics that carry that task's status and responses, for example <namespace>/a2a/v1/gateway/response/<gatewayID>/<taskID>. A task ID is different from a trace ID, which you use to search logs rather than to identify messages. For more information, see Chatting with the Activity Monitor (Experimental).

Tool

A tool is a single capability that an agent can call, such as running a SQL query, searching the internet, or posting a Slack message. The agent's language model decides when to call a tool. In an agent's configuration, tools are listed under tools: with a tool_type of builtin, builtin-group, mcp, or openapi. The documentation also uses these names for kinds of tool. A built-in tool runs inside the Agent-Workflow Executor, or inside the Secure Tool Runtime when it needs isolation or ships as a separate program. A Model Context Protocol (MCP) tool is served by an external MCP server, and an OpenAPI tool is generated from an OpenAPI specification. A remote tool is a Python script or Go binary that runs in the Secure Tool Runtime. A skill-bundled tool ships inside a skill. For more information, see What Are Tools?

Tool manifest

A tool manifest is a file that lists the tools provided by a skill or a toolset. For each tool, it gives details such as the tool's name, timeout, sandbox profile, and the executable that implements it. The Secure Tool Runtime reads tool manifests so that the Agent-Workflow Executor knows which tools it can call, and it gets each tool's parameter schema from the tool itself. A skill keeps its tool manifest at tools/manifest.yaml, and a toolset keeps it at manifest.yaml in the root of the package. For more information, see Creating Skills and Creating Toolsets.

Toolset

A toolset is a package of custom tools that is uploaded once and can then be reused by any agent or workflow. Because a toolset is managed separately from the agents that use it, it can be updated without editing an agent. A toolset is created with sam toolset init and packaged with sam toolset package. It is then uploaded through the platform service, either on the Toolsets page in the Agent Mesh UI or with the /api/v1/platform/toolsets API, and attached to agents and workflows by name. A toolset has a discovery status (created, pending, ready, failed, or removed), and an agent that uses it can be deployed only when the status is ready. The tools in a toolset are remote tools. For more information, see Toolsets.

Topic

A topic is a hierarchical address that components publish messages to and subscribe to when routing messages through an event broker. In Agent Mesh, every topic starts with the configurable namespace, followed by the A2A path, for example solace-agent-mesh/a2a/v1/<service>/.... For the general concept, see Topic in the Glossary. For more information, see Topic Conventions.

Trace ID

A trace ID is a unique identifier that follows one user task from start to finish. The entrypoint generates it when the user submits the task, and every component the task touches (the entrypoint, agent, Secure Tool Runtime, and tools) writes the same trace ID to its logs. The trace ID never changes during the task, even when a message is republished, so searching your logs for it (for example, grep traceID=<uuid>, or @traceID:<uuid> in Datadog Logs) returns every log entry for that task. It is a UUIDv7 and is separate from the distributed tracing feature of the event broker (see Trace in the Glossary), because it has no span hierarchy and does not link into APM tooling. For more information, see Monitoring Your Agent Mesh.

Trust Manager

The Trust Manager is a deployment-wide capability that lets Agent Mesh components verify each other's signed tokens (JSON Web Tokens, or JWTs). It does not use certificates or certificate authorities. Each component generates its own signing key and publishes the matching public key in a signed trust card, and an agent uses those published keys to check that an incoming task was signed by a legitimate entrypoint before it acts on a user's behalf, which helps ensure that agent-to-agent delegation is safe. The Trust Manager is off by default. It is enabled in the trust_manager section of the runtime configuration for every component (or for none), typically by setting the TRUST_MANAGER_ENABLED environment variable to true. It runs in the background, and there is no page or command for viewing it. For more information, see Enable the Trust Manager.

Workflow

A workflow is a multi-step process whose steps and order are defined in advance, so the same input follows the same path every time. Use a workflow instead of an agent when a repeatable process matters more than letting an agent decide each step, for example a regulated process, a scheduled batch job, or a report-generation pipeline. A workflow is built as a DAG of typed nodes that the Agent-Workflow Executor runs, and its nodes can call agents, call tools, or nest other workflows. Workflows are created with Quick Build in the Agent Mesh UI or as YAML in declarative configuration, and a deployed workflow appears on the Workflows page. For more information, see What Are Workflows? (Early Access).