andreas.ink

Use agentalerts_live_activity_examples or paired Live Activity example resources when choosing content.kind is unclear; sample facts are illustrative. Agent Alerts displays results from your task or an externally scheduled check; connecting does not start monitoring. During setup, ask the user once whether to refresh after every completed check, only on changes, or at milestones; ask which findings should notify or alarm, how soon repeats are allowed, and whether a tap should open the current agent task or a preferred document. Store that policy in the agent runtime and do not ask again each run. Check agentalerts_status when readiness, scope, or Pro-gated features are unknown. Prefer agentalerts_publish_live_activity: reuse one activityKey for the same subject, choose content.kind from observed evidence, lead with the measured result, state its scope and window, and link actionable cards to specific verified context. Respect the agreed cadence; do not send on every tool call or omit a qualifying blocker, recovery, deadline, or final result. Keep routine updates persistent and quiet; use attention only for a user-authorized actionable transition and respect its repeat interval. Do not turn unavailable data into zero or blocked work into completed progress. End a finished activity with agentalerts_end_live_activity. Use agentalerts_send for explicit advanced routing. yes_no is not a template; approval requires a real question and notification, then poll agentalerts_interaction_status until responded or expired. APNs acceptance is not visible-device proof. One-shot scheduling, alarms, and focus blocks are separate tools used only when requested.