Professional solution design and architecture

Episode Seven begins Professional by shifting from component correctness to end-to-end ownership. By the end, you should be able to translate a business problem into a justified architecture, select an appropriate automation pattern, define non-functional requirements, and design a production slice with measurable value. Now step back and design the complete solution rather than a single model interaction. The Professional blueprint gives solution design and architecture seventeen percent of the exam. Its first task is not selecting a Claude model. Its first task is translating a business problem into a justified system. What should discovery establish before technical design? The users, decisions, desired outcomes, current process, pain points, data, risk, constraints, service levels, and measurable value.

Text description

• Stated solution: An autonomous complaints agent.
• Underlying need: Faster evidence triage and more consistent drafting, with failure consequences understood first.

It should separate stated solutions from underlying needs. A sponsor may ask for an autonomous complaints agent when the actual need is faster evidence triage and more consistent drafting. The architect should not automate the sponsor's first idea without testing the process and failure consequences. For Harbour Resolution, interviews reveal three different workloads. First, intake staff need documents classified and key facts extracted within minutes. Second, case officers need grounded policy research and draft reasoning within an interactive session. Third, managers want overnight quality analysis across closed cases. Would one architecture and model configuration serve all three optimally? Probably not, because their latency, volume, context, risk, and output needs differ.

Text description

• Workflow: Use known steps and decision points for predictable processes such as structured extraction and validation.
• Augmented application: Combine generation with retrieval, scoped tools, memory, or validation without broad autonomy.
• Agentic system: Let the model select and sequence actions when the required path cannot be economically enumerated.

The architect should decompose the platform into capabilities rather than build one universal agent. The intake workload may be a deterministic workflow with structured extraction and validation. The case-officer workload may be an augmented assistant with retrieval and carefully scoped tools. The overnight workload may use batch processing and a separate evaluation pipeline. This illustrates three broad patterns in the blueprint. A workflow follows known steps and decision points. An augmented language-model application combines generation with retrieval, tools, memory, or validation without granting broad autonomy. An agentic system lets the model select and sequence actions toward a goal within governed boundaries. How do you choose among them?

Text description

• Inputs: Authenticated requests, case records, documents, policy sources, and operational events.
• Processing: Classification, retrieval, model calls, tool execution, validation, approvals, and state transitions.
• Outputs: Drafts, structured records, recommendations, actions, citations, and telemetry.
• Feedback: User corrections, human decisions, incidents, evaluation results, and updated content.

Use the least autonomous pattern that handles the real variability and produces acceptable value. Autonomy adds flexibility but also nondeterminism, cost, latency, attack surface, and evaluation complexity. A fixed workflow is ideal when the process and branches are known. An agent is justified when the appropriate sequence depends on information discovered during execution and cannot be enumerated economically. Multi-agent design is justified only when specialised contexts, permissions, parallel work, or independent perspectives create measurable benefit. Now draw the end-to-end architecture as input, processing, output, and feedback. Inputs include authenticated user requests, case records, documents, policy sources, and operational events. Processing includes classification, retrieval, model calls, tool execution, validation, approvals, and state transitions.

Outputs include drafts, structured records, recommendations, actions, citations, and telemetry. Feedback includes user corrections, human decisions, incident findings, evaluation results, and updated content. A Professional answer should name the system of record for each important state. The model transcript is not automatically the case system, audit system, evaluation store, or policy repository. What non-functional requirements should shape the design? Availability, latency, throughput, privacy, residency, security, recoverability, observability, maintainability, accessibility, and cost. Add quality and safety service levels that describe the actual task. For example, ninety-five percent extraction field accuracy is incomplete unless you define fields, dataset, weighting, and treatment of missing values. A latency target should identify whether it measures time to first token, completed answer, or completed approved workflow.

Text description

• Largest-model default: A permanent rule can add avoidable cost and latency without proving better task performance.
• Task-specific selection: Evaluate quality, latency, token cost, context, tool use, safety, and platform constraints.
• Model routing: Use smaller models for suitable tasks and stronger models for complex synthesis, while evaluating routing mistakes.

An availability target should identify which user journey and dependencies it covers. Business value also needs a baseline. Measure current handling time, rework, queue age, error rates, customer outcomes, and staff effort before claiming productivity benefit. The system may save drafting time while increasing verification time, so evaluate the entire process. Now consider model selection. Choose models through task-specific evaluation against quality, latency, token cost, context, tool use, safety, and platform constraints. Do not encode a permanent rule that every difficult-looking task uses the largest model. A smaller model may handle routing or formatting, while a stronger model handles complex synthesis. A routing strategy can reduce cost, but routing mistakes become another evaluated failure mode.

Should a Professional exam answer name the newest model available? Only when the question requires it, because the durable answer is the measured trade-off and the platform documentation changes over time. Model identifiers, prices, and limits should be refreshed before the exam. Platform selection includes direct Anthropic application programming interfaces and supported cloud-provider surfaces. The choice may depend on existing cloud controls, regional availability, procurement, networking, identity, logging, feature parity, and operating responsibility. Do not claim one platform is universally more compliant. Map actual data paths, contractual controls, and service features to the organisation's requirements. Harbour Resolution uses Azure broadly but also has an established direct SaaS governance process.

Text description

• Choose a narrow scope: Select a case type with sufficient volume, clear sources, reversible outputs, and expert reviewers.
• Assist rather than decide: Begin with drafting support instead of automatic case disposition.
• Evaluate and instrument: Define the evaluation set first and observe retrieval, model, tool, validation, and review stages.
• Handle failures and corrections: Provide fallbacks for source, model, timeout, and policy failures, and capture human acceptance or correction.

The architect should compare the Claude platform and Microsoft-hosted options against required features, data handling, latency, integration, and operational ownership. A cloud preference is a constraint to evaluate, not a substitute for architecture. Now design the first production slice. Choose a narrow case type with sufficient volume, clear source material, reversible outputs, and available expert reviewers. Start with assisted drafting rather than automatic case disposition. Define an evaluation set before changing prompts repeatedly. Instrument retrieval, model, tool, validation, and human-review stages. Establish fallbacks for source failure, model error, timeout, and policy conflict. Make human acceptance and correction easy to capture without turning staff into unpaid data labellers with no feedback.

What would make this slice production-grade rather than a demonstration? Authenticated access, least privilege, durable state, versioned prompts, tested retrieval, evaluations, telemetry, incident handling, support ownership, and controlled release. Also include documented assumptions and an exit path if value does not materialise. The Professional architecture lens asks what problem, what pattern, what boundaries, what state, what service levels, what evidence, and what ownership. Episode Seven is complete when every component can be traced to a business outcome, service constraint, failure mode, owner, and measurable assumption. For source navigation, return to the Professional blueprint, then use the model, deployment, authentication, data-residency, pricing, and rate-limit references to test architectural assumptions.

In the next episode we will connect that architecture to enterprise data through secure integration and a retrieval pipeline that can be diagnosed when it fails.