Notifications & Delivery
Anyy can publish immediate notifications and user-visible messages through the resident Gateway. Delivery is routing-aware: the assistant can address the current user or the trusted origin of the current Channel conversation, not arbitrary external contacts.
Two Message Actions
| Action | Content and routing |
|---|---|
Notification (notify_user) | Text with an optional title; its delivery can select Gateway, a trusted origin, or a default binding on a specified Channel. It has no attachment input. |
Message (send_message) | Text and supported attachments; target is only current_user or origin. It has no delivery or Channel-selection input. |
With send_message, current_user uses the runtime’s current route. An ordinary Dashboard/TUI request uses Gateway; a trusted Channel conversation normally replies to its origin. Explicit origin requires trusted Channel metadata. It does not select a different platform’s default binding.
Both actions are audited. Sending is non-idempotent: retrying can produce a duplicate message.
Notifications in Chat History
Independent system notifications associated with a conversation remain visible when you switch to another conversation, return, or refresh the page. They keep their System notification card rather than becoming an Agent reply. Older notices load with the conversation history, and reconnecting does not create a second copy of the same notice.
These system cards are display records separate from Pi conversation messages. They do not enter model context or change the selected conversation branch. An attachment-bearing message can instead have its existing conversational projection; that message is not duplicated as an independent system card.
Anyy gives the protected notification body its own durable owner before publishing it. That owner is separate from a delivery retry payload. Clearing a completed delivery's retry payload does not clear this conversation history. Deleting the conversation removes its notification history along with the conversation.
This applies to notifications saved with the current implementation. An older notice whose exact body was already released cannot be reconstructed reliably from a job’s status or summary. Profile-wide live events without a session association, including Heartbeat notices, are outside this per-conversation history guarantee.
Delivery Targets
Scheduled jobs and text notifications use the routing vocabulary below. The none option is available to scheduler management through Dashboard/CLI; it is not an accepted notify_user delivery target. These values are not send_message target values.
| Target | Meaning |
|---|---|
gateway | Publish to the resident Gateway event stream |
origin | Route back to the trusted origin of the current Channel conversation |
current_user_default | Resolve the current user’s default binding; notify_user requires a delivery.channel such as telegram |
none | Do not deliver a user-facing result |
Anyy does not treat platform names as arbitrary recipient addresses. A configured and authorized Channel binding must resolve the route.
Ask Anyy to Send
Examples:
When this check finishes, notify me with the title “Backup verified” and a one-line result.
Send this summary back to the current Channel conversation.
For a text-only notification to a configured default binding:
Notify my default Telegram binding with a short text summary of this result.
For an attachment, make the request in the trusted Telegram conversation where the report artifact is available:
Reply to this Telegram conversation with the generated report as an attachment.
The first request can use notify_user with delivery: { target: "current_user_default", channel: "telegram" }. The attachment request uses send_message to the trusted origin. The current interfaces do not let a Dashboard request attach a report to an arbitrarily selected default Telegram binding.
If no trusted origin or default binding exists, Anyy reports that the route is unavailable instead of guessing a recipient.
Receipts and Delivery State
A successful publish proves that Anyy accepted and dispatched the event into its delivery pipeline. It does not by itself prove final receipt by Telegram, email, SMS, or another external service.
Message sends can create a receipt that later reflects adapter delivery progress. Channel capabilities differ: some adapters report acknowledgements while others can report only dispatch. Check the original conversation’s system card, background child, or Cron run history as well as the Channel’s health; a finished run and external delivery are separate states.
Check the message receipt or Channel health before retrying an uncertain send. A second send can create a duplicate when the first one reached the provider but its acknowledgement was delayed.
Attachments
A send_message attachment must be available in the current session scope, and the current/trusted-origin Channel must declare support for its media kind. notify_user is text-only, including when it selects a default Channel binding. Unsupported attachments are rejected rather than silently discarded.
Configure a Default Route
Connect the Channel in Dashboard → Channel or with anyy setup channel, verify its sender access policy/pairing, and test it. Scheduled jobs can then select current_user_default plus a delivery channel.
See Messaging Platforms and Scheduled Automations.
Troubleshooting
| Problem | Fix |
|---|---|
| No default route | Configure and verify a Channel binding for the current user |
| Origin delivery unavailable | Start the request from a trusted Channel conversation |
| Publish succeeds but no external message appears | Check the receipt, Gateway status, and Channel doctor output |
| Duplicate message | Stop retrying automatically and inspect the earlier receipt/event |
| Attachment rejected | Use a media kind supported by the selected Channel |