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
| Hosts | Haili Zhang and Jia Huang |
| Core workshop guests | Dong 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.
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.
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.
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 structure | Identity | Authority | Safeguards | Provenance |
|---|---|---|---|---|
| Serial | Principal at each hop | Scoped per leg and reclaimed | Gates stop error propagation | Linear responsibility chain |
| Parallel | Independent shard roles | Branch isolation; read-only gather | Branch checks plus global validation | One trace with child spans |
| Routing | Route matches identity and risk | Tighter scope on high-risk routes | Ingress filtering and differentiated controls | Route 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
- A new Collaboration module overview separates relationship patterns, constraints, distributed candidates, and implementation mechanisms.
- C1-C5 now cover task identities, write-conflict domains, review feedback, Handoff Contracts, and cross-session isolation.
- C6 distinguishes dynamic orchestration from choreography and remains a candidate.
- G4 describes governance enforcement; cross-module hook composition is covered in a topic.
Open questions
- How should design intent survive topology lowering into a runtime graph?
- Which Handoff Contract fields can remain stable across frameworks?
- How can a scheduler discover cross-session write-conflict domains before execution?
- How should hook composition expose order, idempotency, and failure semantics?
- Where does the Agent OS analogy predict useful architecture, and where does it distort it?
Related pages
- Collaboration module overview
- Human-Agent collaboration boundaries
- Hook Composition
- Abstraction and Reconstruction
- Agent OS engineering checklist
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