Alerting & escalation

Three kinds of runtime outcome ask for human attention. An approval-required decision always pauses for a person before the action proceeds. An escalate outcome flags a sensitive retrieval for review, and denials on the lanes you care about are visible in the event stream the moment they happen.

Which lanes warrant which treatment is your call, made in the same controls that govern the actions. The matrix that decides what a finance agent may do also decides which of its attempts wake somebody up.

A pending approval carries what the approver needs to decide: the agent, the tool, the arguments as evaluated, and the control that routed it there. It is delivered over your configured channels, Slack, Teams, or email, and lands in the dashboard queue either way.

The agent does not hang while the human thinks. The wait is bounded, and the pending action either resumes on an approval or blocks.

An approval that goes unanswered fails closed by default: the action is blocked, and the block is recorded like any other decision. A specific control may instead opt into a masked, degraded execution where that is the safer trade.

Either way the outcome was chosen in advance, in policy, rather than improvised during an incident.

Every human response emits a signed record of its own, tied to the runtime event it governed. The approval that released a payment is evidence, held in the same verifiable trail as the action it released.

That closes the gap most alerting leaves open: knowing a page went out says nothing about what the responder decided. Here the decision, the decider, and the governed action reconstruct together.