Channels are how messages get in and out of Curia. Whether you send a Signal message from your phone, an email from a colleague, or a command from the terminal, every message travels through a channel adapter that normalizes it into the same internal format. Curia’s agents work with that normalized format — they never deal with email headers, Signal protocol specifics, or HTTP request objects directly. Adding a new channel means building one adapter; nothing in the core changes.Documentation Index
Fetch the complete documentation index at: https://curia.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
The four channels
- Email
- Signal
- CLI
- HTTP API
Email is Curia’s primary channel for external communication. It connects via the Nylas API, which abstracts away the differences between Gmail, Outlook, and other providers.Inbound: Curia polls the Nylas Messages API every 30 seconds (configurable) for new messages. Emails are parsed, attachments extracted, and participants auto-added to your contacts.Outbound: Replies and new emails are sent via the Nylas Send API. The Coordinator injects its persona’s display name and email signature into every outbound message.Email validation: Before processing, the email adapter checks SPF, DKIM, and DMARC headers. Messages that fail validation are tagged
sender_verified: false in their metadata — the Coordinator uses this signal when deciding whether to act on consequential requests.Required secrets: NYLAS_API_KEY, NYLAS_GRANT_ID, NYLAS_SELF_EMAILTrust level: Low — email From headers are trivially spoofable, and even with SPF/DKIM validation, email is the least trustworthy channel.Channel trust levels
Every inbound message is tagged with the trust level of the channel it arrived on. The Coordinator uses this trust level — along with the sender’s individual trust score — to decide what actions it is willing to take on that message.| Channel | Trust level | Rationale |
|---|---|---|
| CLI | High | Requires SSH or physical access to the host |
| Signal | High | Strong identity via phone number + Signal protocol |
| HTTP API | Medium | Token-authenticated, but tokens can be shared or leaked |
| Low | From headers are spoofable; even SPF/DKIM is not identity verification |
Unknown sender policy
Each channel can be configured with one of two policies for messages from senders not yet in your contacts:hold_and_notify— the message is held in a queue and you are notified via a high-trust channel (CLI or Signal). You can identify the sender, dismiss the message, or block them. Once identified, the message is replayed through normal processing.ignore— messages from unknown senders are silently discarded.
hold_and_notify. When a held message is waiting, the Coordinator proactively mentions it the next time you interact: “By the way, you have a held email from stranger@example.com about ‘Q3 Numbers’. Want me to identify them?”
Dismissing a held message discards the message — it does not delete the sender’s contact record. Their email address remains in your contacts as provisional. You can look them up later with
contact-lookup.Observation mode
Observation mode lets Curia monitor the CEO’s own email inbox and act as a triage layer — without ever appearing to the sender as the one responding. When observation mode is enabled for an email account, every new message in that inbox is processed through a triage protocol. Curia classifies each email into one of five categories and takes the appropriate action:| Category | What it means | What Curia does |
|---|---|---|
| URGENT | Time-sensitive — needs the CEO’s attention now | Notifies the CEO on Signal or CLI. Does not reply to the sender. |
| ACTIONABLE | Curia can handle it directly | Acts using its skills (calendar, contacts, etc.). No notification unless confirmation is needed. |
| NEEDS DRAFT | Requires the CEO’s voice | Saves a draft reply in the CEO’s email client for review. Does not send. |
| LEAVE FOR CEO | Personal, sensitive, or requires CEO judgment | Takes no action. The CEO handles it directly. |
| NOISE | Marketing, newsletters, automated notifications | Archives the email. No notification. |
Channel security
Channel adapters operate within a hard architectural constraint: they can pass inbound messages into the system and receive outbound messages for delivery — and nothing else. They cannot invoke skills, read memory, or trigger agent tasks directly. This is enforced at the framework level, not by policy. A compromised email adapter could flood inbound messages, but it cannot execute skills, access your data, or impersonate another layer. The boundary is structural.Email setup
Connect your email via Nylas and configure observation mode.
Signal setup
Set up Signal messaging via signal-cli.