Notifications

Amdahl can email the people in your workspace - to hand off a finished draft, flag a broken data connection, or close the loop at the end of an automation. Sends are deliberately constrained so an agent can notify your team without ever becoming a spam vector.

What you can do

• Email members - send to one or more workspace members (with CC) using a subject and body.
• List recipients - look up who you can email (each member's email, display name, and id) before sending.
• Read the send ledger - review what was sent, with a cap-aware usage summary so an automation can check its budget before it sends.

Why sends are safe

• Members only. Recipients are validated against your workspace roster. A single non-member address fails the whole call - external or free-text addresses are never accepted.
• Rate-capped. Per-workspace hourly and per-run caps bound how much any one automation can send; over the cap the call returns rate_limited and sends nothing.
• Idempotent. An idempotency key (or one derived from the run, subject, and recipients) short-circuits a resend, so a retried automation never double-sends.
• Resilient. A single failed recipient is recorded and the rest still go out; the result carries both a sent and a failed list.

Surfaces

Surface	How
MCP	the notifications tool (email_member), plus notification_recipient://list + notification_sends://list reads
REST	POST /notifications/email-member, GET /notifications/recipients, GET /notifications/sends

Sending needs the notifications:write scope (an admin default); listing recipients or reading the ledger needs notifications:read.