Trailer Dwell Optimization
A trailer has sat past its dwell window, and detention is now ticking.
The decision
A loaded trailer has idled in the yard three hours past its target. The detention clock is running, a door is freeing up, and another carrier is waiting. Hold it, move it to a door, release it back to the carrier, or reassign the load?
Why it's hard today
The trailer's position drifts, the appointment schedule lives in the TMS, the detention terms are in the carrier contract, and door availability changes by the minute. No one screen shows all four at once — and the cost of guessing wrong is detention dollars or a missed departure.
Your yard system knows where the trailer is; it doesn't know the detention clause, the downstream appointment, or that this carrier's SLA makes releasing it the cheaper move. It shows a dot on a map, not a decision — and that dot is an estimate, not the truth.
What AgentForgeOS does
It assembles the picture you can't see, and makes the call under your rules.
Reposition to door 14 now and release the empty — clearing detention exposure and the waiting carrier — under your yard policy, pending the yard lead's nod.
- Live yard position and dwell time, with confidence
- Appointment and door schedule
- Detention clock and carrier terms
- Downstream load priority
- Detention-cost thresholds
- Carrier contract terms
- Dock capacity and safety
- Appointment priority
⚠ Dwell 3h 12m over target — trailer T-2207, detention accruing
Evidence assembled
- Position confidence high; idle at staging row 9
- Door 14 frees in ~15 min
- Carrier SLA: release-empty avoids detention after 4h
- Inbound carrier waiting on a door
Recommendation · reposition to door 14, release the empty
Policy: within detention threshold · dock capacity ok · awaiting yard-lead sign-off
What improves
- Lower detention spend
- Higher dock throughput
- More on-time departures
Each call — and whether it actually cleared the congestion — is kept, so the yard's own patterns (which carriers, which doors, which hours) sharpen the next decision, and the model improves with every yard it runs in.
Underneath, this is the same operating model the rest of the platform runs: verified context is assembled, options are weighed and adversarially challenged, the decision is governed by your policy, and the outcome is learned. The decision changes from one of these to the next. The architecture does not.
See how it worksThis is exactly how your team works today.
Only now the decision is assembled, governed, and remembered — instead of made from memory and lost.