Compare Platform Plugin capabilities

Compatibility scope

An Agent is created without a required communication Platform. Communication is added afterward as one or more Communication Connections.

• An Agent can have zero, one, or many Communication Connections.
• The same Agent can have multiple Connections for the same Platform, such as two Slack workspaces.
• Platform selection is independent of Runtime selection.
• Both Hermes and OpenClaw consume the same runtime-neutral Communications protocol.
• All five external Platform Plugins work with both supported Runtimes.

Where this page says a control is not available, it means Agent Barn does not currently expose it as a Connection policy. The underlying provider may still offer an equivalent control through its own administration.

See Communication Connections for the full ownership and lifecycle model.

Quick answer

These are selection guidelines, not Platform rankings. Choose based on where your users already work and which access boundary you need.

Runtime independence

Every shipped Platform Plugin works with either Runtime. There is no Runtime-versus-Platform compatibility matrix to satisfy.

Choose a Runtime on its own merits: operating model, command approval, Template compatibility, Skills, and resource footprint. See Choose an Agent runtime.

Connection ownership

Provider connectivity belongs to the Communication Connection and the Communications Gateway, not to the Agent Runtime.

• Provider sessions and per-Connection credentials stay in Communications; Email uses deployment-managed credentials.
• The Communications Gateway owns provider connectivity, inbound normalization, policy enforcement, and outbound delivery.
• Provider credentials are encrypted and are never returned through the API after being stored.
• Provider tokens are not passed into the Agent Runtime.
• Conversations and resolved identities remain scoped to their Connection.
• Connection changes reconcile independently and do not require restarting the Agent.

Platform capability comparison

Each capability below describes what a Communication Connection configures and enforces for that Platform.

Shared-space access, direct-message access, and mention requirements are Connection policies. They are not Runtime capabilities, and they can be changed without recreating the Agent.

Provider ingress

Slack, Telegram, and Discord use supervised provider sessions. Teams and Email use different webhook ingress paths: Teams addresses one Connection, while Email resolves the allocated recipient address through the shared inbound route. Built-in Web Chat uses authenticated Product API routes and is not another external webhook setup.

The Microsoft Teams webhook is scoped to a Communication Connection rather than to an Agent, and has this shape:

https://AGENT_BARN_HOST/communications/v1/webhooks/CONNECTION_ID

A Teams Connection therefore needs a stable external Agent Barn URL and public HTTPS access to the Communications webhook prefix. A Teams app package may be available for download from the Connection when the installed Teams Platform Plugin exposes that capability.

Slack, Telegram, and Discord need no inbound route into the deployment.

Credential requirements

Each Platform Plugin defines its own credential schema. Credentials are entered on the Connection.

Secret classification

Use a distinct bot or application identity for each production Connection, and do not run two Connections against the same provider bot token.

Access controls

Two separate authorization boundaries apply, and they are not interchangeable:

• Agent Access controls who can view or manage the Agent inside Agent Barn.
• Communication Connection policies control which provider-side users, channels, chats, servers, roles, or conversations may interact with it.

Channel access:  Allowlist
Direct messages: Off or Allowlist
Thread mentions: every_message

Group access:    Allowlist
Direct messages: Off or Allowlist
Mention gating:  Required

Server access:            Allowlist
Allowed channels:         Explicitly configured
Allow all users:          Disabled
Allowed users or roles:   Explicitly configured
Require explicit mention: Enabled
Direct messages:          Off

Mention and direct-message policy

Agents should not act on ordinary conversation in shared spaces unless they are intentionally addressed. How strictly that is enforced is a Connection policy, not a fixed Platform trait.

Slack thread mention behavior

A Slack Connection chooses between two thread behaviors.

every_message requires a fresh mention for each message, including thread replies:

• @agent first request delivered
• thread reply without @agent ignored
• @agent follow-up request delivered

start_only requires the mention that starts the thread, after which replies in that thread can continue without a new mention:

• @agent first request delivered
• thread reply without @agent may be delivered
• unrelated channel message ignored

Use every_message for shared channels where several people talk, and start_only where a thread is a deliberate working session with the Agent.

Microsoft Teams, Telegram, and Discord

• Microsoft Teams requires an Agent mention for group and channel messages.
• Telegram requires an explicit mention in group chats.
• Discord exposes configurable mention gating for server channels.

Keep mention gating enabled unless a channel is deliberately dedicated to one Agent.

Direct messages

Direct messages do not require a mention, and every Platform supports the same three-way policy: off, open, or allowlist. Choose per Connection based on who should be able to reach the Agent privately.

Changing mention or direct-message policy is a Connection update. It reconciles on its own and does not require restarting the Agent.

Operational differences

Activity name enrichment

Directory results are cached, so a recently changed name may not appear immediately. Provider identifiers remain authoritative even when a human-readable name is displayed, and resolved identities stay scoped to their Connection.

Scheduled and initiated messages

Slack currently supports Agent-initiated delivery through Agent Barn Communications. Interactive sends require a live inbound execution and remain on its Connection. Scheduled results use their recorded origin or the Agent's configured default, subject to runtime limitations and the Connection's current policies.

Email, Teams, Telegram, Discord, and built-in Web Chat do not currently advertise this initiated-delivery capability. Their existing inbound and reply paths are separate. A destination-like setting alone does not enable scheduled delivery on another plugin.

For Slack setup and the default target, see the Slack guide. For Hermes and OpenClaw completion routing and recovery, see Runtime Assembly and Deployment.

Additional provider-specific behavior

Choose a Platform

Use this sequence.

1. Choose the Platform where the intended users already work.
2. Create the Agent with the appropriate Runtime and Template.
3. Add one or more Communication Connections.
4. Follow the selected plugin’s credential or deployment setup and configure its policies.
5. Enable the Connection when it is ready to receive traffic.

Platform choice does not constrain Runtime choice, so it never eliminates a Runtime option. If a second audience uses a different provider, add another Connection instead of starting over.

See Hire your first Agent for the creation flow, then Communication Connections for the Connection workflow.

Multi-Platform Agents

One Agent can expose the same role through several Connections at once:

These Connections share the same Agent (its Runtime, Template Version, Skills, Integrations, and cost identity) while provider credentials, policies, identities, and conversation histories stay Connection-scoped.

Do not clone the Agent merely to support another Platform. Use a separate provider bot or application identity for each Connection, and never run two Connections against the same provider token.

API values

Runtime values

agent_type selects the Runtime:

hermes
openclaw

Agent creation

An Agent creation request carries no Platform fields:

{
  "name": "Example Agent",
  "agent_type": "hermes",
  "template_key": "REPLACE_WITH_TEMPLATE_KEY",
  "model": "REPLACE_WITH_MODEL",
  "skill_ids": []
}

Platform configuration is created separately as a Communication Connection after the Agent exists, and the Platform-specific settings and credentials are defined by the selected Platform Plugin.

Setup guides

Continue with the setup guide for the selected Platform.

After adding a Connection:

• Review the Connection lifecycle
• Review Agent health and logs, separately from Connection health
• Test an allowed shared-space request.
• Test an unmentioned shared-space message.
• Test a user or destination outside the intended boundary.
• Record credential ownership and rotation procedures.
• Review the Template and Skills assigned to the Agent.

Email and built-in Web Chat

Agent Barn ships external Platform Plugins for Slack, Microsoft Teams, Telegram, Discord, and Email, plus built-in Web Chat. Email requires deployment configuration. Web Chat is built into the Agent page and does not require external provider credentials.

Email ingress runs from a Cloudflare Email Worker to an authenticated Product API inbound route. Access is Open or sender allowlist, with an empty allowlist by default. Address local parts are permanently non-reissued. Credentials are deployment-managed, with no per-Connection provider credentials. Content is threaded plain-text inbound and replies: no attachments, reply-only. Web Chat is separate from external provider ingress.