No adapter registered for platform "${channel.platform}"

Error message

No adapter registered for platform "${channel.platform}"

What it means

After finding a channel context in RequestContext, getAdapterFromContext looks up this.adapters[channel.platform]. If the platform name from the context is not a registered adapter, it throws this error distinguishing it from the missing-context case: context exists, but no adapter handles that platform.

Source

Thrown at packages/core/src/channels/agent-channels.ts:948

    if (!this.toolsEnabled) return {};
    return this.makeChannelTools();
  }

  // ---------------------------------------------------------------------------
  // Private
  // ---------------------------------------------------------------------------

  /**
   * Resolve the adapter for the current conversation from request context.
   */
  private getAdapterFromContext(context: { requestContext?: RequestContext }): { adapter: Adapter; threadId: string } {
    const channel = context.requestContext?.get('channel') as ChannelContext | undefined;
    if (!channel?.platform || !channel?.threadId) {
      throw new Error('No channel context — cannot determine platform or thread');
    }
    const adapter = this.adapters[channel.platform];
    if (!adapter) {
      throw new Error(`No adapter registered for platform "${channel.platform}"`);
    }
    return { adapter, threadId: channel.threadId };
  }

  /**
   * Derive the three per-event shapes we hand off to downstream systems from one set of
   * inputs. Keeping this in one place ensures the LLM (`attributes`), input processors
   * (`requestContext`), and memory (`metadata`) all see consistent author / thread facts.
   *
   *   - `channelContext` — goes on `requestContext` under the 'channel' key, consumed by
   *     `ChatChannelProcessor` and other input processors.
   *   - `attributes` — serialized as XML on the user message element the LLM sees (e.g. on
   *     `<user messageId=... authorId=... />`). Strings only.
   *   - `providerOptions` — written to the stored message's `content.providerMetadata`
   *     under `mastra.channels.<platform>` so UI/query callers can read author/channel
   *     facts off the message (e.g. show a Slack icon + author name) without unpacking
   *     the signal envelope. The LLM ignores `providerOptions.mastra.*` since only
   *     provider-keyed entries (openai, anthropic, …) are forwarded to the model.

View on GitHub (pinned to 75dd419e61)

Solutions

Register an adapter under the exact platform name present in the channel context
Log/inspect the context's channel.platform and align adapter keys with it
Normalize platform names (e.g. lowercase) when setting the channel context

Example fix

// before
ctx.set('channel', { platform: 'Slack', threadId: 'C1' }); // adapters keyed 'slack'
// after
ctx.set('channel', { platform: 'slack', threadId: 'C1' });

Defensive patterns

Strategy: validation

Validate before calling

const channel = ctx?.get('channel') as ChannelContext | undefined;
if (channel?.platform && !(channel.platform in channels.adapters)) {
  logger.warn(`Unknown platform in context: ${channel.platform}`);
  return;
}

Type guard

function isKnownPlatform(p: string, adapters: Record<string, unknown>): p is keyof typeof adapters {
  return p in adapters;
}

Try / catch

try {
  await channels.reply(message, { requestContext: ctx });
} catch (err) {
  if (err instanceof Error && /No adapter registered for platform/.test(err.message)) {
    logger.error({ platform: ctx.get('channel')?.platform }, 'platform not registered');
  } else throw err;
}

Prevention

Normalize platform names to lowercase keys
Share one PLATFORMS constant across context producers and adapter registration
Add a registration test asserting every platform your integrations emit has an adapter

When it happens

Trigger: RequestContext 'channel' key present with a platform value that has no entry in the AgentChannels adapters map — e.g. typo'd platform string, adapter registered under a different key, or context produced by a different channels configuration.

Common situations: Renaming adapter registration keys while old messages/contexts still carry the previous platform name; multiple channels instances with different adapter sets; hand-crafted context objects with wrong platform values.

Related errors

AI-assisted analysis of mastra-ai/mastra@75dd419e61 (2026-08-30). Data as JSON: /api/errors/46ff7374c90c59e5. Report an issue: GitHub.