Logistics: handling shipment exceptions, from alert to approved action

Shipments go wrong constantly: a delay, a missed pickup, damage, a customs hold, a stockout at the destination. Each exception needs someone to understand it, work out the options, weigh cost against the customer commitment, act in the transportation system, and tell the customer. Planners handle a queue of these, and the work is a mix of looking things up, applying rules of thumb, and making judgment calls on the unusual ones.

Exceptions are a good place to introduce action-taking systems because the consequences differ widely. A one-day delay on a low-value order and a customs hold on a time-critical shipment are the same kind of event with very different stakes. The design should reflect that with tiered autonomy.

The design

• Classify first. A small, fast model labels the exception type and severity. Easy, common types follow a short path.
• Gather context with a few consolidated tools. One call returns the shipment, its service commitment, the customer's terms, and the inventory position at the destination. Fewer, richer tools reduce the chance that the model picks the wrong one or misses a field.
• Cost the options in code. Rebooking, expediting, partial shipment, and customer credit each have a price and a transit time that a rate service knows. The model proposes which options to price and explains the trade-off. It never invents a number.
• Recommend. The system ranks the options against the customer commitment and the cost, with reasons the planner can read in a few seconds.

Tiered autonomy

Approval depends on consequence, not on a blanket rule. A common structure:

Set the limits with the business owners and write them as configuration, not as prompt text. Review what lands in each tier every month. As the evaluation builds a track record, move well-understood exception types to a lower tier. This is the exception-based review pattern: people look at the cases that need them.

Guardrails for write access

• Separate read and write tools. The write tools check for a valid approval token, either from the automatic tier or from a planner.
• Idempotency. Every write carries a key so a retry cannot book twice.
• Hard limits in code. Spend caps and allowed actions are enforced by the tool, whatever the model asks for.
• Make mistakes hard to commit. Anthropic's tool guidance cites changing arguments so a class of error cannot occur. Require explicit shipment and carrier identifiers instead of free-text references.
• A kill switch. One setting that sends everything to a planner.

How to evaluate it

• Historical replay. For past exceptions, compare the recommended action to what the planner did and what it cost. Grade agreement with code, and review disagreements with a planner, since they may show the system was right.
• Cost discipline. Measure realized cost against the planner's choices by exception type.
• Autonomy safety. For the automatic tier, review a sample every week and track the rate at which a person would have chosen differently.
• Timeliness. Time from event to action, by tier. Report the types that did not improve.

Begin with read-only recommendations and a planner approving each one. Add the automatic tier only after the replay and a live period show it behaves.

This is a reference design. It describes how we would build the system and cites Anthropic's documentation for platform facts. It is not a client case study, and the figures it uses are list prices or worked examples, not results.

Sources

• Anthropic, Building effective agents
• Anthropic, Writing effective tools for agents
• Anthropic, How we built our multi-agent research system
• Claude docs, Define success criteria and build evaluations
• Claude docs, Models overview