Talk by Dmitry Buykin (Maersk) on translating human standard operating procedures (SOPs, kept as click-by-click screenshots) into executable agent procedures with preconditions, decisions, identifiers, backend calls, validation, and recovery. Key points: the refining loop around the agent loop is the real system, with the procedure corpus outweighing the runtime roughly 20:1 due to country-by-country variations; accuracy was earned via over 100,000 corrections over nine months, guided by heat maps of traces; a correction only counts once it becomes an executable change; and a harness should make dumb mistakes impossible. Topics include running 200 agent instances against legacy backends, triage and shared evidence, the limits of vibe coding and spec-driven work, guardrails beyond "please be careful," compounding improvement, and composite tools vs. MCP. # Channel Presentation Observations ## Video Framing and Format - **Conference-style practitioner talk** with Q&A and speaker availability afterwards: *"this is all for the talk and little time for questions and I'll be around afterwards."* - Explicitly positioned as **production experience, not a demo**: *"a practitioner report from real production work"* and *"grounded in production."* - Deliberately skips introductory content: *"I'll skip the generic yet another loop agent intro."* ## Speaker Identity and Affiliation - Speaker is **Dmitry Buykin of Maersk** (per video title). - Self-described practitioner in global shipping: *"in my company I'm working for supporting global shipping operations."* ## Claimed Scope - Large-scale production AI agent deployment in logistics: - *"over 200 instances"* running concurrently in production - Latency range *"few minutes to up to 10 minutes"* - *"over 100,000 corrections over last 9 months"* - Multi-country rollout capability: *"possible to roll out them not only for one country but for hundreds country in one go."* - SOP corpus described as **20:1 proportion** relative to runtime: *"the corpus is an asset the company's process memory... far bigger than runtime." ## Demonstrated Expertise Areas - **SOP transformation for agents**: legacy SOPs as *"bunch of screenshots organized in sequence"* vs. agent SOPs needing *"preconditions, decisions, identifiers, back end calls, validation, recovery."* - **Division of responsibility**: *"Experts own the what, agents own the how."* - **Safety engineering**: *"discovery needs agent freedom and production needs a cage"*; *"on this scale 'please be careful' is not a guard."* - **Opinionated tooling stance**: *"we're not using MCPs because... it's always not the best choice... we have to distill responses and tune the tools through function calling."* ## Intended Audience - **AI builders and engineers** developing production agents, addressed directly: *"if you are an AI builder if you emotionally attached to tools"* - Practitioners expected to know software engineering fundamentals: *"this is what every AI agent... should know to help you develop reliable production systems."* - Slight contrarian positioning against mainstream AI culture: *"this what you can find outside of AI bubble in San Francisco."* ## Self-Description vs. Demonstrated Patterns - **Creator claims**: production scale, correction volume, methodology value (*"The real outcome wasn't the agent in the system. It was the methodology"*). - **Demonstrated**: engineering-first vocabulary (heat maps, trace review, replay evals, classifier/right gates), emphasis that quality comes from *"replaying real examples with disabled rights"* — consistent with a rigorous engineering culture rather than model-hype framing (*"not from vibes not from a bigger model"*). # Delivery Observations: Dmitry Buykin, Maersk — Tribal Dungeons of Global Shipping ## Tone and Register - **Practitioner, anti-hype tone.** The speaker explicitly positions the talk against typical demos: > "I'll skip the generic uh yet another loop agent intro. This is about the hard part most agent demos skip." - **Engineering pragmatism.** He repeatedly grounds claims in production scale rather than novelty: > "Nothing exotic. It's engineering common engineering sense applied at scale." - **Wry humor, sparse and dry.** One visible joke: > "See for EI builder dreams and their laptops." ## Verbal Habits - **Heavy filler usage.** "Uh" and "um" appear pervasively throughout, suggesting unscripted or lightly rehearsed delivery: > "Um, this is a practitioner report uh from real production work." - **Self-corrections mid-sentence.** Examples include recovering from a wrong slide: > "Oh, sorry SAP is okay. It's this slide for UK. This is correct one." — handled matter-of-factly, without extended apology. - **Word repetition for emphasis or restart.** > "The organization cannot represent standard legacy SOPs [clears throat] bunch of bunch of screenshots" and > "than than than runtime." - **Physical tells.** Two audible throat clears ([164], [548]) appear at transition points; only two instances, so this is incidental rather than a pattern. ## Vocabulary and Framing Devices - **Metaphorical coinage as a structural device.** The talk title concept is defined explicitly: > "I call this uh tribal dungeons. The knowledge exists but not in a form uh agent can execute." - **Bilateral ownership framing.** A recurring rhetorical structure splits responsibilities: > "Experts own the what, agents own the how." - **Contrastive aphorisms.** The speaker compresses points into paired opposites: - > "Discovery needs agent freedom and production needs a cage." - > "A correction only counts when it becomes an executable change. And that's the line between an opinion and a production fix." - **Anti-"vibes" quality framing.** > "quality comes from. not from vibes uh not from a bigger model from replaying real examples." - **Industry jargon used without much scaffolding.** Terms like SOP, MCP, classifier eval, heat maps, traces are used directly; the one gloss offered is: > "SOPs is a standard operating procedure common and regulated industries." ## Teaching Habits - **Numbers as evidence.** Concrete production figures anchor claims: > "over 200 instances," > "over 100,000 corrections over last 9 months," > "the proportion 20 to 1," > "around one two months of force for the whole team." - **Enumerated blueprint as a takeaway.** The talk closes with a list structure: > "Make work representable. Make exe execution bounded. Make behavior observable for every agent and make correction cheap... make improvement compound." - **Redefinition of the system's core.** A pivot statement reframes the architecture: > "The agent loop is not the system. The refining loop around the agent is the system." - **Brief didactic aside to the audience.** He points listeners to prior art: > "this is what every AI agent uh AI coding agent should know uh to help you develop reliable production systems." ## Communication Patterns - **Hedged, concessionary endings.** Several points end with a qualifying caveat, e.g., on latency: > "we depending on many legacy system which is uh so cannot be faster than agent loop itself." - **Talkative, run-on transitions.** Sentences often chain with "and," "so," and "uh," giving the delivery a stream-of-consciousness feel even when the underlying structure (three parts, five moves, slide-driven) is organized. - **Direct opinion offered unprompted at the close.** On tooling: > "if you emotionally attached to tools not MCPS we're not using MCPS because uh for us it's uh always not the best choice" — delivered as a parting reminder rather than a defended argument. - **Audience handoff.** He ends with availability rather than a strong close: > "Then I will be around so you can ask me questions if you want." ## Stability vs. Isolated Moments - **Stable patterns (repeatedly observable):** filler words, contrastive aphorisms, production-scale numbers as evidence, anti-demo/anti-hype framing, jargon-without-gloss. - **Isolated moments (insufficient repetition):** the wrong-slide recovery ([238]–[249]), the "EI builder dreams" joke, and the MCP opinion in the outro. These should not be treated as characteristic delivery features. # Observation Record: "Tribal Dungeons of Global Shipping: AI Agents at Global Scale" — Dmitry Buykin, Maersk ## Context of Claims - Speaker: Dmitry Buykin (per video metadata), presenting a **practitioner report from real production work** supporting **global shipping operations** at Maersk. - Framing: focused on "the hard part most agent demos skip" — turning messy operational knowledge into something an agent can execute safely. ## Core Position: "Tribal Dungeons" - Buykin's central claim: knowledge exists in organizations but **not in a form an agent can execute safely**. He names this problem **"tribal dungeons."** - Legacy SOPs (standard operating procedures) are described as: - A "bunch of screenshots organized in sequence." - Explaining **what a person sees and clicks** — not a process. - An **agent SOP**, by contrast, needs: **preconditions, decisions, identifiers, back-end calls, validation, recovery, and evidence of successful execution.** - Principle: **"Experts own the what, agents own the how."** Most effort goes into the translation and negotiation between them to align on common sense. ## Operational Reality of Shipping - On paper: one workflow; in reality: **every shipment is an orchestration of many parallel state machines.** - Happy paths agree; when one drifts, **exception work** results. The majority of easy cases is already automated in many companies; what's left is the **expensive long tail** of exceptions. - The process depends on many systems being coherent at once; any incomplete step breaks the happy path, requiring **expert orchestration across incomplete systems.** - Same operations mean different things and are described differently across countries (illustrated by a corrected slide he noted was "for UK"), creating **country-by-country variation.** - The SOP corpus is a **company process memory asset**, modified and aligned per country — far larger than the runtime (proportion stated as **20 to 1**). ## Production Scale (Stated Figures) - **Over 200 concurrently operating instances** in production. - Spikes/latencies deviate from a few minutes up to **10 minutes** — attributed to dependence on legacy systems that "cannot be faster than the agent loop itself." - **Over 100,000 corrections over the last 9 months** during development. - Turning one red block on a heat map into a resolved state takes roughly **one to two months** of work by a full team of engineers plus AI agents. ## Architecture and Methodology - Three parts: **SOP memory (corpus), execution runtime, and feedback capture.** - Key claim: **"The agent loop is not the system. The refining loop around the agent is the system"** — and it's the most complex part. - **Expert time is the bottleneck**; the feedback bench does triage, clusters failures, and returns actionable items. - **Traces are shared evidence** letting experts and engineers agree on what happened. - **"A correction only counts when it becomes an executable change"** — the line between opinion and a production fix. - Quality comes from **replaying real examples with disabled writes** (to protect production), not "from vibes" or "a bigger model." ## Effort Distribution and Limits of Spec-Driven Development - Per his effort-ratio chart: **pipelined coding and spec-driven development end early** because they cannot improve accuracy further at this scale — "this is where the real work starts." - Characterizes the work as "nothing exotic — engineering common engineering sense applied at scale." - Claim: terminology developed over 30 years of software engineering is what "every AI coding agent should know." ## Guardrails and Safety - Stated tension: **"Discovery needs agent freedom and production needs a cage."** - The harness's purpose is **making dumb mistakes impossible**, not giving the agent more room. - **"On this scale, 'please be careful' is not a guardrail."** - Failure-mapped responses: wrong workflow → classifier eval; wrong write → write gate; wrong assumption → review. Preventive measures eliminate unsafe paths on critical paths; **review and approval stay in the loop**. - **Agent failure is where investigation starts, not where it ends** — each failure maps to a specific fix. ## Outcome and Blueprint - Claimed real outcome: not the agent itself, but **the methodology built around it**. Five moves: 1. Make work representable 2. Make execution bounded 3. Make behavior observable 4. Make correction cheap 5. Make improvement compound - **AI-native operations** defined as a system that learns from what works and folds it back into code as **new composite tools**, adapting to applications and people. - Successful repeatable step sequences are aggregated and merged into **bigger reusable tools/snippets** usable by other agents — enabling rollout to "hundreds of countries in one go." - Claim: the **adaptive architecture, not the AI models, is the final asset**. ## Contested/Qualified Position: MCPs - Buykin states his team is **not using MCPs**, "because for us it's always not the best choice": - Systems are "really bloated"; they must **distill responses** and **tune tools through function calling** to control software quality and correct task processing. - Noted as a direct remark to AI builders "emotionally attached to tools." ## Qualifications and Tensions Preserved - Acknowledged slide error mid-talk (showed the wrong country-specific slide, corrected to the UK one) — used as evidence for his country-variation claim. - Tension explicitly maintained: **freedom vs. cage**, **experts vs. agents**, **opinion vs. executable fix**, **models vs. architecture as the asset**. - No questions were asked in the session; speaker offered availability afterwards. # Speaker Attribution & Provenance Record ## Video - **Title:** Tribal Dungeons of Global Shipping: AI Agents at Global Scale — Dmitry Buykin, Maersk - **Video ID:** `01a15ca7-9862-725f-a0d3-284e35050be8` - **Format:** Practitioner conference talk ("practitioner report from real production work") ## Speakers | Speaker | Role | Evidence | |---|---|---| | Dmitry Buykin | **Creator / Presenter** — sole speaker | Title metadata names him; first-person statements: "I'm working for supporting global shipping operations"; "I'll skip the generic... loop agent intro" | - **No guests, narrators, or other identified speakers** appear in the transcript. - Audience/audience questions are implied ("Any questions?") but no audience utterances are recorded. ## Referenced Sources & Claims - **Employer/organization:** Speaker states the work comes from "real work in my company... supporting global shipping operations" (Maersk, per title metadata). - **Referenced systems (by name):** **SAP** (briefly, during a slide correction: "Oh, sorry SAP is okay. It's this slide for UK."); **MCPs** (Model Context Protocol) — explicitly stated as *not used*: "we're not using MCPs because... it's always not the best choice." - **Internal production statistics (speaker-reported claims, unverifiable from source):** - Over **200 concurrently running instances** in production - Latency spikes of **few minutes up to 10 minutes**, attributed to legacy system dependencies - SOP corpus to runtime proportion of **20:1** - Over **100,000 corrections over 9 months** - Roughly **one to two months of team effort** per heatmap block improvement ## Third-Party Claims - No third-party sources, citations, or external datasets are referenced. ## Promotional Segments - **None flagged.** No product pitches, sponsor mentions, or calls to action (beyond "I'll be around afterwards" for questions, which is standard talk close-out, not promotion). ## Comment Availability - **No comment metadata supplied** — comment availability unknown. ## Uncertainty Notes - Speaker affiliation with Maersk is established via title metadata only; the speaker says "my company" without naming it in the transcript. - Transcript contains disfluencies and apparent transcription artifacts; quoted statistics are as spoken and not independently verifiable from this source. Hello everyone. Um, this is a practitioner report uh from real production work. So, let's get into it. Um, I'll skip the generic uh 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 uh in my company I'm working for supporting global shipping operations and grounded in production. On paper it's uh one workflow usually but uh 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 built uh to handle them. That tail is uh the expensive part. And then there's my favorite category. And it comes with a special uh plate here. See for EI builder dreams and their laptops. This what you can find outside of AI bubble in San Francisco. The signal process uh depends on many systems being coherent at once. If any step uh can't complete the happy path breaks and then it takes expert uh archist expert orchestration across uh multiple incomplete systems. All these uh variations um path pathways should be captured in SOPs. SOPs is a standard operating procedure common and regulated industries. So an expert and the model read them uh the same way. That gap is the hard part. Stable intent detection tool calls you can guarantee are safe integrating with legacy back ends and results evaluated with experts. Uh I call this uh tribal dungeons. Uh the knowledge exists but not in a form uh agent can execute and you can safely run a process. You can't safely run a process. The organization cannot represent standard legacy SOPs \[clears throat\] bunch of bunch of screenshots organized in sequence and but screenshots not uh a process. A legacy SOPs explain what a person sees and clicks. And an agent SOP needs a more complex uh setup, preconditions, uh decisions, identifiers, back end calls, validation, recovery, and evidence of uh 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 um in this architecture it's SOP memory uh organized as SOP corpus execution runtime and theme 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. Oh, sorry SAP is okay. It's this slide for UK. This is correct one. So and it's good illustration why the the same thing is means different and uh describing differently in different countries and it's creating a lot of variations between each country and that corpus is a asset the company company's process memory uh modified and aligned with every country um conditions and far bigger than than than runtime you could see the proportion 20 to1 So and this is concurrently operating system and this is the scale we run in production today over 200 instances and spikes and latencies deviates from few minutes to up to 10 minutes. Um and mainly yeah the mainly main reason for it that u we depending on many legacy system which is uh so cannot be faster than agent loop itself. Expert time is the bottleneck. So the theme bench uh does the triage for us. It clusters the failures and hands back something you can act on. Not just look at look at it. 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 and this is where quality comes from. not from vibes uh not from a bigger model from replaying real examples with u disabled rights to uh protect the production systems and checking whether behavior improved. You can see here on the uh cognitive proportion u or this effort ratio uh between each activity in our project. So usually uh pipe coding ends here. Here there ends um specdriven development because it cannot uh grow improve accuracy more than this stage on this scale. And this is uh where the real work starts. Nothing exotic. It's engineering common engineering sense applied at scale. So if uh you don't know all this uh terminology which developed over lastuh 30 years in software development argument to check because this is what every AI agent uh AI coding agent should know uh to help you develop reliable production systems and accuracy it's uh wasn't designed uh in one diagram up front it was earned one small correction at the time at the scale you see here. So we have over 100,000 corrections over last 9 months in the system when we developing it and this um heat maps uh turned thousands of traces into priorities. is how we keep experts and engineers uh looking at the same problems and prioritize where the the most beneficial work for them. Every cell is a group of tracked scenarios we have and uh usually to turn one block in red it's around one two months of force for the whole team whole team of engineers and also AI agents um the agent failed is uh where the investigation starts not where it ends each failure maps to a specific uh fix discovery needs agent freedom and production needs a cage. Uh 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 guard guard. Uh if we have wrong workflow then classifier eval. If it's wrong right then right gate. If it's wrong assumption then it's a mere view. A preventive measure eliminates the unsafe path on critical paths. U review and approval stay in the loop. The engine engineering focus is uh to build safe hands offs and a trail you can trust. The real outcome uh wasn't the agent in the system. It was the \[clears throat\] methodology we built around it. If you want the blueprint, then it's uh these five moves. Make work representable. Make exe execution bounded. Make behavior observable for every agent and make correction cheap. And last thing is make improvement compound. So gradually systematically improve the quality of the system. AI native um operation is more than agents in workflow. It's a system that learns from what works and fold folds it back into code as new composite tools adapting to the applications and the people around it. The best AI models um oriented intelligence for us. The adaptive architecture we built is the asset, the final asset and we aggregating all um repeatable sequences of steps successful scenarios and uh merging them into bigger tools which uh combine the disproven scenarios into the reusable snippets by other agents. So and then um it's possible to roll out them not only for one country but for hundreds country in one go. So this is um um all for the talk and little time for questions and I'll be around afterwards. And the final reminder you know if you you know if you are AI builder if you emotionally attached to tools not MCPS we're not using MCPS because uh for us it's uh always not the best choice. So because all all systems usually really bloated and we have to distill responses and uh tune the tools through function calling uh to our agents then we can control quality of um our software and ensure that uh it's correctly processing assigned tasks. Thank you. Any questions? Okay, then um thanks for your attent u attention. Then I will be around so you can ask me questions if you want. \>\> \[music\]