Topics/Pattern Selection Card
ADPS Design Method
Pattern Selection Card: Turning Constraints into an Agent Design
A one-page record from scenario boundary to architecture sketch, with the decisions and tradeoffs kept visible.
The ADPS matrix helps locate patterns by cognitive function and execution topology. A design review still needs to explain why a particular scenario calls for a particular combination. The Pattern Selection Card supplies that missing decision record.
The card is deliberately small. It asks a team to name the boundary, identify the two or three cognitive needs that dominate the work, choose a topology, shortlist patterns, expose tradeoffs, and draw the runtime path. The result is compact enough for a workshop and specific enough for an architecture review.
What the six fields record
| Field | Design question | Reviewable output |
|---|---|---|
| 01 Scenario boundary | What enters, what leaves, what may change, and what failure matters? | Input, output, authority, failure modes |
| 02 Cognitive needs | Which functions dominate this scenario? | Two or three priorities from perception, memory, reasoning, action, reflection, collaboration, and governance |
| 03 Execution topology | How does work move and where does control return? | Chain, Route, Parallel, Loop, Hierarchy, or Orchestrate, plus the selection reason |
| 04 Candidate patterns | Which reusable mechanisms close the identified gaps? | Two or three core patterns and their composition rationale |
| 05 Tradeoffs | What does the design gain, spend, and constrain? | Explicit choices across safety and efficiency, accuracy and cost, simplicity and robustness |
| 06 Architecture sketch | How do data, decisions, controls, and evidence move at runtime? | Main flow, quality gates, human intervention points, and observation points |
Begin with a scenario that can fail
A useful boundary is smaller than a product and larger than a model call. It has an identifiable input, an externally meaningful output, a defined authority envelope, and failure consequences that can be discussed. “Review this design proposal against these standards” is a scenario. “Build a knowledge assistant” is still a programme of work.
Authority belongs in the first field because it changes the architecture. A read-only reviewer can report and escalate. An agent that may edit a source document also needs admission rules, version control, rollback, and evidence of the change.
Select the dominant cognitive needs
Marking every cognitive function does not improve the design. Select the two or three functions whose failure would change the outcome. A document review may depend on perception for extracting the right evidence, reasoning for comparing claims with criteria, and reflection for finding unsupported conclusions. Memory and collaboration may still appear in implementation, but they need not drive the first pattern search.
Choose the runtime shape
The topology describes how execution moves, not the department chart or the number of agents. Use Chain for staged transformations, Route for selecting a path, Parallel for independent branches, Loop for bounded iteration, Hierarchy for delegated levels, and Orchestrate for dynamic coordination across workers or capabilities.
A scenario may compose several topologies. Record the main path first and then mark local structures, such as a review loop inside one routed branch. Every loop needs a budget and stop condition; every branch needs a merge or acceptance rule.
Shortlist patterns, then add the engineering planes
Candidate patterns should answer a named need. Two or three are usually enough to expose the architecture. Cross-cutting planes are recorded separately: X1 Observability carries trajectory and evidence, X2 Evaluation & Validation supplies acceptance and regression, and X3 Security & Identity supplies principals, delegation, and policy boundaries.
The card is not a pattern inventory. If a pattern cannot be tied to a failure mode, interface, or quality requirement, leave it out.
Worked example: technical document review
| Card field | Example decision |
|---|---|
| Scenario boundary | Input: a technical proposal and review criteria. Output: a cited review with unresolved questions. Authority: read-only. Main failures: missed requirements, unsupported findings, and shallow review. |
| Cognitive needs | Perception, reasoning, and reflection. |
| Execution topology | Route a simple proposal to a fast path and a complex or high-risk proposal to a deeper chain; run a bounded review loop before release. |
| Candidate patterns | P1 Context Triage, R2 Complexity-Based Routing, and F1 Generator-Critic. |
| Tradeoffs | Broader evidence search raises coverage and cost. A stronger critic loop raises review quality and latency. The loop therefore receives an iteration budget and an unresolved-question exit. |
| Architecture sketch | Sources and criteria flow through triage, routing, and a generator-critic loop into a cited report. X1 records evidence and versions; X2 tests acceptance and regression. |
Finish with one decision statement
End the card with a sentence that can survive a design review:
We use P1 to establish a scope and evidence contract, R2 to reserve deeper work for complex proposals, and F1 to challenge unsupported findings before release. X1 preserves the trace and X2 verifies cited coverage. The review loop stops at its budget and returns unresolved questions instead of inventing certainty.
The sentence binds the scenario, pattern choices, tradeoffs, and failure policy. If it cannot be written without vague claims, the card still contains an unresolved design decision.
Review questions
- Does the card describe one bounded scenario with an externally meaningful output?
- Are authority and failure modes stated before pattern selection?
- Do the selected cognitive needs identify actual bottlenecks?
- Does the topology show movement, return paths, budgets, and merge rules?
- Can every candidate pattern be traced to a need or failure mode?
- Are human intervention, quality gates, and observation points visible?
- Can the team explain what it chose not to optimize?
Related material
- ADPS Pattern Catalogue and Selection Framework
- Composing Agent Patterns
- Agent Design Lifecycle
- Human-Agent Interaction
Suggested citation: ADPS, Pattern Selection Card: Turning Constraints into an Agent Design, ADPS Design Method, 2026-09-03.
The worked example illustrates the selection method. Production designs require domain-specific evidence, controls, and acceptance criteria.