meshagent service with service manifests. Use Deploy a built in Agent when you want to deploy a process-backed agent from CLI flags instead.
In MeshAgent, you can deploy fixed or templated services project-wide or to specific rooms, either as MeshAgent-managed container services or as external services that MeshAgent routes to; for more detail, see Intro to Services.
The examples below show three common cases:
- a
Servicewith acontainer - a
ServiceTemplatewith acontainer - a
Servicewith anexternalruntime
Example 1: Service with container
Use kind: Service when the configuration is fixed at deploy time.
kind: Service with a container. MeshAgent runs the meshagent/cli:default image, and the container starts meshagent process join ... inside it.
Validate and deploy it:
bash
--global instead of --room myroom to deploy the same manifest as a project service.
Example 2: ServiceTemplate with container
Use kind: ServiceTemplate when the manifest shape stays the same but some values should be supplied during deployment or install.
language variable and uses {{ language }} inside the container.command.
Validate and deploy it:
bash
--global instead of --room myroom to deploy the rendered service project-wide.
If you want to inspect the rendered YAML first, use meshagent service render-template --file meshagent.yaml --value language=Spanish.
Example 3: Service with external
Use external when MeshAgent should route to a service you already host elsewhere instead of running a container for you.
Service that routes to an MCP server hosted outside MeshAgent. MeshAgent does not run the MCP server. It uses the external.url and ports.endpoints config to register that server’s tools in the room.
Validate and deploy it:
bash
external inside a ServiceTemplate too.
For a longer walkthrough, see Connect to an External MCP Server.
Manage deployed services
Usemeshagent service after deployment to inspect and manage what you deployed.
bash
--room myroom when you are updating, listing, or deleting a project service instead.
Service configuration field reference
Top-level fields
* Either
container or external is required, but not both.
metadata
Identifies the service and provides information displayed in the UI.agents
Declares the participant identities this service provides. MeshAgent uses this to route requests, apply policies, and display agents in the UI.agents.channels
Usechannels when one deployed agent should participate in more than one entry point.
Queue channel entries support:
Messaging channel entries support:
agents.email
Useemail when the agent identity itself should have mailbox settings attached to it.
agents.heartbeat
Useheartbeat when the agent should enqueue a recurring turn for itself without creating a separate scheduled-task resource by hand.
Heartbeat
prompt items use the same typed content model as agent turns:
Example:
files
Top-levelfiles seed room storage before the service starts. MeshAgent creates each file only if it does not already exist, which makes this useful for editable starter content such as prompts, rules, or templates.
Use top-level
files when the content should live in room storage and remain editable after deploy. Use container.storage.files when the file should be mounted inside the running container itself.
container
Defines a container for MeshAgent to run. Fields marked † are only available inService, not ServiceTemplate.
container.template
container.template controls the MeshAgent runtime defaults added when the container starts:
"agent"(default): mount room storage at/data, create a participant token for the container name with roleagentand default agent API permissions, and inject MeshAgent/OpenAI/Anthropic runtime environment variables."none": do not add those defaults. Only values explicitly configured in the manifest or container start request are passed through.
"agent" template sets defaults only when the environment variable is not already configured. Values in container.environment override template defaults.
The "agent" template may set:
container.run_as
container.run_as selects the service account identity used by the container.
The default scope list grants access to the HTTP/MCP secret proxy without
granting broad project administration.
container.environment
Each entry sets an environment variable in the container. A variable can come from a literalvalue, a MeshAgent token, or a service-account secret.
Use:
valuefor plain configurationtokenfor MeshAgent API accesssecretfor service-account credentials.container.run_asis required when any environment variable usessecret.
token fields:
secret fields:
This pattern is common for services:
token gives the service access to MeshAgent, while secret gives it an external credential through its service account.
container.storage
Mounts storage volumes into the container.
Room and project mount fields:
Image mount fields:
File mount fields:
Empty directory mount fields:
Config mount fields:
Config mounts are useful when a shell tool or helper process inside the container needs access to runtime files such as
spec.json and members.json.
external
Routes traffic to a service running outside MeshAgent. Requiresports to define how MeshAgent reaches the service.
ports
Defines network ports the service listens on and how MeshAgent routes HTTP traffic to them.
For HTTP ports, set
liveness to the path MeshAgent should poll to decide whether the service port is ready. For example, liveness: /healthz tells MeshAgent to request that path on the running service. A 2xx response reports the port as ready; failed checks report not ready; ports without a liveness path report no liveness in meshagent room service list.
ports.endpoints
Each endpoint maps a URL path to either a MeshAgent-native service or an MCP server.meshagent endpoint
Connects the endpoint to a MeshAgent participant identity.mcp endpoint
Registers an MCP server as a toolkit in the room.allowed_tools entries:
oauth fields:
variables (ServiceTemplate only)
Defines user-provided inputs for aServiceTemplate. Values are substituted into the YAML using {{ variable_name }} syntax.
Template values are rendered into the manifest before validation, so they can be used anywhere the resulting YAML remains valid.
Annotations
Annotations are key-value strings attached to services, agents, or variables. MeshAgent and Powerboards use specific annotation keys to control behavior. You can also define custom annotations.Service annotations
Set inmetadata.annotations.
Agent annotations
Set inagents[].annotations.
Variable annotations
Set invariables[].annotations.
Event annotations
Set inagents[].annotations. Subscribe an agent to room events. The value is the name of a queue that a queue-consuming agent can process.
Read next
- Build and Deploy Images: build and deploy images with
meshagent buildandmeshagent deploy - Secrets and Credentials: manage user-owned and service-account-owned secrets
- Observability: inspect logs, traces, metrics, and custom OpenTelemetry output
- Webhook Handoffs: handle
room.callwebhook handoffs in your own services