Workshops/Action

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

Code generation, review, testing, and repair can form a loop. 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.

A plan for complex work records each step's state, artifact, and checkpoint so that an interrupted task can resume from confirmed progress. Small, low-risk tasks can use ReAct to choose the next step from tool results. Long-running tasks, production environments, and irreversible operations need an explicit plan.

Offline creative environments and online production require different controls. 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 compiling the Plan itself. Before any tool call, check legality, dependencies, constraints, repeated steps, and uneconomic order. Wei Wang and Pylon Peng then added authority, concurrency conflicts, and cross-project scheduling to the compilation checks.

Plans can be expressed as structured data or a domain DSL, then checked for 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.

Domain DSL practice 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

A production path can combine fixed routes, 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.

One class of 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

Online pipelines remain 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.

One class of 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. The platform can separately record files created and resources used by commands, then reclaim the environment when the task ends.

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

Pylon Peng described a morning workflow that dispatched six sub-agents to scan task sources in parallel. A main agent gathered the results, assigned work by repository, and proceeded through design, coding, quality checks, and repair. People intervened mainly at design confirmation and final acceptance.

One R&D support system 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.

In Peng's workflow, task-source scanning uses parallelism, repository assignment uses routing, and correction after quality checks uses a loop. A composition design identifies where each structure applies and which artifacts pass between stages.

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

Pylon Peng asked whether Event-Driven should become a topology; Leida Ren added an event-reactive multi-agent practice. Their examples separate trigger and delivery from control structure: events determine when work appears and how it is delivered; topology determines who owns the plan and how work branches and closes after it appears.

A loop uses a termination condition to decide whether to continue; an event uses a trigger condition to decide when to start. A queue retains pending events while a downstream agent is unavailable, ready for consumption when it recovers. In the practice Leida Ren described, agents publish events to notify other agents to perform subsequent tasks.

The challenge to a seventh-topology classification is that 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:

• Event-driven execution defines triggers, delivery, waiting, and replay.
• Execution topology defines how control unfolds after work begins.
• Choreography defines collaboration among agents that react through local rules and events without a central orchestrator.

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. Concepts extracted from the workshop

8. 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.

9. Open questions

• Which Plan DSL fields can remain stable across domains, and which belong in domain adapters?
• What measurable threshold should move a task from direct ReAct to an explicit plan?
• What authorization, UI evidence, and failure receipt should a GUI fallback produce?
• How should a sandbox connect commands, file changes, network access, and resource use to one Action trace?
• What interfaces should connect event-driven mechanisms to perception, governance, and choreography?

Related pages

• A1 Tool Dispatch
• A2 Plan-and-Execute
• A3 Prompt Chaining
• A4 Guardrail Sandwich
• A5 Minimal Tool Set
• C6 Choreography
• White Paper contributors

Based on the 6 August 2026 workshop transcript. Internal project details have been anonymized.

Edit source · Published source · Review process