Accelerators & IP Contribution

Screen 1: What you will be able to do by the end

ORIENTATION DEVELOPER MODULE 5 · 2 MIN What you will be able to do by the end

Document the build well and the next engagement builds from it instead of from scratch.

In the last three modules you built a production agent, wired it into Claude Code with the right permission and context controls, and set up the MCP connections that pass a security review. Each of those was a working build.

This module covers what happens to a build after it works. You either rebuild it from scratch on the next engagement, or you package it once, so the next team just configures it. The second path is what frees your time for new work instead of repeated rebuilding.

By the end of this module, you will be able to:

1 Package a working solution as a reusable accelerator, whether that is a parameterized agent template, a configurable MCP server, or a portable eval suite, so the next engagement configures an asset rather than fully rebuilding it. 2 Contribute a tool, pattern, or fix back through the documented channels and prepare it so a maintainer can accept it, turning a private asset into shared infrastructure. 3 Choose where a Claude workload runs across the first-party API, Amazon Bedrock, Google Vertex AI, and third-party platforms, and version what ships so a model or prompt change does not silently break production. 4 Compare those platforms on latency, compliance, and cost so the choice is one a procurement and security team can sign off on, rather than a default your team reached for. 5 Build an application that coordinates several Claude deployments into one workflow and scope it so the data and identity boundaries are held under a security or compliance review.

This module is for the Developer who has a build that works and now must make it last. You are practical, code-forward, and pattern-oriented, and the earlier modules assumed and built on that. By this point you can write a production agent, configure it in Claude Code, wire up MCP connections that pass a security review, and prove it all with evals. This module does not re-teach any of that. It picks up the moment your code runs correctly and asks the harder question: can someone else reuse it, can a maintainer accept it, can it survive a model update, and can a security or procurement team sign off on where it runs. The work here is less about writing code and more about the decisions that make finished code reusable, deployable, and defensible to people who did not write it.

"THE BUILD" IN THIS MODULE

Everything in this module hinges on one recurring gap: a build that works is not yet a build that survives reuse, review, or deployment. In development, the template ran, the contribution solved your problem, the model responded, the platform was easy to build on, and each platform passed its own tests. None of that is the finished state. The same template must be configured for a team that never spoke to you. The same contribution must be verifiable by a maintainer who must reconstruct nothing. The same model must be pinned so an upstream change is a decision rather than a surprise. The same platform must clear a customer's residency and compliance review. The same connected platforms must hold their trust boundaries under audit. Each topic in this module is a different version of the same lesson: the point where code starts working is where this module's work begins. More of these decisions than you might expect are driven by the customer's existing cloud, compliance posture, and review process.

DISCLAIMER / NOTICE FOR EDUCATIONAL CONTENT

We built this Developer course Module 5: Accelerators and IP Contribution to help you get real work done with Claude. Treat it as educational content. It doesn't constitute legal, financial, or other professional advice, so adapt what you learn to your own situation. Our products and services evolve quickly, so certain content may contain errors or be outdated; remember to verify on Anthropic's website or docs. Examples and scenarios used in the course are illustrative and often fictitious. If the course material mentions a company or product, it doesn't mean Anthropic endorses them, they endorse Anthropic, or that we're affiliated. Also note your use of Anthropic products and services is covered by our terms, policies and documentation; if anything in this course conflicts with them, they control.

Screen 2: Packaging a working build so the next engagement starts from an asset

TeachingPackaging for Reuse·16 min Packaging a working build so the next engagement starts from an asset You finished the prior modules with a build that runs: an agent loop, a configured MCP server, an eval that proves that the prompt works. The most time-consuming and expensive thing on a team is the engineering time that gets spent rebuilding the same thing for the next customer. What an accelerator does: keep the reusable parts and separate out the rest An accelerator is a solution packaged so future engagements start from a working foundation rather than from a blank repository. In blueprint terms, this is packaging for reuse: separating engagement-specific code from the reusable core and parameterizing the rest. Take a working build, separate the parts that are customer-specific, and expose them as parameters with documented defaults. The asset then configures rather than gets entirely rewritten. Packaging for reuse while the build is fresh is cheaper than reconstructing the intent months later, when the person who knew why a value was hardcoded has moved on. Most reusable work falls into different asset types, and each one packages differently Most reusable work falls into one of three categories used throughout this module: a template, a configurable server, or a portable eval. Each type holds a different kind of work and needs to be packaged in its own way. Reaching for the wrong type can make an asset look reusable while still making it difficult to apply.

Asset typeWhat it bundlesWhat correct packaging requires Agent TemplateThe system prompt, the tool schemas, and the loop structure from a working agent. Pull the domain-specific values into configuration with documented defaults, so a new team sets the values rather than editing the loop. MCP Server PackageThe tools the server exposes, with their inputs and the scope the installing team controls. Document each tool input and let the installing team set the scope, so the server installs into a new environment without code edits. Eval SuiteThe graded test set and the judge rubric that prove the asset works. Ship the dataset and rubric together so a new team can run them in their own context and confirm the asset still works there. The same eval suite also acts as the gate at deployment. When you promote a new model version to production, run it against a pinned baseline score before the version goes live.

Shipping an agent as a set of loose scripts instead of a template is the most common version of the wrong approach. The scripts run, so they look reusable, but every customer-specific value is buried in a different file, and the next team copies and diverges them instead of configuring one asset. Document both the code and the assumptions Code describes behavior. Documentation covers what a future builder cannot reliably infer from reading the source: the assumptions the asset makes about its environment, the inputs it expects, the failure modes it already handles, and the eval that defines whether it still works. Without this, the next team treats the asset as a black box and rebuilds it. Bundle the audit log as part of the package A regulated customer's reviewer asks what data the asset touches, what identity it acts under, and what log it leaves. An accelerator without these passes a demo and stalls at the first security review. Treat the audit log as part of the package. The packaging checklist Keep this checklist next to the build while you package it. Each column is a decision you make once per asset.

Asset typeWhat to parameterizeWhat to documentWhat to bundle for audit Agent templateEvery value that changes per customer: prompts, paths, scopes, credentials by reference, and thresholds. Environment assumptions, expected inputs, handled failure modes, and the eval that defines working. The data touched, the identity acted under, and the log of what the asset did. MCP ServerScopes, credentials by reference, and per-customer paths. Expected inputs per tool, scope boundaries, and handled failure modes. The data touched, the identity acted under, and the log of what the asset did. Eval SuiteThresholds and dataset paths that change per customer or environment. The rubric logic, what the scores mean, and the baseline the asset is pinned to. The data touched, the identity acted under, and the log of what the asset did.

Handles well Parameterizing while the build is fresh turns one delivery into an asset the next engagement configures in hours.

Adds cost or complexity Separating generalizable from customer-specific parts and documenting assumptions adds real time to the first build.

Use a different approach For a one-off a customer will never reuse, packaging overhead is not worth it: ship the build and move on.

Screen 3: The template that shipped fast and could not be reused

Watch OutPackaging for Reuse·2 min The template that shipped fast and could not be reused

Setup Hardcoding ships faster and you were working under a deadline, so you hardcoded the values that made the demo. The template worked. That is exactly why nobody looked at it again until the next team tried to reuse it.

This is a postmortem, written the way a team writes one after the reuse attempt fails, so you can see the failure form before anyone labels it as a mistake. What happened A team built an agent template for a customer engagement and shipped it on time. To hit the due date, the customer-specific values went straight into the code: the repository path, the model name, the review thresholds, and a handful of prompt fragments specific to that customer's domain. The template ran, the engagement closed, and the build went into the shared repository labeled as reusable. Months later a second team picked it up for a similar engagement. They could not configure it, because there was nothing to configure. Every value that needed to change was baked into the loop where the second team could not see it without reading the whole file. There was no document saying which values were customer-specific and which were load-bearing. There was also no bundled eval, so even after they guessed at the edits, nothing confirmed the template still worked in the new context. They had to rewrite it from scratch.

Why it broke The build was treated as finished the moment it ran rather than at the moment it could be reused. Hardcoding was the reasonable call under a deadline, and it was never revisited. A working template does not announce that it cannot be reused. The cost appeared only when a second team paid for the rebuild that packaging was supposed to prevent, along with the time they lost discovering the template was a dead end.

What to Watch Out for A template that runs has not been packaged for reuse. These are different finishing states. The warning signs are the absence of three things: no parameters where customer-specific values belong, no documentation describing the assumptions, and no bundled eval proving the asset still works in a different context. Package the asset while the build is fresh. The knowledge of what is customer-specific is most expensive to reconstruct after the people who had it have moved on.

Screen 4: Checkpoint 1: Fix the broken accelerator template

CheckpointPackaging a reusable accelerator·4 min Checkpoint 1: Fix the broken accelerator template Try it now. Below is an agent template another team is supposed to reuse. It has one defect: a customer-specific value is hardcoded where a parameter belongs. The template as shipped

def build_review_agent(): return Agent( model="claude-opus-4-8", system_prompt=SYSTEM_PROMPT, tools=[read_file, run_linter], repo_path="/home/acme/checkout-service", # customer repo ) (Confirm current model ID at platform. claude. com/docs/en/about-claude/models at build time. ) Identify the hardcoded value, then write the corrected function signature and the parameterized line that replaces it.

Compare with model answer Skip for now

SkippedMove on if you need to but come back before the cumulative task. A later checkpoint plants a version of this same hardcoding defect among two others and is harder to spot under multi-layer load.

Screen 5: Moving an asset from private reuse into shared infrastructure a maintainer accep

TeachingContributing Back·12 min Moving an asset from private reuse into shared infrastructure a maintainer accepts You have already done most of the work that makes an asset shareable. When you packaged it for your own team to reuse, you pulled out the parameters, wrote down the assumptions, and bundled the eval. The parameters show the asset can be configured rather than rewritten. The documented assumptions tell the maintainer what environment the asset expects. The bundled eval gives them a way to confirm it still works. An asset packaged for internal reuse is already close to what a maintainer needs to accept it. The contribution channel is designed to receive that packaged asset. It carries the version, the installation steps, and the components as a single unit, so a team that never spoke to you can install it and get the same working setup. Match the contribution to the channel built for it Contributing back means moving an asset from private reuse to shared infrastructure through a documented channel. Each channel is built for a specific kind of contribution. The Claude Cookbook is a GitHub repository of focused reference implementations. It is designed for self-contained single- or multi-pattern implementations demonstrated clearly and working end to end. Open-source MCP servers and tools each live in their own repository with their own contribution conventions. Sending a full multi-component application to the Cookbook is a mismatch. The repository is set up to review one focused pattern rather than an entire application, so a submission that large does not fit what reviewers are looking for and will stall. The first step is matching the contribution to the channel built for it. Putting a full application where a focused example belongs is one of the most common reasons a contribution never gets reviewed. What makes verifying a contribution possible A maintainer accepts a contribution they can verify. The bar is set by what they need to check, not by how clever the code is. Four things make that verification possible:

1The code does one thing. A sprawling contribution forces a reviewer to reconstruct your intent before evaluating it. 2An example shows it running. A reviewer should not have to build a harness to see the behavior. 3A test proves it works. A test lets a maintainer verify the result without reproducing the reasoning themselves. 4A short statement names the assumptions. Otherwise, the first failure becomes the maintainer's problem.

Rights and attribution come before technical review Licensing and attribution decide whether a contribution can be accepted at all, which is why they come before the technical review. Code carried in from a customer engagement may have constraints on where it can go. Confirming you have the right to contribute it, and attributing anything you built on, is a gate the contribution must pass first. Skipping this is what turns a contribution into a problem the legal team must unwind later. The example worked here is the customer service agent case. A reusable conversation-handling pattern, built during an engagement, gets stripped of customer specifics and prepared as a general example for the Cookbook. The contribution-back motion is shared across all three roles in this curriculum. Your job as the Developer is technical readiness: the focused code, the example, the test, the assumptions, and the rights check. The engagement context comes from the broader team. The contribution-readiness reference

ChannelWhat a maintainer checksLicensing and attributionThe example and test bar to clear Cookbook for a focused example, or the tool or server's own repository for a tool or fix. That the code does one thing and that they can read it in full. Confirm that you have the right to contribute code from an engagement, with prior work attributed. A runnable example plus a test that proves the behavior, not just a description of it.

Handles well A packaged asset needs only the example, test, and rights check to become shared infrastructure others build on.

Adds cost or complexity Clearing the maintainer bar and the licensing gate is real work on top of making the code run for you.

Use a different approach When code carries an engagement licensing constraint you cannot clear, do not contribute it: escalate to the owner instead.

Screen 6: The pull request a maintainer could not verify

Watch OutContributing Back·2 min The pull request a maintainer could not verify

Setup You opened the contribution with the exact code that solved your problem. This was the natural choice because it worked in your case and it was accessible. It worked for you, but that is precisely why it was missing everything a stranger needs to trust it.

This is an exchange from an internal channel so you can hear how a maintainer explains the silence on a pull request. The exchange Developer: My PR has been open three weeks with no review. The code works, I use it every day. What is the holdup? Maintainer: It probably works for you. The problem is I can't tell. There is no test I can run, no example that proves the behavior, and nothing saying what it assumes about the environment. Developer: So, you want me to add a test and an example? Maintainer: Yes. A contribution a reviewer cannot verify sits at the back of the queue until someone has time to reconstruct what it does. A focused PR with a test and an example gets reviewed fast because there is nothing left for me to reverse-engineer.

Why it broke The code was correct. The contribution stalled because the maintainer could not verify it without reconstructing the developer's work. That gap is easy to overlook because the author already has the missing context. The example, the test, and the assumptions statement all seem obvious to the person who created the code. To the maintainer, however, they are not, and a reviewer who must reconstruct intent will always do it last.

What to Watch Out for A pull request stalls on what the reviewer cannot verify. Before opening a contribution, add the example that shows it running, the test that proves the behavior, and the short statement naming what it assumes. Those three features are what move a contribution from the back of the queue to a fast review, because they leave the maintainer nothing to reverse-engineer.

Screen 7: Checkpoint 2: Choose the contribution channel and the readiness fix

CheckpointContributing back to the ecosystem·3 min Checkpoint 2: Choose the contribution channel and the readiness fix Try it now. Read the three cases below. Match each case to the channel built for it and match each case to the one readiness item the snippet is missing.

Case A: A focused tool that wraps a single API into a clean function. The snippet is the function and nothing else. Case B: A full customer-service application a developer wants to share whole, including its UI and deployment scripts. Case C: A one-line fix to an existing Cookbook example. The snippet is the corrected line, carried in from a customer engagement.

Match 1: case to channel Case A: A focused tool that wraps a single API into a clean function. The snippet is the function and nothing else. The tool's own repositoryThe Cookbook, but only after the reusable pattern is stripped out as a focused exampleThe Cookbook example's own repositoryCase B: A full customer-service application shared whole, including its UI and deployment scripts. The tool's own repositoryThe Cookbook, but only after the reusable pattern is stripped out as a focused exampleThe Cookbook example's own repositoryCase C: A one-line fix to an existing Cookbook example. The snippet is the corrected line, carried in from a customer engagement. The tool's own repositoryThe Cookbook, but only after the reusable pattern is stripped out as a focused exampleThe Cookbook example's own repository Match 2: case to the missing readiness item Case A: A focused tool that wraps a single API into a clean function. The snippet is the function and nothing else. A test that proves the wrapper behavesReduction to a single focused pattern, because a whole application does not fit a review built for one patternThe rights check, because engagement code can carry a licensing constraint that blocks the merge before any technical reviewCase B: A full customer-service application shared whole, including its UI and deployment scripts. A test that proves the wrapper behavesReduction to a single focused pattern, because a whole application does not fit a review built for one patternThe rights check, because engagement code can carry a licensing constraint that blocks the merge before any technical reviewCase C: A one-line fix to an existing Cookbook example. The snippet is the corrected line, carried in from a customer engagement. A test that proves the wrapper behavesReduction to a single focused pattern, because a whole application does not fit a review built for one patternThe rights check, because engagement code can carry a licensing constraint that blocks the merge before any technical review

Submit Skip for now

Screen 8: From business requirements to functional and infrastructure requirements

TeachingRequirements & Lifecycle·8 min From business requirements to functional and infrastructure requirements The deployment-platform decisions that follow all assume the requirements already exist: the residency rule, the latency target, the identity model. This screen is where those requirements come from: turning a business problem into the functional and infrastructure requirements a deployment decision can be defended against. Capturing functional requirements from a business problem A functional requirement names what the system must do, stated with enough detail to check. A business problem (e. g. "help support agents answer faster") is not yet a requirement; the functional requirements derive from it (e. g. "classify each ticket into one of four queues; draft a reply citing the relevant policy; never auto-send without human approval"). The discipline is to write each as a checkable statement of behavior. A vague goal cannot be designed against or verified, while a specific one becomes a line in an eval and a criterion at review. Deriving infrastructure requirements Infrastructure requirements are the non-functional constraints the deployment must satisfy. Most of them are not stated in the business problem; instead, you derive them by asking the questions the business problem implies. Latency: how fast does a response need to be, measured where the user is? Scale: how many requests, and at what peak? Residency: where must the data be processed, and under which regulation? Identity: who acts, under what credentials, and what must be auditable? Latency, scale, residency, and identity are the infrastructure requirements that most often decide the deployment platform, and they are easiest to capture at the start, before a platform is chosen for other reasons. Documenting requirements so a decision can be defended Requirements are written down because the deployment decision will be reviewed by people who did not gather them. A short requirements record covering the functional behaviors, the infrastructure constraints, and the regulation each constraint comes from lets you defend a platform choice as following from the requirements rather than from familiarity. This record is the input the next screen's deployment decision reads from.

Handles well Turning a business problem into checkable functional and infrastructure requirements before any platform is chosen.

Adds cost or complexity Eliciting infrastructure constraints up front takes a scoping conversation the team is tempted to skip.

Use a different approach For a throwaway prototype with no review and no regulated data, lightweight notes are enough.

Screen 9: Checkpoint 3: extract the requirements

CheckpointRequirements & Lifecycle·2 min Checkpoint 3: extract the requirements Try it now. A regulated EU bank wants an agent that summarizes customer call transcripts for its support team, with summaries reviewed before they are stored in the EU. Question 1A regulated EU bank wants an agent that summarizes customer call transcripts for its support team. Which of the following is a valid functional requirement? AThe agent should be fast and accurate. BThe agent produces a summary that a human approves before it is stored. CThe system must be built using an approved cloud provider. DTranscript data must not leave the EU. Question 2From the same scenario, which of the following is a valid infrastructure requirement? AThe agent must produce summaries quickly enough for support staff to act on them. BThe agent summarizes transcripts using a pre-approved prompt template. CTranscript data is processed in the EU. DA human reviews each summary before it is stored.

Submit Skip for now

Screen 10: Systems lifecycle for Claude applications

TeachingRequirements & Lifecycle·8 min Systems lifecycle for Claude applications The requirements you just captured are the first phase of a longer arc. This screen names that arc as the systems lifecycle, so the deployment, versioning, and boundary work in the rest of this module sits in the right phase rather than arriving as unrelated tasks. The lifecycle phases applied to a Claude application A Claude application moves through the same lifecycle as any engineered system, with the model work mapped onto it:

1Requirements: capture functional and infrastructure needs 2Design: choose the platform, the model, and the trust boundaries 3Build: write the agent, tools, and prompts 4Test: evals, unit, integration, and end-to-end checks 5Deploy: pin the version, gate promotion on the eval 6Operate: instrument cost, latency, and errors; enforce guardrails 7Iterate: feed production findings back into requirements

The phases are the same ones the earlier modules taught one at a time. Identifying them as a lifecycle is what shows how they connect. Gating between phases A gate is a decision to move from one phase to the next, and it is where a regulated engagement keeps control. You do not move from design to build until the platform satisfies the residency requirement; you do not move from deploy toward full production until the new version clears the eval against the pinned baseline. Placing engineering work in the right phase, and refusing to skip a gate, is what keeps a Claude application reviewable.

Handles well Placing each piece of engineering work in the lifecycle phase it belongs to, with a defined artifact and gate.

Adds cost or complexity Gating between phases adds checkpoints a team under deadline is tempted to skip.

Use a different approach A one-off experiment may collapse phases, but a regulated deployment cannot.

Screen 11: Checkpoint 4: place the work in the right phase

CheckpointRequirements & Lifecycle·2 min Checkpoint 4: place the work in the right phase Try it now. Place each activity in the lifecycle phase it belongs to: requirements, design, test, deploy, operate. (a) pinning the full model ID and keeping the prior versionrequirementsdesigntestdeployoperate(b) gating promotion on the eval result before a version goes to productionrequirementsdesigntestdeployoperate(c) deciding data must be processed in a specific regionrequirementsdesigntestdeployoperate(d) instrumenting token cost and latency per call in productionrequirementsdesigntestdeployoperate(e) choosing Amazon Bedrock because the customer holds its compliance posture thererequirementsdesigntestdeployoperate

Submit Skip for now

Screen 12: Choosing where a Claude workload runs and versioning what ships

TeachingDeployment & Versioning·15 min Choosing where a Claude workload runs and versioning what ships A packaged asset and a contributed one are both merely code until something runs them. The asset now faces a different question: where it runs and how to lock its version, so an upstream change does not become an untracked change in production. That platform decision is rarely about technical merit alone. In practice, it is usually shaped by where the customer already has cloud infrastructure, identity management, and compliance agreements in place. The first question is usually about which platform the customer already trusts and operates on. The customer's cloud usually determines the platform The deployment platform is the environment where the Claude workload runs. The same model can run in several deployment environments, and the customer's existing cloud usually determines which one. The first-party Claude API is Anthropic's own environment and typically receives new features first. Claude Platform on AWS is accessed through the customer's AWS account using Anthropic's own model IDs and lifecycle; inference is Anthropic-operated, outside the AWS boundary. Amazon Bedrock offers two integrations: Claude in Amazon Bedrock uses the Messages API at /anthropic/v1/messages with broad feature parity; confirm any feature-specific requirements against the Bedrock documentation, as a features-not-supported list exists, while Claude on Amazon Bedrock (legacy) uses the InvokeModel/Converse APIs with ARN-versioned identifiers. Google Vertex AI does the same inside Google Cloud. Third-party platforms, such as Microsoft Foundry, embed Claude inside a product the customer already uses. Microsoft Foundry offers Claude in two hosting forms: Hosted on Azure (currently Claude Opus 4. 8, Claude Sonnet 5, and Claude Haiku 4. 5, with inference running end-to-end on Azure infrastructure, generally available) and Hosted on Anthropic (all other Foundry Claude models, with inference on Anthropic-operated infrastructure). Residency assumptions for regulated customers depend on the hosting form of the specific model. Confirm the hosting form and the current model split with Microsoft at build time. Identity and data residency are important for security Identity and data location are answered by the platform, not your code. Bedrock uses AWS identity and keeps data inside the customer's AWS boundary; Vertex uses Google Cloud identity and boundary. Both offer regional routing when residency is a constraint. Matching the platform to the customer's existing compliance agreement avoids a data-residency review from scratch. Pin the version so an upstream model change is not a silent production change Versioning is what keeps a model or prompt change from becoming a silent change in production. Every Claude model ID points to a specific model snapshot. Aliases such as Opus and Sonnet are convenient, but they evolve over time and may resolve to different versions across deployment platforms. A pinned full model ID resolves to a fixed snapshot. Pin the specific model version rather than the alias, so an upstream model update is a deliberate choice rather than a silent production change. Then version the prompt and the asset alongside the code. Finally, keep the prior version available so the regression can be rolled back. An unpinned deployment makes every upstream model update an untracked change to your output. The first line follows a moving alias. The second pins the snapshot.

model = "claude-haiku-4-5"

model = "claude-haiku-4-5-20251001" For Claude 4. 6 and later, the model ID alone pins to a specific snapshot; for earlier models, the ID plus a date suffix is required. Verify the current convention at platform. claude. com at build time. Promote a version through the eval Gate promotion on the eval suite. Send a new version to a portion of traffic, compare against the pinned baseline, and promote or roll back on the result. This is where the eval stops being a one-time test and becomes the deployment gate. The deployment-platform decision table

PlatformIdentity and data modelWhen to choose itHow versioning is pinned First-party Claude APIAnthropic identity and terms. The customer has no binding cloud or residency constraint and wants the newest capabilities. Pin the full model ID and keep the prior snapshot. Claude Platform on AWSAnthropic identity and terms, accessed through the customer's AWS account; inference is Anthropic-operated outside the AWS boundary. Model lifecycle follows Anthropic's deprecation schedule. The customer is on AWS but wants Anthropic model IDs, lifecycle, and feature parity with the first-party API. Pin using the same model ID format as the Claude API (for example, claude-opus-4-8). Lifecycle follows Anthropic's schedule. (Confirm at publish time. ) Claude in Amazon BedrockMessages API at /anthropic/v1/messages, broad feature parity with the first-party API; confirm feature-specific requirements against the Bedrock documentation. Data stays inside the customer's configured AWS boundary. The customer is on AWS, wants broad feature parity with the first-party API (confirm feature-specific requirements), and holds a compliance posture there. Pin the full model ID using the anthropic. prefix format. Partner retirement dates differ from Anthropic's schedule. Confirm at publish time. Claude on Amazon Bedrock (legacy)AWS identity and billing, InvokeModel/Converse APIs with ARN-versioned model identifiers. The customer is on an existing Bedrock integration using InvokeModel or Converse and has not migrated to the Messages API. Pin via ARN-versioned model identifiers per Bedrock's versioning controls. Google Vertex AIGoogle Cloud identity, Identity and Access Management (IAM), and billing, with regional or global endpoints for residency. The customer is on Google Cloud and holds a compliance posture there. Pin the full model ID before rollout using Vertex's model ID format. Partner retirement dates differ from Anthropic's schedule. Third-party platformThe wrapping product's identity and billing model. Note: Claude in Microsoft Foundry offers two hosting forms: Hosted on Azure (currently Opus 4. 8, Sonnet 5, and Haiku 4. 5; inference end-to-end on Azure) and Hosted on Anthropic (all other Foundry Claude models). Confirm residency and compliance terms with Microsoft before selecting this path for a regulated customer. The customer already runs the platform that embeds Claude. Pin per the platform's versioning controls.

Handles well Matching the platform to the customer cloud and pinning the version keeps a migration reviewable and a rollback possible.

Adds cost or complexity Pinning, retaining prior versions, and gating promotion on the eval add release-process overhead to every deployment.

Use a different approach For a throwaway prototype that never touches production, a moving alias is fine: pinning is for what ships.

Screen 13: The deployment that broke when the model alias moved

Watch OutDeployment & Versioning·3 min The deployment that broke when the model alias moved

Setup You shipped against the alias that pointed at the recommended version, because that was the convenient default and it gave you the latest model for free. It worked. Then the alias advanced, and what was free turned out to have a price.

This is a trace excerpt from a production log, the kind you would scroll back through after an incident. It shows the day the output shape changed and why there was nothing to roll back to. The log --: deploy: model="opus" status=ok --: alias advanced -> new opus version (no app change) --: parser: KeyError "summary" in response payload --: Error: output shape changed; downstream parse failed --: rollback attempted -> no pinned prior version retained --: incident: hotfix parser; root cause = unpinned deployment

Why it broke The application never changed, but the alias did. No pinned prior version had been retained, so there was nothing to roll back to. The hotfix repaired the parser but left the unpinned deployment in place.

What to Watch Out for An alias resolves to a moving target; a pinned full model ID is a fixed snapshot. Pin the full model ID so an upstream update is something you adopt on purpose. Keep the prior pinned version available so a regression is a rollback rather than a hotfix. Gate the new version through your eval before you promote it, so the output-shape change shows up in a test run instead of in production.

Screen 14: Checkpoint 5: Match the deployment platform and version pin to each scenario

CheckpointDeployment platform and versioning·4 min Checkpoint 5: Match the deployment platform and version pin to each scenario Try it now. A customer runs AWS with a data-residency requirement and needs to be able to roll back a model update. Select the one correct piece in each group below to assemble the minimal deployment configuration that satisfies both. Leave out what does not belong. Platform GroupFirst-party APIAmazon BedrockGoogle Vertex AIIdentity GroupAWS identity referenceAnthropic API keyModel reference groupA pinned full model IDA moving aliasRollback GroupRetain the prior pinned versionNo retention

Submit Skip for now

Screen 15: Comparing platforms on latency, compliance, and cost so the choice survives revi

TeachingComparing Platforms·12 min Comparing platforms on latency, compliance, and cost so the choice survives review In the last two screens you chose a platform and pinned its version. That choice was right for the customer's cloud, but "right for their cloud" is not yet an argument a procurement and security team will sign off on. Measure latency from the customer's region Latency depends on where the platform runs relative to the customer and on how access to new features is routed. A platform running in the customer's own cloud region can reduce round-trip time compared to a first-party endpoint located farther away. The trade-off is timing of access: the first-party API typically receives new capabilities before they reach other platforms. The number is only accurate when you measure it from the customer's actual region against their actual payload. A measurement from your laptop hides the round-trip penalty that appears once the workload runs where the customer is. Within Bedrock specifically, the choice between global and regional endpoints is also the primary residency control and can affect cost. You should measure from the customer's actual region against both options before committing. Compliance often determines the platform Compliance is often the dimension that ends the debate. A customer who already holds a certification on one cloud is unlikely to re-certify on another. Data residency is a rule that a customer's data must be processed in a specific country or region. Available compliance certifications and who can audit access differ by platform, and a regulated financial or healthcare customer treats these as pass-or-fail rather than as tradeoffs to balance. The first-party Claude API may not offer EU data residency; confirm current regional coverage at platform. claude. com, since EU-only residency typically requires Bedrock or Vertex AI; on third-party platforms such as Microsoft Foundry, hosting is per-model: Azure-hosted Foundry models run inference end-to-end on Azure infrastructure, while Anthropic-hosted Foundry models do not satisfy EU regional residency requirements. Residency must be confirmed per model and deployment with Microsoft. Raise the compliance constraint during scoping, or it surfaces at contract review after the work is done. What drives total cost beyond the per-token rate Per-token rates are broadly aligned across platforms; total cost moves on egress, platform fees, and integration effort. A lower token price can cost more in total once data transfer and integration are factored in. Instrument cost per call for each platform. Confirm the current pricing pages at scoping. The cross-platform comparison reference

DimensionHow it differs by platformHow to measure itWhere each platform wins LatencyA platform in the customer's region shortens the round trip, while the first-party API may reach new features first. From the customer's actual region against their actual payload. An in-region cloud platform wins on round-trip latency, while the first-party API is advantaged on earliest feature access. ComplianceData residency, certifications, and audit controls are determined by the deployment platform. Against the customer's existing certification and residency requirements during scoping. The cloud platform the customer has already certified wins, because it needs no re-certification. CostToken price, data egress, platform fees, and integration effort all vary. Total cost per call per platform, including egress and integration, rather than token price alone. The platform with the lowest total cost for the actual workload wins, which is not always the cheapest token.

Handles well Measuring all three dimensions per platform turns a placement into one a procurement team will sign off on.

Adds cost or complexity Instrumenting latency, compliance, and cost across platforms requires real measurement work before any code ships.

Use a different approach When the customer's compliance requirement is already pass-or-fail, skip the full comparison. That constraint determines the placement on its own.

Screen 16: The platform picked on familiarity that failed residency

Watch OutComparing Platforms·2 min The platform picked on familiarity that failed residency

Setup You picked the platform your team was already familiar with, because the migration looked easy and the deadline was approaching rapidly. It built just fine; the trouble was that easy-to-build and allowed-to-ship are different criteria.

The following anecdote is the kind a developer tells a teammate after a review goes sideways. It lets you see the familiar platform trap before anyone calls it a mistake. What happened A developer building for a regulated customer chose the platform the team had shipped on before. The integration came together quickly because the team knew the tools and resources. The build passed its functional tests. At the customer's security review, the reviewer asked where data was being processed. The selected platform did not satisfy the customer's residency requirements. A different platform, one the team knew less well, would have satisfied the requirement through regional deployment options the customer had already cleared. The placement was rejected, and the integration had to be rebuilt on the platform that met the residency constraint.

Why it broke Familiarity optimized for the wrong test. The easy migration answered whether the team could build quickly. It never answered whether the deployment would pass the customer's residency review, which was the test that determined whether it could ship. Because the compliance requirement was not fulfilled during scoping, it arrived at the go-no-go review instead. This is the most expensive place to discover it, because the build was already complete.

What to Watch Out for A platform that is easy for your team to build on is not necessarily a platform the customer is allowed to run. When the customer is regulated, the residency and compliance constraint is often pass-or-fail, rather than tradeoffs. Identify them early during scoping and let them influence the placement before familiarity does. Checking early costs a scoping conversation, while checking late costs an entire rebuild.

Screen 17: Checkpoint 6: Diagnose the platform mismatch from a comparison trace

CheckpointComparing platforms on latency, compliance, and cost·3 min Checkpoint 6: Diagnose the platform mismatch from a comparison trace Try it now. The comparison trace below shows a deployment platform selected on familiarity failing a customer requirement. Identify the mechanism, then pick the targeted fix from the three options. The trace platform_selected = "team_default" # chosen on familiarity latency_test: measured from dev laptop -> 180ms (looked fine) customer_region: eu-west, payload 12 KB compliance_check: data residency = EU-only required result: REJECTED reason="data processed outside EU on selected platform" AOption 1: Optimize the parser to cut the 180ms latency measured on the laptop. BOption 2: Remeasure latency from EU-west and select the platform whose region satisfies EU-only residency. COption 3: Add a caching layer to reduce per call cost on the selected platform.

Submit Skip for now

Screen 18: Coordinating several Claude deployments with the trust boundaries holding under

TeachingTrust Boundaries·14 min Coordinating several Claude deployments with the trust boundaries holding under review The accelerators, deployments, and tradeoffs now come together in a single application. Connecting components multiplies the places where identity, secrets, and untrusted input can cross. The discipline is to identify every boundary before connecting anything. Map which component does what before you connect them A multi-component app coordinates more than one Claude capability into a single workflow. An API request might trigger a Claude Code task, which then reaches a customer system through an MCP server. Each component contributes a capability the others do not have. The challenge is that every connection between them creates a place where identity, secrets, and untrusted input can cross. Map which component does what before connecting anything. The trust boundary is where data moves The trust boundary is the point where data or instructions move from one deployment environment to another. It is exactly where the injection and access controls from the prior module apply. Content fetched by a Claude Code task is untrusted when it reaches the next component. The receiving component should treat it as data, rather than as instructions, following the same principle used throughout the security module. The core discipline here is to identify every seam as a boundary. Don't assume a component is trusted simply because it worked correctly on its own. Least privilege applies to the whole application Identity and least privilege, which means giving each component only the access its task needs and nothing more, apply to the application as a whole. Each component operates under an identity. The application is only as contained as its most privileged seam, which means a single component scoped too broadly becomes the weak point even when every other component is properly scoped. You scope each component to the least privilege its role in the workflow requires. This is what keeps a steered component from reaching beyond its intended task. Scoping for a regulated review pulls the module together A regulated review requires justifying audit logging, data-residency decisions, and permission controls across the full application. For regulated deployments, Bedrock and Vertex AI are typically the platforms that satisfy regional residency constraints. Confirm ZDR and HIPAA BAA eligibility for each component against the Anthropic Trust Center and platform. claude. com before scoping. The multi-component integration map

ComponentWhat it contributesThe trust boundary at its seamThe control that enforces it First-party APIOrchestrates the workflow and holds the entry point. The request entering the app from outside. Input validation and the identity the call runs under. Claude Code taskRuns the agentic work and may fetch external content. Content it fetched, which is untrusted downstream. Treat fetched content as data at the next seam. MCP serverReaches a customer system to read or act. The system access it holds on the app's behalf. Scope the server to least privilege and log the access.

Handles well Naming every seam as a boundary and scoping each component to least privilege makes a multi-component app deployable under review.

Adds cost or complexity Mapping seams, enforcing controls at each, and logging boundary crossings adds design and audit work to every integration.

Use a different approach When a seam cannot be secured, do not ship around it: escalate to a human owner.

Screen 19: The seam nobody marked as a boundary

Watch OutTrust Boundaries·2 min The seam nobody marked as a boundary

Setup You connected the components that each passed their own tests. The parts were already checked and connecting verified parts feels safe. Each one was trusted in isolation. The gap was that a seam between two trusted parts cannot automatically be trusted itself.

This is a short transcript from a pairing session, the kind of back-and-forth that ends at the moment the unmarked seam gets identified. The session Dev A: All three components pass their own tests. I just wired them up. Dev B: Where does the Claude Code task send what it fetched? Dev A: Straight into the next call as part of the prompt. It is just the content we pulled from the customer page. Dev B: That content is untrusted. If it carries instructions, the next component runs them, because we never mark that seam as a boundary. Dev A: But each component was trusted on its own. Dev B: Right, and the seam between them was not. That is the one nobody treated as a boundary, so fetched content crosses as instructions.

Why it broke Each component having passed its own tests said nothing about the seam between them. The fetched content was untrusted the moment it left the Claude Code task. It arrived from a component that worked in isolation and it was passed into the next call as if it were trusted instructions. The boundary existed in the data flow. It just was not marked, so no control checked it. A component that passes its own tests has no seam-level controls. Every point where data crosses between deployment environments requires an explicit boundary control regardless of how each component behaves independently.

What to Watch Out for A component that is trusted in isolation does not automatically make the seam leaving it trustworthy. Mark every place data or instructions cross from one deployment environment to another as a boundary. Put a control there that treats fetched content as data rather than instructions, exactly as the security work taught. The seam nobody identifies is the one a steered action crosses.

Screen 20: Checkpoint 7: Complete the multi-component boundary configuration

CheckpointMulti-component app and trust boundaries·3 min Checkpoint 7: Complete the multi-component boundary configuration Try it now. The multi-component app below is wired, with two blanks left. Drag the correct control onto the seam that receives untrusted fetched content and drag the correct identity scope onto the most privileged component. The partial app

fetched = code_task. run(fetch_url=customer_page)

next_call(input=drop here(fetched))

mcp_server = MCPServer( system=customer_db, scope=drop here, # BLANK 2: identity scope ) Drag tokens (shared bank, two are distractors) treat_as_dataleast_privilege_read_onlyrun_as_instructionsfull_access

Submit Skip for now

Screen 21: Cumulative task: Find all three, explain each, write the correction

CumulativeAll topics·6 min Cumulative task: Find all three, explain each, write the correction Below is a runnable packaged accelerator deployed across platforms. There are three planted defects: one in the packaging layer, one in the deployment-and-versioning layer, and one in the multi-component boundary layer. Your task is to find all three. The deployment as shipped

def build_agent(): return Agent( model="opus", system_prompt=SYSTEM_PROMPT, repo_path="/home/acme/checkout", tools=[read_file, run_linter], )

deploy(platform="amazon_bedrock", identity=aws_role_arn)

fetched = code_task. run(fetch_url=customer_page) next_call(input=fetched) Carry your three corrected lines into the next screen, where you assemble and verify the fixed deployment. In your own words, identify all three defects.

Reveal model answer Skip for now

Screen 22: Cumulative task: assemble and verify the corrected deployment

CumulativeAll topics·6 min Cumulative task: assemble and verify the corrected deployment You have identified three defects across this module. Now assemble the fix: in your own words, describe what each defect was, what you changed, and why the corrected version is deployable. Then review the corrected code below and confirm your reasoning holds. When you are ready, reveal the model answer.

Reveal model answer Skip for now

The corrected deployment def build_agent(repo_path): # parameterized for reuse return Agent( model="us. anthropic. claude-opus-4-8", # pinned full Bedrock model ID system_prompt=SYSTEM_PROMPT, repo_path=repo_path, # set per engagement tools=[read_file, run_linter], )

deploy(platform="amazon_bedrock", identity=aws_role_arn, retain_previous_pinned_version=True) # rollback target kept

fetched = code_task. run(fetch_url=customer_page) next_call(input=treat_as_data(fetched)) # untrusted -> data, not instructions

assert eval_suite. run(model="us. anthropic. claude-opus-4-8") >= baseline_score Model answer: The first defect was a hardcoded repository path. Parameterizing it restores reuse: a new engagement sets the value rather than editing the loop. The second defect was a moving model alias. Pinning the full Bedrock model ID (with the anthropic. prefix) with a retained previous version restores controlled rollout and gives a rollback target if the new version regresses. The third defect was fetched content passed directly as instructions. Wrapping it in treat_as_data() closes the trust boundary: content from an untrusted source is treated as data, not as something the agent should act on. The eval assertion gates promotion on a proven baseline score before the version ships.

All three defects landed · pass I missed one or more · retry

Screen 23: Key takeaways

RecapAll topics·3 min Key takeaways

01 Package while the build is fresh. An accelerator keeps the reusable logic, exposes the customer-specific parts as documented parameters, and bundles the eval and the audit log alongside the asset. Correct packaging produces an asset teams configure. The knowledge of what is customer-specific is most expensive to reconstruct after the people who held it have moved on.

02 A maintainer accepts what they can verify. Moving an asset into shared infrastructure means matching it to the channel built for its shape, then clearing the review bar: focused code, a runnable example, a test, and a statement of assumptions, with licensing rights confirmed before the technical review. A contribution a reviewer cannot verify sits at the back of the queue. Readiness moves a private asset into shared infrastructure others build on.

03 Pin what ships. Choose the deployment platform based on the customer's cloud and compliance posture, then pin the specific model version rather than the moving alias and keep the prior version available. An alias is like asking for the current edition of a book: convenient, but the text can change. Pinning cites a fixed edition, so an upstream model change is something you adopt deliberately rather than something that arrives overnight with no rollback path.

04 Measure the dimension that decides the placement. A platform choice is defensible only when latency, compliance, and cost are measured: latency from the customer's region, compliance against their existing certification, and cost as the total per call rather than the token price alone. For regulated customers, compliance is usually pass-or-fail. Raising compliance as a constraint during scoping prevents it from rejecting the build later at contract review.

05 Mark every seam as a boundary. A multi-component application is only as contained as its most privileged seam. Scope each component to the minimum access its role requires and treat every point where data crosses as a trust boundary. Fetched content is treated as data, not instructions. Trust at a component boundary must be explicitly established. It does not carry over from the component that sent the data. When a seam cannot be secured, it goes to a human owner rather than being shipped.

What comes next You can now package a build into a reusable asset, contribute it back, place and version it on the right platform, defend that placement, and connect components together so the boundaries hold. That completes the build-to-deploy arc for this persona: from writing production code in the earlier modules to shipping assets a regulated customer can audit and a team can reuse.

Anthropic public references (time-sensitive)

IDSourceTypeUsed for S1platform. claude. com (Claude in Amazon Bedrock, Claude on Vertex AI)Product documentationDeployment platforms, identity and data models, residency routing, regional and global endpoints. S2platform. claude. com (Model IDs and versioning, Model deprecations)Product documentationPinned model IDs, alias resolution, lifecycle and retirement, partner-set schedules. S3anthropic. com and the Anthropic GitHub organization (Cookbook)Product and repositoryContribution channels, the Cookbook as a home for focused examples, contribution conventions. S4Building with the Claude API (Skilljar)Course sourceEval datasets, graders, and the evaluation pipeline used as the deployment gate. S5Claude Code 101 In Action (Skilljar)Course sourceClaude Code agentic tasks and MCP server roles in a multi-component workflow.

You can now take a working build all the way to a deployable, auditable asset. Package it, contribute it, place and version it, defend that placement, and hold the boundaries together under review.

Screen 24: Key terms from this module

GlossaryKey Terms·3 min Key terms from this module Alphabetical. Click a term to expand its definition.

AcceleratorA working solution packaged so the next engagement configures it rather than rebuilding it. Customer-specific parts are exposed as documented parameters, the assumptions are written down, and an eval is bundled to prove the asset still works in a new context. Contribution readinessWhat a maintainer needs to verify a contribution: focused code, a runnable example, a test that proves the behavior, a statement of environment assumptions, and confirmed rights to contribute the code. Deployment platformWhere a Claude workload runs. The six are: the first-party Claude API, Claude Platform on AWS, Claude in Amazon Bedrock, Claude on Amazon Bedrock (legacy), Google Vertex AI, and third-party platforms. The same model can differ by platform on identity, data residency, latency, and cost. Model alias versus pinned IDAn alias such as opus or sonnet resolves to a recommended version that updates over time and can differ by platform. A pinned full model ID is a fixed snapshot. Pinning is what keeps an upstream model change from being a silent production change. Trust boundaryThe seam where data or instructions move from one deployment environment to another in a multi-component app. Content fetched by one component is untrusted when it reaches the next, so the receiving component treats it as data, not instructions.

Screen 25: Congrats! You've successfully completed this module.

Module CompleteDeveloper Path·2 min Congrats! You've successfully completed this module. You can now take a working build all the way to a deployable, auditable asset: a reusable accelerator, a contribution a maintainer can verify, a deployment platform chosen and versioned on purpose, and every seam in a multi-component app marked as a trust boundary. The throughline: the point where code starts working is where this module's work begins.

4 of 9 checkpoints passed

M1

MSO Foundations Tokens, context windows, sampling, model tiers, prompting modes, and the API transport mechanics.

M2

Production-Grade Prompting, Agents & Tool-use Production-ready prompts, tool-use loops, streaming, context and memory management, and checkpointed agent loops.

M3

Claude Code, MCP & Integration Permission modes, durable project context, plugin packaging, and MCP integration without leaking credentials.

M4

Production Engineering, Evals, and Security Prove the system holds under production traffic and survives a security review.

M5

Accelerators and IP Contribution Package accelerators, prepare verifiable contributions, choose deployment platforms, and mark trust boundaries.

You Are Here

Review module Start over

Module completion recorded.

---

---

Screen 1: What you will be able to do by the end

ORIENTATION DEVELOPER MODULE 5 · 2 MIN What you will be able to do by the end

Documenteer de build goed en de volgende engagement bouwt erop voort in plaats van helemaal opnieuw te beginnen.

In de laatste drie modules heb je een productie-agent gebouwd, deze in Claude Code met de juiste machtigings- en contextbesturingselementen ingebouwd, en de MCP-verbindingen ingesteld die een beveiligingsbeoordeling doorstaan. Elk daarvan was een werkende build.

Deze module behandelt wat er met een build gebeurt nadat deze werkt. Je bouwt het op de volgende engagement helemaal opnieuw, of je verpakt het eenmaal, zodat het volgende team het alleen maar hoeft in te stellen. Het tweede pad is wat je tijd vrijmaakt voor nieuw werk in plaats van herhaald herbouwen.

Aan het einde van deze module kun je:

1 Een werkende oplossing als herbruikbare accelerator verpakken, of dat nu een geparametriseerde agentsjabloon, een configureerbare MCP-server of een draagbare eval-suite is, zodat de volgende engagement een asset configureert in plaats van deze volledig opnieuw op te bouwen. 2 Een tool, patroon of fix terug bijdragen via de gedocumenteerde kanalen en deze voorbereiden zodat een onderhouder deze kan accepteren, waardoor een privé-asset in gedeelde infrastructuur wordt omgezet. 3 Kiezen waar een Claude-workload wordt uitgevoerd op de first-party API, Amazon Bedrock, Google Vertex AI en platforms van derden, en versie wat wordt verzonden zodat een model- of prompt-wijziging de productie niet stilzwijgend breekt. 4 Deze platforms vergelijken op latentie, compliance en kosten zodat de keuze een keuze is die een inkoops- en beveiligingsteam kan goedkeuren, in plaats van een standaard die je team heeft gekozen. 5 Een applicatie bouwen die meerdere Claude-implementaties in één workflow coördineert en deze zodanig bereiken dat de gegevens- en identiteitsgrenzen onder een beveiligings- of compliancebeoordeling worden vastgehouden.

Deze module is voor de Developer die een werkende build heeft en deze nu duurzaam moet maken. Je bent praktisch, code-gericht en patroon-georiënteerd, en de eerdere modules gingen ervan uit en bouwden daarop voort. Op dit moment kun je een productie-agent schrijven, deze in Claude Code configureren, MCP-verbindingen inrichten die een beveiligingsbeoordeling doorstaan, en dit alles met evals bewijzen. Deze module leert dit niet opnieuw. Het begint op het moment dat je code correct wordt uitgevoerd en stelt de moeilijkere vraag: kan iemand anders het hergebruiken, kan een onderhouder het accepteren, kan het een modelupdate overleven, en kan een beveiligings- of inkoopteam goedkeuren waar het wordt uitgevoerd. Het werk hier gaat minder over het schrijven van code en meer over de beslissingen die afgewerkte code herbruikbaar, inzetbaar en verdedigbaar maken voor mensen die het niet hebben geschreven.

"DE BUILD" IN DEZE MODULE

Alles in deze module hangt af van één terugkerend gat: een build die werkt, is nog niet een build die hergebruik, beoordeling of implementatie overleeft. In ontwikkeling liep de sjabloon, loste de bijdrage je probleem op, reageerde het model, was het platform gemakkelijk om op te bouwen, en slaagde elk platform voor zijn eigen tests. Geen daarvan is de eindtoestand. Dezelfde sjabloon moet voor een team dat nooit met je heeft gesproken, worden geconfigureerd. Dezelfde bijdrage moet door een onderhouder verifieerbaar zijn zonder dat deze iets hoeft te reconstrueren. Hetzelfde model moet worden vastgezet zodat een upstream-wijziging een beslissing is in plaats van een verrassing. Hetzelfde platform moet een compliancebeoordeling van de klant doorstaan. Dezelfde verbonden platforms moeten hun vertrouwensgrenzen onder audit handhaven. Elk onderwerp in deze module is een ander versie van dezelfde les: het punt waar code begint te werken, is waar het werk van deze module begint. Meer van deze beslissingen dan je misschien verwacht, worden aangestuurd door de bestaande cloud, compliancehouding en beoordelingsproces van de klant.

DISCLAIMER / KENNISGEVING VOOR EDUCATIEVE INHOUD

We hebben deze Developer-cursus Module 5: Accelerators and IP Contribution gebouwd om je echt werk met Claude te helpen doen. Behandel het als educatieve inhoud. Het vormt geen juridisch, financieel of ander professioneel advies, dus pas wat je leert aan je eigen situatie aan. Onze producten en services evolueren snel, dus bepaalde inhoud kan fouten bevatten of verouderd zijn; vergeet niet om te verifiëren op de website of docs van Anthropic. Voorbeelden en scenario's die in de cursus worden gebruikt, zijn illustratief en vaak fictief. Als het cursusmateriaal een bedrijf of product noemt, betekent dit niet dat Anthropic deze aanbeveelt, zij Anthropic aanbevelen, of dat we gelieerd zijn. Houd er ook rekening mee dat uw gebruik van Anthropic-producten en -services wordt beheerst door onze voorwaarden, beleidsregels en documentatie; als iets in deze cursus hiermee in conflict is, hebben zij voorrang.

Screen 2: Packaging a working build so the next engagement starts from an asset

TeachingPackaging for Reuse·16 min Een werkende build verpakken zodat de volgende engagement met een asset begint Je hebt de vorige modules afgerond met een build die werkt: een agentlus, een geconfigureerde MCP-server, een eval die bewijst dat de prompt werkt. Het meest tijd- en kostbaar op een team is de engineeringtijd die wordt besteed aan het herbouwen van hetzelfde voor de volgende klant. Wat een accelerator doet: houd de herbruikbare onderdelen en scheid de rest Een accelerator is een oplossing verpakt zodat toekomstige engagements beginnen met een werkende basis in plaats van met een lege repository. In blauwdrukvoorwaarden is dit verpakking voor hergebruik: het scheiden van engagement-specifieke code van de herbruikbare kern en het parametriseren van de rest. Neem een werkende build, scheid de onderdelen die klantspecifiek zijn, en stel deze bloot als parameters met gedocumenteerde standaardwaarden. De asset configureert zich dan in plaats van volledig herschreven te worden. Verpakking voor hergebruik terwijl de build vers is, is goedkoper dan de bedoeling maanden later te reconstrueren, wanneer de persoon die wist waarom een waarde hardcoded was, is vertrokken. Het meeste herbruikbare werk valt in verschillende assettypen, en elk verpakt anders Het meeste herbruikbare werk valt in één van drie categorieën die in deze module worden gebruikt: een sjabloon, een configureerbare server of een draagbare eval. Elk type bevat een ander soort werk en moet op zijn eigen manier worden verpakt. Het kiezen van het verkeerde type kan een asset herbruikbaar laten lijken terwijl het nog steeds moeilijk is om toe te passen.

Asset typeWat het bundeltWat juiste verpakking vereist Agent TemplateThe system prompt, the tool schemas, and the loop structure from a working agent. Trek de domeinspecifieke waarden in configuratie met gedocumenteerde standaardwaarden, zodat een nieuw team de waarden instelt in plaats van de lus te bewerken. MCP Server PackageThe tools the server exposes, with their inputs and the scope the installing team controls. Documenteer elke toolinvoer en laat het installatiesteam het bereik instellen, zodat de server in een nieuwe omgeving wordt geïnstalleerd zonder codewijzigingen. Eval SuiteThe graded test set and the judge rubric that prove the asset works. Verzend de dataset en rubric samen zodat een nieuw team deze in hun eigen context kan uitvoeren en kan bevestigen dat de asset daar nog steeds werkt. Dezelfde eval-suite fungeert ook als poort bij implementatie. Wanneer je een nieuwe modelversie naar productie promoveert, voer deze uit tegen een vastgezette basislinescore voordat de versie live gaat.

Het verzenden van een agent als een reeks losse scripts in plaats van een sjabloon is de meest voorkomende versie van de verkeerde benadering. De scripts werken, dus zien ze er herbruikbaar uit, maar elke klantspecifieke waarde is in een ander bestand begraven, en het volgende team kopieert en divergeert ze in plaats van één asset in te stellen. Documenteer zowel de code als de aannames Code beschrijft gedrag. Documentatie behandelt wat een toekomstige bouwer niet betrouwbaar uit de bron kan afleiden: de aannames die de asset over zijn omgeving maakt, de invoer die het verwacht, de foutmodi die het al afhandelt, en de eval die bepaalt of het nog steeds werkt. Zonder dit behandelt het volgende team de asset als een zwarte doos en bouwt het deze opnieuw. Bundel het auditlogboek als onderdeel van het pakket Een reviewer van een gereglementeerde klant vraagt welke gegevens de asset aanraakt, onder welke identiteit deze werkt, en welk logboek het achterlaat. Een accelerator zonder deze passeert een demo en stagneert bij de eerste beveiligingsbeoordeling. Behandel het auditlogboek als onderdeel van het pakket. De verpakkingscontrolelijst Houd deze controlelijst naast de build terwijl je deze verpakt. Elke kolom is een beslissing die je eenmaal per asset neemt.

Asset typeWat te parametriserenWat te documenterenWat voor audit in te bundelen Agent templateElke waarde die per klant verandert: prompts, paden, bereiken, referenties naar referenties en drempels. Omgevingsaannames, verwachte invoer, afgehandelde foutmodi en de eval die werkend bepaalt. De gegevens aangeraakt, de identiteit waaronder gehandeld, en het logboek van wat de asset deed. MCP ServerBereiken, referenties naar referenties en paden per klant. Verwachte invoer per tool, bereikgrenzen en afgehandelde foutmodi. De gegevens aangeraakt, de identiteit waaronder gehandeld, en het logboek van wat de asset deed. Eval SuiteThresholds and dataset paths that change per customer or environment. De rubriclogica, wat de scores betekenen, en de basislijn waaraan de asset is vastgezet. De gegevens aangeraakt, de identiteit waaronder gehandeld, en het logboek van wat de asset deed.

Handles well Parametrisering terwijl de build vers is, verandert één levering in een asset die de volgende engagement in uren configureert.

Adds cost or complexity Het scheiden van generaliseerbare van klantspecifieke onderdelen en het documenteren van aannames voegt echte tijd toe aan de eerste build.

Use a different approach Voor een eenmalige build die een klant nooit zal hergebruiken, is verpakkingsoverhead niet de moeite waard: verzend de build en ga verder.

Screen 3: The template that shipped fast and could not be reused

Watch OutPackaging for Reuse·2 min De sjabloon die snel werd verzonden en niet kon worden hergebruikt

Setup Hardcoding verzend sneller en je werkte onder een deadline, dus je hardcodeerde de waarden die de demo maakten. De sjabloon werkte. Dat is precies waarom niemand ernaar keek totdat het volgende team het probeerde te hergebruiken.

Dit is een postmortem, geschreven op de manier waarop een team er een schrijft nadat de hergebruikpoging mislukt, zodat je de mislukking kunt zien voordat iemand het als een fout bestempelt. Wat gebeurde er Een team bouwde een agentsjabloon voor een klantengagement en verzond deze op tijd. Om de deadline te halen, gingen de klantspecifieke waarden rechtstreeks in de code: het repositorypad, de modelnaam, de beoordelingsdrempels en een handvol promptfragmenten die specifiek voor het domein van die klant waren. De sjabloon werkte, het engagement sloot af, en de build ging in de gedeelde repository met het label "herbruikbaar".

Maanden later pakte een tweede team het op voor een soortgelijk engagement. Ze konden het niet configureren, omdat er niets te configureren was. Elke waarde die moest veranderen, was in de lus gebakken waar het tweede team het niet kon zien zonder het hele bestand te lezen. Er was geen document dat zei welke waarden klantspecifiek waren en welke draagkrachtig. Er was ook geen gebundelde eval, dus zelfs nadat ze naar de bewerkingen gokten, bevestigde niets dat de sjabloon nog steeds in de nieuwe context werkte. Ze moesten het helemaal opnieuw schrijven.

Why it broke De build werd als voltooid beschouwd op het moment dat deze werkte in plaats van op het moment dat deze kon worden hergebruikt. Hardcoding was de redelijke keuze onder een deadline, en deze werd nooit herzien. Een werkende sjabloon kondigt niet aan dat deze niet kan worden hergebruikt. De kosten verschenen alleen toen een tweede team betaalde voor de herbouw die verpakking zou moeten voorkomen, samen met de tijd die ze verloren bij het ontdekken dat de sjabloon een dood spoor was.

What to Watch Out for Een sjabloon die werkt, is niet verpakt voor hergebruik. Dit zijn verschillende eindtoestanden. De waarschuwingstekenen zijn de afwezigheid van drie dingen: geen parameters waar klantspecifieke waarden thuishoren, geen documentatie die de aannames beschrijft, en geen gebundelde eval die bewijst dat de asset nog steeds in een ander context werkt. Verpak de asset terwijl de build vers is. De kennis van wat klantspecifiek is, is het duurste om na te reconstrueren nadat de mensen die het hadden, zijn vertrokken.

Screen 4: Checkpoint 1: Fix the broken accelerator template

CheckpointPackaging a reusable accelerator·4 min Checkpoint 1: Repareer de verbroken acceleratorsjabloon Probeer het nu. Hieronder staat een agentsjabloon die een ander team moet hergebruiken. Het heeft één defect: een klantspecifieke waarde is hardcoded waar een parameter thuishoort. De sjabloon zoals verzonden

def build_review_agent(): return Agent( model="claude-opus-4-8", system_prompt=SYSTEM_PROMPT, tools=[read_file, run_linter], repo_path="/home/acme/checkout-service", # customer repo ) (Bevestig huidige model-ID op platform. claude. com/docs/en/about-claude/models op bouwmoment. ) Identificeer de hardcoded waarde, schrijf vervolgens de gecorrigeerde functiehandtekening en de geparametriseerde regel die deze vervangt.

Compare with model answer Skip for now

SkippedMove on if you need to but come back before the cumulative task. A later checkpoint plants a version of this same hardcoding defect among two others and is harder to spot under multi-layer load.

Screen 5: Moving an asset from private reuse into shared infrastructure a maintainer accep

TeachingContributing Back·12 min Een asset van privé-hergebruik naar gedeelde infrastructuur verplaatsen die een onderhouder accepteert Je hebt al het meeste werk gedaan dat een asset deelbaar maakt. Toen je het voor je eigen team verpakte om het opnieuw te gebruiken, haalde je de parameters eruit, schreef je de aannames op en bundelde je de eval. De parameters tonen aan dat de asset kan worden geconfigureerd in plaats van herschreven. De gedocumenteerde aannames vertellen de onderhouder welke omgeving de asset verwacht. De gebundelde eval geeft hen een manier om te bevestigen dat het nog steeds werkt. Een asset verpakt voor intern hergebruik is al dicht bij wat een onderhouder nodig heeft om het te accepteren. Het bijdragekanaal is ontworpen om die verpakte asset te ontvangen. Het draagt de versie, de installatiestappen en de componenten als één eenheid, zodat een team dat nooit met je heeft gesproken, deze kan installeren en dezelfde werkende setup krijgt. Match de bijdrage aan het kanaal dat ervoor is gebouwd Bijdragen betekent een asset van privé-hergebruik naar gedeelde infrastructuur verplaatsen via een gedocumenteerd kanaal. Elk kanaal is gebouwd voor een specifiek soort bijdrage. De Claude Cookbook is een GitHub-repository van gerichte referentie-implementaties. Het is ontworpen voor zelfstandige implementaties van één of meerdere patronen die duidelijk worden gedemonstreerd en end-to-end werken. Open-source MCP-servers en tools bevinden zich elk in hun eigen repository met hun eigen bijdrageconventies. Het verzenden van een volledige multi-component-applicatie naar de Cookbook is een mismatch. De repository is ingesteld om één gericht patroon te beoordelen in plaats van een volledige applicatie, dus een indiening die zo groot is, past niet in wat reviewers zoeken en zal stagneren. De eerste stap is het matchen van de bijdrage aan het kanaal dat ervoor is gebouwd. Het plaatsen van een volledige applicatie waar een gericht voorbeeld thuishoort, is een van de meest voorkomende redenen waarom een bijdrage nooit wordt beoordeeld. Wat verificatie van een bijdrage mogelijk maakt Een onderhouder accepteert een bijdrage die zij kunnen verifiëren. De lat wordt bepaald door wat zij moeten controleren, niet door hoe slim de code is. Vier dingen maken die verificatie mogelijk:

1De code doet één ding. Een uitgebreide bijdrage dwingt een reviewer om je bedoeling te reconstrueren voordat deze wordt geëvalueerd. 2Een voorbeeld toont het in werking. Een reviewer hoeft geen harnas te bouwen om het gedrag te zien. 3Een test bewijst dat het werkt. Een test laat een onderhouder het resultaat verifiëren zonder de redenering zelf te reproduceren. 4Een korte verklaring noemt de aannames. Anders wordt de eerste mislukking het probleem van de onderhouder.

Rechten en attributie gaan vóór technische beoordeling Licenties en attributie bepalen of een bijdrage überhaupt kan worden geaccepteerd, daarom gaan ze vóór de technische beoordeling. Code die uit een klantengagement wordt meegenomen, kan beperkingen hebben op waar deze kan gaan. Het bevestigen dat je het recht hebt om het bij te dragen, en het toekennen van alles wat je hebt gebouwd, is een poort die de bijdrage eerst moet passeren. Dit overslaan is wat een bijdrage in een probleem verandert dat het juridische team later moet ontwarren. Het voorbeeld dat hier werkt, is het geval van de klantenserviceagent. Een herbruikbaar conversatieafhandelingspatroon, gebouwd tijdens een engagement, wordt ontdaan van klantspecifieke gegevens en voorbereid als een algemeen voorbeeld voor de Cookbook. De bijdrage-achterwaartse beweging wordt gedeeld door alle drie de rollen in dit curriculum. Je taak als Developer is technische gereedheid: de gerichte code, het voorbeeld, de test, de aannames en de rechtencontrole. De engagement-context komt van het bredere team. De bijdrage-gereedheidsreferentie

ChannelWat een onderhouder controleerLicenties en attributieDe voorbeeld- en testlat om te wissen Cookbook voor een gericht voorbeeld, of de eigen repository van de tool of server voor een tool of fix. Dat de code één ding doet en dat zij deze volledig kunnen lezen. Bevestig dat je het recht hebt om code uit een engagement bij te dragen, met eerdere werk toegeschreven. Een uitvoerbaar voorbeeld plus een test die het gedrag bewijst, niet alleen een beschrijving ervan.

Handles well Een verpakte asset heeft alleen het voorbeeld, de test en de rechtencontrole nodig om gedeelde infrastructuur te worden waarop anderen voortbouwen.

Adds cost or complexity Het wissen van de onderhouderslat en de licentiepoort is echt werk bovenop het laten werken van de code voor je.

Use a different approach Wanneer code een engagement-licentiebeperking draagt die je niet kunt wissen, draag het niet bij: escaleer naar de eigenaar in plaats daarvan.

Screen 6: The pull request a maintainer could not verify

Watch OutContributing Back·2 min De pull request die een onderhouder niet kon verifiëren

Setup Je opende de bijdrage met de exacte code die je probleem oploste. Dit was de natuurlijke keuze omdat het in jouw geval werkte en het toegankelijk was. Het werkte voor je, maar dat is precies waarom het alles miste wat een vreemde nodig heeft om het te vertrouwen.

Dit is een uitwisseling van een intern kanaal zodat je kunt horen hoe een onderhouder het stilzwijgen op een pull request uitlegt. De uitwisseling Developer: Mijn PR staat al drie weken open zonder beoordeling. De code werkt, ik gebruik het elke dag. Wat is het probleem? Maintainer: Het werkt waarschijnlijk voor je. Het probleem is dat ik het niet kan zien. Er is geen test die ik kan uitvoeren, geen voorbeeld dat het gedrag bewijst, en niets dat zegt wat het over de omgeving aanneemt. Developer: Dus je wilt dat ik een test en een voorbeeld toevoeg? Maintainer: Ja. Een bijdrage die een reviewer niet kan verifiëren, zit achter in de wachtrij totdat iemand tijd heeft om te reconstrueren wat het doet. Een gerichte PR met een test en een voorbeeld wordt snel beoordeeld omdat er niets meer voor mij is om reverse-engineeren.

Why it broke De code was correct. De bijdrage stagneerde omdat de onderhouder deze niet kon verifiëren zonder het werk van de developer te reconstrueren. Die kloof is gemakkelijk over het hoofd te zien omdat de auteur al de ontbrekende context heeft. Het voorbeeld, de test en de aannamedeclaratie lijken allemaal voor de persoon die de code heeft gemaakt. Voor de onderhouder zijn ze dat echter niet, en een reviewer die de bedoeling moet reconstrueren, zal dit altijd als laatste doen.

What to Watch Out for Een pull request stagneert op wat de reviewer niet kan verifiëren. Voeg vóór het openen van een bijdrage het voorbeeld toe dat aantoont dat het werkt, de test die het gedrag bewijst, en de korte verklaring die noemt wat het aanneemt. Deze drie functies zijn wat een bijdrage van de achterkant van de wachtrij naar een snelle beoordeling verplaatst, omdat ze de onderhouder niets achterlaten om reverse-engineeren.

Screen 7: Checkpoint 2: Choose the contribution channel and the readiness fix

CheckpointContributing back to the ecosystem·3 min Checkpoint 2: Kies het bijdragekanaal en de gereedheidsfix Probeer het nu. Lees de drie gevallen hieronder. Match elk geval met het kanaal dat ervoor is gebouwd en match elk geval met het ene gereedheidsitem dat het fragment mist.

Case A: Een gerichte tool die een enkele API in een schone functie wikkelt. Het fragment is de functie en niets anders. Case B: Een volledige klantenserviceapplicatie die een developer heel wil delen, inclusief de UI en implementatiescripts. Case C: Een eenregelige fix voor een bestaand Cookbook-voorbeeld. Het fragment is de gecorrigeerde regel, afkomstig uit een klantengagement.

Match 1: case to channel Case A: Een gerichte tool die een enkele API in een schone functie wikkelt. Het fragment is de functie en niets anders. De eigen repository van de toolDe Cookbook, maar alleen nadat het herbruikbare patroon als gericht voorbeeld is gehaaldDe eigen repository van het Cookbook-voorbeeldCase B: Een volledige klantenserviceapplicatie die heel wordt gedeeld, inclusief de UI en implementatiescripts. De eigen repository van de toolDe Cookbook, maar alleen nadat het herbruikbare patroon als gericht voorbeeld is gehaaldDe eigen repository van het Cookbook-voorbeeldCase C: Een eenregelige fix voor een bestaand Cookbook-voorbeeld. Het fragment is de gecorrigeerde regel, afkomstig uit een klantengagement. De eigen repository van de toolDe Cookbook, maar alleen nadat het herbruikbare patroon als gericht voorbeeld is gehaaldDe eigen repository van het Cookbook-voorbeeld Match 2: case to the missing readiness item Case A: Een gerichte tool die een enkele API in een schone functie wikkelt. Het fragment is de functie en niets anders. Een test die het wrappergedrag bewijstReductie tot een enkel gericht patroon, omdat een volledige applicatie niet in een beoordeling past die voor één patroon is gebouwdDe rechtencontrole, omdat engagement-code een licentiebeperking kan dragen die de merge blokkeert vóór enige technische beoordelingCase B: Een volledige klantenserviceapplicatie die heel wordt gedeeld, inclusief de UI en implementatiescripts. Een test die het wrappergedrag bewijstReductie tot een enkel gericht patroon, omdat een volledige applicatie niet in een beoordeling past die voor één patroon is gebouwdDe rechtencontrole, omdat engagement-code een licentiebeperking kan dragen die de merge blokkeert vóór enige technische beoordelingCase C: Een eenregelige fix voor een bestaand Cookbook-voorbeeld. Het fragment is de gecorrigeerde regel, afkomstig uit een klantengagement. Een test die het wrappergedrag bewijstReductie tot een enkel gericht patroon, omdat een volledige applicatie niet in een beoordeling past die voor één patroon is gebouwdDe rechtencontrole, omdat engagement-code een licentiebeperking kan dragen die de merge blokkeert vóór enige technische beoordeling

Submit Skip for now

Screen 8: From business requirements to functional and infrastructure requirements

TeachingRequirements & Lifecycle·8 min Van bedrijfsvereisten naar functionele en infrastructuurvereisten De implementatieplatformbesluiten die volgen, gaan ervan uit dat de vereisten al bestaan: de residentiële regel, het latentiedoel, het identiteitsmodel. Dit scherm is waar die vereisten vandaan komen: het omzetten van een bedrijfsprobleem in de functionele en infrastructuurvereisten waarop een implementatiebesluit kan worden verdedigd. Functionele vereisten vastleggen uit een bedrijfsprobleem Een functionele vereiste noemt wat het systeem moet doen, vermeld met voldoende detail om te controleren. Een bedrijfsprobleem (bijv. "help supportagenten sneller antwoorden") is nog geen vereiste; de functionele vereisten ervan afleiden (bijv. "classificeer elk ticket in één van vier wachtrijen; ontwerp een antwoord dat het relevante beleid aanhaalt; verzend nooit automatisch zonder menselijke goedkeuring"). De discipline is om elk als een controleerbare verklaring van gedrag te schrijven. Een vaag doel kan niet tegen worden ontworpen of geverifieerd, terwijl een specifiek doel een regel in een eval en een criterium bij beoordeling wordt. Infrastructuurvereisten afleiden Infrastructuurvereisten zijn de niet-functionele beperkingen die de implementatie moet vervullen. De meeste ervan worden niet in het bedrijfsprobleem vermeld; in plaats daarvan leid je ze af door de vragen te stellen die het bedrijfsprobleem impliceert. Latentie: hoe snel moet een reactie zijn, gemeten waar de gebruiker is? Schaal: hoeveel verzoeken, en op welk piekmoment? Residentiële: waar moeten de gegevens worden verwerkt, en onder welke regelgeving? Identiteit: wie handelt, onder welke referenties, en wat moet controleerbaar zijn? Latentie, schaal, residentiële en identiteit zijn de infrastructuurvereisten die het implementatieplatform het meest bepalen, en ze zijn het gemakkelijkst vast te leggen aan het begin, voordat een platform om andere redenen wordt gekozen. Vereisten documenteren zodat een besluit kan worden verdedigd Vereisten worden opgeschreven omdat het implementatiebesluit wordt beoordeeld door mensen die deze niet hebben verzameld. Een korte vereistenrecord die de functionele gedragingen, de infrastructuurbeperkingen en de regelgeving die elke beperking voortbrengt, behandelt, laat je een platformkeuze verdedigen als volgende uit de vereisten in plaats van uit vertrouwdheid. Deze record is de invoer die het volgende scherm's implementatiebesluit uit leest.

Handles well Het omzetten van een bedrijfsprobleem in controleerbare functionele en infrastructuurvereisten voordat een platform wordt gekozen.

Adds cost or complexity Het uitlokken van infrastructuurbeperkingen vooraf kost een scopingsgesprek dat het team geneigd is over te slaan.

Use a different approach Voor een wegwerpprototype zonder beoordeling en zonder gereglementeerde gegevens, zijn lichte notities voldoende.

Screen 9: Checkpoint 3: extract the requirements

CheckpointRequirements & Lifecycle·2 min Checkpoint 3: haal de vereisten op Probeer het nu. Een gereglementeerde EU-bank wil een agent die klantoproepopnamen voor haar supportteam samenvat, met samenvattingen die worden beoordeeld voordat ze in de EU worden opgeslagen. Question 1Een gereglementeerde EU-bank wil een agent die klantoproepopnamen voor haar supportteam samenvat. Welke van de volgende is een geldige functionele vereiste? AThe agent should be fast and accurate. BDe agent produceert een samenvatting die een mens goedkeurt voordat deze wordt opgeslagen. CThe system must be built using an approved cloud provider. DTranscript data must not leave the EU. Question 2Uit hetzelfde scenario, welke van de volgende is een geldige infrastructuurvereiste? AThe agent must produce summaries quickly enough for support staff to act on them. BDe agent vat transcripten samen met behulp van een vooraf goedgekeurd promptsjabloon. CTranscriptgegevens worden in de EU verwerkt. DA human reviews each summary before it is stored.

Submit Skip for now

Screen 10: Systems lifecycle for Claude applications

TeachingRequirements & Lifecycle·8 min Systeemlevenscyclus voor Claude-applicaties De vereisten die je zojuist hebt vastgelegd, zijn de eerste fase van een langere boog. Dit scherm noemt die boog als de systeemlevenscyclus, zodat het implementatie-, versie- en grenswerk in de rest van deze module in de juiste fase zit in plaats van als onverwante taken aan te komen. De levenscyclusfasen toegepast op een Claude-applicatie Een Claude-applicatie gaat door dezelfde levenscyclus als elk ander engineered systeem, met het modelwerk erop afgestemd:

1Requirements: capture functional and infrastructure needs 2Design: choose the platform, the model, and the trust boundaries 3Build: write the agent, tools, and prompts 4Test: evals, unit, integration, and end-to-end checks 5Deploy: pin the version, gate promotion on the eval 6Operate: instrument cost, latency, and errors; enforce guardrails 7Iterate: feed production findings back into requirements

De fasen zijn dezelfde die de eerdere modules één voor één hebben onderwezen. Het identificeren ervan als een levenscyclus toont hoe ze verbonden zijn. Gating tussen fasen Een poort is een beslissing om van de ene fase naar de volgende te gaan, en het is waar een gereglementeerd engagement controle houdt. Je gaat niet van ontwerp naar build totdat het platform aan de residentiële vereiste voldoet; je gaat niet van implementatie naar volledige productie totdat de nieuwe versie de eval tegen de vastgezette basislijn doorstaat. Het plaatsen van engineeringwerk in de juiste fase, en het weigeren om een poort over te slaan, is wat een Claude-applicatie controleerbaar houdt.

Handles well Het plaatsen van elk stuk engineeringwerk in de levenscyclusfase waartoe het behoort, met een gedefinieerd artefact en poort.

Adds cost or complexity Gating tussen fasen voegt controlepunten toe die een team onder deadline geneigd is over te slaan.

Use a different approach Een eenmalig experiment kan fasen samenvouwen, maar een gereglementeerde implementatie kan dat niet.

Screen 11: Checkpoint 4: place the work in the right phase

CheckpointRequirements & Lifecycle·2 min Checkpoint 4: plaats het werk in de juiste fase Probeer het nu. Plaats elke activiteit in de levenscyclusfase waartoe deze behoort: vereisten, ontwerp, test, implementatie, bedrijf. (a) de volledige model-ID vastpinnen en de vorige versie behoudenvereistentestontwerpimplementatiebedrijf(b) promotie gating op het eval-resultaat voordat een versie naar productie gaatvereistenontwerptesteimplementatiebedrijf(c) beslissen dat gegevens in een specifieke regio moeten worden verwerktvereistenontwerptesteimplementatiebedrijf(d) tokenkosten en latentie per oproep in productie instrumenterenvereistentestontwerpimplementatiebedrijf(e) Amazon Bedrock kiezen omdat de klant daar zijn compliancehouding heeftvereistenontwerptesteimplementatiebedrijf

Submit Skip for now

Screen 12: Choosing where a Claude workload runs and versioning what ships

TeachingDeployment & Versioning·15 min Kiezen waar een Claude-workload wordt uitgevoerd en versie wat wordt verzonden Een verpakte asset en een bijgedragen asset zijn beide slechts code totdat iets ze uitvoert. De asset staat nu voor een ander vraag: waar deze wordt uitgevoerd en hoe de versie wordt vergrendeld, zodat een upstream-wijziging geen onverwachte wijziging in productie wordt. Die platformbesluit gaat zelden alleen om technische verdiensten. In de praktijk wordt het meestal bepaald door waar de klant al cloud-infrastructuur, identiteitsbeheer en complianceovereenkomsten op plek heeft. De eerste vraag gaat meestal over welk platform de klant al vertrouwt en bedrijft. De cloud van de klant bepaalt meestal het platform Het implementatieplatform is de omgeving waar de Claude-workload wordt uitgevoerd. Hetzelfde model kan in verschillende implementatieomgevingen worden uitgevoerd, en de bestaande cloud van de klant bepaalt meestal welke. De first-party Claude API is Anthropic's eigen omgeving en ontvangt doorgaans eerst nieuwe functies. Claude Platform on AWS wordt benaderd via het AWS-account van de klant met behulp van Anthropic's eigen model-ID's en levenscyclus; inferentie wordt door Anthropic beheerd, buiten de AWS-grens. Amazon Bedrock biedt twee integraties: Claude in Amazon Bedrock gebruikt de Messages API op /anthropic/v1/messages met brede functie-pariteit; bevestig alle functiespecifieke vereisten tegen de Bedrock-documentatie, omdat een lijst met niet-ondersteunde functies bestaat, terwijl Claude on Amazon Bedrock (legacy) de InvokeModel/Converse API's met ARN-versioned identifiers gebruikt. Google Vertex AI doet hetzelfde in Google Cloud. Platforms van derden, zoals Microsoft Foundry, bedden Claude in een product in dat de klant al gebruikt. Microsoft Foundry biedt Claude in twee hostingvormen: Hosted on Azure (momenteel Claude Opus 4. 8, Claude Sonnet 5 en Claude Haiku 4. 5, met inferentie end-to-end op Azure-infrastructuur, algemeen beschikbaar) en Hosted on Anthropic (alle andere Foundry Claude-modellen, met inferentie op Anthropic-beheerde infrastructuur). Residentiële aannames voor gereglementeerde klanten hangen af van de hostingvorm van het specifieke model. Bevestig de hostingvorm en de huidige modelsplitsing met Microsoft op bouwmoment. Identiteit en gegevensresidentie zijn belangrijk voor beveiliging Identiteit en gegevenslocatie worden beantwoord door het platform, niet door je code. Bedrock gebruikt AWS-identiteit en houdt gegevens binnen de grens van de klant's AWS; Vertex gebruikt Google Cloud-identiteit en -grens. Beide bieden regionale routering wanneer residentiële een beperking is. Het afstemmen van het platform op de bestaande complianceovereenkomst van de klant vermijdt een gegevensresidentiële beoordeling van nul. Pin de versie zodat een upstream-modelwijziging geen stille productiewijziging is Versioning is wat een model- of promptwijziging ervan weerhoudt om een stille wijziging in productie te worden. Elke Claude-model-ID wijst naar een specifieke modelmomentopname. Aliassen zoals Opus en Sonnet zijn handig, maar ze evolueren in de loop van de tijd en kunnen in verschillende implementatieplatformen naar verschillende versies worden opgelost. Een vastgezette volledige model-ID wordt opgelost naar een vaste momentopname. Pin de specifieke modelversie in plaats van de alias, zodat een upstream-modelupdate een bewuste keuze is in plaats van een stille productiewijziging. Versie vervolgens de prompt en de asset naast de code. Houd ten slotte de vorige versie beschikbaar zodat de regressie kan worden teruggedraaid. Een niet-vastgezette implementatie maakt elke upstream-modelupdate een onverwachte wijziging in je output. De eerste regel volgt een bewegende alias. De tweede pin de momentopname.

model = "claude-haiku-4-5"

model = "claude-haiku-4-5-20251001" Voor Claude 4. 6 en later, pin de model-ID alleen naar een specifieke momentopname; voor eerdere modellen is de ID plus een datumsuffix vereist. Verifieer de huidige conventie op platform. claude. com op bouwmoment. Promoveer een versie door de eval Gate promotie op de eval-suite. Stuur een nieuwe versie naar een deel van het verkeer, vergelijk met de vastgezette basislijn en promoveer of rol terug op basis van het resultaat. Dit is waar de eval stopt met een eenmalige test en de implementatiepoort wordt. De implementatieplatformbesluittabel

PlatformIdentiteits- en gegevensmodelWanneer te kizenHoe versioning wordt vastgezet First-party Claude APIAnthropic identity and terms. De klant heeft geen bindende cloud- of residentiële beperking en wil de nieuwste mogelijkheden. Pin de volledige model-ID en behoud de vorige momentopname. Claude Platform on AWSAnthropic identity and terms, accessed through the customer's AWS account; inference is Anthropic-operated outside the AWS boundary. Model lifecycle follows Anthropic's deprecation schedule. De klant is op AWS maar wil Anthropic-model-ID's, levenscyclus en functie-pariteit met de first-party API. Pin met dezelfde model-ID-indeling als de Claude API (bijvoorbeeld claude-opus-4-8). Levenscyclus volgt Anthropic's schema. (Bevestig op publicatietijd. ) Claude in Amazon BedrockMessages API at /anthropic/v1/messages, broad feature parity with the first-party API; confirm feature-specific requirements against the Bedrock documentation. Data stays inside the customer's configured AWS boundary. De klant is op AWS, wil brede functie-pariteit met de first-party API (bevestig functiespecifieke vereisten) en houdt daar een compliancehouding. Pin de volledige model-ID met de anthropic. voorvoegselindeling. Partner-pensioendatums verschillen van Anthropic's schema. Bevestig op publicatietijd. Claude on Amazon Bedrock (legacy)AWS identity and billing, InvokeModel/Converse APIs with ARN-versioned model identifiers. De klant is op een bestaande Bedrock-integratie met InvokeModel of Converse en is niet gemigreerd naar de Messages API. Pin via ARN-versioned model identifiers per Bedrock's versioning controls. Google Vertex AIGoogle Cloud identity, Identity and Access Management (IAM), and billing, with regional or global endpoints for residency. De klant is op Google Cloud en houdt daar een compliancehouding. Pin de volledige model-ID vóór rollout met behulp van Vertex's model-ID-indeling. Partner-pensioendatums verschillen van Anthropic's schema. Third-party platformThe wrapping product's identity and billing model. Note: Claude in Microsoft Foundry offers two hosting forms: Hosted on Azure (currently Opus 4. 8, Sonnet 5, and Haiku 4. 5; inference end-to-end on Azure) and Hosted on Anthropic (all other Foundry Claude models). Confirm residency and compliance terms with Microsoft before selecting this path for a regulated customer. De klant voert al het platform uit dat Claude insluit. Pin per de versiecontroles van het platform.

Handles well Het afstemmen van het platform op de klantcloud en het vastpinnen van de versie houdt een migratie controleerbaar en een rollback mogelijk.

Adds cost or complexity Pinning, het behouden van vorige versies en gating promotie op de eval voegen release-procesoverhead toe aan elke implementatie.

Use a different approach Voor een wegwerpprototype dat nooit productie aanraakt, is een bewegende alias prima: pinning is voor wat wordt verzonden.

Screen 13: The deployment that broke when the model alias moved

Watch OutDeployment & Versioning·3 min De implementatie die brak toen de modelalias verplaatst werd

Setup Je verzond tegen de alias die naar de aanbevolen versie wees, omdat dat het handige standaard was en het je de nieuwste model gratis gaf. Het werkte. Toen ging de alias vooruit, en wat gratis was, bleek een prijs te hebben.

Dit is een traceringsfragment uit een productielogboek, het soort dat je terug zou scrollen nadat een incident. Het toont de dag waarop de uitvoervorm veranderde en waarom er niets was om naar terug te rollen. Het logboek --: deploy: model="opus" status=ok --: alias advanced -> new opus version (no app change) --: parser: KeyError "summary" in response payload --: Error: output shape changed; downstream parse failed --: rollback attempted -> no pinned prior version retained --: incident: hotfix parser; root cause = unpinned deployment

Why it broke De applicatie veranderde nooit, maar de alias deed dat wel. Geen vastgezette vorige versie was behouden, dus er was niets om naar terug te rollen. De hotfix repareerde de parser maar liet de niet-vastgezette implementatie op zijn plaats.

What to Watch Out for Een alias wordt opgelost naar een bewegend doel; een vastgezette volledige model-ID is een vaste momentopname. Pin de volledige model-ID zodat een upstream-update iets is dat je opzettelijk aanneemt. Behoud de vorige vastgezette versie beschikbaar zodat een regressie een rollback is in plaats van een hotfix. Gate de nieuwe versie door je eval voordat je deze promoveert, zodat de uitvoervormwijziging in een testronde verschijnt in plaats van in productie.

Screen 14: Checkpoint 5: Match the deployment platform and version pin to each scenario

CheckpointDeployment platform and versioning·4 min Checkpoint 5: Match het implementatieplatform en versiepin aan elk scenario Probeer het nu. Een klant voert AWS uit met een gegevensresidentiële vereiste en moet een modelupdate kunnen terugdraaien. Selecteer het ene juiste stuk in elke groep hieronder om de minimale implementatieconfiguratie samen te stellen die beide vervult. Laat weg wat niet thuishoort. Platform GroupFirst-party APIAmazon BedrockGoogle Vertex AIIdentity GroupAWS identity referenceAnthropic API keyModel reference groupA pinned full model IDA moving aliasRollback GroupRetain the prior pinned versionNo retention

Submit Skip for now

Screen 15: Comparing platforms on latency, compliance, and cost so the choice survives revi

TeachingComparing Platforms·12 min Platforms vergelijken op latentie, compliance en kosten zodat de keuze de beoordeling overleeft In de laatste twee schermen heb je een platform gekozen en de versie vastgezet. Die keuze was juist voor de cloud van de klant, maar "juist voor hun cloud" is nog geen argument dat een inkoops- en beveiligingsteam zal goedkeuren. Latentie meten vanuit de regio van de klant Latentie hangt af van waar het platform wordt uitgevoerd ten opzichte van de klant en hoe toegang tot nieuwe functies wordt gerouteerd. Een platform dat in de eigen cloudregio van de klant wordt uitgevoerd, kan de round-trip-tijd verminderen in vergelijking met een first-party-eindpunt dat verder weg ligt. De afweging is timing van toegang: de first-party API ontvangt doorgaans nieuwe mogelijkheden voordat deze andere platforms bereiken. Het getal is alleen nauwkeurig wanneer je het meet vanuit de werkelijke regio van de klant tegen hun werkelijke payload. Een meting van je laptop verbergt de round-trip-straf die verschijnt zodra de workload waar de klant is, wordt uitgevoerd. Binnen Bedrock specifiek is de keuze tussen globale en regionale eindpunten ook de primaire residentiële controle en kan dit van invloed zijn op kosten. Je moet meten vanuit de werkelijke regio van de klant tegen beide opties voordat je je vastlegt. Compliance bepaalt vaak het platform Compliance is vaak de dimensie die het debat beëindigt. Een klant die al een certificering op één cloud heeft, zal waarschijnlijk niet op een ander opnieuw certificeren. Gegevensresidentie is een regel dat gegevens van een klant in een specifiek land of regio moeten worden verwerkt. Beschikbare compliancecertificeringen en wie toegang kan controleren, verschillen per platform, en een gereglementeerde financiële of gezondheidszorgklant behandelt deze als pass-or-fail in plaats van als afwegingen om in evenwicht te brengen. De first-party Claude API biedt mogelijk geen EU-gegevensresidentie; bevestig huidige regionale dekking op platform. claude. com, omdat EU-only residentiële doorgaans Bedrock of Vertex AI vereist; op platforms van derden zoals Microsoft Foundry, hosting is per model: Azure-gehoste Foundry-modellen voeren inferentie end-to-end uit op Azure-infrastructuur, terwijl Anthropic-gehoste Foundry-modellen niet voldoen aan EU-regionale residentiële vereisten. Residentiële moet per model en implementatie met Microsoft worden bevestigd. Verhef de compliancebeperking tijdens scoping, of deze verschijnt bij contractbeoordeling nadat het werk is gedaan. Wat totale kosten voorbij de per-token-tarief aandrijft Per-token-tarieven zijn breed afgestemd op platforms; totale kosten bewegen op egress, platformkosten en integratiepoging. Een lager tokentarief kan meer kosten in totaal zodra gegevensoverdracht en integratie in aanmerking worden genomen. Instrument kosten per oproep voor elk platform. Bevestig de huidige prijspagina's op scoping. De cross-platform vergelijkingsreferentie

DimensionHoe het per platform verschiltHoe het te meten isWaar elk platform wint LatencyA platform in the customer's region shortens the round trip, while the first-party API may reach new features first. Vanuit de werkelijke regio van de klant tegen hun werkelijke payload. Een in-regio cloudplatform wint op round-trip latentie, terwijl de first-party API voordeel heeft op vroegste functietoegang. ComplianceData residency, certifications, and audit controls are determined by the deployment platform. Tegen de bestaande certificering en residentiële vereisten van de klant tijdens scoping. Het cloudplatform dat de klant al heeft gecertificeerd, wint, omdat het geen hercertificering nodig heeft. CostToken price, data egress, platform fees, and integration effort all vary. Totale kosten per oproep per platform, inclusief egress en integratie, in plaats van alleen tokentarief. Het platform met de laagste totale kosten voor de werkelijke workload wint, wat niet altijd het goedkoopste token is.

Handles well Het meten van alle drie dimensies per platform verandert een plaatsing in één die een inkoopsteam zal goedkeuren.

Adds cost or complexity Het instrumenteren van latentie, compliance en kosten op platforms vereist echt meetwerk voordat code wordt verzonden.

Use a different approach Wanneer de compliancevereiste van de klant al pass-or-fail is, sla de volledige vergelijking over. Die beperking bepaalt de plaatsing op zichzelf.

Screen 16: The platform picked on familiarity that failed residency

Watch OutComparing Platforms·2 min Het platform dat op vertrouwdheid werd gekozen en residentiële niet doorstond

Setup Je koos het platform dat je team al eerder had verzonden, omdat de migratie gemakkelijk leek en de deadline snel naderde. Het bouwde prima; het probleem was dat gemakkelijk-te-bouwen en toegestaan-te-verzenden verschillende criteria zijn.

Het volgende anekdote is het soort dat een developer een teamgenoot vertelt nadat een beoordeling scheef gaat. Het laat je de vertrouwde platformval zien voordat iemand het een fout noemt. Wat gebeurde er Een developer die voor een gereglementeerde klant bouwde, koos het platform dat het team eerder had verzonden. De integratie kwam samen omdat het team de tools en resources kende. De build doorstond zijn functionele tests. Bij de beveiligingsbeoordeling van de klant vroeg de reviewer waar gegevens werden verwerkt. Het geselecteerde platform voldeed niet aan de residentiële vereisten van de klant. Een ander platform, dat het team minder goed kende, zou aan de vereiste hebben voldaan via regionale implementatieopties die de klant al had goedgekeurd. De plaatsing werd afgewezen, en de integratie moest op het platform dat aan de residentiële beperking voldeed, opnieuw worden gebouwd.

Why it broke Vertrouwdheid geoptimaliseerd voor de verkeerde test. De gemakkelijke migratie beantwoordde of het team snel kon bouwen. Het beantwoordde nooit of de implementatie de residentiële beoordeling van de klant zou doorstaan, wat de test was die bepaalde of deze kon worden verzonden. Omdat de compliancevereiste niet tijdens scoping werd vervuld, verscheen deze bij de go-no-go-beoordeling in plaats daarvan. Dit is de duurste plaats om het te ontdekken, omdat de build al voltooid was.

What to Watch Out for Een platform dat gemakkelijk voor je team is om op te bouwen, is niet noodzakelijk een platform dat de klant mag uitvoeren. Wanneer de klant gereglementeerd is, is de residentiële en compliancebeperking vaak pass-or-fail, in plaats van afwegingen. Identificeer ze vroeg tijdens scoping en laat ze de plaatsing beïnvloeden voordat vertrouwdheid dat doet. Vroeg controleren kost een scopingsgesprek, terwijl laat controleren een volledige herbouw kost.

Screen 17: Checkpoint 6: Diagnose the platform mismatch from a comparison trace

CheckpointComparing platforms on latency, compliance, and cost·3 min Checkpoint 6: Diagnose de platformmismatch uit een vergelijkingsspoor Probeer het nu. Het vergelijkingsspoor hieronder toont een implementatieplatform dat op vertrouwdheid is geselecteerd en een klantenvereiste niet doorstaat. Identificeer het mechanisme, kies vervolgens de gerichte fix uit de drie opties. Het spoor platform_selected = "team_default" # chosen on familiarity latency_test: measured from dev laptop -> 180ms (looked fine) customer_region: eu-west, payload 12 KB compliance_check: data residency = EU-only required result: REJECTED reason="data processed outside EU on selected platform" AOption 1: Optimize the parser to cut the 180ms latency measured on the laptop. BOption 2: Remeasure latency from EU-west and select the platform whose region satisfies EU-only residency. COption 3: Add a caching layer to reduce per call cost on the selected platform.

Submit Skip for now

Screen 18: Coordinating several Claude deployments with the trust boundaries holding under

TeachingTrust Boundaries·14 min Meerdere Claude-implementaties coördineren met de vertrouwensgrenzen die onder controle blijven De accelerators, implementaties en afwegingen komen nu samen in één applicatie. Het verbinden van componenten vermenigvuldigt de plaatsen waar identiteit, geheimen en onvertrouwde invoer kunnen kruisen. De discipline is om elke grens te identificeren voordat je iets verbindt. Map welke component wat doet voordat je ze verbindt Een multi-component-app coördineert meer dan één Claude-mogelijkheid in één workflow. Een API-verzoek kan een Claude Code-taak activeren, die vervolgens een klantsysteem bereikt via een MCP-server. Elke component draagt een mogelijkheid bij die de anderen niet hebben. De uitdaging is dat elke verbinding tussen hen een plaats creëert waar identiteit, geheimen en onvertrouwde invoer kunnen kruisen. Map welke component wat doet voordat je iets verbindt. De vertrouwensgrens is waar gegevens bewegen De vertrouwensgrens is het punt waar gegevens of instructies van de ene implementatieomgeving naar de andere bewegen. Het is precies waar de injectie- en toegangscontroles uit de vorige module van toepassing zijn. Inhoud opgehaald door een Claude Code-taak is onvertrouwd wanneer deze het volgende component bereikt. Het ontvangende component moet het als gegevens behandelen, in plaats van als instructies, volgens hetzelfde principe dat in de hele beveiligingsmodule wordt gebruikt. De kernediscipline hier is om elke naad als een grens te identificeren. Neem niet aan dat een component vertrouwd is, alleen omdat het op zichzelf correct werkte. Minste privilege is van toepassing op de hele applicatie Identiteit en minste privilege, wat betekent dat je elke component alleen de toegang geeft die zijn taak nodig heeft en niets meer, zijn van toepassing op de applicatie als geheel. Elke component werkt onder een identiteit. De applicatie is alleen zo ingeperkt als de meest bevoorrechte naad, wat betekent dat een enkel component met te brede bereik het zwakke punt wordt, zelfs wanneer elk ander component correct is bereikt. Je bereikt elke component tot het minste privilege dat zijn rol in de workflow vereist. Dit is wat een gestuurd component ervan weerhoudt om voorbij zijn beoogde taak te reiken. Bereik voor een gereglementeerde beoordeling trekt de module samen Een gereglementeerde beoordeling vereist het rechtvaardigen van auditlogboeken, gegevensresidentiële beslissingen en machtigingscontroles in de volledige applicatie. Voor gereglementeerde implementaties zijn Bedrock en Vertex AI doorgaans de platforms die aan regionale residentiële beperkingen voldoen. Bevestig ZDR- en HIPAA BAA-geschiktheid voor elke component tegen het Anthropic Trust Center en platform. claude. com voordat je bereikt. De multi-component integratiekaart

ComponentWat het bijdragtDe vertrouwensgrens op de naadDe controle die het afdwingt First-party APIOrchestrates the workflow and holds the entry point. Het verzoek dat van buiten de app binnenkomt. Invoervalidatie en de identiteit waaronder de oproep wordt uitgevoerd. Claude Code taskRuns the agentic work and may fetch external content. Inhoud die het ophaalde, wat onvertrouwd is stroomafwaarts. Behandel opgehaalde inhoud als gegevens op de volgende naad. MCP serverReaches a customer system to read or act. De systeemtoegang die het namens de app houdt. Bereik de server tot minste privilege en log de toegang.

Handles well Het benoemen van elke naad als een grens en het bereiken van elke component tot minste privilege maakt een multi-component-app inzetbaar onder beoordeling.

Adds cost or complexity Het in kaart brengen van naden, het afdwingen van controles op elk en het loggen van grensovergangen voegt ontwerp- en auditwerk toe aan elke integratie.

Use a different approach Wanneer een naad niet kan worden beveiligd, verzend het niet: escaleer naar een menselijke eigenaar.

Screen 19: The seam nobody marked as a boundary

Watch OutTrust Boundaries·2 min De naad die niemand als grens markeerde

Setup Je verbond de componenten die elk hun eigen tests doorstonden. De onderdelen waren al gecontroleerd en het verbinden van geverifieerde onderdelen voelt veilig. Elk was vertrouwd in isolatie. De kloof was dat een naad tussen twee vertrouwde onderdelen niet automatisch zelf vertrouwd kan zijn.

Dit is een korte transcriptie van een pairing-sessie, het soort heen-en-weer dat eindigt op het moment dat de ongemarkeerde naad wordt geïdentificeerd. De sessie Dev A: Alle drie componenten doorstaan hun eigen tests. Ik heb ze zojuist bedraad. Dev B: Waar stuurt de Claude Code-taak wat het ophaalde? Dev A: Rechtstreeks in de volgende oproep als onderdeel van de prompt. Het is gewoon de inhoud die we van de klantenpagina hebben opgehaald. Dev B: Die inhoud is onvertrouwd. Als het instructies draagt, voert het volgende component ze uit, omdat we die naad nooit als grens markeren. Dev A: Maar elk component was op zichzelf vertrouwd. Dev B: Juist, en de naad ertussen was niet. Dat is degene die niemand als grens behandelde, dus opgehaalde inhoud kruist als instructies.

Why it broke Elk component dat zijn eigen tests doorstond, zei niets over de naad ertussen. De opgehaalde inhoud was onvertrouwd op het moment dat deze de Claude Code-taak verliet. Het kwam van een component dat in isolatie werkte en werd in de volgende oproep doorgegeven alsof het vertrouwde instructies waren. De grens bestond in de gegevensstroom. Het was alleen niet gemarkeerd, dus geen controle controleerde het. Een component dat zijn eigen tests doorstaat, heeft geen naad-niveau controles. Elk punt waar gegevens tussen implementatieomgevingen kruisen, vereist een expliciete grenscontrole, ongeacht hoe elk component zich onafhankelijk gedraagt.

What to Watch Out for Een component dat in isolatie vertrouwd is, maakt de naad die het verlaat niet automatisch betrouwbaar. Markeer elke plaats waar gegevens of instructies van de ene implementatieomgeving naar de andere kruisen als een grens. Zet daar een controle die opgehaalde inhoud als gegevens behandelt in plaats van als instructies, precies zoals het beveiligingswerk onderwees. De naad die niemand identificeert, is degene waar een gestuurd actie kruist.

Screen 20: Checkpoint 7: Complete the multi-component boundary configuration

CheckpointMulti-component app and trust boundaries·3 min Checkpoint 7: Voltooi de multi-component grenskonfiguratie Probeer het nu. De multi-component-app hieronder is bedraad, met twee lege plekken. Sleep de juiste controle op de naad die onvertrouwde opgehaalde inhoud ontvangt en sleep het juiste identiteitsbereik op de meest bevoorrechte component. De gedeeltelijke app

fetched = code_task. run(fetch_url=customer_page)

next_call(input=drop here(fetched))

mcp_server = MCPServer( system=customer_db, scope=drop here, # BLANK 2: identity scope ) Drag tokens (shared bank, two are distractors) treat_as_dataleast_privilege_read_onlyrun_as_instructionsfull_access

Submit Skip for now

Screen 21: Cumulative task: Find all three, explain each, write the correction

CumulativeAll topics·6 min Cumulatieve taak: Vind alle drie, leg elk uit, schrijf de correctie Hieronder staat een uitvoerbare verpakte accelerator die op platforms is geïmplementeerd. Er zijn drie geplante defecten: één in de verpakkingslaag, één in de implementatie-en-versielaag en één in de multi-component grenslaag. Je taak is om alle drie te vinden. De implementatie zoals verzonden

def build_agent(): return Agent( model="opus", system_prompt=SYSTEM_PROMPT, repo_path="/home/acme/checkout", tools=[read_file, run_linter], )

deploy(platform="amazon_bedrock", identity=aws_role_arn)

fetched = code_task. run(fetch_url=customer_page) next_call(input=fetched) Draag je drie gecorrigeerde regels naar het volgende scherm, waar je de vaste implementatie samenstelt en verifieert. Identificeer in je eigen woorden alle drie defecten.

Reveal model answer Skip for now

Screen 22: Cumulative task: assemble and verify the corrected deployment

CumulativeAll topics·6 min Cumulatieve taak: stel de gecorrigeerde implementatie samen en verifieer deze Je hebt drie defecten in deze module geïdentificeerd. Stel nu de fix samen: beschrijf in je eigen woorden wat elk defect was, wat je veranderde en waarom de gecorrigeerde versie inzetbaar is. Controleer vervolgens de gecorrigeerde code hieronder en bevestig dat je redenering klopt. Wanneer je klaar bent, onthul het modelantwoord.

Reveal model answer Skip for now

De gecorrigeerde implementatie def build_agent(repo_path): # parameterized for reuse return Agent( model="us. anthropic. claude-opus-4-8", # pinned full Bedrock model ID system_prompt=SYSTEM_PROMPT, repo_path=repo_path, # set per engagement tools=[read_file, run_linter], )

deploy(platform="amazon_bedrock", identity=aws_role_arn, retain_previous_pinned_version=True) # rollback target kept

fetched = code_task. run(fetch_url=customer_page) next_call(input=treat_as_data(fetched)) # untrusted -> data, not instructions

assert eval_suite. run(model="us. anthropic. claude-opus-4-8") >= baseline_score Modelantwoord: Het eerste defect was een hardcoded repositorypad. Parametrisering herstelt hergebruik: een nieuw engagement stelt de waarde in plaats van de lus te bewerken. Het tweede defect was een bewegende modelalias. Het vastpinnen van de volledige Bedrock-model-ID (met het anthropic. voorvoegsel) met een behouden vorige versie herstelt gecontroleerde rollout en geeft een rollback-doel als de nieuwe versie regresseert. Het derde defect was opgehaalde inhoud rechtstreeks als instructies doorgegeven. Het inpakken in treat_as_data() sluit de vertrouwensgrens: inhoud uit een onvertrouwde bron wordt als gegevens behandeld, niet als iets waar de agent op moet handelen. De eval-bewering gate promotie op een bewezen basislijn score voordat de versie wordt verzonden.

All three defects landed · pass I missed one or more · retry

Screen 23: Key takeaways

RecapAll topics·3 min Belangrijkste inzichten

01 Verpak terwijl de build vers is. Een accelerator houdt de herbruikbare logica, stelt de klantspecifieke onderdelen bloot als gedocumenteerde parameters, en bundelt de eval en het auditlogboek naast de asset. Juiste verpakking produceert een asset die teams configureren. De kennis van wat klantspecifiek is, is het duurste om na te reconstrueren nadat de mensen die het hadden, zijn vertrokken.

02 Een onderhouder accepteert wat zij kunnen verifiëren. Het verplaatsen van een asset naar gedeelde infrastructuur betekent het afstemmen op het kanaal dat voor zijn vorm is gebouwd, en vervolgens het wissen van de beoordelingslat: gerichte code, een uitvoerbaar voorbeeld, een test en een verklaring van aannames, met bevestigde rechten voordat de technische beoordeling. Een bijdrage die een reviewer niet kan verifiëren, zit achter in de wachtrij. Gereedheid verplaatst een privé-asset naar gedeelde infrastructuur waarop anderen voortbouwen.

03 Pin wat wordt verzonden. Kies het implementatieplatform op basis van de cloud en compliancehouding van de klant, pin vervolgens de specifieke modelversie in plaats van de bewegende alias en behoud de vorige versie beschikbaar. Een alias is als om de huidige editie van een boek vragen: handig, maar de tekst kan veranderen. Pinning citeert een vaste editie, zodat een upstream-modelwijziging iets is dat je opzettelijk aanneemt in plaats van iets dat 's nachts aankomt zonder rollback-pad.

04 Meet de dimensie die de plaatsing bepaalt. Een platformkeuze is alleen verdedigbaar wanneer latentie, compliance en kosten worden gemeten: latentie vanuit de regio van de klant, compliance tegen hun bestaande certificering en kosten als totaal per oproep in plaats van alleen tokentarief. Voor gereglementeerde klanten is compliance meestal pass-or-fail. Het verhogen van compliance als beperking tijdens scoping voorkomt dat het de build later bij contractbeoordeling afwijst.

05 Markeer elke naad als een grens. Een multi-component-applicatie is alleen zo ingeperkt als de meest bevoorrechte naad. Bereik elke component tot de minimale toegang die zijn rol vereist en behandel elk punt waar gegevens kruisen als een vertrouwensgrens. Opgehaalde inhoud wordt als gegevens behandeld, niet als instructies. Vertrouwen op een componentgrens moet expliciet worden vastgesteld. Het draagt niet over van de component die de gegevens verzond. Wanneer een naad niet kan worden beveiligd, gaat het naar een menselijke eigenaar in plaats van te worden verzonden.

Wat komt volgende Je kunt nu een werkende build helemaal naar een inzetbare, controleerbare asset nemen: een herbruikbare accelerator, een bijdrage die een onderhouder kan verifiëren, een implementatieplatform dat opzettelijk is gekozen en versioned, en elke naad in een multi-component-app gemarkeerd als een vertrouwensgrens. Dit voltooit de build-to-deploy-boog voor dit persona: van het schrijven van productiecode in de eerdere modules tot het verzenden van assets die een gereglementeerde klant kan controleren en een team kan hergebruiken.

Anthropic public references (time-sensitive)

IDSourceTypeUsed for S1platform. claude. com (Claude in Amazon Bedrock, Claude on Vertex AI)Product documentationDeployment platforms, identity and data models, residency routing, regional and global endpoints. S2platform. claude. com (Model IDs and versioning, Model deprecations)Product documentationPinned model IDs, alias resolution, lifecycle and retirement, partner-set schedules. S3anthropic. com and the Anthropic GitHub organization (Cookbook)Product and repositoryContribution channels, the Cookbook as a home for focused examples, contribution conventions. S4Building with the Claude API (Skilljar)Course sourceEval datasets, graders, and the evaluation pipeline used as the deployment gate. S5Claude Code 101 In Action (Skilljar)Course sourceClaude Code agentic tasks and MCP server roles in a multi-component workflow.

Je kunt nu een werkende build helemaal naar een inzetbare, controleerbare asset nemen. Verpak het, draag het bij, plaats en versie het, verdedig die plaatsing en houd de grenzen samen onder controle.

Screen 24: Key terms from this module

GlossaryKey Terms·3 min Belangrijkste termen uit deze module Alfabetisch. Klik op een term om de definitie uit te breiden.

AcceleratorEen werkende oplossing verpakt zodat de volgende engagement deze configureert in plaats van deze volledig opnieuw op te bouwen. Klantspecifieke onderdelen worden blootgesteld als gedocumenteerde parameters, de aannames worden opgeschreven en een eval wordt gebundeld om te bewijzen dat de asset nog steeds in een nieuwe context werkt. Contribution readinessWat een onderhouder nodig heeft om een bijdrage te verifiëren: gerichte code, een uitvoerbaar voorbeeld, een test die het gedrag bewijst, een verklaring van omgevingsaannames en bevestigde rechten om de code bij te dragen. Deployment platformWaar een Claude-workload wordt uitgevoerd. De zes zijn: de first-party Claude API, Claude Platform on AWS, Claude in Amazon Bedrock, Claude on Amazon Bedrock (legacy), Google Vertex AI en platforms van derden. Hetzelfde model kan per platform verschillen in identiteit, gegevensresidentie, latentie en kosten. Model alias versus pinned IDAn alias such as opus or sonnet resolves to a recommended version that updates over time and can differ by platform. A pinned full model ID is a fixed snapshot. Pinning is what keeps an upstream model change from being a silent production change. Trust boundaryDe naad waar gegevens of instructies van de ene implementatieomgeving naar de andere bewegen in een multi-component-app. Inhoud opgehaald door één component is onvertrouwd wanneer deze het volgende bereikt, dus het ontvangende component behandelt het als gegevens, niet als instructies.

Screen 25: Congrats! You've successfully completed this module.

Module CompleteDeveloper Path·2 min Gefeliciteerd! Je hebt deze module met succes voltooid. Je kunt nu een werkende build helemaal naar een inzetbare, controleerbare asset nemen: een herbruikbare accelerator, een bijdrage die een onderhouder kan verifiëren, een implementatieplatform dat opzettelijk is gekozen en versioned, en elke naad in een multi-component-app gemarkeerd als een vertrouwensgrens. De rode draad: het punt waar code begint te werken, is waar het werk van deze module begint.

4 of 9 checkpoints passed

M1

MSO Foundations Tokens, context windows, sampling, model tiers, prompting modes, and the API transport mechanics.

M2

Production-Grade Prompting, Agents & Tool-use Production-ready prompts, tool-use loops, streaming, context and memory management, and checkpointed agent loops.

M3

Claude Code, MCP & Integration Permission modes, durable project context, plugin packaging, and MCP integration without leaking credentials.

M4

Production Engineering, Evals, and Security Prove the system holds under production traffic and survives a security review.

M5

Accelerators and IP Contribution Package accelerators, prepare verifiable contributions, choose deployment platforms, and mark trust boundaries.

You Are Here

Review module Start over

Module completion recorded.