Teams rarely want an agent to live in just one place. The same agent often needs to answer in chat, respond to email, handle background jobs, or be called from another agent or system.
Many agent interactions span multiple interfaces. A task might start in chat, continue through email, and run again later from a scheduled job or another system. If each entry point is treated as a separate agent, you quickly end up duplicating configuration, splitting context, and making the workflow harder to manage.
We've introduced a new unified agent model through `meshagent process...` to solve these problems. One agent can be exposed through multiple channels while keeping the same identity, rules, and tools.
In this post, we'll look at the channels MeshAgent supports, how continuity works across them, and some of the built-in tools that make multi-channel agents useful in practice.
A single meshagent process agent can be reached through several channel types:
- `chat` enables direct collaboration and conversation in the room
- `mail` makes the same agent accessible via email
- `queue` supports scheduled tasks and event-driven work
- `toolkit` makes the agent callable by other agents or systems
Each channel is simply another way to reach the same agent. You are not redefining the agent each time. You are adding another input path to an agent that already has its own identity, rules, and capabilities.
This gives you a practical way to build agents that work across both conversational and background workflows. The same agent can answer a question in chat, receive a follow-up over email, and process queued work later.
A process agent keeps the same identity, rules, and tools no matter how it is reached. But that does not mean all of its work is dumped into one giant conversation.
In MeshAgent, history is organized into threads. You can think of a thread as one saved conversation or work log. A single process agent can have many threads.
When chat, email, queue work, or toolkit calls use the same thread, they continue the same history. When they use different threads, the work stays separate. That means the same agent can resume an existing thread when related work continues across channels, while maintaining separate threads for new or unrelated tasks.
Threads are not the only way the agent keeps context. You can also give the agent memory, which is useful for facts, preferences, and other structured information you want it to recall. Threads preserve the history of a specific conversation or task. Memory preserves longer-lived knowledge the agent may need across many threads and channels.
MeshAgent also gives agents built-in tools for working with thread history. The current thread can be searched, counted, and read in ranges, including messages outside the active context window. In chat-oriented setups with a thread list, agents can also list and search known threads by name and path.
Once work reaches the agent, the next question is what the agent can actually do. MeshAgent provides built-in tools that you can enable as part of the agent definition. These include general-purpose capabilities like web search, web fetch, shell access, and MCP support, along with MeshAgent-native tools for storage, memory, database access, and toolkit-based integrations.
Those tools stay with the agent across channels. If the agent is reachable through chat, email, a queue, and a toolkit call, it keeps the same rules and the same tool configuration. You do not need to redefine the agent for each entry point.
MeshAgent supports both OpenAI and Anthropic models natively. For many core capabilities, including web search, web fetch, and shell, you can use the same MeshAgent configuration across providers even when the underlying tool implementation differs.
In this example we define one agent with chat, mail, queue, and toolkit channels using the meshagent process join command. This example lets you choose a name for the agent and equips it with tools for web search, shell use, storage, memory, and skills loaded from a path in room storage. It also uses --room-rules to load editable rules for the agent from room storage. This is important because it gives the agent instructions that can be updated over time by anyone in the room without redeploying the whole service.
Each of the built-in tools in the sample plays a different role. Web search helps the agent pull in current external information. Shell gives it a working execution environment, so it can inspect files, run commands, and produce artifacts. Storage gives it room-scoped files it can read and update over time. Memory gives it a way to save and recall information across threads and channels. Skills let you package reusable guidance without overloading the agent's context window.
The sample also shows how these tools fit together in a deployed service. Room storage is mounted at /data, so the agent can work with the same underlying files through both MeshAgent storage tools and shell tools. In deployed services, the agent runs with a scoped MESHAGENT_TOKEN that carries the MeshAgent API grants it needs for things like storage, messaging, memory, and agent/tool access. In this sample, --delegate-shell-token passes that token into the shell environment, so the agent can call MeshAgent APIs and run meshagent CLI commands through the shell tool using its own scoped permissions.
You can install the agent directly into Powerboards using this link! Once the agent is installed consider asking it to do something like add all of the anthropic skills from the anthropic-skills folder to it's directory. This will allow your agent to use and update the existing publicly available skills from Anthropic. You can also ask it to create a new database in the room for you, spin up a container to execute code in, and more.
meshagent process gives you a cleaner way to build agents that match how work actually happens. People move between interfaces. Systems trigger work in the background. Follow-up tasks happen later and from different places. A useful agent needs to handle that reality without losing its identity or scattering its context.
That is the core idea behind process agents in MeshAgent: one agent, multiple ways in, with threads preserving continuity where it matters and built-in tools giving that agent meaningful ways to do work.
Join our Discord Server to stay up to date with MeshAgent releases, ask questions, and share feedback with our team.
Check out the MeshAgent documentation to start building today.
MeshAgent Studio, SDK, and Server give you everything to build, test, and deploy agentic applications, from development to production.
