MyDot Consultancy

Featured image: AI-generated conceptual illustration. Sources checked 26 October 2026.

A shipping-exception summary can tell an operator that a parcel needs attention. It cannot, by itself, decide whether the next step is to wait, contact the carrier, ask the customer a question or prepare a replacement proposal. Those decisions need explicit states and transitions tied to evidence.

A state machine is simply a defined map of what can happen next. In an exception workflow, it helps distinguish a new signal from an acknowledged case, an investigation from an approved remedy and a closed case from one that only stopped receiving updates. An agent can explain and assist within that map.

Define the case separately from the shipment

Imagine a hypothetical retailer receiving a delivery-exception event for a parcel. The shipment has a carrier-reported state. The business case has a different state: newly detected, awaiting review, awaiting carrier information, awaiting customer response or resolved. Do not force both meanings into one field.

Link the case to the order and shipment identifiers, then retain the evidence that opened it. A later normal tracking event may resolve the shipping concern, but the business may still owe the customer a response. Conversely, a support case can close while the shipment continues in transit.

Shippo’s tracking documentation describes normalized shipment information and event history. Use that as a source stream, not as a complete definition of the merchant’s exception process. The merchant must decide what each event means for its service obligations.

Let code own transitions with clear rules

Define which events can open a case, which facts permit an escalation and which actions require approval. Some transitions can be deterministic, such as marking that a new carrier event arrived. Others need judgment, such as interpreting a customer’s account of a failed delivery.

The agent can assemble context and propose the next state, but the application should validate the transition. A case awaiting approval should not become remedy executed merely because a generated summary uses past tense. The stored status must follow an actual approved operation and its verified result.

Keep the rule owner visible. Customer support may define communication policy, logistics may own carrier escalation and finance may own refunds. A single model prompt should not quietly become the only place where these responsibilities are encoded.

Treat webhook delivery as an integration concern

Shippo’s webhook documentation describes notifications for tracking and other events. Receiving a notification is useful, but the application still needs to authenticate and process it according to the provider’s current guidance, preserve relevant identifiers and handle failures.

Design for duplicate or delayed information. Do not send a new customer message every time the same underlying event is processed. Maintain a case-level record of what was already acknowledged and what action, if any, followed. Distinguish a new event from a changed interpretation of an old one.

Check the exact subscription and event behavior in the deployed integration. Different event types can have different delivery or retry semantics. Avoid treating a webhook as a universal exactly-once delivery guarantee or assuming that every missing notification means no change occurred.

Use the agent for the evidence packet

For each active case, prepare a concise packet: latest tracking evidence, prior relevant events, order context, customer communications and the next decision required. Label each source and timestamp. The operator should not have to open several systems just to understand why the case is waiting.

The agent can draft a carrier inquiry or customer update, but preserve the difference between preparation and sending. A draft should not promise compensation or a delivery date that the policy and evidence do not support. A customer’s frustration is important context, not authority to bypass approval.

When the evidence is incomplete, make the gap specific. “Awaiting carrier confirmation of the delivery location” is more useful than “investigating.” The packet should identify who owns the next step and what observation would allow the case to advance.

Make remedies separate, reviewable operations

A replacement, refund, address correction or claim submission can have different consequences. Each should have its own proposal and authority check. The case state machine should show which remedy was approved and whether execution was confirmed.

If a remedy call times out, do not immediately repeat it. The Amazon Builders’ Library discussion of idempotent APIs explains the general risk of duplicate side effects during retries. Use the destination’s supported operation identity or reconciliation mechanism, and escalate uncertain outcomes when necessary.

Define closure with evidence

A case can close when the agreed resolution is established and required communication is complete. Record the reason: delivered after delay, customer confirmed receipt, approved replacement issued or another defined outcome. Do not use “no recent events” as a generic closure rule.

Preserve unresolved discrepancies. If the carrier reports delivery but the customer disputes receipt, the case should remain in the appropriate review path until policy allows a resolution. The agent should not decide which person is truthful from writing style or sentiment.

Test the transitions, not only the prose

• The same exception event arrives more than once.
• A normal delivery event arrives while a remedy is awaiting approval.
• A customer reply changes the facts after a draft has been prepared.
• A carrier update is delayed or unavailable.
• A remedy may have committed before the response times out.
• A canceled case receives a late event or callback.

Inspect state, notifications and external actions in each test. A well-written summary can coexist with duplicate messages or an illegal transition. Grade those separately. Measure false escalations and operator review effort as well as time to assemble the packet.

Use an agent only where interpretation helps

For a simple event-to-alert process, a deterministic rule may be sufficient. An agent becomes useful when operators need to interpret several sources, prepare tailored communication or identify missing evidence. Keep the surrounding state machine explicit so the language model does not become the sole keeper of the process.

A reliable exception service knows what state the case is in, why it is there and what can happen next. The agent’s role is to make that work clearer and easier, not to replace the controls that keep remedies and commitments accountable.

Sources and further reading

Shippo: Tracking. Shipment status and history source; checked October 26, 2026.

Shippo: Webhooks. Event notification mechanisms and event-specific behavior; checked October 26, 2026.

Amazon Builders’ Library: Idempotent APIs. General retry and duplicate-side-effect principles; checked October 26, 2026.