Skip to main content
Write a service manifest when you want to review, customize, validate, deploy, update, or delete the service configuration yourself. Use 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 Service with a container
  • a ServiceTemplate with a container
  • a Service with an external runtime

Example 1: Service with container

Use kind: Service when the configuration is fixed at deploy time.
This example uses 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
Use --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.
This example adds a language variable and uses {{ language }} inside the container.command. Validate and deploy it:
bash
Use --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.
This example is a fixed 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
If you need installer-provided values such as a URL, label, or OAuth settings, you can use external inside a ServiceTemplate too. For a longer walkthrough, see Connect to an External MCP Server.

Manage deployed services

Use meshagent service after deployment to inspect and manage what you deployed.
bash
Omit --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

Use channels when one deployed agent should participate in more than one entry point. Queue channel entries support: Messaging channel entries support:

agents.email

Use email when the agent identity itself should have mailbox settings attached to it.

agents.heartbeat

Use heartbeat 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:
This mirrors the built-in assistant service template: each heartbeat run is queued to the assistant, uses the heartbeat prompt file from room storage, and writes the run into a timestamped thread under the assistant thread directory.

files

Top-level files 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 in Service, 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 role agent and 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.
The "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 literal value, a MeshAgent token, or a service-account secret. Use:
  • value for plain configuration
  • token for MeshAgent API access
  • secret for service-account credentials. container.run_as is required when any environment variable uses secret.
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. Requires ports 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 a ServiceTemplate. 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 in metadata.annotations.

Agent annotations

Set in agents[].annotations.

Variable annotations

Set in variables[].annotations.

Event annotations

Set in agents[].annotations. Subscribe an agent to room events. The value is the name of a queue that a queue-consuming agent can process.