Deterministic Runtime Controls AI Agent Actions in Synthetic Payment Service Experiments
November 11, 2026 · 2 min read
Also published in Deutsch, Português (Brasil), Italiano
A deterministic execution environment successfully controlled the actions of an artificial intelligence agent during experiments involving a synthetic payment service. The system ensured that the model selected subsequent steps while a governed runtime verified the permissibility and execution of operations. This approach addressed challenges in scenarios where confident model responses were insufficient and strict constraints required enforcement.
The development focused on a governed agent runtime integrated with a local Qwen3.8:27b model. The environment simulated a payment service containing data on version states, replica health, service load distribution, and dependency metrics. Constraints included power limits, N-1 fault tolerance requirements, and tool contracts. The environment was intentionally simplified to limit experimental conditions and allow precise analysis of model behavior. The project evolved from single-step proposals to multi-step execution, though questions regarding model explanations remained.
Initial testing involved a deterministic check of scenario S01 without a large language model. This scenario described service degradation during a partial deployment of a new version. The runtime logic verified action permissibility and prevented premature rollbacks. Subsequent testing expanded to five diverse scenarios using the Qwen3.8:27b Q4_K_M model. Each scenario underwent three runs with fixed input conditions, including a fixed seed. The runtime checked model proposals against structural contracts, context, and conditions. Quality assessment combined automated checks with human-confirmed semantic analysis.
Four of the five scenarios yielded positive results. Scenario S12 attracted special attention due to a zero-out-of-three success rate and its substantive nature. Unlike S01, which tested basic diagnostics, S12 required the model to prepare a recovery plan considering load, power, and constraints. The model selected a permissible proposal type but included unconfirmed operational criteria. Specifically, the model added stopping conditions based on error rates and dependency load thresholds that were not present in the available context. These criteria could potentially mislead operators who might trust the persuasive but unsubstantiated response.
Further work on S12 involved a new experiment with more specific service states and recovery conditions. To avoid reliance on independent model calculations, the platform calculated numerical indicators and passed them to the agent as context. The context indicated that six stable replicas were insufficient at 820 requests per second, seven failed the N-1 requirement, and eight provided necessary capacity. The development followed specifications with bounded changes. The project repository contains the implementation and materials. A demonstration interface displays the results. The experiments highlighted the necessity of deterministic control over model-generated operational criteria in critical infrastructure scenarios.