The Mechanical State Plane and Provenance Coordinates

From the Dongfang Yiteng execution agent (case by Bo Liang)

Definition

The mechanical state plane is the layer of an execution-type agent's runtime context that governs business API parameters. It separates the reading, writing, binding, and passing of state values entirely from the content the LLM touches, so that every API call's input parameters have a single, auditable, fail-fast mechanical source rather than being generated on the spot by a model that drifts.

Picture it as a whole wall of small cells, built when the agent starts. Each cell corresponds to one mechanical parameter, and its key is determined by two things together: which tool supplies the parameter, and at which runtime stage it is produced. Along the session's timeline, each cell holds only the latest value of that parameter. Whoever needs a piece of state reads it from the corresponding cell, instead of letting the model guess it out of a long stretch of narrative context. Every parameter in the runtime corresponds to a Provenance structure, assembled by parsing the various specifications and descriptions into a single coordinate — key name plus scope plus supplier plus production stage. All reads and writes go by this coordinate, so a parameter's ownership and value stay unambiguous.

How it works

The failure it prevents is concrete. The first step of building a payroll group calls a template-matching interface; on a match it returns a template_id, and downstream, when the template is imported, that id must be passed in verbatim. The trouble is that the various ids in an enterprise are commonly 64-bit or even 128-bit random strings generated by snowflake algorithms. Asking a model to read the conversation and then reproduce such an id exactly — every character restored correctly, not one digit off — is something models still cannot do today. The reason is that an LLM is a stateless probabilistic function: even when told the id's value in context, it does not take your parameter by value; it only tries to regenerate an approximate string. In this scenario, an id missing one digit fails validation, and a wrong digit is worse — the agent may execute "successfully" while the business data is quietly corrupted, and the expected state change never happens.

Dongfang Yiteng fell into this pit early on. Tasks were still in an MCP-like form: after the first task succeeded, its result was assembled into the conversation context, and the second task parsed its binding parameters from the latest context. A travel assistant has no problem with this, because what it passes is text like city or weather, where a semantic deviation is not fatal. Switched to a scenario with strict mechanical-parameter binding, it proved extremely unreliable in practice — sometimes succeeding, sometimes failing, and when it failed was neither controllable nor predictable. The solution is to carve out the mechanical state plane on its own, with parameter values maintained mechanically and accurately at each execution stage according to the tool call's receipt. This way no line of the existing SaaS API has to change; exposed through the gateway, it can be orchestrated flexibly by the agent per scenario, calling any number of interfaces in sequence, with no more parameter-binding errors.

This solution holds on one premise: the system is an enterprise-grade closed system, where all tools are managed and registered by the team itself, with no need or wish for users to plug in arbitrary external tools. Precisely because of this, the agent can determine at startup the full dictionary of state keys possible in the world it perceives, pinning down each parameter's coordinate.

When you need it

When your agent executes a chain of business steps with strict state dependencies, where what passes between steps is mechanical parameters like ids and status codes, and one digit off corrupts data or causes a false success. Splitting the whole runtime context by responsibility is the unified session state and its separation of powers; the task scheduling that the mechanical parameters serve is maintained by the task DAG and state machine; its fundamental distinction from narrative content and control signals is the dualism of the control plane and the narrative plane.

This is an ADPS blue-book concept. Back to Concepts or the pattern matrix.