# Renewal Pipeline Orchestration

Run scheduled 90/60/30-day renewal sweeps across the book of business, turning upcoming policy expirations into outreach and per-policy board tasks while keeping a durable memory of retention outcomes.

## When to use

- On a recurring cron (daily or weekly) to catch every policy crossing the 90, 60, or 30 day-to-renewal threshold.
- When a producer or account manager asks "what's renewing this month" and needs a task board built, not just a list.
- After a renewal outcome (renewed, lapsed, marketed elsewhere) to record retention history for future sweeps.
- When outreach needs to go out to policyholders ahead of an AMS (agency management system) renewal deadline.

## Tools

- `http-get`
- `create-task`
- `schedule-task`
- `send-email`
- `update-memory`

## Playbook

1. Confirm the sweep is running on a recurring cadence via `schedule-task` (e.g. daily at 06:00) so 90/60/30-day windows are never missed between runs.
2. Pull the active book of business from the agency management system with `http-get` (e.g. GET https://api.amsvendor.com/v1/policies?status=active&expires_before=90d). Auth is injected by the org's Integration row for this host — never ask for, echo, or hardcode credentials. On 401/403 or missing Integration, stop and message a human via send-message naming the service and scopes.
3. Bucket the returned policies by days-to-renewal (90, 60, 30) and skip any policy already flagged as bound-to-renew or cancelled in the response.
4. For each policy entering the 90-day window, create a per-policy board task with `create-task` describing the policyholder, policy number, line of business, and expiration date, and assign it to the account manager of record.
5. For each policy entering the 60-day window with no recorded producer response, draft and send a renewal reminder to the policyholder with `send-email`, keeping the tone informational — never quote premiums, limits, or coverage terms.
6. For each policy entering the 30-day window still unresolved, escalate the board task priority with `create-task` (a follow-up task tagged "urgent") and note the approaching hard deadline.
7. After each sweep, record retention signals with `update-memory` — e.g. which policies moved stages, which policyholders were unresponsive, and any prior-year renewal outcome, so the next sweep can compare trends.
8. If a policyholder replies asking about coverage changes, limits, carrier options, or whether coverage is bound, do not answer — create a board task via `create-task` tagged for a licensed agent and stop.
9. If the sweep discovers a request for a COI (certificate of insurance) for a non-standard holder, or any endorsement request, create a human-gated board task via `create-task` instead of acting on it.

## Failure modes

- The AMS API paginates or rate-limits results, causing a sweep to silently miss policies past the first page — always check for a next-page cursor before concluding the sweep is complete.
- A policyholder email bounces or the address is stale, leaving a 30-day-window policy with no outreach sent — flag this as a board task rather than retrying silently.
- Duplicate board tasks get created when a policy appears in both the 60-day and 30-day sweep before the prior task is closed — check `update-memory` history for an open task on that policy number before creating a new one.
- Coverage, limits, carrier, or claims-fault questions arriving inside a "renewal" reply get treated as routine outreach instead of being escalated to a licensed agent.

## Done when

- Every policy in the 90/60/30-day windows has a corresponding board task with current status and an assigned owner.
- Retention memory is updated with this sweep's outcomes, and any coverage, binding, COI, endorsement, or claims question has been routed to a human via a board task, never answered directly.