// agents

Channels: Slack and iMessage

An agent nobody can reach does nothing. Channels put it where people already talk, and they decide where it reaches back when it needs an answer.

01// slack

One home, many mentions, and DMs

Slack is installed once per workspace, then configured per agent. There are exactly three modes, and an agent can use all three at once.

Home channel

at most one

The agent answers every message there, and all of it rides one shared rolling conversation rather than a new session per message. The home channel is also the agent's alert target: alerts arrive as new threads in it. One home channel per agent, per Slack team, enforced in the database rather than only in the UI.

Mention channels

any number

The agent answers only when it is @-mentioned, or when a message continues a thread it is already in. No alerts land here. This is how an agent sits in a busy channel without talking over everyone.

Direct messages

on or off

Authorized members can DM the agent, and each person gets their own rolling conversation with it. DMs always answer, with no mention needed.

saves are atomic

Saving the Slack card writes the whole configuration in one request, which is what keeps the one-home-channel rule true. A channel that was set up elsewhere and answers every message is shown read-only and left exactly as it is, so a save here never silently demotes it.

02// slack tools and workspace settings

What the agent can do in Slack

Being routed into a channel lets the agent answer there. Wiring the Slack tools lets it act there: post on its own initiative, read back through a thread, open a channel, pull someone in.

Tool	What it does
`slack_post_message`	Posts into a channel or thread the agent can reach.
`slack_request_approval`	Posts Approve / Decline buttons and ends the agent's turn. It does not block: when someone clicks, the same session resumes with the answer. This is the one that can actually get a decision.
`slack_conversation_history`	Reads recent messages in a channel.
`slack_conversation_replies`	Reads a single thread.
`slack_list_channels`	Lists the channels the install can see.
`slack_get_channel_info`	Reads one channel's metadata.
`slack_create_channel`	Creates a channel.
`slack_invite_to_channel`	Adds people to a channel by Slack user id.
`slack_lookup_user_by_email`	Turns an email address into a Slack user id, for an invite or an @-mention.

Three settings live on the Slack install itself rather than on any one agent:

Setting	Effect
Default agent for DMs and mentions	The agent that answers anywhere no channel-specific route matches.
Escalation channel id	The channel workspace-level escalations are posted to.
External-user policy	Reject external users (the default), allow listed users, or allow all users.

03// imessage

A phone number your agent answers

iMessage runs through one shared agnt number. You bind a phone number to an agent, and from then on texts from that number reach that agent.

01
Register the number
Adding a number creates a binding in pending state. Nothing routes yet. Confirm the number with its owner first: it is somebody's real phone, and a number already bound elsewhere on the platform is refused.
02
They text the agnt number
The binding flips to confirmed only when that person texts the agnt number. Texting first without a pending binding does nothing, so there is no way to be opted in by someone else.

reply-only

The single iMessage tool is imessage_send_message, and it can only text confirmed contacts in your own workspace. An arbitrary or external number is rejected. The agent can start a text to a confirmed contact whenever it likes, but the relationship has to be opened by the human.

04// the default channel

Where it reaches you when nobody is in the room

Most of an agent's work happens with no chat attached: a schedule fires at 6am, a webhook arrives, another agent hands it a task. When it needs an approval or has to escalate, the default channel is where that request goes.

There are three settings. Auto, the default, resolves live: a confirmed iMessage binding first, otherwise the Slack DM with the person who installed Slack. Picking iMessage or Slack pins the preference, but the concrete target still resolves at send time, so a removed binding degrades to the other channel instead of breaking. With neither connected, requests stay on the dashboard.

05// threads become sessions

The conversation continues

A Slack thread maps to a session, and so does a phone number. Replying continues the same conversation rather than starting a cold one, which is why an agent you have been talking to for a week still knows what you meant by "the second one". Channel chatter in a home channel rides one shared rolling session; DMs get a rolling session per person.

Every one of those conversations is mirrored into the dashboard and opens read-only in the session inspector, so you can audit what the agent said in Slack without being in the channel. See sessions and observability.

06// gating

Reaching a human is opt-in on purpose

The chat-route tools are the bindings family on the workspace MCP surface, and unlike most families they are never served unless you turn them on. Routing reaches into a real person's Slack and phone, so enabling it stays a deliberate act rather than something a freshly connected client inherits. Inbox management is opt-in for the same reason.

Commercially, bindings and email are sold together as the Inbox & Messaging module at $29/mo with a 7-day free trial, which includes one phone number. If a gated call arrives without it, the answer is an upgrade offer carrying the module, its price and a confirm URL a person taps. It is never a protocol error.

Connecting Slack in the dashboard is separate from enabling the tools: the connection is what makes routes possible, the family is what lets a client create them. See tools and tool families.