Process Agents Overview

Overview

meshagent process is MeshAgent’s CLI command group for process-backed agents.

It is the main runtime for new conversational and background agents. Use it when you want one agent that stays available over time, can accept work through one or more channels, and keeps thread-based continuity instead of treating every request as an isolated run.

What a process-backed agent can do

A process-backed agent can:

• answer people in chat
• handle inbound mail
• consume queued jobs
• expose itself as a callable toolkit
• use built-in and custom tools
• keep work separated by thread
• stay available as a deployed service

That makes meshagent process a good fit for support agents, coding agents, research agents, and operations agents.

When to use meshagent process

Use meshagent process when you need an agent that:

• should stay available over time
• may need more than one entry point
• should keep one rules and tool setup across those entry points
• should preserve thread continuity across turns
• should be easy to run locally and deploy with the CLI

Supported channels

Today, meshagent process supports:

• chat
• mail:EMAIL
• queue:NAME
• toolkit:NAME

Each --channel flag adds another entry point to the same process-backed agent.

Channel	Use it for	What it enables
chat	Interactive conversation in MeshAgent Studio or another chat client	Threaded conversation, streaming responses, human interaction
mail:EMAIL	Turning inbound email into agent work	Mailbox-backed replies, attachments, email-first workflows
queue:NAME	Background jobs delivered through a room queue	Non-interactive work, queued job handling
toolkit:NAME	Exposing the agent as a callable toolkit	Agent-as-tool workflows and agent composition

How to think about it

The simplest mental model is:

• the process is the running agent
• the channels are the ways work reaches that agent
• the thread is the continuity boundary

That means one process-backed agent can serve several entry points without mixing unrelated work together. Work only shares history when it uses the same thread path.

Main commands

Most users will touch these meshagent process commands:

Command	Use
meshagent process join	Join a room and run a process-backed agent
meshagent process run	Run a process-backed agent and wait for interactive messages
meshagent process use	Send a one-shot or interactive message to a running process-backed agent
meshagent process spec	Generate a service spec for deployment
meshagent process deploy	Deploy a process-backed agent service

Build one agent with all four primary channels

If you want one agent that can answer in chat, receive email, handle queued work, and be called like a toolkit, set up the mailbox first and then start the process with all four channels.

Step 1: Create the mailbox

Create the mailbox before you add a mail:EMAIL channel:

meshagent mailbox create \
  --address [e-mail] \
  --room quickstart \
  --queue [e-mail]

Step 2: Start the process-backed agent

Run one agent with chat, mail, queue, and toolkit entry points:

meshagent process join \
  --room quickstart \
  --agent-name support-agent \
  --channel chat \
  --channel mail:[e-mail] \
  --channel queue:support-jobs \
  --channel toolkit:support-agent \
  --threading-mode default-new \
  --thread-dir ".threads/support-agent" \
  --web-search \
  --require-storage \
  --rule "You are a helpful support agent. Answer clearly, use web search when needed, and save important artifacts to storage."

This gives you:

• one long-running process-backed agent
• one shared identity across four entry points
• thread-aware chat behavior
• mailbox-backed email handling
• queue-driven background work
• a callable toolkit for other participants or apps

Step 3: Chat with the agent

Open MeshAgent Studio, join the quickstart room, and start chatting with support-agent.

Step 4: Email the agent

Now email [e-mail]. The mail channel turns that inbound email into work for the same running agent.

Use mail:EMAIL when you want:

• mailbox-backed inbound email
• reply behavior through the mailbox flow
• attachment and metadata handling inside the same thread-aware runtime

Step 5: Send work through the queue

Use queue:NAME when you want non-interactive background jobs:

meshagent room queue send \
  --room quickstart \
  --queue support-jobs \
  --json '{"prompt":"Summarize the latest support backlog and save a report."}'

This keeps the useful worker-style behavior:

• queued job handling
• background execution without a human back-and-forth
• optional continuity when queued work reuses a thread path

Step 6: Invoke the agent through the toolkit channel

List toolkits in the room:

meshagent room agent list-toolkits \
  --room quickstart

Then invoke the process-backed agent as a toolkit:

meshagent room agent invoke-tool \
  --room quickstart \
  --toolkit support-agent \
  --tool run_support_agent_task \
  --arguments '{"prompt":"Draft a short reply explaining the refund policy."}'

Use toolkit:NAME when you want:

• a clean invocation boundary
• an agent that can be called by other agents or applications
• the same rules and tools available through a toolkit entry point

Deploy the same agent shape

Once the agent works locally, you can deploy it directly with the CLI:

meshagent process deploy \
  --service-name support-agent \
  --room quickstart \
  --agent-name support-agent \
  --channel chat \
  --channel mail:[e-mail] \
  --channel queue:support-jobs \
  --channel toolkit:support-agent \
  --threading-mode default-new \
  --web-search \
  --require-storage \
  --rule "You are a helpful support agent. Answer clearly, use web search when needed, and save important artifacts to storage."

That deploys the same process shape you just tested locally.

How process-backed agents behave

Process-backed agents are built around threads.

• one agent can receive work from several channels
• the running agent is shared
• thread history is only shared when turns reuse the same thread path
• different thread paths stay separate

This is what allows one deployed agent to handle many conversations or jobs without collapsing them into one shared context.

How meshagent process works

At a high level:

• channels turn chat, mail, queue, or toolkit input into process messages
• a supervisor routes those messages by thread_id
• one thread process handles each active thread
• a thread adapter persists turn state, outputs, and status

See Process Agent Architecture for the implementation details and the runtime pieces involved.

Where to go next

• Process Agent Architecture: what the CLI builds behind the scenes
• Threads Overview: how thread paths control continuity and isolation