Tribal Dungeons of Global Shipping: AI Agents at Global Scale — Dmitry Buykin, Maersk

Hello, everyone. Um, this is a practitioner report from real production work, so let's get into it. I'll skip the generic "yet another loop agent" intro; this is about the hard part most agent demos skip, and about turning messy operational knowledge into something an agent can execute safely.

This comes from real work in my company I'm working for, supporting global shipping operations and grounded in production.

On paper it's one workflow usually, but in reality every shipment is an orchestration of many parallel state machines. While they agree the happy paths work, the moment one drifts you get exception work.

The easy majority is already automated in many companies. What's left is the long tail and more exceptions than system build to handle them. That tail is the expensive part.

And then there's my favorite category: it comes with a special plate here, see, for AI builder dreams and their laptops. This is what you can find outside of AI bubble in San Francisco.

A single process depends on many systems being coherent at once. If any step can't complete, the happy path breaks and then it takes expert orchestration across multiple incomplete systems. All these variations, pathways, should be captured in SOPs. SOPs are the standard operating procedure, common in regulated industries, so an expert and the model read them the same way.

That gap is the hard part: stable intent detection, tool calls you can guarantee are safe, integrating with legacy backends and results evaluated with experts.

I call these tribal dungeons. The knowledge exists but not in a form an agent can execute. And you can safely run a process; you can't safely run a process the organization cannot represent.

Standard legacy SOPs are a bunch of screenshots organized in sequence, but screenshots are not a process. Legacy SOPs explain what a person sees and clicks, and an agent SOP needs a more complex setup: preconditions, decisions, identifiers, backend calls, validation, recovery, and evidence of successful execution.

Experts own the what, agents own the how, and exception becomes a guardrail. Most of the effort is the translation and negotiation between them to align on common sense.

Three parts here in this architecture: it's SOP memory, organized as SOP corpus, execution runtime, and SME feedback capture. The agent loop is not the system; the refining loop around the agent is the system. And it's the most complex part.

Oops, sorry, SOPs okay, it's this slide for UK. This is the correct one. So, and it's a good illustration why the same thing means different and described differently in different countries. And it's creating a lot of variations between SOPs in each country.

And that corpus is the asset, the company's process memory, modified and aligned with every country's conditions, and far bigger than runtime. You can see the proportion 20 to 1. So, and this is a currently operating system.

And this is the scale we run in production today: over 200 instances and spikes, and latencies deviates from a few minutes to up to 10 minutes.

And mainly, yeah, the main reason for it is that we're depending on a many-legacy system which is, so cannot be faster than the agent loop itself.

Expert time is the bottleneck, so the SME bench does the triage for us. It clusters the failures and hands back something you can act on, not just look at.

The trace is the shared evidence that lets an expert and an engineer review the same case and agree on what happened.

A correction only counts when it becomes an executable change, and that's the line between an opinion and a production fix.

And this is where quality comes from, not from vibes,

not from a bigger model, from replaying real examples with disabled rights to protect production systems, and checking whether behavior improved.

You can see here on the

cognitive proportion of this effort ratio between each activity in our project. So usually vibe coding ends here. Here it ends spec driven development because it cannot grow and improve accuracy more than this stage on this scale. And this is where the real work starts.

Nothing exotic, it's a common engineering sense applied to that scale. So if you don't know all this terminology, which developed over the last 30 years in software development, I recommend to check because this is what every AI agent, AI coding agent should know to help you develop reliable production systems.

And accuracy, it wasn't designed in one diagram up front. It was earned one small correction at a time at the scale you see here. So we have over 100,000 corrections over the last nine months in the system when we were developing it.

And these heat maps turned thousands of traces into priorities. It's how we keep experts and engineers looking at the same problems and prioritize where the most beneficial work for them. Every cell is a group of tracked scenarios we have, and usually to turn one block in red, it's around one to two months' efforts for the whole team.

Whole team of engineers and also AI agents. And the agent failed is where the investigation starts, not where it ends. Each failure maps to a specific fix.

Discovery needs agent freedom, and production needs a cage. The harness isn't there to give the agent more room; it's there to make the dumb mistakes impossible.

So on this scale, please be careful is not a guardrail. If we have a wrong workflow, then classifier eval. If it's wrongright, then bright gate. If it's wrong assumption, then it's a mirror view. A preventive measure eliminates the unsafe path.

On critical paths, review and approval stay in a loop. The engineering focus is to build safe hands-offs and a trail you can trust.

The real outcome wasn't the agent in the system; it was the methodology we built around it. If you want the blueprint, then it's these five moves: make work representable, make execution bounded, make behavior observable for every agent, and make correction cheap.

And last thing, it's make improvement compound. So gradually, systematically improve the quality of the system.

AI native operation is more than agents in workflow. It's a system that learns from what works and folds it back into code as new composite tools, adapting to the applications and the people around it. The best AI models are rented intelligence for us.

The adaptive architecture we built is the asset, the final asset.

And we're aggregating all repeatable sequences of steps, successful scenarios, and merging them into bigger tools which combine the disproven scenarios into the reusable snippets by other agents. So, and then it's possible to roll out them not only for one country but for hundreds of countries in one go.

So this is all for the talk. Little time for questions, and I'll be around afterwards. And the final reminder: you know if you know if you are an AI builder if you're emotionally attached to tools, not MCPs. We're not using MCPs because for us it's always not the best choice.

So because all systems usually really bloated, and we have to distill responses and tune the tools through function coding to our agents. Then we can control quality of our software and ensure that it's correctly processing assigned tasks.

Thank you. Any questions?

Okay, then thanks for your attention. Then I will be around so you can ask me questions if you want.