An AI operations platform for shipping and logistics

Overview

Mailboxes Etc branches handle shipping, fulfilment, and print work for thousands of business customers. The operational reality was a lot of skilled people doing careful, repetitive data entry: rekeying addresses from emails, itemising customs declarations by hand, and checking tracking across several carrier portals.

The obvious answer — "add a chatbot" — would not have touched any of that, because none of the work is answering questions. It is doing things. So we built an operations platform where staff describe what they need in plain language and an agent performs the action against real systems, with the guardrails that makes safe.

---

Key challenges and solutions

Challenge 1: The work is write-heavy, and wrong writes are expensive

A shipment created with the wrong address or weight costs money and a customer relationship. Most AI systems avoid this by only reading. That would have solved nothing here.

Our solution: every action the agent can take is an explicit, typed tool with a validated schema — thirteen of them in production, covering shipment creation, customer records, tracking, open actions, and bulk import and export. Write actions are gated server-side, so an approval requirement is enforced in the backend rather than requested in a prompt. Retries and duplicate submissions are handled explicitly, so an agent that runs twice does not create two shipments.

Challenge 2: Customs itemisation carries regulatory risk

International parcels need customs declarations with HS tariff codes and per-item weights. Getting a code wrong means held parcels and penalties — a failure mode where confident-sounding output is worse than none.

Our solution: the itemisation tool classifies contents and proposes HS codes with per-item weights, but is deliberately built read-only and non-persisting. It never writes the declaration. An operator reviews and applies it. The AI does the tedious part; the accountable human keeps the decision. This was a design choice, not a limitation.

Challenge 3: Tracking lived across several carrier portals

Staff checked FedEx, UPS, and other carriers separately, and customers asked for updates faster than anyone could gather them.

Our solution: first-party OAuth2 integrations with FedEx and UPS, with AfterShip as a fallback for carriers without direct integration, unified behind one tracking interface. Scheduled re-tracking runs on cron, exceptions are detected automatically, and customer update messages are drafted for staff to review and send.

Challenge 4: Vendor lock-in was an unacceptable risk

A platform this central to daily operations cannot be one provider's outage or price change away from a crisis.

Our solution: model selection is configuration, not code. Seven models are available through a gateway with per-provider fallback ordering, and the platform probes model capabilities — tool support, vision, reasoning — at runtime rather than assuming them. Switching models is a config change.

---

What we did

• Production AI agents
• Typed tool design
• Server-enforced approval gates
• Carrier API integration
• Multi-provider routing
• Next.js & PostgreSQL

---

What shipped

13

Production tools taking write actions

7

Models with per-provider fallback

2

First-party carrier OAuth integrations

Server

Where approval gates are enforced

Alongside the platform, we built and maintain the marketing sites for five high-potential branches — Euston, City Fulfilment, Holborn, Highgate, and Fleet Street — on Next.js and Tailwind, each optimised for local search in its own catchment.

---

Conclusion

The interesting part of this project was not the language model. It was deciding, action by action, which things an agent should be allowed to do on its own, which need a human to approve, and which it should only ever propose. That is the work that separates an AI system you can put into daily operations from one that stays a demo.

---