The expensive part of shipping automation is the long tail of exceptions across incomplete and country-specific systems.
2
An agent-ready procedure needs preconditions, decisions, identifiers, backend calls, validation, recovery, and evidence, rather than screenshots of human clicks.
3
Production quality comes from a refining loop built on traces, expert corrections, bounded execution, and executable fixes.
Summary
Dmitry Buykin describes agent work in global shipping, where a shipment is really an orchestration of many parallel state machines. The easy cases are already automated, while exceptions remain expensive because they cross incomplete legacy systems and vary by country. Maersk's existing procedures were screenshots that showed people what to click. Buykin's team translated them into executable procedures with preconditions, decisions, identifiers, backend calls, validation, recovery, and evidence. He argues that the refining loop around the agent is the real system. It includes an SOP corpus, runtime controls, traces, triage, expert review, replay, and executable corrections. The team has made more than 100,000 corrections over nine months, with heat maps directing attention to scenario groups. Discovery can allow freedom, but production needs a harness that blocks unsafe paths. The resulting reusable composite tools can be rolled out across countries, while tightly tuned function calls give the team more control than MCP.
The long tail of exceptions costs more than the happy path
Buykin says a shipping workflow looks like one process on paper, but each shipment involves many parallel state machines. The easy majority is already automated in many companies. What remains is a long tail of exceptions, where systems drift and no single system can complete the work. A successful path depends on several systems staying coherent. When one step fails, an expert has to orchestrate work across incomplete systems. Buykin says these variations should be captured in standard operating procedures, but ordinary procedures do not give an agent enough information to act safely.
Buykin calls the gap between organizational knowledge and executable agent behavior "tribal dungeons." Legacy SOPs often consist of screenshots arranged in sequence. They explain what a person sees and clicks, but a screenshot is not a process an agent can safely run. An agent-ready SOP needs preconditions, decisions, identifiers, backend calls, validation, recovery, and evidence of successful execution. Experts own the what, while agents own the how. Much of the project therefore involved translation and negotiation with process experts, including turning exceptions into guardrails.
The refining loop around the agent is the actual system
Buykin describes three parts of the architecture: SOP memory organized as a corpus, the execution runtime, and a feedback capture system. He says the agent loop itself is not the system. The refining loop around it is more complex and does the real operational work. The same process can mean different things in different countries, so the corpus must be modified and aligned with local conditions. He estimates that the process corpus is about twenty times larger than the runtime. In his view, that corpus is the company's process memory.
Legacy systems make production orchestration slow and variable
The production setup runs more than 200 instances concurrently. Spikes and latency deviations range from a few minutes to up to ten minutes, largely because the agents depend on legacy systems that cannot respond faster than the agent loop. Expert time is another bottleneck. Buykin's team bench performs triage by clustering failures and returning cases that people can act on. Traces provide shared evidence, so an expert and an engineer can inspect the same case and agree on what happened instead of relying on separate impressions.
A correction matters only when it becomes an executable change
Buykin draws a firm line between feedback and a production fix. A correction counts only when it becomes an executable change. Quality comes from replaying real examples with writes disabled to protect production systems, then checking whether behavior improved. He says vibe coding reaches its limit, and spec-driven development also stops improving accuracy at this scale. The work that follows is ordinary engineering applied across a large system. The agent's failure starts an investigation, but it does not finish one. Each failure must map to a specific fix.
Accuracy was earned through more than 100,000 small corrections
Buykin says accuracy was not designed in a diagram at the beginning. It was earned one small correction at a time. The system accumulated more than 100,000 corrections over nine months. Heat maps turned thousands of traces into priorities and helped experts and engineers work on the same scenario groups. Turning one block on the heat map red typically takes one or two months of effort from the engineering team and its agents. The scale changes how quality work is selected, because the team must spend its time where a group of related scenarios offers the most benefit.
Production needs a harness that blocks unsafe paths
Buykin contrasts discovery and production. Discovery needs agent freedom, while production needs a cage. The harness is not there to give the agent more room. It makes dumb mistakes impossible. A wrong workflow can trigger a classifier evaluation, a wrong route can trigger a gate, and a wrong assumption can require review. Preventive measures remove unsafe paths from critical workflows. Review and approval remain in the loop. The engineering task is to create safe handoffs and a trail that people can trust. Telling an agent to be careful is not a guardrail.
Reusable composite tools let improvements spread across countries
Buykin gives five moves for building the system: make work representable, make execution bounded, make behavior observable, make correction cheap, and make improvement compound. The team collects repeatable sequences and successful scenarios, then merges them into larger reusable tools. These composite tools contain proven sequences that other agents can reuse. Buykin says they can then be rolled out beyond one country, potentially across hundreds of countries in one go. His team does not use MCP because its systems are often bloated and responses need to be distilled. Tuned function calls give them more control over tool quality and task processing.
"The final reminder, if you are an AI builder, if you are emotionally attached to tools not MCPs, we're not using MCPs because for us it's always not the best choice."10:31
Who should watch
You are automating exception-heavy operations where the easy workflows already work and the remaining cases cross several legacy systems.
Your procedures are stored as screenshots or informal expert knowledge, and agents cannot execute them with clear validation and recovery steps.
You are building production agent infrastructure and need a concrete approach to traces, replay, guardrails, expert review, and correction workflows.
