Solution Design & Architecture

Knowledge of

• The design flow: elicit the requirement, derive functional and non-functional requirements, then choose the architecture that meets them at acceptable cost
• The six dimensions to extract before choosing any pattern: latency, volume/scale, criticality, data sensitivity, cost ceiling, and quality bar
• How these constraints -- not preference -- decide realtime vs. batch processing, the model tier, the integration protocol, and where humans sit in the loop
• The difference between a proof-of-concept design and a production-ready design, which adds evaluation, observability, security, and lifecycle as first-class concerns from day one

Skills in

• Eliciting the business outcome before defaulting to a technology choice such as "use an agent" or "use the biggest model"
• Extracting latency, volume, criticality, data sensitivity, cost ceiling, and quality-bar constraints from a stated business requirement before selecting a pattern
• Anchoring an architecture recommendation on the stated constraint rather than a default preference
• Distinguishing proof-of-concept scope from production scope when sizing a design, and accounting for evaluation, observability, security, and lifecycle from the start

Knowledge of

• The complexity gradient across augmented LLM, workflow, and agentic patterns, and when each fits
• The augmented LLM (model + retrieval + tools + memory) as the atomic unit that workflows and agents compose
• Workflow composition patterns: prompt chaining, routing, parallelization (sectioning and voting), orchestrator-workers, and evaluator-optimizer
• The definition of an agent as a system where the LLM dynamically directs its own steps and tool use in a loop (plan -> call tool -> observe real environment feedback -> repeat)
• The distinction between orchestrator-workers (subtasks decided dynamically at runtime) and parallelization sectioning (subtasks known in advance)

Skills in

• Selecting the augmented LLM as the pattern for a single well-scoped step in a design
• Selecting a workflow when a task decomposes into known, fixed steps where predictability and testability matter
• Selecting an agentic pattern for open-ended tasks whose steps can't be enumerated in advance
• Choosing among prompt chaining, routing, parallelization, orchestrator-workers, and evaluator-optimizer based on the shape of the task
• Distinguishing orchestrator-workers from parallelization sectioning by identifying who decides the subtasks and when

Knowledge of

• The end-to-end architecture shape: input -> processing -> output -> feedback loops
• Input-stage concerns: ingestion, validation, separation of trusted instructions from untrusted data, and retrieval of grounding context
• Processing-stage concerns: the chosen pattern (augmented LLM/workflow/agent), model selection, and prompt/context assembly
• Output-stage concerns: structured-output contracts, validation, defensive parsing, and delivery to downstream systems
• Why feedback loops (evaluation, monitoring, observability) are mandatory rather than optional given model non-determinism

Skills in

• Designing an end-to-end architecture that explicitly accounts for input, processing, output, and feedback stages rather than a single model call
• Separating trusted instructions from untrusted input data at the input stage
• Specifying structured-output contracts and defensive parsing at the output stage
• Building feedback loops that detect regressions on a new model version and catch retrieval drift, proving the system still meets its SLA

Knowledge of

• The manager/orchestrator + specialized subagents pattern, where each subagent runs in its own context window and returns only a condensed result
• Context isolation as the defining benefit of subagents, not merely "more prompts"
• Specialization benefits: a focused prompt, tool set, and model tier per subagent (e.g., routing cheap steps to Haiku, hard steps to Sonnet/Opus)
• Parallelism benefits when independent subtasks run concurrently
• The real costs of multi-agent designs: multiplied token usage and coordination overhead

Skills in

• Reserving multi-agent hierarchies for work that is genuinely separable and expensive enough to justify the overhead, not as a default
• Assigning subagents a focused prompt, tool set, and model tier appropriate to their subtask
• Recognizing when a single well-scoped augmented LLM wins on cost and latency over a multi-agent design
• Justifying a manager/subagent design by its context-isolation benefit rather than assuming it is automatically higher quality

Knowledge of

• Sequential decomposition (prompt chaining) for ordered sub-steps that depend on the previous step
• Parallel decomposition for independent subtasks that run concurrently and merge
• Routing decomposition: classify first, then send each class down a specialized path
• Recursive/hierarchical decomposition where an orchestrator spawns subagents that may themselves decompose further
• How decomposition improves reliability by making steps easier to prompt, evaluate, and debug, and by creating natural boundaries for gate checks

Skills in

• Choosing sequential decomposition when sub-steps have genuine dependencies on prior output
• Choosing parallel decomposition when subtasks are independent and can be merged after execution
• Choosing routing decomposition when inputs fall into distinguishable classes that need specialized handling
• Choosing recursive/hierarchical decomposition for tasks that need orchestrator-spawned subagents that may decompose further
• Placing validation or gate checks at decomposition boundaries to catch errors before they propagate

Knowledge of

• The five business value pillars: efficiency, transformation, productivity, cost, and performance/SLAs
• How to map a specific architectural tradeoff to the value pillar it serves (e.g., smaller model + prompt caching = cost/performance; human-in-the-loop review = risk/quality)
• The risk of optimizing a metric the business didn't ask for at the expense of one it did

Skills in

• Articulating which business value pillar a given architectural decision serves
• Anchoring tradeoff decisions (model tier, caching, batching, human review) on the pillar the business actually asked for
• Avoiding over-optimization of unrequested metrics (e.g., latency) at the expense of requested ones (e.g., cost, quality)
• Communicating design tradeoffs in the language of business value for stakeholder discussions