Skip to content
Alquimia Platform Alquimia Platform Alquimia Platform

Channels

Channels are adapters that connect an agent to an external messaging platform. When a message arrives on a channel, the adapter normalizes it into the standard inference request format and dispatches it through the same execution pipeline as a direct API call. When the agent responds, the adapter routes the answer back to the originating platform.

Supported channels

Section titled “Supported channels”

Alquimia Platform ships adapters for:

ChannelBest for
WhatsAppCustomer support, field service, mobile-first users
Kapso WhatsAppWhatsApp access managed through the Kapso platform
SlackInternal helpdesks, slash commands, team collaboration
EmailTicket-style workflows, formal approvals, document intake

A single agent can have multiple channels. For example, a support agent might accept WhatsApp messages from customers and Slack messages from employees, using the same configuration and memory.

How channels work

Section titled “How channels work”
External platform
       │
       ▼
Webhook / poll endpoint
       │
       ▼
Channel adapter ──► normalized inference request
       │
       ▼
Execution pipeline
       │
       ▼
Channel adapter ◄── final response
       │
       ▼
External platform

The adapter handles three concerns:

  1. Ingestion — parse the provider-specific payload and extract the message, sender, attachments, and metadata.
  2. Authentication — verify the request using the provider’s mechanism, such as a verify token or HMAC signature.
  3. Response — format and deliver the agent’s answer back to the sender.

Normalization

Section titled “Normalization”

Every channel produces the same internal request shape. This means:

  • An agent does not need to know whether a message came from WhatsApp or Email.
  • Tools and memory behave the same regardless of channel.
  • Adding a new channel does not require changing the agent’s core logic.

Sender identifiers are mapped to stable user and session identifiers so conversation history persists across messages from the same source.

Channel-bound approvals

Section titled “Channel-bound approvals”

For tools that require human approval, the runtime can route the approval request back through the same channel the original message arrived on. This keeps the approval experience in the user’s native messaging app instead of forcing them to visit a separate web interface.

The flow works like this:

  1. A user sends a message on WhatsApp.
  2. The agent calls a tool that requires approval.
  3. The runtime asks the tool provider for the approval message text.
  4. The approval message is sent back to the user on WhatsApp.
  5. The user replies with approval or rejection.
  6. The runtime resumes the agent execution and sends the final answer.

Response templates

Section titled “Response templates”

Each channel can define a template for formatting the agent’s response before delivery. For example, an email channel might render the answer as HTML, while a WhatsApp channel sends plain text. Templates use Jinja2 and can access platform-specific metadata such as sender name or message ID.

Choosing channels

Section titled “Choosing channels”
NeedRecommended channel
Mobile users, rich mediaWhatsApp
Internal team workflowsSlack
Formal requests, attachments, long-form contentEmail
WhatsApp without direct Meta integrationKapso WhatsApp
Section titled “Related pages”