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

Dmitry Buykin opens with a production problem: turning messy operational knowledge into something an agent can execute safely. His setting is global shipping, where a workflow that looks singular on paper actually coordinates many parallel state machines. As long as those systems agree, the happy path works. When one drifts, the shipment becomes exception work.

The easy majority, he says, is already automated in many companies. The remaining long tail contains more exceptions than the existing systems were built to handle, making it disproportionately expensive. A process depends on multiple systems remaining coherent at once; if one step cannot complete, an expert must orchestrate work across incomplete systems. That is the operational challenge his agents have to address.

Standard operating procedures, or SOPs, are supposed to capture the variations and pathways experts handle. Making them useful to agents involves stable intent detection, safe tool calls, integration with legacy backends, and evaluation with experts. Buykin calls the gap “tribal dungeons”: the organization possesses the knowledge, but has not represented it in a form an agent can safely execute.

His concrete example is a legacy SOP consisting of screenshots arranged in sequence. It records what a person sees and clicks. An agent procedure needs preconditions, decisions, identifiers, backend calls, validation, recovery, and evidence of successful execution. These elements make explicit when work may start, which branch to follow, what records and operations are involved, how to check the result, and what to do when execution fails. A record of clicks alone does not supply that execution contract.

Buykin assigns experts ownership of the what and agents ownership of the how. Most of the effort lies in translating and negotiating between them until the procedure reflects a shared understanding. An exception can then become a guardrail: knowledge that once required an expert’s intervention becomes an explicit constraint on subsequent execution.

The architecture has three parts: SOP memory organized as a corpus, an execution runtime, and feedback capture. Buykin places the greatest complexity in the refinement process surrounding the agent. Running a loop is only one part of the system; the organization also needs a way to retain process knowledge and revise it as execution exposes gaps.

A slide correction becomes an illustration of country variation: what appears to be the same thing can mean something different, and be described differently, in different countries. The corpus therefore represents company process memory adapted to local conditions. Buykin gives its proportion to the runtime as 20 to 1. He does not specify a measurement unit, so the comparison establishes the corpus’s relative importance without establishing a ratio of code, storage, or engineering hours.

At the reported production scale, the system runs over 200 instances, with latency ranging from a few minutes to as much as 10 minutes. Buykin attributes the delay mainly to dependencies on legacy systems. Concurrency and completion time are separate concerns here: many instances can operate at once while individual workflows still wait on the backends they must coordinate.

Expert time becomes the bottleneck, so the team uses triage tooling to cluster failures into actionable groups. The trace supplies shared evidence: an expert and an engineer can inspect the same case and agree on what happened. Clustering helps decide where to spend attention, while the individual trace supports a concrete diagnosis.

A correction counts only when it becomes an executable change. Agreement about what should have happened is not yet a production fix; the system’s behavior must change. The team checks those changes by replaying real examples with rights disabled to protect production systems, then examining whether behavior improved. This connects diagnosis, implementation, and verification in one refinement cycle.

Buykin argues that vibe coding and spec-driven development reach limits in this project: further accuracy at this scale requires sustained engineering work. He frames that work as established software engineering practice rather than an exotic new discipline, and says AI coding agents need that engineering knowledge to help build reliable production systems.

Accuracy, he says, was earned one small correction at a time. He reports over 100,000 corrections during nine months of development. That number describes the scale of refinement; the supplied account does not define the counting unit or give an accuracy percentage, so it cannot establish a success rate by itself.

Heat maps turn thousands of traces into priorities. Each cell represents a group of tracked scenarios, allowing experts and engineers to focus on the same problems and identify where work would be most beneficial. Buykin associates changing one block with around one or two months of effort from the whole team, including engineers and AI agents. The effort estimate makes clear that a compact visual summary can represent substantial work.

“The agent failed” is the beginning of investigation. Each failure needs to map to a specific fix. This requirement keeps a broad failure label from becoming the final explanation..

Buykin draws a boundary between discovery and production. Discovery benefits from agent freedom; production needs a constrained harness that makes avoidable mistakes impossible. Asking an agent to be careful does not create that constraint. A preventive measure must remove the unsafe execution path.

One clearly stated example connects selecting the wrong workflow to classifier evaluation: the remedy should address the mechanism that chose the workflow. Specific failures require specific preventive measures. On critical paths, review and approval remain in the loop, with engineering focused on safe handoffs and a trustworthy trail of what happened.

Buykin presents the methodology as the central outcome of the project. Its five moves are to make work representable, make execution bounded, make every agent’s behavior observable, make correction cheap, and make improvement compound. Together they connect process definition to controlled execution and then to a systematic way of improving quality.

The compounding mechanism is concrete: learn which sequences work and fold them back into code as composite tools. Repeated successful sequences are aggregated into larger tools and reusable snippets that other agents can use. Operational learning therefore changes the software available to later executions, while the architecture adapts to the applications and people around it.

Buykin identifies this adaptive architecture as the lasting asset. He says reusable tools make it possible to roll out successful sequences across hundreds of countries in one go. This is a claim about the potential reach of reuse, not a documented rollout count.

In his closing technical point, Buykin says the team does not use MCP for this system. He describes the connected systems as bloated and says the team needs to distill their responses and tune tools to the agents through function calling. The decision centers on controlling what the agent receives and how its tools support assigned tasks.

This is a system-specific integration choice. Buykin’s stated benefit is control over software quality and correct task processing; he provides no comparative benchmark establishing a general limitation of MCP.