# Final User Notes

*This document responds to issues raised by docs/channels/method.md and docs/channels/shape.md, and clarifies some misconceptions and corrected decisions from these documents. Anything said here must be taken as the final requirement.*

Channels are natively integrated in the hub backend, wwith shared responsibility between app_mixins/channel.py and server (may be one server module for channels or one per channel, depends on individual api complexity). We always use a public endpoint for incoming data (if we ever need a hostname, get it from an env. never imply it but also don't require it).

Channels are stored as `AgentResource` on the agent that responds to the prompt. The application does an initial query to setup the api endpoint listeners (if necessary, if the host is registered on the chat provider this is not necessary). No data should be persisted beyond essential information required for access.

The shape report mentions "flattening" the data into the prompt message, which is actually still a map but one level lower. We must flatten the channel input one level further: the entire conversation (the most recent messages up to some byte size limit) goes in a single "conversation" message. Other important channel context (time? idk what's important) goes in a separate user message (first user message for status and info), and the instruction discloses the source of the prompt and what the agent is expected to do with it (responding I guess).

We will first implement the Telegram channel. We will do the minimum required modifications to get it working, adhering to the design contraints refined in these documents. When done, write 'docs/telegram.md' with brief instructions to setup a telegram channel.