Workshops/Collaboration

ADPS Design Pattern Workshop Series

First Collaboration Module Workshop

Task, context, authority, evidence, and responsibility across multi-agent and human collaboration.

25 August 2026

HostsHaili Zhang and Jia Huang
Core workshop guestsDong Zhang and Wei Wang

The workshop used LangGraph, Deep Agents, and the collaboration patterns to discuss dynamic workflows, delegated authority, cross-session conflicts, hook composition, human collaboration, and the Agent OS analogy.

Three collaboration planes: agent-agent, human-agent, and human-human around agent systems
The three relationships cover task handoffs, human authorization and takeover, and records of team decisions.

1. Dynamic sub-agents can still be centrally orchestrated

A dynamic workflow may let a model interpret the task, select sub-agents, generate call steps, and pass them to an interpreter. The flow changes at runtime, but the interpreter still owns the current plan, call order, and result aggregation.

An order flow makes choreography concrete. A payment service publishes PaymentConfirmed. Inventory subscribes, reserves stock, and publishes StockReserved. Delivery and notification services subscribe to that new event and act under their own rules. No orchestrator stores the full payment-inventory-delivery-notification plan. By contrast, a model may select sub-agents at runtime while one interpreter still owns the plan, call order, and result aggregation; that remains dynamic orchestration. Runtime change is not the criterion. Ownership of the complete plan is. C6 therefore remains a candidate.

Dynamic orchestration retains one plan owner; choreography advances through participant-local event rules.
Dynamic orchestration retains one plan owner; choreography advances through participant-local event rules.

2. Six design topologies can lower to three runtime primitives

Dong Zhang observed that many runtime graphs reduce to serial execution, parallel execution, and routing. Node responsibilities still need separate definitions. In a lead-worker hierarchy, the lead owns the task and accepts the work; in generator-reviewer-adjudicator review, the reviewer checks the artifact and the adjudicator resolves disagreements.

Hierarchical Delegation may execute as route, parallel workers, and gather. Adversarial Review may execute as generate, review, adjudicate, and conditional loop. Similar low-level edges still carry different ownership, acceptance, and failure responsibilities. ADPS calls this topology lowering: preserve responsibility in design, then compile it into runtime primitives supported by the framework.

Topology governance matrix across serial, parallel, routing and identity, authority, safeguards, provenance
Check node identity, resource permissions, validation points, and trace records for each runtime structure.

3. Every topology needs four more checks

Dong Zhang applied identity, authority, safeguards, and provenance to each topology. A lead who may read the full batch does not imply that a worker verifying one record inherits that scope. A gather node may read every branch result without gaining authority to mutate source records.

Runtime structureIdentityAuthoritySafeguardsProvenance
SerialPrincipal at each hopScoped per leg and reclaimedGates stop error propagationLinear responsibility chain
ParallelIndependent shard rolesBranch isolation; read-only gatherBranch checks plus global validationOne trace with child spans
RoutingRoute matches identity and riskTighter scope on high-risk routesIngress filtering and differentiated controlsRoute reason and full path

Effective authority is limited by user scope, task scope, agent role, tool permissions, and resource scope. If all workers share the user's long-lived token, each can acquire the user's full access, including workers assigned to verify just one record.

4. Versioning the graph for production

Development can allow coding agents to split work and try new branches under close review. In test, the main graph, agent roles, tools, and policies become versioned. Staging approaches production conditions. Production pins agent, model, tool, and policy versions while keeping only evaluated dynamic choices.

5. Collaboration has three planes

Wei Wang noted that decisions made by product, engineering, and test teams affect later agent work. If a rejected approach and the reason for rejecting it remain only in chat, the next agent reading the repository may propose it again.

Agent-Agent collaboration covers decomposition, parallel work, hand-off, and review. Human-Agent collaboration covers intent, missing evidence, approval, takeover, and acceptance. Human-Human collaboration around the agent carries team decisions and responsibility over time.

The third plane often remains in meetings and chat. A later agent can read the repository but cannot see why a path was chosen. Decisions, evidence, and boundaries that affect future work belong in versioned assets such as RFCs, ADRs, and runbooks. Raw conversations do not need to be copied wholesale.

6. Worktrees do not isolate every conflict

Wei Wang encountered two sessions allocating the same requirement identifier while working in separate Git worktrees. Their files did not conflict, but the shared identifier allocation did.

Separate worktrees isolate files, but concurrent sessions may still compete for requirement IDs, shared configuration, test databases, deployment environments, and external quotas. The scheduler must identify the write-conflict domain before launching parallel work.

7. A hand-off needs a contract

Conversation history rarely states which decisions are binding, which paths were rejected, what the next role may change, and how its work will be accepted.

handoff_id: h_01K...
goal: preserve the compatibility interface
from_role: requirements-agent
to_role: implementation-agent
artifacts:
  - uri: artifact://spec/417
    version: sha256:...
decisions:
  - choice: keep the public schema
    evidence: adr://23
authority:
  allowed_tools: [repo_read, patch_write]
  resource_scope: repo://service-a
acceptance:
  checks: [unit_tests, contract_tests]

A Handoff Contract transfers goal, artifacts, decisions, authority, responsibility, and acceptance together. The receiver explicitly accepts or rejects the hand-off, and temporary authority from the previous leg is reclaimed.

8. Independent review creates its own gap

Separating generator and reviewer reduces self-review bias. Execution may then expose missing dependencies, version differences, or insufficient authority. Those facts must return to the review layer; otherwise the next run repeats an obsolete judgement.

9. Hook triggers and composition

Wei Wang asked whether hooks should form an independent collaboration pattern. Participants discussed starting a coding agent after requirements are complete, pausing before a dangerous call for approval, recording a trace after a call, and saving a checkpoint on failure. These uses belong to orchestration, governance, observation, and recovery respectively; the same callback mechanism serves different designs.

No C7 was added. G4 defines deterministic governance enforcement points. Cross-module use is documented in the Hook Composition topic.

10. Probabilistic core, deterministic shell

ambiguous goal → model interpretation and candidates → structured intent
              → rules / state / authority / tests → controlled action → external result

Models handle open-ended understanding, planning, and candidate generation. Identity, money, resources, state transitions, idempotency, tests, and receipts require reproducible mechanisms. The shell protects boundaries that cannot be carried by probability.

11. Agent OS is an engineering checklist

Dong Zhang discussed processes, threads, coroutines, and IPC as references for multi-agent runtimes. Haili Zhang described service-based sub-agents, standard protocols, and virtual file systems. They suggest concrete design questions: who schedules tasks, how environments are isolated, how agents communicate, and where artifacts are stored.

Identity, observability, resource reclamation, and failure handling also need assigned components. An operating-system process has defined resource and isolation rules, whereas an agent may call models and tools across several services. Its actual runtime boundaries need to be specified rather than assumed to match a process.

12. Abstract, then reconstruct

Jia Huang compared processing eight hundred résumés with processing eight hundred code files. Both jobs can use parallel shards. Résumé processing needs candidate-data access limits and hiring decisions by a responsible person; code processing needs worktree isolation, tests, and repository merge controls. The parallel structure is shared, but authorization and acceptance differ.

Abstraction extracts the shared split-execute-gather structure. Reconstruction specifies what each worker can read and change, and who checks its result. Differences affecting business decisions, state changes, authority, evidence, responsibility, or acceptance must remain explicit in that design.

Resulting revisions

  1. A new Collaboration module overview separates relationship patterns, constraints, distributed candidates, and implementation mechanisms.
  2. C1-C5 now cover task identities, write-conflict domains, review feedback, Handoff Contracts, and cross-session isolation.
  3. C6 distinguishes dynamic orchestration from choreography and remains a candidate.
  4. G4 describes governance enforcement; cross-module hook composition is covered in a topic.

Open questions

Related pages

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

Chronicle

Recorded source
First Collaboration Module Workshop; workshop held on
Source date
First published on ADPS

View in the ADPS Chronicle