Channels
Added in: @mastra/core@1.22.0
Channels connect agents to messaging platforms. Configure them via the channels property on the Agent constructor. The object you pass is a ChannelConfig. See the Channels overview for concepts and platform setup instructions.
Usage exampleDirect link to Usage example
import { Agent } from '@mastra/core/agent'
import { createSlackAdapter } from '@chat-adapter/slack'
import { createDiscordAdapter } from '@chat-adapter/discord'
export const supportAgent = new Agent({
id: 'support-agent',
name: 'Support Agent',
instructions: 'You are a helpful support assistant.',
model: 'openai/gpt-5.5',
channels: {
adapters: {
slack: createSlackAdapter(),
discord: createDiscordAdapter(),
},
},
})
ParametersDirect link to Parameters
The channels property accepts a ChannelConfig object with the following fields:
adapters:
slack, discord). Pass an Adapter directly for defaults, or a ChannelAdapterConfig object to customize per-adapter options.handlers?:
inlineMedia?:
inlineLinks?:
tools?:
add_reaction, remove_reaction). Set to false for models that do not support function calling.state?:
MastraStateAdapter backed by the Mastra instance storage. Channels require storage to be configured.userName?:
name, or 'Mastra' if no name is set.threadContext?:
maxMessages controls how many recent platform messages are fetched on first mention (set to 0 to disable; only applies to non-DM threads). addSystemMessage: false skips the built-in system message that tells the agent which channel/platform a request came from.chatOptions?:
dedupeTtlMs, fallbackStreamingPlaceholderText, lockScope, and messageHistory.resolveResourceId?:
resourceId owns resource-level memory for a channel thread, separately from who sent the message. Runs only when a new thread is created; reused threads keep their stored owner and never call the hook. Return ctx.defaultResourceId (${platform}:${message.author.userId}) to keep the built-in behavior.waitUntil?:
waitUntil function. Required on Vercel so background agent runs survive after the webhook returns 200. On Vercel pass waitUntil from @vercel/functions. Cloudflare Workers and Netlify Functions are detected automatically from the request context. AWS Lambda does not need waitUntil because it waits for the event loop to drain naturally.resolveWaitUntil?:
waitUntil lives on the Hono request context but is not covered by the built-in helper. Resolution order: bare waitUntil → resolveWaitUntil(c) → default (Cloudflare Workers, Netlify).Per-adapter optionsDirect link to Per-adapter options
Wrap an adapter in a ChannelAdapterConfig object to set per-adapter options:
import { Agent } from '@mastra/core/agent'
import { createDiscordAdapter } from '@chat-adapter/discord'
import { createSlackAdapter } from '@chat-adapter/slack'
const agent = new Agent({
id: 'example',
name: 'Example',
instructions: '...',
model: 'openai/gpt-5.5',
channels: {
adapters: {
discord: {
adapter: createDiscordAdapter(),
toolDisplay: 'text',
cors: {
origin: ['https://customer-saas.example'],
credentials: true,
},
gateway: false,
},
slack: createSlackAdapter(), // Plain adapter uses defaults
},
},
})
adapter:
gateway?:
false for serverless deployments that only need webhook-based interactions.cards?:
toolDisplay instead. When toolDisplay is not set, cards: true maps to toolDisplay: "cards" and cards: false maps to toolDisplay: "text". IDEs flag the field with a strikethrough; runtime behavior is preserved.cors?:
formatError?:
formatToolCall?:
toolDisplay (function form) instead. When set, runs as a ToolDisplayFn that only fires on result/error events; running and approval events fall through to no render. Mutually exclusive with toolDisplay at the type level.streaming?:
true; other adapters default to false.toolDisplay?:
"cards" posts per-tool running/result cards as rich Block Kit. "text" posts the same lifecycle as plain text (no Block Kit). "timeline" and "grouped" stream tool state as inline task_update chunks (requires streaming: true; Slack only today — other adapters may render a placeholder). "hidden" executes tools silently. Pass a function to render tool events yourself; return { kind: "post", message } for a discrete post/edit, { kind: "stream", chunk } to push into the active streaming widget, or undefined to skip rendering that event. Approve/deny prompts always render as a separate card regardless of mode.typingStatus?:
true uses built-in defaults (is typing… on text, is calling {tool}… on tool-call, is waiting for approval… on tool-call-approval). false suppresses typing entirely — useful when a live streaming widget (e.g. toolDisplay: "grouped" in Slack) already conveys progress. Pass a function to set custom status copy per chunk; return a string to set the status, or false/null/undefined to leave it unchanged. Compose with defaultTypingStatus (exported from @mastra/core/channels) to fall back to defaults for chunks you don't handle.Tool display modesDirect link to Tool display modes
toolDisplay controls how tool calls render in chat. The default 'cards'
posts a "Running…" card per tool and edits it with the result, matching the
behavior in earlier versions. 'text' is the same lifecycle but without rich
Block Kit, useful for platforms that don't render cards well.
'timeline' and 'grouped' stream tool state as inline task_update chunks
alongside the agent's text. These modes require streaming: true and rely on
the chat adapter to render the chunks. Slack supports both natively; other
adapters may render a placeholder until they ship support. If streaming is
disabled, the channel logs a one-time warning and falls back to 'cards'.
'hidden' executes tools silently. Only the typing status indicates work in
progress.
Pass a function to toolDisplay for fully custom rendering. The function
receives a ToolDisplayEvent (running / result / error / approval)
and a ToolDisplayContext ({ mode, platform }); return { kind: 'post', message } for a discrete post/edit, { kind: 'stream', chunk } to push into
the active streaming widget, or undefined to skip rendering that event.
Approve/deny prompts (requireApproval) always render as a separate card
regardless of mode, because inline task entries can't carry interactive
buttons.
import { Agent } from '@mastra/core/agent'
import { createSlackAdapter } from '@chat-adapter/slack'
const agent = new Agent({
id: 'streaming-agent',
name: 'Streaming Agent',
instructions: '...',
model: 'openai/gpt-5.5',
channels: {
adapters: {
slack: {
adapter: createSlackAdapter(),
streaming: true, // already the Slack default
toolDisplay: 'timeline',
},
},
},
})
Custom typing statusDirect link to Custom typing status
Pass a function to typingStatus to customize the status copy. The function is
called once per stream chunk; return a string to set the status, or false /
null / undefined to leave the current status unchanged. Return values are
de-duplicated so the platform only sees a call when the status changes.
defaultTypingStatus is exported from @mastra/core/channels so you can
fall back to the built-in defaults for chunks you don't handle.
import { Agent } from '@mastra/core/agent'
import { defaultTypingStatus } from '@mastra/core/channels'
import { createDiscordAdapter } from '@chat-adapter/discord'
const agent = new Agent({
id: 'custom-typing-agent',
name: 'Custom Typing Agent',
instructions: '...',
model: 'openai/gpt-5.5',
channels: {
adapters: {
discord: {
adapter: createDiscordAdapter(),
typingStatus: (chunk, ctx) => {
if (chunk.type === 'tool-call' && chunk.payload.toolName === 'searchDocs') {
return 'is searching docs…'
}
return defaultTypingStatus(chunk, ctx)
},
},
},
},
})
HandlersDirect link to Handlers
Override built-in event handlers. Each handler can be:
- Omitted: uses the default Mastra handler (routes the message through the agent and posts the response)
false: disables the handler entirely- A function
(thread, message, defaultHandler) => Promise<void>: wraps or replaces the default
import { Agent } from '@mastra/core/agent'
import { createSlackAdapter } from '@chat-adapter/slack'
const agent = new Agent({
id: 'custom-handler-agent',
name: 'Custom Handler Agent',
instructions: '...',
model: 'openai/gpt-5.5',
channels: {
adapters: {
slack: createSlackAdapter(),
},
handlers: {
onMention: async (thread, message, defaultHandler) => {
console.log('Received mention:', message.text)
await defaultHandler(thread, message)
},
onDirectMessage: false,
},
},
})
onDirectMessage?:
onMention?:
onSubscribedMessage?:
The ChannelHandler function signature:
type ChannelHandler = (
thread: Thread,
message: Message,
defaultHandler: (thread: Thread, message: Message) => Promise<void>,
) => Promise<void>
Resource ID resolutionDirect link to Resource ID resolution
By default a channel thread's memory resourceId is ${platform}:${message.author.userId}. The sender owns the memory, scoped per platform. For apps with a shared identity, such as single sign-on (SSO), this splits memory: the same user gets feishu:user_123 in a Feishu DM but user_123 on the web.
Pass resolveResourceId to decide memory ownership separately from the sender. It runs only when a new thread is created. Reused threads keep their stored resourceId and never call the hook, so existing conversations don't depend on the resolver being available. Return ctx.defaultResourceId to fall back to the built-in behavior.
import { Agent } from '@mastra/core/agent'
import { createSlackAdapter } from '@chat-adapter/slack'
const agent = new Agent({
id: 'sso-agent',
name: 'SSO Agent',
instructions: '...',
model: 'openai/gpt-5.5',
channels: {
adapters: {
slack: createSlackAdapter(),
},
resolveResourceId: async ({ thread, message }) => {
// DM: share resource-level memory with the web app by using the bare SSO id
if (thread.isDM) {
return await resolveSsoUserId(message)
}
// Group chat: the conversation owns the memory; the sender stays the actor
return thread.channelId
},
},
})
The ResolveResourceIdContext passed to the function:
platform:
slack, discord).thread:
thread.isDM to tell DMs apart from group/channel threads.message:
message.author.userId is the actor/sender, not necessarily the memory owner.defaultResourceId:
${platform}:${message.author.userId}). Return this to keep the current behavior.Inline mediaDirect link to Inline media
Controls which attachment types (images, video, PDFs, etc.) are sent as file parts to the model. Types that don't match are described as text summaries so the agent knows about the file without crashing models that reject unsupported types.
The default (['image/png', 'image/jpeg', 'image/webp', 'application/pdf']) matches the formats supported by major vision models. Override inlineMedia to expand the list (e.g. ['image/*', 'audio/*']) or replace it entirely with a predicate function.
Supported glob patterns:
| Pattern | Matches |
|---|---|
image/* | All image types (image/png, image/jpeg, etc.) |
video/* | All video types |
* or */* | All types |
application/pdf | Exact type match |
For platforms with private CDNs (e.g. Slack), attachments are fetched with authenticated credentials from the Chat SDK. For platforms with public CDNs (e.g. Discord), the URL is passed directly to the model.
Inline linksDirect link to Inline links
Promotes URLs found in message text to file parts so the model can process linked content instead of seeing raw URL text. Each entry can be a string (domain pattern) or an object with a forced mime type.
String entries match a domain and perform a HEAD request to detect the Content-Type. The resolved type is checked against inlineMedia and only matching types become file parts.
Object entries match a domain and force a specific mime type, skipping the HEAD request and bypassing the inlineMedia check. This is useful for sites like YouTube where a HEAD request returns text/html, but the model treats the URL as video content.
type InlineLinkEntry =
| string // Domain pattern (HEAD determines mime type)
| { match: string; mimeType: string } // Domain + forced mime type (skips HEAD)
RelatedDirect link to Related
- Channels overview: Concepts, quickstart, and platform setup
- Agent class: Constructor parameters and methods
- Chat SDK adapters: Adapter configuration and platform setup