Cases/Blue Book

Case at a glance

1. Start with the step that blocks the customer

Dongfang Yiteng provides SaaS products for HR, organization management, attendance, approvals, and payroll, with connections to banking and tax systems. This case follows one workflow that tends to stall during initial configuration.

The team first considered workforce analysis, compensation optimization, and reporting. These features demonstrated AI well, but customer interviews pointed to a more immediate problem: initial configuration. A new customer has to create payroll groups and items, import employees and organizations, set salaries, and configure attendance and approval rules.

Customers supported by an implementation team generally completed their first month. Self-service customers were more likely to stop during setup. The team therefore selected rapid payroll-group setup as the first agent workflow. It is narrow enough to test, yet includes template matching, snapshots, sequential API calls, rollback, and human approval.

2. The first prototype selected tools but lost state

The initial plan exposed existing APIs through an MCP server and let the model choose tools and assemble parameters. Tool discovery worked, while sequential execution revealed a different problem.

Consider an expense claim. The workflow creates the claim, uploads an invoice, submits the claim, and reads the result. The upload call must receive the application_id returned by that specific create call. Payroll setup has the same dependency: the template_id returned by template matching must reach the import call unchanged.

The first prototype appended each tool result to the conversation and asked the model to construct the next call. Tests produced occasional ID changes and parameter misbindings. JSON Schema could check type and format. It could not prove which call produced a value. A single changed character in a 64-bit or 128-bit identifier may address the wrong entity.

The team kept the model for intent, semantic interpretation, and route selection. Exact parameters moved out of conversational text and into program-managed state.

3. Runtime observability

The backend is written in Go. The first stage connected multi-turn chat, attachments, and streamed responses without introducing an agent framework. This fixed the entry and exit contracts before more capabilities were added.

The web interface arrived at the same time. Business users could inspect input, execution progress, and results in one place. Each conversation became an ordered set of Activity records. One Activity contains one or more Frame records with the input, model output, tool call, latency, and cost for that point in the run. Intent classification, routing, ReAct iterations, and state changes publish events to the same timeline.

The timeline first served development: which tool was selected, where an ID came from, and why a task stopped at an approval step. The same events support business review, incident reproduction, and production monitoring, with debugging detail hidden by role.

4. How one request moves through the runtime

Intent classification converts a message into a finite control signal. Early signals included chat, analyze, and resolve; parse failures became unknown. The vocabulary can grow, but every signal must map to an explicit program branch.

user message
  -> MessageHandler opens the event stream
  -> intent classifier emits a control signal
  -> Orchestrator selects an execution path
  -> reasoning or planning selects the next step
  -> action module invokes a tool
  -> narrative, business state, and task progress are persisted separately
  -> one event stream returns progress and results to the interface

MessageHandler owns the message boundary, SSE, and completion protocol. Orchestrator reads control signals and coordinates reasoning, memory, retrieval, and action. Capabilities register through explicit input and output contracts, so a new capability can join the middle of the flow without changing message handling.

The runtime also separates control information from narrative context. Route choices, task states, and admission outcomes drive program branches. User goals, analyses, and execution summaries supply semantic context to the model. The two sets use different structures, validation, and persistence.

5. Explore while the task is unclear; schedule when dependencies are known

resolve says that the user wants an operation, but it does not yet provide a stable plan. The runtime uses stepwise reasoning or ReAct when the next action depends on newly gathered information. Each iteration appends a Thought, Action, and Observation block to a scratchpad.

Once dependencies are known, execution moves to a DAG. The executor schedules a ready node only after all upstream nodes are completed; an acceptance component decides whether a node can enter completed.

The payroll prototype matched a template, created a snapshot, imported the template, and rolled back on failure. A text-only ReAct instruction skipped or jumped steps during testing. That failure led directly to the task graph.

6. Program state owns business identifiers and their provenance

Exact values from tool receipts enter SessionState. Later tools read them by coordinate. The model receives a narrative statement such as "the template has been matched," not the identifier itself as a value it must reproduce.

The following record is an ADPS reconstruction of the mechanism.

{
  "scope": "session/payroll_setup",
  "key": "template_id",
  "value": "9287461350021",
  "producer": "match_salary_template",
  "call_id": "call_0187",
  "receipt_ref": "events/0187/tool-result"
}

At registration time, a tool declares which state it produces and consumes. Before invocation, RunPipeline reads the coordinate, checks provenance, injects the value, and records the consumption link. The model never has to spell template_id again.

This design assumes a managed tool environment. The organization must know the tools, state keys, scopes, and permissions before a run. Arbitrary tools from an open network do not automatically receive the same provenance guarantee.

7. Approval must preserve a resume point

Before a sensitive operation, the executor moves the node into a waiting state. After approval, it reloads persistent state, checks task and tool preconditions again, and resumes at that node. Rejection or timeout follows an explicit termination or replanning path.

The case uses two forms of human involvement.

• Resume in a later turn: the current turn ends; the user later says "continue" or supplies missing information.
• Wait inside the execution flow: a running task pauses at a node until an approval event arrives.

The second form requires the DAG, node state, approval result, and parameter provenance to survive the wait. A confirmation dialog only pauses one action; the task state machine stores the checkpoint required for resumption.

8. Long-running state has three homes

The Anchor preserves the original goal, while the Ledger appends material progress. A Collection projects the small set of records needed for the current step. These structures support semantic reasoning and do not transport business IDs.

Memory is also layered by use distance. L1 serves the current step, L2 preserves traceable facts, and L3 stores experience distilled across runs. An L3 item retains the ID of its L2 evidence so the original record can be loaded when needed. Retrieval is concentrated at reasoning, first ReAct, and planning boundaries instead of running after every step.

Mechanism diagrams

Four runtime structures in the execution agent

9. What the current evidence supports

The next useful evidence would include strict-workflow success and takeover rates, the number of provenance checks that blocked an error, and successful resumes after approval waits.

10. A seven-step transfer method

1. Select one sequential workflow that changes real business state.
2. List each step's inputs, outputs, side effects, rollback, and accountable person.
3. Mark every value the model must not regenerate: IDs, versions, amounts, and permission scope.
4. Register the producer, consumer, scope, and receipt for each exact value.
5. Encode known dependencies as a task graph and let program logic decide which node may run.
6. Make high-impact nodes durable waiting states; test approval, rejection, timeout, and duplicate events.
7. Connect model, tool, state, and task events in one timeline before expanding the workflow.

After the first path is stable, decide which tasks need ReAct and which can enter a fixed plan immediately. Exploration remains available for open questions while business state stays deterministic.

11. Limits and ADPS mapping

This design fits sequential operations with strict state dependencies and real side effects. Tools must be registered and managed by the organization. Content retrieval, summaries, and report generation usually do not require a complete DAG, mechanical state plane, or resumable approval flow.

Open tool ecosystems require additional trust policy. Multiple concurrent writers require transactions, locking, or conflict handling. Those concerns are outside the published case.

Contributor and citation

Case contributor: Bo Liang, Shanghai Dongfang Yiteng Technology Co., Ltd.

Suggested citation: ADPS and Bo Liang, "Dongfang Yiteng's Execution Agent: Preserve Business State Across a Workflow," ADPS Enterprise Agent Systems Blue Book, Case Report 01, v0.4, 2026.