Channels

A Channel is a wire connecting askTheodor to the outside world — an email account, a messaging app, and so on. It’s how a message from a real person reaches your Workers, and how a worker’s prepared reply finds its way back.

Channels turn your workforce from something you talk to inside the app into something that can quietly handle your incoming correspondence — on your terms.

What you can connect

• Live today: Email and Signal.
• Planned: Telegram, WhatsApp, Discord, Slack, Teams, and Viber.

Each channel stores its own connection settings (account details, credentials) and reports when it last checked for messages and whether that went smoothly.

Routing: deciding who handles what

A channel on its own just receives. Routing rules decide what happens next. Each rule matches an inbound message — by who it’s from, and optionally by subject (for email) — and sends it to a target:

• a specific worker (persona),
• a Company’s lead,
• the Kafenio tavern, or
• a generated report.

So “anything from my biggest client → route to Iris” or “newsletters → file a report” become simple rules you set once.

The Inbox, and the golden rule

Inbound messages land in your Inbox, where you can see them and chat about them with Theodor. When a worker handles one, it drafts a reply — and that’s where it stops. Nothing is sent automatically. The draft is saved and surfaced for you to review, edit, and send.

This is deliberate and central to how askTheodor treats safety: the app prepares; you decide what actually goes out. (A rule can optionally let a worker run tools to act on a request, but it’s still gated by your autonomy settings and the global kill-switch — see Budgets & approvals.)

Drafts, not sends

By default every reply a worker writes for an inbound message is a draft awaiting your review — the worker won’t send on its own. That’s the intended behaviour, not a limitation.

Where the wires live

This page describes the idea. The actual connecting, polling, and sending happen behind the scenes; you configure channels and rules in Settings, and read what comes in from the Inbox.

In practice

What connecting a channel actually buys you is triage, not automation. Incoming messages get read, classified and answered in draft, so you start from a queue of prepared responses rather than an unread inbox. The reading is delegated; the sending never is.

Ground the replies before you connect anything. A channel worker with an empty Library writes plausible, generic answers. Put your top questions, prices, delivery times and policies in the Library first — then the drafts are worth the review time instead of being rewritten from scratch.

Treat inbound content as untrusted. A message can contain text designed to read as an instruction to the worker handling it. That’s exactly why the reply is a draft and why the worker’s allowlist should be narrow — capability it doesn’t hold can’t be misused by a hostile email.

Give the channel worker an escalation rule. Write into its SOP what it must not answer — refunds, legal commitments, discounts beyond your standard, complaints — and what to do instead: draft a holding reply, flag it, and say why it stopped.

🎓 Learn it hands-on: OAuth sign-in

Terms in this page

• Channel — a connection between askTheodor and an external messaging system (email, Signal, and more to come).
• Inbound message — a message arriving from the outside world through a channel.
• Routing rule — a setting that matches inbound messages (by sender, and optionally subject) and sends them to a chosen target.
• Target — where a routed message goes: a worker, a Company lead, the Kafenio tavern, or a report.
• Worker / persona — the AI character that handles a routed message; see Workers.
• Inbox — the in-app place where inbound messages collect for you to review.
• Draft — a reply a worker prepares but does not send; you review and send it yourself.
• Kill-switch / autonomy — the safety controls that govern whether a worker may act on a message; see Budgets & approvals.