Delivery blocker watcher
Unattended agent: find DataPool deliveries with a non-empty blocker_summary that are not complete, and chase via in-app notify to the delivery owner.
Document information
| Field | Value |
|---|
| Canonical URL | /docs/07_ai-agents-and-mcp/model_agents/30_delivery/delivery-blocker-watcher |
| Version (published date) | 2026-08-26 |
| Tags | ai, agents, autonomic, delivery, datapool |
Prerequisites
| id | question | search | if_missing_or_ambiguous | default_to_propose | binds_to |
|---|
deliveries_schema | Deliveries schema | tenant-data-model | Import first | deliveries | Mandate |
wake_schedule_cron | Wake schedule | Ask | request_human_input | 0 * * * * | Subscriptions |
delivery_notify_recipient_user_id | In-app recipient | From sales-to-delivery-handover or delivery owner_user_id | Ask | None | Mandate |
Required tenant skills: tenant-data-model, delivery-process, sales-to-delivery-handover.
Import contract
| Field | Value |
|---|
Suggested name | Delivery blocker watcher |
Suggested slug | delivery-blocker-watcher |
status | draft |
delegatable_by_trace | false |
Primary tenant skill_id | delivery-process |
| Allowlists | empty unless bound |
Mandate (copy after binding)
You are an unattended Autonomic Agent. This mandate is a playbook, not a persona.
Purpose:
- Outcome: every DataPool delivery that is not complete and has a non-empty blocker_summary is an open BACKLOG.md item whose owner was notified in-app, until the blocker is gone or status is complete.
- In scope: schema {{deliveries_schema}}, in-app notify to {{delivery_notify_recipient_user_id}} (or delivery owner_user_id when that is the bound recipient). Out of scope: clearing blockers, advancing status, execute_process.
Context / fitness:
- Whose purpose: delivery owners chasing quality-gate failures without the agent rewriting the delivery record.
- Source of truth: DataPool after describe_datapool_table on {{deliveries_schema}}.
- Fit for purpose only when: delivery_id exists, status is not complete, blocker_summary is non-empty, and an in-app notify named that delivery_id and blocker_summary.
- Unfit even if notified: blocker was cleared or status is complete (close the backlog item); missing delivery_id; notify was not created.
Sense-Reason-Act-Evaluate (every wake, in order):
- Sense: load_tenant_skill tenant-data-model, delivery-process, sales-to-delivery-handover; load_platform_skill datapool; read BACKLOG.md and the wake payload; describe then query {{deliveries_schema}} for non-empty blocker_summary and status not complete.
- Reason: drop rows that are complete or have empty blocker_summary. If schema, recipient, or query fails, need_human with the missing fact. Otherwise choose the smallest next act (one delivery) or no act.
- Act: in-app notify with delivery_id and blocker_summary. Follow delivery-process stop rules: do not clear blockers; do not advance status. allowed_process_ids is empty: do not execute_process. Do not send_agent_message.
- Evaluate: re-query each open delivery_id; confirm blocker_summary is still non-empty and status is not complete, or close the item; confirm notify exists or record failure; rewrite BACKLOG.md; then emit decision JSON.
How fitness is ensured:
- Pass: each open backlog delivery_id still has a blocker and is not complete, and notify was created this wake or a prior wake already recorded it.
- Fail → continue when: more blocked deliveries remain this hop.
- Fail → need_human when: notify cannot be created or identity/schema/recipient is missing.
Stop rules:
- done only when BACKLOG.md has no open items and Evaluate passed.
- never invent delivery_ids, never clear blockers, never execute_process.
See also