# Tribal Dungeons of Global Shipping: AI Agents at Global Scale — Dmitry Buykin, Maersk AI Engineer · 2026-08-29 Dmitry Buykin of Maersk explains that global shipping's hardest AI problem is not the agent loop but the refining loop around it, turning tribal dungeons of screenshot-based SOPs into executable procedures. He reports 200 production instances at scales up to 10-minute latencies, with a procedure corpus 20 times larger than runtime because the same step differs across countries. Accuracy was earned through over 100,000 corrections in nine months, heat maps turning traces into priorities, and corrections counting only when they become executable changes. He advocates five moves — make work representable, execution bounded, behavior observable, correction cheap, improvement compound — and skipping MCP for tuned composite tools, since 'please be careful' is not a guardrail. ## Questions this episode answers ### Why does Maersk skip MCPs? Dmitry Buykin says they are not using MCPs because for them it is always not the best choice. The systems are usually really bloated, so they have to distill responses and tune the tools through function coding to their agents. That lets them control software quality and ensure correct processing of assigned tasks. [10:39](https://aiengineer.podhood.com/96ac4679-c103-4945-9161-e2f7b7dca0ec?t=639000) ### What is a 'tribal dungeon' and why are legacy SOPs a problem for agents? Dmitry Buykin calls legacy SOPs 'tribal dungeons' because the knowledge exists but not in a form an agent can execute. Legacy SOPs are a bunch of screenshots of what a person sees and clicks, which are useless to an agent. The hard part is the gap between stable intent detection, safe tool calls, legacy integration, and expert-reviewed results. [2:33](https://aiengineer.podhood.com/96ac4679-c103-4945-9161-e2f7b7dca0ec?t=153000) ### Why is the refining loop more important than the agent loop? Dmitry Buykin says the agent loop is not the system; the refining loop around the agent is the system. The architecture has SOP memory, execution runtime, and SME feedback capture. The refining loop is the most complex part, capturing expert corrections and turning traces into executable changes, so quality comes from replaying real examples. [3:38](https://aiengineer.podhood.com/96ac4679-c103-4945-9161-e2f7b7dca0ec?t=218000) ### How did Maersk improve agent accuracy with corrections and heat maps? Dmitry Buykin says accuracy was earned one small correction at a time, with over 100,000 corrections over the last nine months. Heat maps turned thousands of traces into priorities so experts and engineers focus on the same problems. Turning one red block usually takes one to two months' effort for the whole team of engineers and AI agents. [7:12](https://aiengineer.podhood.com/96ac4679-c103-4945-9161-e2f7b7dca0ec?t=432000) ## Key moments - **[0:00] Long Tail** - **[2:04] Agent SOPs** - [2:33] Dmitry Buykin calls the SOP gap 'tribal dungeons': 'The knowledge exists but not in a form an agent can execute.' - [2:50] Dmitry Buykin: legacy SOPs are screenshots, but an agent SOP needs preconditions, decisions, backend calls, validation, recovery, and evidence of success. - [3:46] Dmitry Buykin: 'The agent loop is not the system; the refining loop around the agent is the system.' - **[3:56] Refining Loop** - [4:20] Maersk's SOP corpus outweighs the agent runtime 20 to 1, says Dmitry Buykin, because the same shipping step differs by country. - [4:42] Dmitry Buykin runs 200+ Maersk agent instances in production, with latencies from a few minutes up to 10 minutes due to legacy backends. - **[4:50] Legacy Backends** - **[5:47] Triage and Traces** - [6:30] Dmitry Buykin: vibe coding and spec-driven development both run out before the real work of AI agent reliability starts. - **[6:44] Coding Limits** - [7:12] Dmitry Buykin: Maersk earned accuracy through over 100,000 corrections in nine months, not from one up-front diagram. - **[7:39] Heat Maps** - **[8:36] Guardrails** - [8:37] 'Please be careful is not a guardrail' — Dmitry Buykin on Maersk's classifier evals, bright gates, and preventive fixes. - [9:09] Dmitry Buykin's five moves: make work representable, make execution bounded, make behavior observable, make correction cheap, make improvement compound. - **[9:31] Five Moves** - **[10:31] Composite Tools** - [10:45] Dmitry Buykin: Maersk skips MCPs because legacy systems are bloated, instead distilling responses and tuning tools via function coding. - **[11:27] Closing** ## Speakers - **Dmitry Buykin** (guest) ## Topics Agent Engineering, Agent Evaluation ## Mentioned Maersk (company), MCP (product) ## Transcript ### Long Tail **Dmitry Buykin** [0:14] 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. ### Agent SOPs **Dmitry Buykin** [2:17] 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. ### Refining Loop **Dmitry Buykin** [3:59] 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. ### Legacy Backends **Dmitry Buykin** [4:57] 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. ### Triage and Traces **Dmitry Buykin** [5:53] 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. ### Coding Limits **Dmitry Buykin** [6:44] 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. ### Heat Maps **Dmitry Buykin** [8:07] 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. ### Guardrails **Dmitry Buykin** [8:37] 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. ### Five Moves **Dmitry Buykin** [9:32] 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. ### Composite Tools **Dmitry Buykin** [10:39] 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. ### Closing **Dmitry Buykin** [11:27] Thank you. Any questions? Okay, then thanks for your attention. Then I will be around so you can ask me questions if you want. --- This library is powered by PodHood (https://podhood.com), the podcast website platform.