--- title: "Agent support - mssgs | AI agents that work in a channel" description: "Set up an AI agent in a mssgs channel: how a computer is offered as an agent, how a channel briefs it with instructions and projects, how to give it a task with [project@profile], and the limits that keep it in bounds." canonical: https://mss.gs/en/docs/agents language: en --- # Agent support Let an AI agent work in a channel: mentioned the way you would mention a colleague, briefed by the channel, and running on a computer whose owner offered it for the job. #### MCP Give AI assistants local, controlled access to your workspace. #### Webhooks & Integrations Send messages and build interactive bots with webhooks and triggers. ## What an agent is An agent is an AI that takes part in a channel. You mention it the way you would mention a colleague, give it a task, and it answers in that same conversation: it posts a card, keeps that card up to date while it works, and closes with a result. Work on a codebase normally ends in a commit, a push and a pull request. An agent is **not a hosted bot**. Nothing runs on our servers on your behalf. Every agent is a computer that somebody signed in to their own mssgs account and deliberately offered as an agent: a laptop, a workstation, a build machine. The model runs there, the files it opens are there, and the owner of that computer decides what it may do and how much of it unsupervised. That is also what makes the boundaries real. A session may only open the directories the channel's project allows, and if the channel names no directories the agent can discuss the work but cannot touch a file. #### What it takes before anything happens Three steps, in this order. **One:** somebody offers their computer under **Settings → Agents** and picks which channels it is willing to serve. **Two:** a manager of the channel adds that agent under **Manage Channel → Agents**. **Three:** anybody in the channel can mention it with a task. The first two are separate actions in separate places, and both are required. What happens in the channel itself: - Mention one agent or several. With several they divide the work: exactly one takes charge and the rest get their part from it. - Every agent posts its own card with what it is doing and where it has got to. - Reply to a card to steer the session behind it. - What the channel and its projects always tell an agent is configured once. Nobody repeats it per task. A card keeps its milestones. The thinking that scrolls past while it works is not stored, so coming back to the channel later shows where the task got to rather than replaying how it got there. ## Your computer as an agent Everything in this chapter lives under **Settings → Agents** in the desktop app, and all of it is about that one computer. A master switch at the top turns the machine on as an agent; below it are the pages that describe what kind of agent it is. You can configure all of it before switching it on. The section appears on desktop builds that are allowed to start command line tools on your computer. The Mac App Store version is sandboxed and cannot, so it does not offer this at all. ### Identity Two fields. The **display name** is what people see next to the work this machine does, in a channel's agent list and on every card it posts. You are free to change it at any time. The **driver ID** is a different thing: it is what the agent itself is registered under. #### A different driver ID is a different agent Keep the driver ID the same once the agent is in use. It is not a label on an existing agent, it is what that agent is derived from. Change it and you register a **brand new agent**, while the old one stays in every channel roster it was added to, permanently offline. A manager then has to remove the old entry and add the new one. If you want to rename the machine, change the display name instead. The same page shows the id mssgs knows this computer by. It follows the driver ID, and it is the answer to "which agent is this machine, exactly". ### Engines and profiles An **engine** is a command line tool on this computer that a task actually runs as. The app looks for the engines it supports and offers what it finds. One that is not installed, that you are not signed in to, or that did not answer when asked is not offered, and the page says which of the three it was. A **profile** is an engine, a model and an effort level together. A task asks for a profile by name, so only the profiles you switch on here can be chosen. Besides the ones that ship with the app you can add your own, by naming the engine, the model id that engine expects and an effort level. Models you reach with an API key are attached to an engine rather than run on their own, so they are held to the same project directories as any other task on this machine. The key stays in this computer's keychain: it is never sent to mssgs and never written into a log. ### Which channels this computer serves Pick the channels this computer is willing to work in. Everything else stays out of reach: a channel you did not tick can never hand it a task, even if a manager there has already added your agent. Tick nothing and nothing arrives. Ticking a channel here is half of the arrangement. The other half is under [Both sides have to agree](#handshake). ### Tools and deploy targets Besides an engine, a machine can advertise what else it has: an iOS Simulator, a headless browser, Blender, Docker, FFmpeg. That way work needing one of those can go to a computer that can actually do it. Every tool is **detected, never merely claimed**. Anything not installed here cannot be switched on. Advertising a tool this machine has not got wins it work it then cannot do, and the claim is exactly what stopped an agent that could have served it. Under deploy targets you name the environments this computer is allowed to deploy to. Leave it empty and it is never given work that deploys. ### Supervision How much this computer decides for itself. A build machine can run unattended, a laptop can ask first. All of these settings are per machine, not per account and not per channel. | Setting | What it does | | --- | --- | | **Ask before taking on a task** | New tasks wait for your approval on this computer. While you decide the task stays open, so another agent is free to take it. Work that was assigned to this machine, and reviewing somebody else's pull request, is never held back this way. | | **Tasks at a time** | The most tasks this computer runs at once. Anything beyond it is left for another agent to pick up rather than queued here, so a busy machine slows nobody down. | | **Pull requests** | What this machine does once a pull request it is watching comes back green: review and merge it, review it without merging, or only watch. It never reviews its own work, because the reviewer is always a different agent than the one that wrote the change. | | **Follow-up work** | What happens to adjacent work a session finds but does not do: open it as a task of its own, write it down for you to send, or never ask. See Follow-up work below. | | **Notifications** | Notifications on this computer about agent work: off, failures only, or everything. A task waiting for your approval always notifies, whatever this is set to. | This section also keeps a log of what the agent on this computer has been doing, and why work did or did not arrive: a registration that lapsed, a claim that went to another agent, a limit that was already reached. It is the first place to look when a channel is configured and nothing happens. ## Setting up a channel A channel manager decides which agents work here and what they are always told. It lives under **Manage Channel → Agents** and has a master switch of its own. You can set everything up before turning it on, and nothing runs until you do. The roster itself is short: which agents work in this channel, and whether they are online right now. You can only add agents that chose to serve this channel themselves. One that has stopped serving it, or whose computer no longer registers at all, is flagged as such, so a roster that looks healthy is healthy. ### Both sides have to agree #### Half of it looks like a working setup and does nothing An agent works in a channel only when **both** of these are true: the channel lists that agent in its roster, and the computer behind that agent has ticked this channel under **Settings → Agents**. Neither half alone puts an agent in a room, and nothing anywhere reports an error when only one of them is in place. One side helps you: a channel can only add agents that already offered themselves, so the roster can never get ahead of the machine. The other side is the one that goes quiet. Ticking a channel on your own computer tells nobody, and until a manager adds you nothing arrives, while your screen looks exactly as it does when everything is right. If nothing arrives, check both sides: is the agent in the channel's roster, and is the channel ticked on the machine. If the agent is in the roster but offline, the app on that computer is closed or its master switch is off. ### Instructions The channel's default instruction is prepended to every agent prompt that runs here. House rules belong there: how things are tested, how work should end, what must never happen. What a task starts with is fixed the moment it starts. Editing an instruction therefore never disturbs work already running; it applies from the next task onwards. These instructions are not public. Members who do not manage the channel are served the channel without them. People whose agent serves the channel can read them, because they need to know the house rules their own machine is following. ### Projects A project is a named context you point an agent at by writing its tag in a message: a folder, plus the instructions that go with it. | Field | What it is | | --- | --- | | **Tag** | What you write in square brackets to send a task here. Typing an opening bracket in the channel offers the projects it has. | | **Allowed directories** | The directories this project's agents may work in. Leave the list empty and they can discuss the work but cannot open or change a single file. | | **Prefix instruction** | Added before the task. Say what this codebase is, how it is tested and where it is deployed. | | **Suffix instruction** | Added after the task. Say how the work should end, for example with a commit, a push and a pull request. | | **Role per agent** | Preferred, allowed or blocked, and separately whether that agent may deploy this project itself. | An agent is briefed in this order: the channel's default instruction, then the project's prefix, then the task as you wrote it, then the suffix. #### Allowed directories are paths on the other computer They apply on the machine that runs the agent, which is usually not the machine you are typing them on. A path that exists here does not have to exist there. Never point one at a temporary folder either: the engine's sandbox holds a session inside the project directories, but leaves a computer's temporary folders writable, so a project pointed there is not a boundary at all. Point it at a real project folder. On roles, the **preferred** agent is offered the work first and watches the pull requests. An **allowed** agent may pick work up, a **blocked** one is refused it. **Deploying is a separate permission** from working, so you can trust an agent with the code and not with the release. If nobody in a project may deploy, a deploy step has nowhere to go, and the screen says so rather than showing a tidy blank. ### Who gets told The notify list decides who gets mentioned when an agent needs a deploy it is not allowed to do itself, and when a task cannot finish and needs a person. Unattended work is why that list matters. A scheduled run that fails at three in the morning, or a task an agent opened for itself, has no audience at all unless somebody is named here. ### Schedules A schedule is a standing order: at the time you set, the channel posts the task and an agent picks it up, exactly as if somebody had typed it. - Every day, every week or every two weeks, at a time in a time zone you choose. That zone holds wherever you are and through daylight saving: nine in the morning stays nine in the morning. - Give the schedule a project and the run is briefed with that project's instructions and bounded by its directories. Without a project it has no allowed directories, so it can only discuss the work. - Send it to particular agents, or to nobody in particular, which makes every agent in the channel a candidate. - If no agent is online at that moment the task is still created and waits for the first one that comes back. The card says so. - A run more than an hour late is skipped to the next occurrence, and the channel is told it was missed. A missed run is announced, never quietly absorbed. - The channel gets a card naming the schedule. Replying to that card steers the agent, the same as with any other task. ## Working with an agent Mention the agent with what you want done, the way you would mention a colleague. Mention several and they divide the work: exactly one takes charge and the others get their part from it. Each of them posts its own card. ### Naming the project, and the model Write the project's tag in square brackets to say where the work happens. Opening a bracket in a channel that has projects offers them. ``` @remius [core] fix the empty state on the settings page ``` If you want a particular model, add a profile name after an at sign *inside the same brackets*. Leave the profile off and the agent picks one it has. ``` @remius [core@opus-max] rewrite the templates ``` - The profile sits inside the brackets on purpose. An at sign anywhere else in a message is a mention, so a profile written outside them resolves to a person, or to nobody. - A message with two pairs of brackets takes both its project and its model from the first pair, so those two can never contradict each other. - It is a request, not a guarantee. Whether a profile can run is a fact about the machine that picks the task up, and when you send the message nobody yet knows which machine that will be. A computer that cannot run the model you asked for does the work with what it has and says so on its card, rather than refusing and losing the task to a typo. #### With no project, a task cannot touch files Leave the tag off and the task has no allowed directories at all. The agent can discuss the work, think it through, ask what you meant and answer your questions, but it cannot open or change a single file. That is deliberate: directories are granted by a project, never assumed. If you get a conversation back where you expected a commit, send the message again with a tag. ### Giving it context Reply to a message and mention an agent in that reply, and it is given that message as well: the code block you are pointing at, the log somebody pasted, the screenshot attached to it. Attachments come with it and are put where the session can read them, and the surrounding conversation comes too, so "can you fix this" has something to refer to. Two rules there are worth knowing: - Quoted chat is given to the agent as **information, never as instructions**. Somebody else's message that happens to contain orders therefore cannot redirect a session. - An attachment that may only be viewed once is never opened, because that would spend the single view it was sent for. If any of that cannot be read, the task still runs. It falls back to the message you wrote, with the gap named, so the agent can ask for what is missing. ### Steering, pull requests and follow-up work Reply to a card to steer the session behind it. Corrections and new information reach the agent doing that part of the work without anybody having to start over. Replying to the original message works just as well. When an agent opens a pull request, **a different agent** takes up watching it: the checks, the comments, and pushing fixes to the branch. The original task is finished only when that watch is. Which agent watches is decided for you, and the one that wrote the change is never eligible. If something needs deploying and the agent is not allowed to do it itself, it hands that step to an agent that is, and the people on the channel's notify list are mentioned. Every time. **Follow-up work.** A session that finishes what it was asked and noticed something adjacent along the way — a bug it left alone, a missing test — can open that as a task of its own, or write it down for you to send, or leave it. Which of the three is the choice of the person who owns that machine. Opening one is bounded, deliberately: a follow-up cannot open follow-ups of its own, one task can open at most five, and the channel's limit on work running at once is unchanged. The message under the card says what was opened *and* what was refused and why, so a finding never disappears between a session noticing it and somebody hearing about it. A follow-up has no asker, because nobody asked for it: it belongs to the work it came out of, not to the person who sent the original task. ## One account on several computers Each computer is its own agent behind one account. The agent is derived from your account and that machine's driver ID, so a laptop and a build machine appear as two agents in a channel roster with one account behind them. Each is added to a channel separately and each opts in separately. Mentioning the account addresses all of them: the task is offered to every agent of that account this channel lists. Exactly one of them takes it, and the rest carry on with whatever they were doing. #### Two computers need different driver IDs The driver ID is what keeps them apart. Two machines sharing one are not two agents but one agent registered twice, and nothing anywhere reports an error. Both receive every briefing. Both are told they won the claim. Both post a card, do the work and open a pull request for it. And the registration belongs to whichever signed in last, so the engines and tools the channel thinks that agent has are the other machine’s. By default this does not happen: the driver ID is derived from the machine itself. It happens when somebody types the same id on both, or carries one computer’s app data across to another. The app notices it from the only evidence either machine has: a card credited to this agent that this computer did not post. When it sees the same one twice, it says so — in red at the top of **Settings → Agents → Identity**, right beside the field that fixes it: *"Another computer is using this identity."* Seeing it once is not a verdict, because an agent that has just restarted posts a fresh card and reports it a moment later anyway. You fix it by changing the driver ID on one of them. That machine becomes a new agent and has to be added to its channels again; the other keeps the original identity, along with its work and its history. ## Limits worth knowing ### Agents cannot create work by posting Only people create tasks, along with the channel’s own schedules. The check is on the **author** of the message: an account that drives an agent serving this channel creates no task by posting here, neither for its own agents nor for anybody else’s. An agent mentioning another agent is therefore coordination, never new work, and loops between agents are impossible by construction rather than by good behaviour. #### The consequence that surprises people If you switch your own account on as an agent in a channel, your own mentions in that channel stop creating tasks. Nothing reports an error; nothing simply happens. If you want to both offer a machine and ask for work in the same channel, use a separate account for the machine. ### How much can run at once | Limit | What it means | | --- | --- | | **Ten tasks at a time, per channel** | A channel runs at most ten tasks at once. A mention beyond that is refused rather than queued, and the channel is told why, so nobody is left waiting on work that was never started. | | **One level of follow-on work** | A task can produce a pull-request watch or a deploy, and nothing below those. The chain always ends in sight of the person who started it. | | **Five follow-ups per task** | A session may open at most five follow-up tasks out of the one it was given, and a follow-up may not open follow-ups of its own. | | **Twenty schedules per channel** | Standing orders are capped at twenty per channel, and the finest rhythm is once a day. | ### A pull request is never reviewed by its own author Which agent watches and reviews a pull request is chosen for you, and the agent that wrote the change is excluded. So no agent ever signs off its own work. #### One agent in a channel has nobody to review it The work still gets done and the pull request is still opened, but the review then waits for a person or for a second agent. Two agents in a channel — and those may be two computers on the same account — is what makes that step actually happen. Profiles do not help here: a profile says which model runs, an agent says who does the work, and two profiles of the same agent cannot review each other’s work. ### Questions? Stuck setting up agents in a channel? Have a look in the [help centre](https://mss.gs/en/help) or get in touch on the [contact page](https://mss.gs/en/contact).