Pattern White Paper/Workshops/Action

ADPS Agent Design Pattern White Paper · Workshop

ADPS Design Pattern Workshop Series · First Action Module Workshop

Plan and ReAct, structured plans, tool admission, GUI action, sandboxes, and event-driven execution.

Date
2026-08-06
Module
Action
Document type
Workshop record
License
CC BY 4.0
Discussion host Bingsheng Ru
Core participants Qingfeng Li, Dong Zhang, Jun Luo, Hongshan Tang, Wei Wang, Pylon Peng, Leida Ren

ADPS held its first workshop on the Action module on 6 August 2026. The group examined how an agent turns a judgment into an operation that an external system can accept, inspect, and recover. The discussion drew on code development, security scanning, GUI automation, R&D platforms, multimodal evaluation, and multi-agent collaboration.

The session ended with two open questions: where Event-Driven belongs in the framework and how much of a Plan DSL can remain stable across domains. Both affect A1–A5 and the candidate status of C6 Choreography.

1. Route between Plan and ReAct by task risk

Qingfeng Li described a loop that connects code generation, review, testing, and repair. Such a loop depends on explicit acceptance conditions: whether tests pass, whether the repair addresses the original failure, and whether the change reaches human review. Model capability affects the speed of the loop; acceptance conditions determine where it stops.

Bingsheng Ru and Wei Wang treated a plan for complex work as a recoverable navigation map. Each step needs state, an artifact, and a checkpoint so that an interrupted task can resume from confirmed progress. Small, low-risk work can run directly through ReAct. Long-running work, production environments, and irreversible operations require an explicit plan.

Dong Zhang distinguished offline creative environments from online production. The former can allow experimentation and wider model freedom. The latter needs a fixed pipeline, structured inputs and outputs, and controlled release intervals. Production data can drive offline revisions, which return only after testing and review.

Plan granularity is selected from task length, action consequence, recovery requirements, and the environment's tolerance for error.

2. A structured plan is a compilable execution contract

Bingsheng Ru proposed expressing plans as structured data or a domain DSL, then checking legality, dependencies, constraints, and cost before execution. An executable plan needs at least a step identifier, dependencies, expected artifacts, acceptance conditions, allowed tools, and a recovery position. Once these fields exist, the system can detect parallel work, repeated reads, and uneconomical ordering.

Dong Zhang's domain DSL experience showed why one language rarely transfers unchanged across static analysis, supply-chain scanning, and other tool families. The white paper therefore puts the stable core in a PlanStep contract while domain verbs, parameters, and validators remain in adapters.

3. Action interfaces need an explicit order of preference

Jun Luo described a combination of fixed paths, dynamic GUI reasoning, and edge-cloud execution. Short tasks use verified static routes. Complex tasks retain dynamic recognition and orchestration. Edge processing performs coarse interpretation and compaction before cloud calls. When a structured interface exists, a Skill or API provides stable parameters and receipts; GUI execution covers capabilities that have not exposed such an interface.

Wei Wang's evaluation platform organizes capability as a main agent, role-specific sub-agents, Skills, and CLIs. Skills load on demand, and a sub-agent sees only the tools required for its role. Coding and testing use separate execution and review roles so that one path does not both generate and approve its own work.

These practices give A1 and A5 a common rule: prefer structured interfaces, disclose capability by responsibility, and admit GUI execution only with explicit authorization and acceptance evidence.

4. Tool execution needs sandboxes and release gates

Dong Zhang keeps online pipelines within tested formats, tools, and confidence bounds. A model may participate in classification and initial handling, while deterministic flow owns release. Offline revisions use production evidence without allowing a runtime agent to rewrite its production contract.

Hongshan Tang's R&D platform decides after intent recognition whether a task needs a sandbox. Commands and local tools run in a dynamically created sandbox with role, Skill, prompt, and agent configuration. Reasoning and scheduling remain in the main process. This boundary makes command side effects observable and disposable.

The discussion directly supports A4 Guardrail Sandwich: validate permissions, parameters, and environment before execution; run the tool inside an isolation boundary; verify artifacts and side effects afterward.

5. Production workflows compose several topologies

Hongshan Tang described an R&D support system that combines routing, multi-source retrieval, sub-agents, sandboxes, and iterative validation. Short tasks can run directly, while work that needs clarification or more context begins with a plan. Index and knowledge services provide candidates, a routing layer chooses an access path, and commands enter a sandbox.

Pylon Peng presented a cross-project development flow. Sub-agents scan task sources in parallel; a main agent aggregates and orchestrates; routing sends work to the relevant repository; design and quality checks converge through loops. People intervene mainly at design confirmation and final acceptance.

Both cases show that a topology describes a local control structure. One production workflow may use parallelism, routing, orchestration, loops, and hierarchy at different stages without assigning a single topology label to the whole system.

6. Event-driven defines triggering and delivery; choreography defines collaboration

Bingsheng Ru asked whether Event-Driven should become a seventh execution topology. Qingfeng Li made a useful distinction: a loop uses a termination condition to decide whether to continue, while an event uses a trigger condition to decide when to start. Wei Wang added the persistence value of a queue; an event can wait while a downstream agent is unavailable. Leida Ren supplied a multi-agent example in which one agent's action emits an event that other agents consume.

Pylon Peng and Hongshan Tang challenged the seventh-topology classification. An event explains how work starts and travels. Once started, the work still takes the form of a chain, route, parallel branch, orchestration, loop, or hierarchy. Event listening may also be part of perception.

ADPS currently separates the concepts as follows:

The workshop recorded an existing multi-agent practice that uses events for collaboration. C6 Choreography remains a candidate, and Event-Driven does not become a seventh core topology column in this release.

7. Changes made to the white paper

  1. A1 Tool Dispatch now emphasizes capability registration, candidate reduction, interface preference, and admission criteria for GUI fallback.
  2. A2 Plan-and-Execute treats a plan as a versioned structured contract whose steps carry dependencies, artifacts, acceptance conditions, and recovery positions.
  3. A3 Prompt Chaining passes structured artifacts between steps and releases each artifact only after its stage check succeeds.
  4. A4 Guardrail Sandwich defines pre-execution validation, isolated execution, and post-execution verification, with command tools directed to sandboxes.
  5. A5 Minimal Tool Set uses responsibility boundaries and progressive disclosure to control the tool surface.
  6. C6 Choreography remains a candidate extension pending independent evidence across more cognitive functions and documented failure cases.

8. Open questions

Related pages