Dmitry Buykin

Dmitry Buykin is a software engineer whose work connects AI agent systems for shipping operations with the operational knowledge needed to run them reliably. His work at Maersk turns complicated shipping procedures into software that can act within defined limits, preserve a record of what happened, and improve through expert corrections.

From financial systems to shipping operations

Buykin’s background spans applied mathematics and mechatronics, Nordic payments, and Deutsche Bank trading systems. He subsequently worked on AI and machine-learning adoption at DataRobot, extending his career from operational software into the practical use of machine learning.

At Maersk, his responsibilities have included chapter leadership and bootcamps, bringing an organizational dimension to his engineering work. Helping colleagues develop capabilities sits alongside building the systems themselves—a relevant combination when automation depends on engineers and operational experts understanding one another. In 2026, he held the roles of Applied AI Lead and staff software engineer. His career background connects operational software, machine-learning adoption, and engineering leadership.

Shipping makes those concerns concrete. A shipment depends on several systems progressing together; when their states diverge, operators must reconcile incomplete information across legacy applications. Routine cases may already be automated, leaving a costly long tail of exceptions. Buykin’s work addresses the knowledge and coordination required to handle that tail.

Making operational knowledge executable

Buykin calls knowledge that exists inside an organization but remains difficult for agents to execute tribal dungeons. A standard operating procedure assembled from screenshots may show an employee where to click while leaving the reasons for those clicks implicit. An agent needs prerequisites, decision points, identifiers, backend calls, validation, recovery steps, and evidence that the task succeeded. Operational experts define what must happen; the system must translate that intent into actions it can safely perform.

His production shipping-agent architecture combines a procedure corpus, an execution runtime, and a workspace for expert feedback. The corpus preserves country-specific requirements and grows as the team resolves exceptions. Differences between local processes require negotiation between experts and engineers, even when the underlying task sounds identical. The accumulated procedures become a form of organizational memory that the runtime can use.

In 2026, Buykin reported more than 200 production instances, with execution taking several minutes and sometimes up to ten minutes because tasks depended on legacy systems. A faster agent loop cannot remove every downstream delay. His attention therefore falls on the quality of the process being executed and the system surrounding it.

Several distinctive principles shape that work:

• Corrections become executable changes. Execution traces let an operator and an engineer examine the same case and agree on what happened. Failure clustering and scenario heat maps help direct scarce expert time toward useful fixes. Feedback remains unfinished until it changes executable behavior; the team then replays real cases with write permissions disabled to check the result without affecting production systems. Buykin reported more than 100,000 corrections over nine months of development, placing sustained refinement at the center of reliability.

• Bounded execution removes unsafe paths. A wrong workflow calls for evaluation of the routing decision; an inappropriate write calls for a permission gate; an unsupported assumption calls for review. Critical paths retain human review and approval. His goal is to make specific mistakes impossible where practical, rather than depend entirely on an agent correctly interpreting a warning.

• Composite tools preserve successful behavior. The team combines repeatedly successful sequences into reusable tools that other agents can call. This allows improvements to spread across country-specific operations. Buykin favors tailored function calls over the Model Context Protocol in this environment because legacy-system responses need to be distilled and shaped for the agents. The choice serves control over task execution and tool-response quality.

Learning the structure of logistics

Buykin also proposes a different way to learn from shipping activity itself. His large logistics model proposal treats shipment events as tokens and historical routes as sequences for model training. Learning route embeddings from those sequences could capture patterns in how shipments progress, providing a basis for forecasting and anomaly detection. A shipment that departs from learned patterns could be identified as unusual and examined more closely.

The proposal also explores simulation of disrupted routes. Starting with a partial route, a disruption could be inserted into the event sequence and the model used to simulate downstream consequences. That would give planners a way to explore how an interruption might change the rest of a shipment’s journey, extending the model’s usefulness beyond recognizing unusual activity to investigating possible outcomes.

These are proposed applications, rather than an established deployed Maersk product. They add a distinct technical direction to Buykin’s work: agent procedures encode operational knowledge explicitly, while learned route representations seek patterns in the history of operations. Both address how knowledge becomes usable software—whether by specifying the steps a system may execute or by learning how a shipment’s path might unfold.

His agent-refinement methodology centers on procedures that software can execute, constrained actions, inspectable behavior, and corrections that improve subsequent runs. The lasting asset is the organization’s accumulated ability to handle its real processes and exceptions.