Exception Resolution Agent

An exception resolution agent takes a confirmed delay (or similar move exception) and runs the response playbook without waiting for a dispatcher to assemble the next steps by hand. It notifies the customer, proposes reroute or recovery options that fit the shipment context, and escalates when policy thresholds are exceeded. Every action it records cites an exception ID and a policy rule ID so ops, audit, and customer care can see why the system acted.

The agent does not invent exceptions. If the exception is unconfirmed, the output stays empty: no notification draft, no reroute package, no escalation queue entry. Confirmation is the gate. Upstream signals from visibility and planning systems may suggest risk; this agent only executes once the exception record is validated.

Speed is the outcome that matters here. The value is shorter time from confirmed exception to customer-facing update and to an actionable recovery path, while keeping humans in control of high-impact escalations.

In most logistics stacks, delay truth lives across several systems. Visibility platforms such as project44 and FourKites surface ETA drift, dwell, and milestone breaks. Planning and execution layers such as Blue Yonder hold appointment, capacity, and network constraints. CRM and service clouds such as Salesforce hold customer preferences, SLA commitments, and case history. The exception resolution agent sits after those signals have been reconciled into a confirmed exception object.

On a confirmed exception, the agent typically:

1. Loads the exception payload (shipment, lane, customer, SLA class, current ETA, root cause code if present).
2. Resolves applicable policy rules (notification windows, compensation or courtesy thresholds, allowed recovery modes, escalation triggers).
3. Emits customer notification content that references the exception ID and the governing notification rule ID.
4. Builds a short list of reroute or recovery options with constraints and estimated impact, each option tagged to the exception ID and the recovery rule ID that allows it.
5. If thresholds are crossed (time-to-promise breach, high-value SKU, critical customer tier, repeated exception count), creates an escalation package for ops approval rather than auto-committing network changes.

Empty-on-unconfirmed is deliberate. Partial or contested ETAs produce noisy customer messages and bad recovery proposals. Ops teams that wire the agent to “maybe delayed” signals usually reverse course after the first week of false alarms. Keep predictive detection and confirmed resolution as separate stages; see predictive delay detection and proactive ETA notification for the upstream path.

Customer notification is often the first action and the one that damages trust when it is late, vague, or wrong. The agent’s job is not creative copywriting. It is policy-bound messaging: who gets notified, by which channel, within which window, with which facts, and under which tone or template class.

A useful notification package includes:

• Exception ID and rule ID in the audit metadata (and, where policy allows, a customer-visible reference).
• Confirmed status change and revised ETA or “ETA under revision” state if policy forbids publishing a soft ETA.
• Clear next step for the customer (reschedule window, will-call option, hold at terminal) only when those options are allowed by rule.
• Pointers to related proactive ETA work so care agents see what was already sent earlier in the lifecycle (proactive ETA notification generator).

Integration with Salesforce (or equivalent) matters for preference and case continuity: preferred channel, language, named contacts, and whether an open case already covers this shipment. The agent should attach or update the case with the same exception and rule IDs rather than opening duplicate threads. project44 or FourKites milestone context can enrich the message with factual delay drivers (weather, congestion, equipment failure) when those codes are confirmed on the exception record; unconfirmed causes stay out of the customer message.

After notification, the agent proposes recovery paths. Proposal is not commitment. Network changes that move freight, burn capacity, or break appointments usually need either a low-risk auto-approve band or explicit ops approval.

Typical option types:

• Alternate linehaul or carrier swap within contracted lanes.
• Cross-dock or relay that recovers calendar days without breaking delivery appointment rules.
• Appointment shift proposals coordinated with DC or store receiving calendars.
• Split or hold strategies when partial delivery is allowed by customer policy.
• Mode shift only when policy and cost ceilings explicitly allow it.

Blue Yonder (or similar TMS/WMS planning context) supplies feasibility: capacity, appointment slots, inventory allocation, and cutoffs. Visibility data from project44 or FourKites supplies live position and remaining transit realism so options are not purely theoretical. Each option should state estimated time recovery, cost or penalty class, customer impact, and the policy rule ID that authorizes offering it.

When dynamic network replanning is already modeled elsewhere, this agent should consume those candidates rather than invent a second planner. Link the recovery shortlist to dynamic replanning so planners see one coherent set of moves. For last-mile or POD failures that are not pure transit delays, hand off to failed delivery resolution with the shared exception ID so the customer story stays continuous.

Escalation is where speed and control meet. The agent accelerates packaging and routing of the decision; ops still approves escalations that change cost, SLA remediation, or network commitments beyond the auto band.

Threshold examples that commonly force escalation:

• Revised ETA breaches contractual delivery window by more than N hours.
• Customer tier or SKU criticality flags mandatory human review.
• Cumulative exception count on the same shipment or order.
• Recovery cost above a defined ceiling.
• Conflicting rules (for example, customer demands same-day recovery while network capacity is full).

The escalation artifact should be decision-ready: exception ID, triggered rule IDs, customer notification status, ranked recovery options with tradeoffs, and a recommended action. Ops approves, rejects, or amends. The agent then executes the approved path (send follow-up notification, open carrier tender, update Salesforce case) and writes the approval reference back onto the exception record.

Do not auto-approve “everything except the biggest customers.” Write explicit rule IDs for auto bands and escalation bands. Ambiguous thresholds produce inconsistent behavior that care teams cannot explain.

Treat the agent as a controlled automation layer on top of visibility, planning, and CRM, not as a replacement for them.

• Visibility (project44, FourKites): confirmation inputs and live constraints for options.
• Planning / execution (Blue Yonder): feasibility of recovery moves and appointment reality.
• CRM / service (Salesforce): notification preferences, SLA context, case continuity.
• Policy store: versioned rules with stable rule IDs the agent must cite on every action.

Failure modes to design against:

• Unconfirmed exceptions leaking into notifications (keep the empty-output rule strict).
• Options that ignore receiving calendars or labor constraints.
• Duplicate customer messages when proactive ETA and exception resolution both fire without a shared exception ID.
• Escalations that dump raw telemetry instead of a decision package.
• Missing rule IDs on actions, which breaks audit and makes rollback guesswork.

Measure speed as time from exception confirmation to first compliant customer notification, and time from confirmation to first approved recovery action (or explicit ops reject). Secondary measures: percent of exceptions handled without escalation, escalation approval turnaround, and customer contact rate after the first notification. Keep predictive false-positive rates out of this agent’s scorecard; those belong to detection.

When the exception is confirmed, the agent should move fast and leave a clean trail. When it is not confirmed, it should do nothing visible. That asymmetry is the product.