Professional solution design starts when we stop asking whether one model response looks good and start taking responsibility for the whole path from a person's need to a dependable business outcome. The architect's job is to translate a business problem into a justified system, choose an automation pattern that fits the real variability, define how well the service must operate, and identify evidence that would show whether it creates value. That work begins with discovery, meaning the deliberate study of users, decisions, desired outcomes, current steps, pain points, data, risks, constraints, service expectations, and the people who will operate or support the result.

Discovery should separate a sponsor's proposed solution from the need underneath it, because a confident request for an autonomous agent, meaning a system in which the model can choose and sequence actions toward a goal within enforced boundaries, may really express a need for faster evidence triage and more consistent drafting. Harbour Resolution is our fictional running example, and its sponsor initially asks for an agent that can handle complaints from arrival to final decision. A careful architect would walk through the existing process with intake staff, case officers, managers, policy owners, security specialists, and support teams before treating that request as a settled design.

Those conversations might reveal that an incorrect classification is easy to reverse, an unsupported draft can mislead a busy reviewer, and an unauthorized final decision could have serious consequences. The tempting mistake is to automate the sponsor's first description, while the better move is to break the work into decisions and ask what each decision needs, who may make it, and how failure will be detected or contained. Suppose this fictional discovery identifies three workloads with very different rhythms and risks. Intake staff need incoming documents classified and key facts extracted within minutes, where structured extraction means placing identified information into named fields such as case type, claimant name, and relevant date.

Case officers need interactive policy research and grounded draft reasoning, where grounded means that important claims are tied to retrieved source material rather than generated from the model's general patterns alone. Managers need overnight analysis across closed cases, where batch processing means handling a collected group of jobs without making a person wait through each one. One universal agent would be attractive because it looks simpler on a slide, but these workloads differ in response time, volume, available context, acceptable risk, and output format. Capability decomposition addresses that problem by designing classification, extraction, research, drafting, quality analysis, and approval as separable capabilities with clear interfaces and controls.

The intake capability could use a deterministic workflow, meaning a sequence and set of permitted branches explicitly orchestrated by software. Its control flow is predefined, but model calls, changing data, or external tools within it can still produce varying results, so consequential outputs require validation. That workflow might classify a document, extract required fields, check their formats, flag missing values, and send uncertain cases to a person instead of inventing the next step. The case-officer capability could be an augmented language-model application, meaning generation combined with supporting functions such as retrieval, tools, stored context, or validation without giving the model broad freedom to act. Retrieval is the process of finding relevant material from an approved collection and supplying it to the model, while a tool is a controlled function the application can invoke to read information or perform a bounded operation.

Stored context, sometimes called memory, is information retained beyond the immediate exchange, and it needs explicit rules because remembering the wrong case detail can be as harmful as forgetting a useful one. The managers' overnight capability could combine batch processing with a separate evaluation pipeline, which is a repeatable process for measuring outputs against defined examples, criteria, and reviewer judgments. An agentic system goes further by allowing the model to choose and sequence actions toward a goal within governed boundaries, rather than merely filling a slot in a fixed sequence. A hypothetical investigation agent might decide to search one policy collection, inspect a case attachment, compare dates, and request clarification because each discovery changes which action makes sense next.

The useful design rule is to choose the least autonomous pattern that can handle the genuine variability and still deliver acceptable value. Known steps and enumerable branches usually favor a workflow, while an agent becomes more defensible when the necessary sequence depends on facts discovered during execution and listing every path would be impractical. Autonomy brings flexibility, but it also brings nondeterminism, meaning that the same situation may lead to different action sequences or wording even when those differences were not explicitly programmed. It can also increase cost, response time, evaluation difficulty, and attack surface, which means the interfaces, data paths, tools, credentials, and other exposed points an attacker could try to exploit.

Greater autonomy can separately create more opportunities for accidental misuse, such as a user causing a permitted tool to act on the wrong case even when no attacker is involved. Multi-agent design means using several model-driven actors with distinct roles, contexts, or permissions, and it is justified only when specialization, parallel work, separation of authority, or independent perspectives produce measurable benefit. For example, a hypothetical procurement team might use one restricted component to summarize bids and another to check policy conflicts, but two agents debating each other adds little if neither has better evidence or a distinct control boundary. An analogy is a workplace committee: separate expertise can help, but adding chairs does not create facts, and the analogy stops working when software agents act at machine speed or share the same hidden weaknesses.

After selecting patterns, the architect maps the system from inputs through processing to outputs and feedback so that no consequential step disappears inside the phrase artificial intelligence. Inputs for Harbour Resolution could include requests from authenticated users, whose claimed identities have been verified, along with case records, uploaded documents, approved policy sources, and operational events such as a document arriving or a reviewer returning a draft. Processing could include classification, retrieval, model calls, controlled tool execution, validation, human approval, and state transitions, where a state transition is a recorded move such as draft becoming reviewed or reviewed becoming approved. Outputs could include draft text, structured case fields, recommendations, permitted actions, source references, and telemetry, which is operational data such as timings, errors, tool calls, and review outcomes.

Feedback could include user corrections, approval decisions, incident findings, evaluation results, and revised policy content, but feedback should not silently become training data or policy without an authorized process. Each important state needs a system of record, meaning the authoritative place where that state is durably stored and governed. A model transcript is not automatically the case record, audit history, evaluation store, or policy repository, because conversational text may be incomplete, mutable, hard to query, or subject to different retention rules. In a hypothetical insurance office, an assessor might see a polished recommendation in a chat window and assume it has updated the claim, while the actual claims system still contains yesterday's status.

The better architecture writes an authorized, validated change to the claims system and records who or what initiated it, although this adds integration work and still cannot guarantee that the underlying business data is correct. Authentication and authorization must also remain distinct: authentication establishes who or what is making a request, while authorization decides which records and actions that identity is permitted to access. A signed-in case officer may be authenticated successfully yet lack authorization to view another region's cases or approve compensation above an assigned limit. Least privilege means granting only the access needed for a defined task and duration, so a drafting assistant should not receive final-disposition authority merely because both functions concern the same case.

Prompts are instructions expressed to the model, but enforcement is a control outside the model that reliably restricts data access, tool parameters, transactions, or approval paths. Telling a model in a prompt not to open restricted cases can guide behavior, but a real authorization check at the data or tool boundary must reject the request even if the prompt is ignored or manipulated. Confirmation and authorized approval are different too, because a model asking whether someone is sure does not establish that the person has the organizational authority to approve the action. A hypothetical payroll assistant might display a transfer amount and receive a clear yes from an intern, yet the payment service should still refuse execution unless an authorized approver completes the required control.

Structured output provides syntax, meaning an agreed shape such as named fields in JSON, but valid syntax does not make the contents true. A response can contain a perfectly formatted policy identifier and a plausible date that were never present in the source, so field validation must be paired with source checks, business rules, or human review appropriate to the risk. Evidence is information directly supported by an identified source, while inference is a conclusion drawn from evidence, and the interface should not blur the two. If a complaint letter says a customer called on Monday, that statement is evidence from the letter, while concluding that the call caused a missed deadline is an inference requiring additional support.

These distinctions shape the control boundaries around every component, especially when generated text can influence money, rights, safety, or official records. The architecture also needs non-functional requirements, which describe how the service must behave rather than the business function it performs. Availability describes when a defined user journey is usable, latency is the elapsed time for a defined result, and throughput is the amount of work the system can process over a period. A latency objective is ambiguous until it says whether the clock stops at the first generated text, the complete answer, the validated record, or the fully approved workflow. An availability objective is equally incomplete unless it identifies the journey and dependencies, because a chat screen may load while retrieval or the case system is unavailable.

Privacy concerns appropriate use and exposure of personal information, while data residency concerns the geographic locations in which data is stored or processed. Security covers protection against unauthorized access and harmful manipulation, and recoverability describes how the service and its state can be restored after failure. Observability means having enough logs, metrics, traces, and identifiers to understand what happened across components without exposing more sensitive content than operations genuinely require. Maintainability concerns how safely the system can be changed, accessibility concerns whether people with different abilities can use it, and cost must include integration, review, monitoring, support, and rework rather than model charges alone. For a hypothetical complaints service, a throughput objective could require the intake path to handle the measured peak arrival rate plus an agreed margin without an ever-growing queue, but that target can miss rare bursts and downstream review bottlenecks.

Privacy and data-residency objectives could restrict which personal fields are collected and define approved processing locations for requests, logs, backups, and support access, while recognizing that keeping data in one location does not by itself prevent misuse or unauthorized access. A hypothetical security objective could require every restricted-record request and prohibited-action test to be rejected at the data or tool boundary, but passing known tests cannot prove there is no unknown attack path, and tighter controls may add user friction. Recoverability should state the longest acceptable time to restore service and how much recent state the organization can afford to lose, then test that recovery path, because possessing a backup does not show that it can be restored correctly.

An observability objective could require each accepted outcome and failure to be traceable across retrieval, model, tool, validation, and review stages while minimizing sensitive content in logs, which protects privacy but can make some incidents harder to diagnose. Maintainability can be tested by introducing a small change in a limited environment and showing that the team can detect trouble and return to a previously tested version, although such tests cannot expose every interaction with future data or dependencies. An accessibility objective might require representative users to complete drafting and approval with a keyboard and screen reader, because checking a technical standard alone can miss confusing language or workflow barriers.

Full-lifecycle cost can be measured per accepted business outcome and include model use, integration, review, monitoring, support, rework, and recovery, but this measure can still miss delayed effects or a decline in outcome quality. Quality and safety service levels should describe the actual task, dataset, scoring method, and treatment of uncertainty rather than relying on a reassuring headline number. For example, a hypothetical extraction target is not meaningful until the team defines which fields count, how missing fields are scored, whether some errors carry more weight, and which representative cases make up the evaluation set. A useful safety objective might track unsupported policy claims in reviewed drafts, but it still needs a definition of unsupported, a review method, an escalation rule, and an owner.

No metric proves absolute correctness or safety, and optimizing one measure can move harm elsewhere, such as reducing missed fields by producing more incorrect guesses. Business value needs the same discipline, beginning with a baseline of current handling time, queue age, rework, error patterns, customer outcomes, and staff effort. In a hypothetical legal operations team, faster first drafts may look like a win until reviewers spend longer checking invented citations and correcting confident language. The better evaluation measures the complete process from request to accepted outcome, including verification and recovery work, although some outcomes may take time or remain difficult to attribute to the system alone.

Model selection should therefore use task-specific evaluation across output quality, latency, usable context, tool behavior, safety, platform constraints, and token cost, where a token is a unit of text processed by the model and token cost reflects the input and output tokens consumed. Usable context is the relevant instructions, interaction history, and source material that a model can effectively use for one request, not merely all the text an interface permits the application to send. When too much or poorly selected context is supplied, token cost and latency rise, important evidence may be buried, and material that does not fit may be omitted, so model and retrieval choices should be tested on representative long inputs as well as ordinary cases.

Even a larger context capacity does not guarantee reliable attention to every detail, while aggressive trimming can remove the evidence needed for a sound answer. Token counts do not map neatly to spoken words, so teams should measure representative inputs and outputs instead of estimating cost from page count alone. The largest or strongest available model should not become a permanent default for every difficult-looking task, because different stages may reward speed, lower cost, longer context, or stronger reasoning in different proportions. A smaller model might route a request or normalize a format, while a stronger model handles a complex synthesis that has demonstrated a need for that capability.

Routing means selecting a model or processing path based on the request, and it can reduce unnecessary work, but a routing mistake is now its own failure mode that needs examples, measurements, logs, and a safe fallback. A request that looks routine may conceal a policy conflict, so a low-cost route should be able to escalate when confidence is weak or validation finds higher risk. Durable architectural reasoning focuses on measured trade-offs rather than a changing catalogue of model names, prices, or limits. Platform selection can include a direct Anthropic application programming interface, or API, which is a software interface used by one system to request functions from another, as well as supported services offered through cloud providers.

The choice should be evaluated against required features, regional availability, procurement, networking, identity controls, logging, data handling, integration effort, and the division of operational responsibility. No platform label makes a design universally compliant, because compliance depends on the organization's requirements, actual data paths, contracts, configured controls, operating practices, and evidence. In the fictional Harbour Resolution scenario, the organization already uses Azure broadly and also has a governed process for direct software-as-a-service suppliers, where software as a service means externally operated software consumed as an online service. Its architect would compare the relevant deployment options against the required capabilities and responsibilities rather than treating either cloud preference or direct access as an automatic answer.

The comparison has limitations because feature availability and service conditions can change, so assumptions that depend on current platform behavior need verification during implementation and operation. The first production slice should be narrow enough to govern and learn from, but real enough to test value under ordinary working conditions. For Harbour Resolution, a sensible fictional slice could cover one case type with adequate volume, clear policy sources, reversible draft outputs, and expert reviewers who understand both normal and difficult cases. Assisted drafting is safer than automatic disposition for this slice because an authorized case officer still evaluates the evidence and owns the decision, although human review is not a magical safeguard when workloads, interfaces, or incentives encourage careless approval.

The team should define an evaluation set before repeatedly editing prompts, since changing prompts against a few memorable examples can produce a convincing demonstration without reliable general behavior. That set should include ordinary cases, ambiguous documents, missing evidence, conflicting policies, access restrictions, malformed inputs, and cases where declining to answer is the appropriate result. Instrumentation should cover retrieval, model generation, tool use, validation, and human review so the team can tell whether a bad draft began with a missing source, a routing error, an unsupported inference, or an overlooked warning. Source references should help reviewers inspect evidence, but a citation's presence is not proof that it supports the nearby claim, so citation correctness requires its own evaluation.

Fallbacks are predefined safer responses to failure, such as using a secondary approved source, retrying within limits, preserving work during a timeout, or returning the case to manual handling. A policy conflict should not be resolved by whichever document appears first in retrieval, because the architecture needs an authoritative source hierarchy and an escalation route for genuinely unresolved conflicts. Human acceptance and correction should be easy to record, but staff should understand how feedback is used and should not inherit an invisible data-labelling job without time, support, or a way to report recurring system problems. A production-grade slice needs authenticated access, least privilege, durable state, versioned prompts, tested retrieval, repeatable evaluations, useful telemetry, incident handling, named support ownership, and controlled release.

Retrieval should be tested separately from generation by using representative queries and known access roles to check whether the system returns authoritative, relevant sources while excluding irrelevant or restricted material. In a hypothetical Harbour Resolution test, a case officer searching for the current appeals policy should receive the authoritative policy for that case type, not an obsolete procedure or a restricted document from another region. When no approved source exists, or equally authoritative sources conflict, the intended result should be a visible limitation and escalation rather than a confident answer based on whichever passage ranked first. These tests should include ordinary wording, vague requests, access-boundary cases, and changed content, but a fixed test set cannot guarantee correct retrieval as policies, indexes, permissions, and user questions evolve.

Suppose monitoring shows that several drafts cite a restricted internal memo after a permissions change; this is a hypothetical incident, meaning an event that may threaten the service's security, reliability, or intended operation and therefore requires a coordinated response. The named monitoring team should detect and assess the pattern, while an authorized incident lead may contain it by pausing the affected retrieval path and escalating the possible exposure to the security and policy owners. The response should preserve relevant logs, versions, identifiers, and access decisions as evidence without spreading sensitive content unnecessarily, so investigators can reconstruct what happened. The incident lead should authorize restoration only after a tested configuration or safe manual path is ready and access boundaries have been validated, while the support owner communicates with affected users and accountable business owners.

Afterward, the retrieval-component owner should coordinate the review and follow-up changes, and the support owner should track unresolved user impact and recurring reports. Telemetry can reveal symptoms, but it does not ensure that anyone notices them, has authority to pause or restore the service, or completes the communication and corrective work. A versioned prompt is a prompt stored with an identifiable revision so an output can be connected to the instructions in force at that time, though versioning still cannot reveal every cause of model variation. Controlled release means introducing changes to a limited, observable scope with criteria for expansion, escalation, and rollback, which means returning the service to a previously tested version when a release causes unacceptable problems.

Rollback limits further harm but may not undo outputs or business decisions that people have already acted on, so those consequences need a separate recovery plan. Documented assumptions should identify what the design expects about users, data quality, platform behavior, case volume, reviewer capacity, and policy stability, with an owner and a way to test each assumption. An exit path matters as well, because the organization should be able to stop, replace, or simplify the slice if benefits do not justify its costs and risks while preserving required records and business continuity. The finished architecture should let every major component be traced to a business outcome, a service constraint, a credible failure mode, an accountable owner, and measurable evidence.

That is the central Professional shift: the model remains important, but the solution succeeds or fails as a governed system of people, data, software, controls, feedback, and explicit trade-offs.