Build
Agent messaging
Agent messaging is the plain version of using an agent: somebody sends it a message and it answers. Then they ask a follow-up and it still knows what they were talking about.
Use it when the next message decides what happens. A technician mid-call asking "what's the warranty on this serial number?" and then "and what did we quote them last year?" is a conversation. There's no process to define; they just need answers.
A routine is the other shape: the same request, on a schedule you approved. Both use the same agents, and a routine lives inside a conversation. Pick plain messaging when you can't predict the next question.
What it looks like in practice
Northwind IT keeps Scout in #service-desk. Somebody types @Scout what's Ridgeline's escalation path? and gets an answer in the thread. Somebody else
asks it to summarize a long ticket before picking it up.
Nobody built a job for either of those. They just asked.
Where the conversation can happen
| Where | Good for |
|---|---|
| The Mobius app | Trying an agent out, and internal use |
| Slack or Telegram | Your team, where they already are |
| An address people outside your team can write to | |
| Your own software | A chat window in a client portal or a technician tool |
Same agent, same history, different doorway. A conversation that started in Slack is the same session you can read in the app.
What happens to a message
- Someone sends a message from the app, Slack, Telegram, email, or your software.
- Mobius works out which agent it's for and which conversation it belongs to.
- It finds the existing session, or starts a new one.
- The agent takes its turn and its reply is written into the transcript.
- The reply goes back to wherever the message came from.
Step four and step five are separate on purpose. Slack can be down and the agent's answer still exists in Mobius. If a reply never showed up in a channel, check the session first: if the answer is there, it's a delivery problem, not an agent problem.
Try it in the app first
Open Build > Agents, pick your agent, and click Chat. Give it a real task from your actual work, not a test question.
Chat conversations are real sessions, so you can come back to one later and carry on. Start a new chat when the subject changes and old context would just get in the way.
Do this before connecting a channel. It's much easier to fix instructions in a window nobody else is watching.
Connect Slack or Telegram
First connect the provider under Library > Integrations. Then open the agent's Configure page and find Messaging > Chat integrations.
For each connected provider you decide:
- Whether it's on.
- What wakes the agent up: being mentioned, every message in the channels you pick, or both.
- Which channels it listens in.
- Which people it will answer.
- Whether it accepts direct messages, and from whom.
- Which AI model it uses and how it handles long conversations.
Start narrow. One channel, mentions only. Watch it for a day. Then widen.
An agent set loose on every message in a busy channel becomes noise very fast, and the first impression your team forms is hard to undo.
Reading conversations
Click Sessions on the agent to see every conversation, from every doorway. Open one to read the transcript, see which tools the agent used, and follow it back to Slack, Telegram, a job, or your software.
Recent delivery failures show up alongside the agent's messaging settings.
An email address for an agent
An agent can have its own email address, provisioned from its Messaging
section. Mail sent there reaches the agent, and email.received can start a
job.
This is how you point a support@ alias at Mobius, and it's the easiest way to
get real work flowing in without touching your PSA.
Warning: Anyone can email an address. Treat everything arriving that way as untrusted: keep the agent's actions narrow and put an interaction in front of anything that sends, changes, or spends.
Behind your own software
If you build a portal or an internal tool, you can put the same agent behind a chat window in it. Your backend picks a stable key for each conversation, sends the user's message, and reads or streams the reply.
Nothing about Slack or Telegram is involved, and you don't have to duplicate any configuration.
Request formats, duplicate handling, and reconnection behavior are in Agent invocation. Lower-level control is in Sessions and turns.
FAQ
Should this be a conversation or a routine?
If you already know the request and only the timing changes, ask for a routine. If the person's next message determines what happens, keep it a conversation.
When you're unsure, start with a conversation. It's easier to notice a pattern in real questions and put it on a schedule later than to schedule work you haven't seen yet.
Can a conversation turn into a routine?
Yes, and that is the intended path. Ask for it in the conversation itself. The agent proposes a routine, you approve the schedule and its limits, and each occurrence comes back to that same conversation.
Next
- Understand what a conversation remembers: agent sessions.
- Connect a provider from the integration catalog.
- Put a chat window in your own software with Agent invocation.
- Operate it from the terminal with the CLI command reference.