Triaging shipment exceptions with agents that ask before they act

The situation

A logistics operator's customer service and operations teams handled shipment exceptions largely by email. A late container, a failed delivery, a missing customs document or an address query each arrived as free text, often with attachments, sometimes in a long thread. Staff read each message, worked out which shipment it concerned, looked it up in the transport management system (TMS), decided what to do and then did it, across several screens.

The work was repetitive but not trivial. The hard part of each email was usually the same: identify the shipment, understand the exception, gather the facts. The decision itself was often quick once the facts were on one screen.

What had to be true

• Structured, not chatty: every email becomes a typed exception record, or is routed to a person as unclassifiable.
• Governed tools: the agent reaches systems only through a defined, permissioned tool layer.
• Read freely, write with approval: lookups are automatic; anything with side effects needs a person.
• Inbound email is untrusted and never treated as instructions.
• Measured and traceable: behaviour evaluated before release, every run inspectable afterwards.

Architecture

The design favoured a defined workflow with agentic steps over an open-ended autonomous agent. Anthropic's guidance on building agents makes the same distinction, recommending the simplest pattern that works and adding autonomy only where it earns its keep¹.

The data flow, end to end

Classification and extraction used structured outputs, where the model's response is constrained to a supplied JSON schema⁵, so downstream steps receive valid records rather than prose. Approval pauses used LangGraph interrupts, which persist graph state while waiting for human input and resume with that input³. More in structured outputs for reliable LLM integration.

The hard part: tools you can trust an agent with

The model was rarely the weak point. The tool layer was where safety lived. The MCP specification describes tools as model-invoked and recommends that a human can always deny a tool invocation². The design took that literally:

• Separate read and write servers, with write tools reachable only from the post-approval step of the workflow.
• Narrow tools: "get shipment milestones" and "request redelivery", not a general API passthrough.
• Service identity per tool, scoped to the minimum permissions in the TMS.
• Email as data: inbound text is passed as content to classify, never as instructions, because prompt injection and excessive agency both appear in the OWASP Top 10 for LLM applications⁴.

The checklist used is in securing MCP servers and prompt injection defence for agents.

How it ran

Evaluation followed evaluating AI agents for reliability, scoring classification, shipment matching and proposed actions separately, so a regression could be located rather than just noticed.

Key decisions and trade-offs

What I'd do again, and differently

Again: start read-only, build the labelled set from real emails, and keep write tools behind approval. Differently: invest earlier in shipment matching. Ambiguous references caused more escalations than misclassification did, and better matching would have improved every downstream step.

If you are designing agents that touch operational systems, the AI architect page describes how I approach it, or analyse your challenge and bring the result to a call.