From Probabilistic Generation to Controlled Execution: How Graph-Model Fusion Enables Enterprise-grade Agents to Execute Confidently and Be Auditable

On November 3, the National Development and Reform Commission clearly released the latest signal at a press conference: it will further expand the "Artificial Intelligence +" initiative, drive technological innovation through practical application implementation, and accelerate the development of full-lifecycle AI safety standards and the "regulatory sandbox". Looking back to October 9, the Central Committee of the Communist Party of China and the State Council issued the Opinions on Developing New Quality Productive Forces, which explicitly proposed to "build a system for technical monitoring, risk early warning and emergency response to ensure that artificial intelligence is safe, reliable and controllable". Prior to that in May, three departments including the Cyberspace Administration of China jointly issued the Implementation Opinions on the Standardized Application and Innovative Development of Agents, requiring that the operations performed by agents shall not exceed the scope of user authorization, technologies such as "embedded rules and behavior guardrails" shall be developed, and a "verifiable and traceable" mechanism for agent behaviors in key application scenarios shall be established.

All these policies point to the same core proposition: before AI can truly enter production environments, three questions must be answered – who grants authorization, whether the behavior is traceable, and who takes responsibility when problems occur.

This is exactly the question that Haizhi has been working to answer. Our core view is: when model capabilities reach their limits, enterprises need a queryable fact structure to move AI from a "probabilistic game" to "controlled execution". This structure does not rely on stacking model parameters, but encodes industry experience into definitions that both humans and agents abide by – where the data is, what it means, what operations can be performed, and who can perform them under what conditions, so that AI can operate on top of a queryable, verifiable and rollbackable fact structure.

This article will elaborate from four dimensions: the boundary of large models, the division of labor for graph-model integration, the modeling method of business ontology, and the implementation path of auditable intelligence, and share Haizhi's insights and practices in industrial AI implementation.

01 The Boundary of Models: In Long-Chain Tasks, a 90% Success Rate Collapses to 12%

Large models "fail to understand" enterprises: they excel at semantic understanding and generation, while a large amount of enterprise business data is stored in relational tables and the deterministic calculations behind them, which forms a gap in data form.

From another perspective: even if the data is understood and accurately fed into the context, the characteristics of real enterprise tasks make it difficult for the "pure probabilistic generation mechanism" of large models to be directly competent.

The fundamental problem lies in the training objectives. Academically, under the current training objectives and evaluation paradigms, model "hallucinations" cannot be eradicated: the goal of pre-training is to provide answers, not to express unknowns; evaluations often reward "making a guess" instead of "admitting not knowing". Therefore, "hallucination" is not an occasional bug, but a structural by-product of the probabilistic generation mechanism, which requires an external fact structure to contain it.

This is harmless in casual chat scenarios, but in enterprise production environments, the problem will be magnified exponentially. Real enterprise tasks often involve 20 or even 30 decision nodes. Assuming the success rate of the model at a single decision point is 90%, after 20 rounds of decision-making, the overall success rate is only about 12% (0.9 to the power of 20 is approximately equal to 0.12) – this is the "exponential collapse" of long-chain tasks. If there are approval, rollback or parallel branches in the real system, the attenuation will be alleviated to some extent, but the trend remains unchanged.

What is more troublesome is that the model's decision-making process is unpredictable and unauditable. First, if an enterprise hands over all its data to a large model, the enterprise itself will lose its competitiveness. Second, the entire link is untrustworthy – the enterprise cannot clarify at what time, for what reason, AI called which data and modified which records, making auditing impossible. For scenarios sensitive to accuracy and compliance such as government affairs, finance and energy, such links are unacceptable.

To break it down specifically, there are five thresholds standing in front of enterprise-level Agents:

Misaligned Training Objectives: Models are trained to give answers, not to express unknowns;

Dominance of Small Models: For data security reasons, most enterprise private deployments are based on small-parameter models, which further limit capabilities;

Context Loss: Enterprise data is flattened into plain text and fed to the model, erasing the relationships between objects;

Unverifiable: The reasoning chain has no factual basis, making it impossible to distinguish right from wrong;

Unsafe to Execute: Without permission and state constraints, actions are uncontrollable. 

Based on this, Haizhi has built a graph-based AI engine, also called Harness. It also addresses a reality that is often overlooked: enterprises already have their own business systems, small models and rule engines. If all data is aggregated into one large model, the transformation workload will be huge, and the capabilities of the original systems will be left idle. What is really needed is to mobilize these existing capabilities instead of rebuilding everything from scratch. 

Therefore, there is only one conclusion: beyond model capabilities, enterprises need a queryable fact structure to support the parts that models cannot handle. 

02 Graph-Model Integration: Graph Manages Facts, Model Manages Intelligence

Under this line of thinking, Haizhi proposes graph-model integration.

Graphs naturally fit the modeling of the real world: accounts and transfers in finance, mobile phone numbers and calls in telecommunications, are inherently in the form of graphs. Therefore, we can use graphs to model objects, relationships, states and permissions, and use models to understand, plan and arrange candidate actions. In this way, the quality of interactions can be checked and approved.

When modeling data for enterprises and individuals, there is no need for complete standardization, only the existing concepts in knowledge need to be extracted. Graphs can map "concepts" to "instances": for example, there is a lot of database-related knowledge in personal profiles, including storage engines, metadata engines, and various instances, but for the concept of "graph database", it only needs to be abstracted once, with various specific instances attached under it. This is very similar to the way Baidu Encyclopedia explains a term, including the concept, viewpoints and instances of the term.

It is impossible for a model to see all the enterprise's data during pre-training. With this structure, when the model receives a question, it can first find the relevant concepts, their explanations, the meanings of instances, and the corresponding processable interfaces in the graph, so as to know "which data this question involves, what these data mean, and which interfaces can be used to process them".

In terms of responsibilities, this solution can be summarized in three sentences:

Graph Manages Facts: Assign stable IDs and state versions to each object, covering objects, relationships, states and permissions;

Model Manages Intelligence: Perform semantic understanding and task decomposition, responsible for understanding, planning and candidate actions;

Integration Manages Implementation: Perform reasoning verification and execution orchestration.

In the practice of AtlasGraph, the graph fact layer is always the most heavily invested layer, which also shows where the focus of enterprise-level AI lies.

Traditional Agents freely combine in an open toolset: there are 116 tools hung in the environment, and the model has to search and try errors among the 116 candidates every time. In the graph-model integrated architecture, the semantics of tasks, the location of data, the preconditions and output results of each tool are pre-defined on the graph.

When processing a PDF for example, there may be only two or three related skills, and the candidate toolset is even smaller; before taking action, the model knows which tools it can choose and what results will be produced by operating these tools. The key mechanism of this division of labor is to converge the model's search space from "infinite trial and error in the open toolset" to "enumerable candidate set constrained by ontology"; "finite state machine" is the engineering metaphor. As the candidate set converges, the success rate of each step increases, and the "exponential collapse" of long-chain tasks is interrupted.

The model does not become smarter, but is placed in a structure where it is easier to do things correctly.

From a more macroscopic perspective, when humans solve any problem – whether it is a technical problem or a business process – it can essentially be abstracted as a graph: the starting point is the problem, passing through a series of relationship nodes, and finally reaching the goal.

Haizhi's solution itself is also a graph. When the shape of the problem is isomorphic with the shape of the solution, we have a definite modeling language and a definite execution path.

This is also why the development of Harness or Agent has evolved from the initial Open Tool to Prompt Engineering, Context Engineering, and then to today's Graph Engineering. The essence is to precipitate the methodology of "how to think and how to solve problems".

Then why choose graph as the base in the end? It can be analyzed from two levels

For a single scenario, the ontology does not necessarily have to be built on a graph database – relational tables can carry it, and vector indexes can also carry it. The selection depends on query and computing requirements.

The real problem arises after more and more ontologies are built: different scenarios build their own ontologies, which cannot be mutually recognized or reused, and the ontology degenerates into an asset management problem. Therefore, enterprises must first build a layer of mutually recognized "graph semantics", just like building the DWD public layer in the data warehouse in the past, using unified cleaning and caliber alignment to constrain semantics.

Putting several types of databases into the coordinate system of "fact constraint strength × relationship complexity", this choice becomes clearer: for scenarios with low constraints and low complexity, vector databases are sufficient, because they are good at semantic retrieval and fragment recall; for scenarios with low constraints and complex relationships, relational databases are used, because they are suitable for low-hop table joins and transactions; time-series databases solve the problem of multi-version and sequence queries on time series; for scenarios with high constraints and multi-hop requirements – which require both multi-hop path traversal, permission verification and state snapshots, graph databases are the most direct expression. SQL can also handle joins and recursion, but choosing a graph is to directly express multi-hop dependencies: turn object boundaries, reachable paths and pre-dependencies into queryable structures.

Multi-modal integration solves two other problems.

The first is vectors. A large amount of enterprise data exists in the form of natural language. By vectorizing the entities on the graph and establishing index associations back to graph nodes, the model can "find nodes through semantics, and then traverse relationships along the graph".

The second is time series. Enterprise audits are usually carried out on a weekly or monthly basis. If data is arbitrarily rewritten by AI, there will be no way to reconcile accounts after a few weeks. Moreover, most people will directly select "Yes" without carefully reading the prompt of "whether modification is allowed". Time series makes each write operation a new version instead of modifying in place, and any time slice of the graph can be re-visible – what interface AI called, what tools it used, and what data it modified in what time period can all be replayed.

This is also the bottom line for enterprises to use Agents: it is not the Agent that controls people, but people control the Agent.

To summarize the query division of AtlasGraph in one sentence: Graph queries paths, vectors find semantics, time series freezes versions – one storage base, three query perspectives, each performing its own functions on the same copy of data. The underlying layer is the same storage structure, and the upper layer provides retrieval operators and management strategies, so that each time slice of the graph can be queried efficiently. But the boundary must also be clearly drawn: high similarity does not mean that the fact is true, let alone that there is permission.

In the evolution context of AI engineering, the position of this layer is also clearer: Prompt Engineering solves "how to ask", Context Engineering solves "what to provide", Harness Engineering solves "how to steer models"; Graph Engineering solves "how multiple Agents organize tasks, coordinate components, and manage runtime states with graph structures". Graphs and ontologies are the factual base of this layer, enabling orchestration to not only connect, but also make each step verifiable and traceable. Models are responsible for intelligence, and structures are responsible for credibility.

The biggest difference between Haizhi's harness and general-purpose harnesses lies in the base – whether there is a queryable and constraintable graph ontology platform underneath.

03 Business Ontology: Writing "Who Can Do What Under What Conditions" into the Graph

With the division of labor determined, the next question is: what to put on the graph?

The answer is business ontology.

Here we need to separate two concepts: a knowledge graph describes "which facts are related to each other" and answers "what is it"; enterprise ontology further defines "what these relationships mean and what behaviors they can trigger" and answers "how to do it". Haizhi expresses industry experience as a set of ontology definitions, and both humans and agents operate according to the definitions – it explains what exists in the business, what can be done, and who can do what under what conditions.

By controlling the three things of data ownership, role permissions and executable behaviors, the accuracy of the system will be significantly improved: it can not only run on businesses that the model has never seen during training, but also run better.

Ontology for enterprise data is like folders for personal documents. When people name folders, they are essentially classifying knowledge, telling their future selves "what is stored inside". Classifying documents, dividing them into multiple folders, and each folder having its own multiple subfolders forms a tree shape, and a tree is a type of graph.

In the agent era, the same thing needs to be done again for the Agent: tell it the meaning of the retrieved data, who it belongs to, and what operations can be performed.

In fact, when humans use enterprise systems, a lot of experience is stored in their minds – we know where to click, what to copy, and where to go next; but models do not have this experience, so it is necessary to build a layer of machine-readable semantic cognitive modeling for data and operable interfaces.

After modeling, when the model calls interfaces to process data, it can feel that what it operates on is not discrete or fragmented data and interfaces, but a structured business graph, so that it can well complete scenarios where knowledge is not injected during pre-training.

This idea is not limited to enterprises, and it also applies when individuals organize materials and use Agents.

For enterprises, there is another benefit: this knowledge or business ontology exists inside the enterprise, which is the foundation for the enterprise to maintain its competitiveness. This is also the idea of sovereign AI that is being discussed now.

This layer of modeling is divided into three models on AtlasGraph.

Semantic Model, answering "what exists in the business". Define types first, then implement instances: for example, process is an object type, with attributes including status and person in charge, and relationships including "uses equipment" and "refers to documents"; after instantiation, it becomes process OP-204, with status "to be inspected", using equipment EQ-17, referring to process document R3. The identity of equipment EQ-17 is provided by the equipment ledger, and the revision number of process document R3 is managed by the document system – each object instance has a stable identity, relationships carry versions, pointing to specific objects and revision versions.

Why go through all this trouble? Because inside the enterprise, a process often only has a code name. If there is only the number OP-204 on the graph, the model does not know what it is, who is responsible for it, and which equipment should be configured. With the ontology built, the question can be reversed: which equipment and process documents does this set of processes use? The model traverses along the two edges of "uses equipment" and "refers to documents", and the answers and basis are output together.

More importantly, this lookup process can be explicitly presented to customers. Users do not need to rummage through massive fragmented documents to find the materials used by the model, what they see is a clear path: from the process to the equipment, and then to