Glossary
This page is the canonical place to look up a term that appears throughout the Agent Mesh documentation. Terms are listed alphabetically.
| Term | Definition |
|---|---|
| A2A | Agent-to-Agent protocol. The JSON-RPC 2.0 wire format agents use to exchange messages over the event broker. Wire-compatible with the Python implementation. See Agent-to-Agent Protocol. |
| Agent | An LLM-driven worker, declared in YAML, that processes messages by calling tools and, optionally, delegating to other agents. At the Agent-Workflow Executor and YAML layer, agent_type is standard (an LLM loop plus tool calls) or workflow, a directed acyclic graph (DAG) executed without tool calling. See Extending Agent Mesh: Configuration or Code. |
| Agent card | The self-describing record an agent publishes on the discovery topic at startup, and republishes when its capability set changes. Carries the agent's name, description, model, skills, and protocol features. Entrypoints publish an analogous entrypoint card on the same discovery topic family. |
| Agent-Workflow Executor | The process that loads agent configurations, runs the LLM loop, and dispatches tool calls. In infrastructure identifiers (Helm keys, pod names, and log fields) it uses the awe spelling. See How Agent Mesh Manages Workloads. |
| Artifact | A versioned blob (document, image, or data set) produced or consumed by an agent. Versioning is by integer sequence, exposed as data_version and metadata_version. Backends: filesystem, S3, GCS, Azure Blob Storage, and in-memory. See Artifacts. |
| Artifact handling mode | The per-agent setting (artifact_handling_mode) that governs how tool-produced artifacts surface in the conversation history. Values: ignore (default—no inline summary), embed (artifact content embedded inline), and reference (URI reference only). |
| Artifact scope | The per-component setting (artifact_scope) that determines whether artifacts are partitioned by namespace or by component. namespace (default) places artifacts under the app's namespace, letting agents in the same namespace share them. Distinct from the in-filename user-scope opt-in (the user: filename prefix), which is an addressability concern. |
| Built tool | A tool implemented as a standalone binary that the Secure Tool Runtime spawns—Go using pkg/samtoolsdk, or Python using sam-tool-sdk. The customer authoring path for behavior the YAML tool taxonomy can't express. See Extending Agent Mesh: Configuration or Code. |
| Community | Agent Mesh no longer ships as separate Community and Enterprise products. It is a single product with one feature set—authentication, RBAC, the platform service, every connector, and every entrypoint are all included. |
| Compaction percentage | The post-compaction history size as a fraction of the pre-compaction conversation. Set with the auto_summarization.compaction_percentage YAML key (default 0.25—25% of the conversation is compacted into the summary). The manual-compaction endpoint exposes the same dial as targetPercent. |
| Configured agent | An agent defined entirely in YAML, including its tool list and any embedded prompts. The only customer authoring path for agents in the Go implementation; emphasized when contrasting with a built tool that the agent calls. Synonymous in code with agentType: standard plus a YAML configuration file. See Extending Agent Mesh: Configuration or Code. |
| Correlation ID | A per-hop UUID that matches an outstanding request to its response—distinct from a trace ID (one per user task, immutable) and a task ID (entrypoint-minted user task addressing). Appears in logs as corrID or reqID. |
| Declarative config | The YAML resources passed to sam config apply and reconciled against the platform service. A directory laid out by kind, with a top-level manifest.yaml that names the target and lists resources. Distinct from runtime config, which is read directly by the binary. |
| Default behavior | The per-session_service setting (default_behavior) that governs whether sessions survive the end of a task. Values: PERSISTENT (the row survives—the shipped default for every entrypoint type) and RUN_BASED (the row is bounded to a single task). See Sessions. |
| Deployment | A running instance of an agent or entrypoint, tracked by the platform service as a first-class resource and redeployed from its stored configuration. |
| Desktop mode | A native desktop application that runs the Agent-Workflow Executor, the Entrypoint Executor, the Secure Tool Runtime, and an in-memory event broker together in a single process, behind a graphical interface. Launched by running the desktop sam binary with no arguments (shipped as sam-desktop). There is no --desktop flag. |
| Distributed deployment | A layout that runs the Agent-Workflow Executor, Entrypoint Executor, and Secure Tool Runtime as separate processes connected through an external Solace event broker. Used in production. |
| Embed | A «type:params» token that the runtime substitutes with content drawn from elsewhere—most commonly an artifact reference («artifact_content:report.md»), a status update, or a templated value. Operators tune the resolver with enable_embed_resolution and gateway_artifact_content_limit_bytes. |
| Enterprise | Agent Mesh no longer ships as separate Community and Enterprise products; it is a single product with one feature set. Features are described directly, not gated by edition. |
| Entrypoint | The HTTP-and-event-broker bridge that fronts the Agent-Workflow Executor—a role, not a process. Carries user-facing concerns: Server-Sent Events (SSE) streaming, sessions, auth, and serving the Agent Mesh UI. Wire-level type values: httpsse, eventmesh, slack, email, mcp, and teams. The long-running process that hosts one or more entrypoints is the Entrypoint Executor. |
| Entrypoint Executor | The workload class—the long-running process you operate, scale, and probe—that hosts one or more entrypoints. The third member of the workload-class trio alongside the Agent-Workflow Executor and the Secure Tool Runtime. In infrastructure identifiers—Helm keys (samDeployment.gwe.*), deployment and pod names, and log fields—it keeps the legacy gwe spelling. See How Agent Mesh Manages Workloads. |
| Event broker | The transport that carries every agent-to-agent and entrypoint-agent message in Agent Mesh. Production deployments use a Solace event broker; the desktop bundle uses a built-in in-memory event broker. |
| Event mesh | The conceptual fabric of topics over which agents, entrypoints, and tools communicate. The fabric is provided by an event broker. See The Event Mesh Communication Layer. |
| History compaction | The runtime's mechanism for keeping a conversation inside the model's context window: when continued history would exceed the budget, an extra LLM call summarizes older messages into a single replacement and the loop retries with smaller history. Two modes: reactive auto-compaction and manual compaction (via POST /api/v1/sessions/{id}/compact). |
| IdP | Identity provider. The external service that authenticates users and issues the OpenID Connect (OIDC) claims Agent Mesh maps to roles. |
| Manifest | The kind: manifest document at the root of a declarative config tree. Names the platform service target, declares variables, and lists which resources to apply. Distinct from a skill's SKILL.md and from the tool manifest the Secure Tool Runtime uses. |
| Namespace | The configurable first segment of every A2A topic—set per app in app_config.namespace, default solace-agent-mesh. A single Solace event mesh can carry multiple independent Agent Mesh deployments by giving each one a distinct namespace. |
| Orchestrator agent | A role, not a type. An agent that delegates to other agents over the A2A protocol rather than executing tools itself. Conventionally named Orchestrator in examples. |
| Peer agent | An agent that another agent delegates to over the A2A protocol. The relationship is described from the perspective of the delegating agent. |
| Persistent | One of the two values of default_behavior (wire spelling PERSISTENT). Persistent sessions outlive the task; the runtime loads their prior history on the next turn under the same session key. |
| Platform service | The HTTP service that exposes agents, deployments, evaluations, toolsets and skills, model configuration, RBAC and identity, MCP integrations, audit logs, and the AI assistant. See Platform Service. |
| Project | A workspace in the Agent Mesh UI where a user grounds an agent in their own uploaded documents: a document set the agent searches, plus optional instructions and a default agent. Backed by a database and surfaced as the Projects area in the UI sidebar. It is not an on-disk configuration directory—for that, see runtime config or declarative config. |
| RBAC | Role-Based Access Control. Maps authenticated users to roles and gates actions by role. See RBAC Reference. |
| Role provider | The component that maps a user (after authentication) to roles. The only implementation today is idp_claims, which maps IdP-issued OIDC claim values to roles. |
| Run-based | One of the two values of default_behavior. Run-based sessions are bounded to one task and not reused afterward—the right choice for one-shot transformations. Wire spelling RUN_BASED. Subtask delegations propagate sessionBehavior: RUN_BASED so callees start with no prior history even when the caller is persistent. |
| Runtime config | The YAML files passed to the Agent-Workflow Executor, the Entrypoint Executor, or the Secure Tool Runtime worker at startup. Declares the event broker, models, and the list of apps (one per component). Read directly by the binary—no platform service in the path; each component reads its own runtime config. Distinct from declarative config, which is reconciled through sam config apply. |
| sam CLI | The command-line tool (the sam binary) for managing an Agent Mesh deployment: executing tasks (sam task), managing declarative config (sam config, sam toolset, sam skill), running evaluations (sam eval), and handling authentication (sam auth). See CLI Reference. |
| sam-go | The Go implementation of Agent Mesh, distinguished in prose from the Python implementation when the difference matters. |
| Secure Tool Runtime | The sandboxed process that executes tools—both Python script tools and Go tool binaries. In infrastructure identifiers (Helm keys, pod names, and log fields) it uses the str spelling. See How Agent Mesh Manages Workloads. |
| Session | The persisted conversation between a user and an agent, including message history, task checkpoints, and metadata. Backed by SQLite, PostgreSQL, or in-memory storage. See Sessions. |
| Session key | The identifier the entrypoint derives from its inbound transport to look up (or create) a session row. Each entrypoint type has its own derivation: the Web UI entrypoint uses an explicit sessionID; Slack uses (channel, thread_ts); Email uses the References thread root; Teams uses convID plus tenant; MCP uses the OAuth identity; and Event Mesh derives the key from input_expression or user properties. |
| Skill | An agentskills.io-style bundle (a SKILL.md plus optional references/, assets/, and tools/) that an agent loads on demand with load_skill. Managed as a platform service resource—uploaded through the Skills page or /api/v1/platform/skills, with a discoveryStatus lifecycle, and attached to agents through skillIds or skillRefs. Agent Mesh uses tools/ in place of the agentskills.io scripts/ directory. See Skills. |
| Soft-subset assert | The JWT trust manager's reconciliation rule: the unsigned tool or capability claims in a message body are accepted only if they are a subset of the cryptographically signed claims on the bearer JWT. Narrowing is allowed; widening is dropped with a structured warning. |
| Solace Agent Mesh | The product—an agent development and runtime platform for building, running, and improving agents and agent workflows. "Agent Mesh" is the accepted short form after first reference. |
| Solace event broker | The production event broker product. Carries all agent-to-agent and entrypoint-agent traffic in a production or distributed deployment. Connected to Agent Mesh through the SOLACE_BROKER_URL, SOLACE_BROKER_USERNAME, SOLACE_BROKER_PASSWORD, and SOLACE_BROKER_VPN environment variables. |
| SSO | Single sign-on. The OIDC flow the entrypoint uses for browser-based login. |
| Tool | A discrete capability an agent can invoke. The wire-level tool_type values in YAML are builtin, builtin-group, mcp, and openapi. Non-wire categories in prose: "built-in tool" (runs inside the Agent-Workflow Executor), "MCP tool", "OpenAPI tool", "remote tool" (a Python script or Go binary running inside the Secure Tool Runtime), and "skill-bundled tool". |
| Tool manifest | The tools/manifest.yaml (or equivalent) that declares the tools the Secure Tool Runtime hosts in a skill bundle—name, description, parameter schema, and the binary or script that backs each tool. The Secure Tool Runtime parses tool manifests at startup and broadcasts the available toolset so the Agent-Workflow Executor can determine what is callable. Distinct from a Manifest (the kind: manifest declarative-config root). |
| Toolset | A platform-managed, independently deployable package of remote tools. Authored with sam toolset init, built and zipped with sam toolset package, uploaded through the platform service (the Toolsets page in the Agent Mesh UI or /api/v1/platform/toolsets), and attached to agents by name. Has a discoveryStatus lifecycle (created → pending → ready or failed, plus removed). See Toolsets. |
| Topic | A hierarchical event-broker address under <namespace>/a2a/v1/<service>/... (where <namespace> is the configurable event-broker namespace, for example, solace-agent-mesh) that agents publish or subscribe to. |
| Trace ID | An immutable UUIDv7 minted by the entrypoint when a user task is submitted, then propagated end-to-end on every A2A message hop. A single grep traceID=<uuid> (or @traceID:<uuid> in Datadog Logs) reveals the full causal chain across the entrypoint, agent, Secure Tool Runtime, and tool logs. One per user task, never re-minted on republish. Not a distributed-tracing span. |
| Workflow | A DAG of typed nodes executed by the Agent-Workflow Executor. The valid node types are agent, tool, switch, map, loop, and workflow (nested). Workflows are a distinct concept from agents—a workflow-type agent runs a workflow, but a workflow is not itself an agent. |