Notifications

A workflow that pauses for a human who never finds out is indistinguishable from a workflow that hung. Notifications exist for that problem. Every moment where the platform needs a decision from you, or has done something you should know about, raises a message when it happens.

Email is the only channel

Every notification below arrives as a plain-text email at the address on your account. There is no Slack app, no SMS, no browser push and no outbound webhook. If you want these somewhere else today, the way to get them there is a rule in your own mail client.

Settings, under Notifications, shows you the address in use. It is a read-only view: there is nothing to configure, because there is nothing else to choose.

Two things follow. The address on the account has to be one you read, and it has to accept mail from us. An account with no email address at all gets its deliveries recorded as failed with that reason, rather than having them disappear.

What raises an email

Each of these is a distinct kind of moment and each gets its own message as it happens. Nothing is batched.

A run is waiting on you.

• A run paused before doing something irreversible and needs your approval.
• A run reached a step you pinned as always needing sign-off, and stopped there.

A workflow needs attention.

• A codified run failed and opened a failure review.
• A workflow failed enough times in a row that we recommend stepping it back to learning with you in the loop, rather than patching the same step again.
• A run finished, but only because the agent worked around a problem by supplying different inputs at a step. Nothing is broken right now, which is exactly why it gets said out loud.
• A triggered run could not start at all. There is no run to go and look at in that case, so the message carries the reason.
• The engine repeatedly failed to keep an event subscription registered with the provider, and has stopped trying.
• An event subscription vanished at the provider and the engine re-created it. This one is a heads-up with nothing to do.

Something is ready for you to confirm.

• An updated set of instructions for a workflow is ready for review. Nothing has been applied.
• A workflow has seen enough accepted runs to be codified.
• A fix has been prepared, checked against the known examples, and is waiting for you to confirm it.

Something about the account changed.

• The model key you saved stopped working. See model selection and BYOK.
• A monthly spend limit was reached and new work is waiting instead of starting. See spend limits.

What does not raise an email

This list is as load-bearing as the one above. A notification system you cannot predict is one you start ignoring.

• There is no "your run finished" email. A run that completes without needing anything from you is silent, and the run log is where you go to see it.
• There is no digest. Nothing is rolled up into a daily or weekly summary.
• There are no per-event preferences and no opt-out. Everything above goes to the workflow owner, and there is no screen to switch individual kinds off.
• There is no escalation and no second recipient. Messages reach the one accountable person and stop there. Nothing reminds you if you do not act.

Repeats are fenced

Several of these moments can recur constantly, so the platform speaks once rather than once per occurrence:

• A spend limit sends one message per scope per month. A runaway workflow can park work every few minutes for weeks, and a month of parked jobs must not become a month of mail.
• A broken model key sends one message, on the edge from working to broken, not one per run that then fails.
• "Ready to codify" sends once per streak of accepted runs, not on every accepted run past the threshold.

Reading back what was sent

The console keeps a Notification log: every notification we sent you, newest first, grouped by day. You can filter it to approvals, failures or lifecycle events, and most rows carry a link straight to the thing they are about.

It is a log, not an inbox. There is no read or unread state, nothing to dismiss, and nothing to mark done. The place where you actually act on a pending approval or an open failure review is the Inbox, and the log points at it.

Delivery is tracked apart from the decision

The message about an approval and the approval itself are two separate records with two separate states. That is deliberate: an approval can be sitting there waiting for you while its email bounced, and the platform can answer the question "did that actually get delivered" instead of assuming.

A failed send is retried with a growing gap between attempts. After a handful of attempts it is marked failed and the provider's last error is kept on the record. Sending never blocks the run or the request that raised it, and a message about a problem never becomes a second problem on top of the first.