> ## Documentation Index
> Fetch the complete documentation index at: https://docs.atako.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Channels overview

> How an Atako agent stays reachable through chat, email, webhooks, cron, and other agents.

An Atako agent isn't a chat window you open when you need it — it's a collaborator with its own inbox, its own schedule, and its own way of being paged by other systems. **Channels** are the different ways work reaches an agent, and the different ways it can act back.

Every channel is opt-in. You activate the ones a given agent needs from its agent page, and each one comes with its own guardrails — quotas, approval gates, verification — so an always-on agent never becomes an open door.

## The five channels

| Channel                              | Direction                  | Typical use case                                                                        |
| ------------------------------------ | -------------------------- | --------------------------------------------------------------------------------------- |
| [Chat](/guides/chat)                 | Both                       | Direct, real-time conversation with the agent's owner or team                           |
| [Email](/channels/email)             | Both                       | The agent corresponds with customers, vendors, or colleagues from its own address       |
| [Webhooks](/channels/webhooks)       | Inbound                    | Third-party systems (billing, code hosting, internal tools) notify the agent of events  |
| [Cron](/channels/cron)               | Outbound (agent-initiated) | The agent runs itself on a recurring or scheduled basis, without a trigger from outside |
| [Inter-agent](/channels/inter-agent) | Both                       | Agents in the same company delegate work to each other                                  |

## Where work comes from

```mermaid theme={null}
flowchart LR
    Chat["Chat"]
    Email["Email"]
    Webhook["Webhooks"]
    Cron["Cron"]
    Peer["Other agents\n(inter-agent)"]

    Agent(("Your agent"))

    Chat --> Agent
    Email <--> Agent
    Webhook --> Agent
    Cron --> Agent
    Peer <--> Agent

    Agent --> Owner["Owner's chat\n(escalations, notifications)"]
```

Whatever the source, an inbound message becomes the same thing on the agent's side: a work item it can reason about and act on. The agent doesn't need to know or care whether a request arrived from a person typing in chat, an email from a customer, or an event pushed by a third-party system.

## Principles shared by every channel

* **Nothing is lost.** Inbound messages are queued if the agent is momentarily unavailable, and replayed as soon as it reconnects. There is no silent drop.
* **Every channel has a quota.** Email sends, webhook events, and inter-agent messages are all capped per day (and often per minute), so a runaway integration or a compromised source can't burn through your agent's time unchecked. Exact defaults are documented on each channel's page.
* **Origin is always visible.** Every inbound message — whatever its channel — appears in the agent's [activity timeline](/guides/activity) tagged with a badge: chat, email, webhook, cron, or inter-agent. You always know where a given action started.
* **Activation is per agent, per channel.** Turning on email for one agent doesn't expose it on another. Each channel is configured independently from that agent's page.

<Tip>
  Start with chat and add channels as the agent's role grows — a support agent might only need email, while an operations agent might need webhooks and cron from day one. See [Agents](/concepts/agents) for how channels fit into an agent's overall configuration, and [Integrations](/integrations/overview) for connecting external tools beyond these channels.
</Tip>