Qwen chooses one step at a time, the runtime checks: how a governed AI agent works

Connecting an agent to tools is straightforward. The harder question is what to do when a confident model response is not enough. If an agent proposes bringing a degraded service back into operation, who makes sure the infrastructure can handle the traffic switch and that the service actually recovers? The author of a Habr article decided to test this in practice and built a dedicated environment.

The model proposes, the runtime decides

The testbed is called Governed Agent Runtime. It simulates a payment service: versions and replicas, load in RPS, dependency metrics, capacity constraints and N-1 fault tolerance. A local Qwen model acts as the agent; the article specifies Qwen3.8:27b Q4_K_M. The model selects the next step, while deterministic code controls whether operations are permitted and how they execute. It checks preconditions, requests human approval before any state change, and tracks budgets for model requests and tool calls.

A key detail is that the runtime distinguishes states that are easy to confuse. “8 replicas requested” does not mean 8 replicas are healthy. “Traffic transferred” does not mean the service has recovered. “Operation authorized” does not mean it has executed. “The model considers the task complete” does not mean the final state has been verified.

When the evaluator turned out to be at fault

Across five single-step scenarios with three runs each, Qwen scored 12 out of 15, while the runtime checks passed 15 out of 15. The failure was scenario S12, preparing a rollback plan: the model added thresholds such as “5xx above 5%” and “recovery when 5xx stays below 1% for 5 minutes.” Those figures were absent from its context.

After platform calculations were added to the context—at 820 RPS, six replicas are insufficient, seven fail the N-1 requirement, and eight are enough—the model again received a negative assessment. The author compared three things: what the model saw as input, what the evaluator required, and what the model answered. Some of the evaluator's requirements turned out to have no basis in the input data. The result was revised from “negative” to “inconclusive.”

This led to the introduction of the Evaluation Traceability Gate. Every substantive evaluation criterion must reference a fact in the model's context or have a documented derivation, and a human confirms the decision. The criterion requiring a recovery check before removing the old version still lacked a supporting basis, so the gate blocked it. In a subsequent run, Qwen made an actual mistake: it switched traffic before confirming that eight replicas were ready.

One step at a time

The author then changed the task setup. On each call, the model proposes exactly one action or STOP, and receives updated observations after the step. In the successful run, Qwen followed this sequence: scale to 8 replicas, perform a separate status check, transfer 820 RPS, check recovery, and complete the rollback. That took five model calls, nine tool operations and three human approvals. Before dependent steps, the model itself requested fresh observations and did not mistake an authorized operation for an executed one.

In the negative scenario, the platform returned FAIL during the recovery check. Instead of completing the rollback, Qwen chose STOP, the runtime recorded SAFE_FALLBACK, and the degraded instances remained in place.

Practical takeaways

First: do not give the model execution authority. Let it propose actions, while code checks preconditions and the final state. Second: distinguish “requested,” “authorized,” “executed” and “verified” as separate statuses in logs and tool contracts. Third: the evaluator is itself an artifact that can be misaligned with the input context. If you assess an agent against criteria it could not have known, you are measuring your own process rather than the model.

The caveats are clear. The environment is synthetic and deliberately simplified, the number of runs is small, and some conclusions rely on manual semantic analysis. But the approach applies to any agent that interacts with production systems: you need to check not just the model's answer, but also the relationships between the specification, the context and the evaluator.