Dynamic Replanning Agent

When a transport plan is locked, reality does not stay still. A late pickup, a cancelled trailer, a port hold, or a sudden customer priority change can invalidate dozens of linked legs. A dynamic replanning agent treats those events as first-class inputs: it re-optimizes the full plan under the new constraints, proposes booking changes for every affected shipment, and records which trigger caused the rewrite.

The agent does not replace the dispatcher. It prepares a coherent, auditable replan so a human can release updates faster than a spreadsheet rebuild or a one-leg patch that creates the next conflict.

Speed is the outcome that matters. Minutes saved on each material exception compound across a network: fewer idle assets, fewer missed appointments, fewer last-minute spot buys. The agent earns that speed only when every recommendation is tied to a confirmed trigger and a clear set of affected legs. If the trigger is unconfirmed, the agent returns empty rather than inventing work.

Most logistics stacks already have pieces of this problem. Visibility platforms such as FourKites and project44 surface ETA drift, detention risk, and milestone exceptions. Planning and TMS suites such as Blue Yonder and Kinaxis hold capacity, commitments, and network constraints. The missing layer is an agent that can read an exception, pull the current plan state, run a constrained re-optimize, and write a complete change set back for human approval.

That layer sits downstream of static route building and transit forecasting. Teams that already use AI-assisted route optimization for the initial plan gain a natural reopen path when assumptions break. Teams that feed ML transit time prediction into ETAs give the agent better signals for when a delay is likely to cascade versus when it will absorb into buffer.

Capacity strategy also matters. If demand spikes were already covered through demand-driven capacity pre-booking, the agent can prefer committed lanes and contracted carriers before it opens the spot market. Without that context, replans default to expensive, brittle fills.

The agent should only act on a short list of high-signal triggers:

• Confirmed delay beyond a configured threshold on a critical leg
• Capacity loss (equipment failure, carrier rejection, dock closure, weather hold)
• Priority shift (expedite, customer resequence, SLA risk on a protected order)
• Network constraint change (lane blackout, appointment window move, cross-dock cut time)

Every candidate event needs an ID from the source system: a visibility alert ID, a TMS exception ID, or a carrier EDI status with a durable key. The agent cites that ID on the replan so operations can reconstruct why the plan moved.

Confirmation is non-negotiable. Unconfirmed rumors (a driver’s informal ETA, a single stale ping, a duplicated alert) must yield an empty response. Empty is a success mode: it protects dispatchers from noisy recommendations and keeps the audit trail clean. Once confirmation arrives, the same event ID becomes the root of the replan record.

Downstream booking updates stay gated. The agent can draft carrier tender changes, appointment requests, and internal handoff notes, but the dispatcher releases them. That gate preserves commercial judgment on rate, relationship, and customer communication while still cutting the time from signal to decision.

A useful replan is more than a new route for one truck. It is a network-consistent package:

1. Trigger citation. Event ID, type, confirmation timestamp, and source system.
2. Affected legs. Explicit list of shipments, stops, and assets touched by the change, including second-order impacts (relay, return empty, cross-dock).
3. Constraint set used. Updated windows, capacity, priority weights, and hard exclusions so reviewers can see what the optimizer respected.
4. Proposed booking deltas. Create, cancel, or amend tenders and appointments, with old versus new values.
5. Risk notes. Residual SLA exposure, cost delta bands, and legs left unresolved when no feasible option exists.

If any of those pieces are missing, the proposal is incomplete. Dispatchers will rework it by hand, and the speed benefit disappears. When no feasible plan exists under current constraints, the agent should say so plainly and list blocked legs rather than force a soft violation that will fail in execution.

Adoption fails when the agent floods the board or when humans rubber-stamp without reading. A practical operating model looks like this:

• Score and batch. Group related triggers into one replan cycle so a single port delay does not spawn twenty competing proposals.
• Time-box review. Target a short decision window for confirmed high-severity events; older drafts expire so stale plans do not ship.
• One release owner. A named dispatcher owns acceptance, rejection, or partial accept (for example, keep the routing change, reject the carrier swap).
• Feedback into rules. Rejected proposals should update thresholds, carrier preferences, and blackout logic so the next run is tighter.

Monitoring closes the loop. Pair replanning volume and acceptance rates with KPI trend anomaly monitoring so spikes in on-time failure, detention, or cost-to-serve surface when replans are too slow, too aggressive, or too often empty for the wrong reasons.

Start with one corridor or mode where exceptions are frequent and data quality is already good. Wire confirmed delay and capacity-loss events first; add priority shifts only after confirmation rules are stable. Integrate read access to the planning system of record (Blue Yonder, Kinaxis, or equivalent TMS) and event feeds from FourKites, project44, or carrier portals. Keep write-back as a draft queue until release accuracy is proven.

Define success narrowly for the first phase: median time from confirmed trigger to dispatcher decision, share of replans accepted without edit, and reduction in secondary exceptions after release. Do not optimize for proposal count. Optimize for fewer cascading misses and a shorter path from signal to a coherent plan.

Vendor boundaries stay clear. Visibility vendors excel at detecting and enriching events. Planning vendors excel at network models and execution systems of record. The agent’s job is orchestration under policy: re-optimize the full plan when a constraint changes, cite the trigger and affected legs, stay empty when the trigger is unconfirmed, and leave release authority with the dispatcher.