How agents get fenced in when the answer must be 100% right

In some jobs, 97% accuracy means you can’t use it

On October 10, InfoQ China published a write-up of a talk by Yu Haojun, chief engineer at Zhongruan Rongxin, given at the AICon AI developer conference in Shenzhen. The topic is how to make agents run reliably when a financial institution reports data to its regulator.¹ After reading it, I think this is one of the better architectures I have seen for work that is both high-risk and heavily audited.

The job’s traits drive every design choice, so start there. Yu’s figures: one report can involve 100 to 500 indicators, the data passes through more than 15 processing layers, and the reporting definitions change at least once a year, by about 30%.¹ He says 97% accuracy is not enough. The requirement is 100%, because errors are fined, and he puts industry penalties in the first half of the year at hundreds of millions of yuan.¹ These are the speaker’s figures and I can’t verify them independently. The shape of the job is easy to see, though: the definitions live in documents and change every year, one wrong number means someone is accountable, and afterwards you must show where each number came from.

Other heavily audited fields ask for the same thing

Finance isn’t the only field like this. In pharmaceuticals, US rule 21 CFR 11.10 requires electronic record systems to be validated so they can detect invalid or altered records. Audit trails must be computer-generated and time-stamped, and must log every create, modify and delete. The rule adds that record changes must not obscure previously recorded information.⁴ In aviation maintenance, 14 CFR 43.9 says each record must state what was done, when it was finished and who did it, and, for work that passes inspection, carry the approver’s signature and certificate number.⁵ And the EU AI Act requires high-risk AI systems to log events automatically over their lifetime,² and to be built so people can oversee them: understand their limits, override their output, and stop them.³

The fields differ, the demands rhyme. Leave a trace, never erase history, put a person behind each key judgement, and let the system be validated. An agent that improvises freely collides with all of that. Yu’s answer is to never let it improvise in the first place.

Constraints start at data and knowledge, then move outward

The article’s architecture has two foundations and an execution layer.¹ The first foundation is a knowledge base holding regulatory documents and internal definitions. Retrieval mixes vector search, exact lookup and a graph store, and it is sliced by agent scope, so each agent sees only what it should. The second is a data base holding detail, indicator and report data together with metadata, data standards, security classification and quality governance, with access limited by permission.

On top sits the execution layer: orchestration, packaged skills, controlled MCP connections and full tracing. It puts five controls on every turn of the agent loop. In planning, skills may only come from a registered set and must produce a structured plan. In protection, an action whitelist and schema validation reject anything out of bounds. In execution, deterministic computation moves into fixed Python, Java or SQL tools instead of model reasoning. In checking, contracts and consistency are validated before the next step. In the process check, a state fails if any of four main dimensions is missing.¹

Around the five controls are hard limits. The action space is closed, so unregistered skills and tools cannot be called. There are budgets and step caps; in Yu’s example, a task expected to take 15 steps is halted if it passes 30. Three human checkpoints cover definition confirmation, data completion and final sign-off. Any error stops the run instead of letting the agent find its own way on.¹ Yu also gives a contrast: where about 5 currency types are legitimate, an uncontrolled model produced 15 to 16.¹

The model judges; fixed code computes

The part of this design I agree with most is how it divides the model’s job. The article lets the model do intent recognition, task breakdown, slot extraction, skill routing, anomaly judgement and text recognition. It does not let the model calculate, aggregate, rule on definitions, or retrieve knowledge outside the controlled interface.¹

The reasoning matches the rules above. A number has to be reviewable and replayable, but a model’s reasoning carries some randomness and cannot promise the same output for the same input. Putting calculation in fixed code turns “can this be audited?” from a hard question into one you can answer line by line. The title phrase, definitions are used and not interpreted, says the same thing: definitions come from versioned knowledge entries, and the agent may cite them but not interpret them.

The skill format follows the same logic. Each skill needs a definition reference, calculation outside the model, typed inputs and outputs with enumerations, a version tied to knowledge entries, and regression cases. The article groups skills into definition, calculation, validation, tracing, data replay and output, which covers everything from reading a definition to writing a quality report.¹

One report from start to finish, and where it stops

The article walks through a full run of six steps. The agent receives the task and splits it into indicators, fetches definitions from the knowledge base over MCP, pulls data through controlled access, runs reconciliation checks, traces lineage and proposes remediation when something looks off, and finally produces a review report.¹

Three gates come before production. The first is a red-line rule: an ambiguous definition, a cross-table mismatch, an extreme value or a null blocks release. The second is regression on historical data, where each case runs 5 to 6 times and testing covers 5 and 10 periods. The third is a gray, parallel run: 3 to 4 clean rounds before production, and 3 to 5 months alongside the human process.¹ Yu also mentions spending roughly 30,000 to 40,000 yuan a month on tokens personally. That is his own figure, and it shows that constraints do not make this cheap.¹

Constraints buy accuracy, but the upstream problem is still there

The logic of the design holds. It adds constraints level by level from the data source: skills must be registered, actions must be whitelisted, computation must live in fixed code, every step is checked, and key points have a person. The aim is clear. Keep non-standard data sources out, and keep the agent itself from being polluted.

My one reservation is that this amounts to removing non-standard raw material. It trades more constraints for more accuracy. It stops problems once they are inside the chain, and it does not fundamentally solve non-standard data that may be created at the generation stage. If the first write upstream is not standard, every later check can only find it and block it. None of them can make it standard.

I admit I’m nitpicking. With more than 15 layers in the chain, giving a complete answer for the middle and back of it, with today’s technology, is already a strong result. What to do upstream probably isn’t a question the agent layer can answer. Data producers, business systems and data standards have to answer it together.

A checklist for agents in heavily audited work

The article’s approach compresses into a checklist that carries over to other audited jobs:

• Which steps must be exact? Take them out of the model and into fixed code you can read line by line.
• Is there a registry of skills and tools? Can anything unregistered be called at all?
• Does every step have a contract for inputs and outputs, and a check before the next step?
• Is there a step and budget cap, and what happens when it is exceeded?
• On error, does the agent try to carry on, or stop and hand over to a person?
• Do key judgements (definitions, data completion, final sign-off) have a human checkpoint?
• Before production, is there a historical regression and a parallel run?
• Upstream, who makes sure the first write of the data is already standard?

The article gives answers to the first seven. The eighth is the question it doesn’t answer, and the one worth asking next.