Unified Session State Plane: Separation of Powers

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

Definition

All of the runtime context within a single session should not be read and written in one place. The unified session state plane splits this context into three planes with clear responsibilities. Each plane answers one question, uses one data form, and does not cross into another's territory. This is the backbone design that the Dongfang Yiteng execution agent finally settled on.

How it works

Separation of powers means that the narrative, mechanical, and scheduling planes each govern one segment. The narrative state plane gathers, in natural language, what the user wants and how far the work has gotten. It is the agent's perception and understanding of the world and the current situation: some information is kept in full, some is compacted and distilled, some lives only in memory, and some is persisted to storage and even given a vector index. The mechanical state plane governs the API parameter dictionary alone. It answers where a parameter came from and whether it is correct. It stores strict key-value pairs, every parameter carries a provenance coordinate, and it is auditable and able to fail fast on error. The task scheduling state plane cares only about the order and status of the nodes in the task graph. It answers which step runs first and whether a step has finished. A downstream node can only be started once all its upstream nodes are complete and the node itself is ready. The three planes speak three languages about three things: progress in natural language, parameters in machine-readable key-value pairs, scheduling in a task graph.

The failure it prevents is the kind that recurs whenever these three things get tangled together. In the earliest scheduling context, narrative content was mixed in, and the result details of each task node were read, written, and passed in the same place. The consequence was that parameters and progress polluted each other: from a single stretch of context containing goal descriptions, intermediate thoughts, and API return values all at once, the model had to work out for itself which value was the id to bind in the next step. In an enterprise business system, such an id is often a random string of dozens of characters generated by a snowflake algorithm. Asking the model to pull it verbatim out of the mixed context and then bind it is highly unreliable — it sometimes succeeds and sometimes fails, and when it fails is neither controllable nor predictable. Once the three things are separated, parameters go through the mechanical plane and are passed mechanically by the program rather than generated by the model, progress goes through the narrative plane, and scheduling goes through the task graph. Each line is independent, and drift on one line does not spread to another.

The rapid setup of a salary group at Dongfang Yiteng is a clear slice. This scenario first takes a snapshot of the enterprise's existing salary-group data, then imports the matched template after the snapshot is confirmed, then rolls back to the snapshot if the import fails. The order of "snapshot first, then import, then roll back" belongs to the scheduling plane, pinned down by the node dependencies of the task graph rather than decided by the model on the spot. The template_id returned by the template-matching interface must be used verbatim as the input parameter when the downstream import runs; this belongs to the mechanical plane, maintained by parameter coordinates and passed mechanically. Descriptions such as what kind of salary group the user wants to set up and which step the work has reached belong to the narrative plane, recorded in natural language and projected and injected when needed. The by-products generated within the same task execution are assigned to these three planes by their nature, and nowhere does the model need to make a judgment on the program's behalf inside a mixed context.

When you need it

When your agent has to deliver a multi-step process on top of business interfaces you cannot modify, and the parameter of every step needs a unique, auditable source that can fail fast on error, rather than relying on the model to guess it from context. Upstream of this three-way split is first splitting the runtime into control plane and narrative plane; how the mechanical plane guarantees a unique source for every parameter is covered in the mechanical state plane and provenance coordinates; how the narrative plane organizes its own goals and progress is covered in anchor, ledger, collection.

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