What does my application actually own when it calls Claude through the API, and where must architecture enforce rules the model cannot guarantee? This module answers that question through working implementation demonstrations built around ShopAssist AI, an online-store support application. You will be able to trace how a request travels from your code to Claude and back, explain why conversation state is application state, and decide which behaviors belong in a system prompt and which must be enforced deterministically in application logic. You will examine API authentication, the Messages API structure, max_tokens and stop_reason, manual history management for stateless requests, reusable conversation helpers and the chat loop, system prompt placement, summarization of older turns, and generation controls such as temperature, model selection, prefill, and stop sequences. A companion reading clarifies which controls each model supports, so you do not rely on settings that are unavailable or non-deterministic. The module is designed for architects and senior engineers who need implementation-level grounding for design decisions; basic Python reading ability is sufficient, and Claude API access is optional for reproducing the demonstrations. You will leave with a clear map of the model-application boundary, a checklist for context growth and state handling, and criteria for choosing schema-constrained output over free-form generation.

Which Claude model, prompting technique, and context strategy will meet this workload's quality, latency, and cost requirements? This module shows you how to answer with measured evidence rather than preference. You will be able to benchmark Haiku, Sonnet, and Opus on representative cases, choose a single model or a justified routing and escalation policy, select zero-shot, few-shot, or chain-of-thought prompting for a given task, and design a reusable prompt and context plan. You will practice separating stable system policy from reusable modules, task templates, and dynamic input; treating user text, retrieved documents, and tool results as data that cannot grant authority; packaging guidance as Skills; allocating a context budget across instructions, evidence, history, and tool output; compacting long transcripts without losing identifiers or decisions; and configuring prompt caching boundaries while checking cache creation and read usage. Generic benchmark sheets, classification and planning tasks, and synthetic transcripts keep the examples transferable. The module is designed for architects, AI engineers, and technical leads who design production prompts and context pipelines; familiarity with LLM APIs and JSON is assumed. You will leave with a documented model choice with one rejected alternative, a modular prompt template, a context budget with a compaction rule, and an estimate of where caching will and will not pay off.

How do I make sure Claude's outputs are safe for downstream systems, and how do I prove a change actually improved quality? This module gives you the contracts and evaluation gates that turn plausible output into trustworthy system behavior. You will be able to design tool schemas and structured outputs, validate evidence and structure before acting, define a balanced evaluation scorecard, and build a mixed evaluation plan that combines code, model, and human grading. Implementation demonstrations from ShopAssist AI cover tool schemas, tool_choice, structured output with tool_use and JSON Schema, a structured return-request extraction build, the prompt evaluation workflow, and grader mechanics. Companion readings explain the difference between ordinary schemas and strict tool use, and why a model-generated confidence field needs calibration before it signals reliability. You will also define accuracy, latency, cost, safety, and security metrics with acceptance gates, and design representative datasets with routine, rare, adversarial, permission-sensitive, and no-answer cases. The module is designed for architects and AI engineers responsible for release quality; basic Python reading ability and familiarity with JSON are assumed. You will leave with a validated output contract, a release scorecard with minimum safety and security gates, and an evaluation manifest that assigns a grading method to every criterion.

How should I design retrieval so Claude answers from the right, current, and permitted evidence? This module walks you through the architecture decisions behind a production retrieval-augmented generation system. You will be able to design a complete RAG pipeline from source ingestion to attributed answer, choose chunk boundaries that preserve meaning, design indexes that respect freshness and permissions, match retrieval methods to data shape and query pattern, and decide when progressive discovery beats preloaded context. You will compare fixed-size, structure-based, and semantic chunking; select keyword, vector, hybrid, metadata-filtered, and structured retrieval for different questions; handle index additions, updates, deletions, and embedding changes through controlled rebuilds; apply permission filters before text reaches the model; and evaluate retrieval and generation with separate signals. Generic policy-search pipelines, policy tables, index refresh reports, and discovery traces keep every example independent of a particular vector database. The module is designed for architects, AI engineers, and platform engineers who integrate enterprise knowledge with Claude; familiarity with search concepts and data pipelines is helpful but not mandatory. You will leave with a RAG design justified by document structure, query patterns, permissions, and freshness requirements, plus a retrieval routing table and a safe no-evidence response pattern.

How do I connect Claude to business systems without giving it more authority than the task requires? This module helps you select integration mechanisms and close the access gaps that appear when models, tools, and services work together. You will be able to choose between MCP, API, CLI, and agent-to-agent integration, trace identity and authorization across a complete request path, and remove unnecessary tools and capabilities from agents. You will compare coupling, interoperability, runtime location, authentication, versioning, error handling, and monitoring; distinguish user identity, service identity, and delegated access; identify overbroad credentials, missing downstream authorization, and model-supplied identities treated as proof; and build narrow, stage-specific tool sets for roles such as a read-only analyst. A ShopAssist AI implementation demonstration then shows backend capabilities turned into explicit, controlled tool and MCP interfaces. The module is designed for architects, platform engineers, and security-minded technical leads who own integrations; familiarity with APIs, authentication, and authorization concepts is assumed, and no MCP server-authoring background is required. You will leave with an integration decision for three representative cases, an annotated identity and data-flow diagram showing where permissions are enforced, and a reduced capability manifest that you can apply to your own agents and tools.

When does a multi-agent design pay off, and how do I keep agents from taking actions they should not? This module helps you design orchestration, risk controls, and human review as one coherent system. You will be able to choose a coordinator-worker or supervisor pattern, define reliable handoffs, justify accuracy-latency configuration trade-offs, build an actionable LLM risk register, implement layered guardrails at action boundaries, and design human review as a dependable service. You will practice bounding retries and delegation depth, writing handoff records that separate verified facts from conversational summaries, allocating a latency budget across retrieval, model calls, tools, and validation, assessing risks such as prompt injection, data leakage, and unauthorized actions by likelihood and impact, blocking a forbidden operation with a deterministic pre-execution check, and setting review triggers, queue ownership, and timeout behavior. A ShopAssist AI implementation demonstration brings tools, orchestration, deterministic controls, context management, and human escalation together in one agentic workflow. The module is designed for architects and AI engineers designing agentic systems for consequential tasks; experience with tool use and workflow design is assumed. You will leave with an orchestration design with failure boundaries, a prioritized risk register, a guardrail placement plan, and a review-routing table that never executes while approval is pending.

How do I know whether my Claude system is still performing well in production, and what should I change when it is not? This module shows you how to turn telemetry into diagnoses and evidence-based change decisions. You will be able to design observability across distributed AI components, monitor quality, performance, and drift, isolate the earliest broken stage in a failure, run controlled A/B tests, and optimize cost and latency without dropping below the required quality floor. You will work with correlated traces across request, retrieval, model, tool, and agent spans; sampling and retention choices under cost and cardinality constraints; version-aware dashboards and alert thresholds with owners and runbooks; fixed-evidence replays that separate retrieval defects from model capability problems; A/B results where an average gain hides harm in high-risk segments; and usage sheets that attribute tokens, retries, and review effort to individual stages. All examples use generic traces and dashboards, so the techniques transfer to any monitoring stack. The module is designed for architects, platform engineers, and AI engineers who operate Claude systems after launch; familiarity with logging and basic experiment design is helpful. You will leave with a telemetry strategy, a documented diagnosis of a production regression, a rollout decision with its rationale, and a measured bottleneck fix.

How do GDPR, HIPAA, FedRAMP, and fairness expectations change the architecture I propose, and what evidence will reviewers need? This module helps you turn governance requirements into concrete data-flow controls, boundaries, and accountable owners. You will be able to map personal data across prompts, indexes, caches, and logs, trace deletion through derived stores, identify ePHI destinations and vendor boundaries in a healthcare workflow, check whether a cloud service and integration path fit a government authorization context, and measure bias across meaningful user groups. You will apply minimization, purpose limitation, retention, and individual-rights handling; evaluate business associate agreements and minimum-necessary rules; distinguish authorized service offerings from vendor-wide labels; assign provider, customer, and agency responsibilities; choose fairness measures and recognize proxy bias; and disclose AI involvement and review options to users. Fictional data-flow maps, boundary diagrams, vendor checklists, and classification reports keep the examples realistic without implying legal conclusions. The module is designed for architects, technical leads, and consultants who work with privacy, compliance, and risk teams; no legal background is required, and the module does not replace advice from qualified specialists. You will leave with regulated-use decisions documented as architecture evidence, a list of open approvals with named owners, and a testable fairness mitigation plan.

How do I get stakeholders to agree on an architecture, keep their expectations realistic, and hand the design to engineers who can build it? This module develops the communication and lifecycle practices that make a sound design succeed in an organization. You will be able to write decision records for executive, product, engineering, and governance audiences, manage feedback and renegotiate SLA expectations with measured evidence, produce an implementation-ready architecture handoff package, and manage decisions from discovery through iteration. You will practice presenting options, evidence, risks, and unresolved assumptions without claiming a universally best architecture; separating incidents, feature requests, and unmet expectations; negotiating scope, review workload, and service targets when stakeholders want both immediate answers and mandatory expert approval; documenting interface contracts, denial paths, observability requirements, and acceptance tests; and using release gates, versioned prompts, models, and indexes, and rollback readiness to preserve approved behavior. Generic recommendations, negotiation scenarios, handoff templates, and lifecycle records keep the practice transferable. The module is designed for architects, technical leads, and consultants who work between business stakeholders and delivery teams; no formal project-management training is required. You will leave with a decision record in two audience versions, an approved SLA decision log, and a handoff package that an engineer can implement and an operator can diagnose.

How do I equip my team to use Claude tooling safely and productively, and how do I respond when something breaks in production? This module brings developer enablement, incident response, and professional scenario reasoning together. You will be able to configure Claude Code and shared team environments, improve developer workflows with reviewed AI-assisted changes, coordinate debugging and operational recovery, and solve professional architecture scenarios that span several domains. You will practice setting up shared CLAUDE.md guidance, project settings, approved tools, MCP endpoints, Skills, and permissions in a sample repository; selecting a bounded refactoring or test-generation task and reviewing the diff before adoption; measuring cycle time, rework, and escaped defects instead of lines generated; triaging an incident packet, choosing a mitigation such as rollback or restricted functionality, and writing an operational handoff; and working through original cases on retrieval strategy, agent expansion, and a production regression that challenges an SLA. The module is designed for architects, technical leads, and platform engineers who support engineering teams and are preparing for the CCAR-P exam; experience with Git-based development workflows is assumed. You will leave with a team-tooling configuration plan, a reviewed AI-assisted change with measured benefit, an incident response and root-cause record, and a repeatable method for answering scenario-based exam questions.