CCA Developer M5: Accelerators, IP & Deployment

1. Discovery — problem identification and feasibility
2. Design — architecture, tool definitions, eval criteria
3. Development — prompt engineering, integration coding
4. Evaluation — golden-set testing, calibration
5. Staging — full integration test in production-like environment
6. Production — phased rollout, monitoring
7. Iteration — ongoing eval runs, prompt updates, model upgrades

5.4 Deployment Platform Comparison

Claude is available on four platforms. The right choice depends on your compliance, residency, and integration requirements.

EU data residency: Use Bedrock (eu-west or eu-central) or Vertex AI (europe-west) regions. The direct Anthropic API processes data in Anthropic's infrastructure, which is US-based.

AWS Bedrock deployment example:

import boto3
import json

bedrock = boto3.client(service_name="bedrock-runtime", region_name="eu-west-1")

body = json.dumps({
    "anthropic_version": "bedrock-2023-05-31",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Summarise this report."}]
})

response = bedrock.invoke_model(
    modelId="anthropic.claude-sonnet-5-v1:0",
    body=body
)

result = json.loads(response["body"].read())
print(result["content"][0]["text"])

Vertex AI deployment example:

import anthropic

client = anthropic.AnthropicVertex(
    project_id="my-gcp-project",
    region="europe-west4"
)

response = client.messages.create(
    model="claude-sonnet-5@20251101",  # Vertex uses @ for version
    max_tokens=1024,
    messages=[{"role": "user", "content": "Analyse this contract."}]
)

5.5 Model Versioning Strategy

The two ID types and when to use each:

The release lifecycle. Anthropic releases new model versions. A "model alias" like claude-sonnet-5 always points to the current recommended release for that tier. When Anthropic releases a new version (e.g., 20260101), the alias updates. If you're using an alias in production, your production behaviour changes when the alias moves.

Production versioning rule:

1. Develop and experiment with the alias (claude-sonnet-5)
2. When ready to ship, run your full eval suite
3. Check the specific version the alias currently resolves to
4. Lock production to that pinned ID (claude-sonnet-5-20251101)
5. When a new version is released, run your eval suite against the new pinned ID
6. Only update production after the eval suite confirms the new version passes

Measuring model performance changes. Before updating a pinned model ID in production, compare:

• Eval pass rate on your golden set (new vs old version)
• Latency at P50, P90, P99 (new models are often faster, not always)
• Cost per request (token counts may change with new versions)

5.6 Latency, Cost, and Compliance Measurement

Key latency metrics:

Cost measurement. Track costs per feature, not just aggregate. This lets you identify which prompts are expensive and optimise selectively:

# After each API call
cost = (
    response.usage.input_tokens * INPUT_COST_PER_TOKEN +
    response.usage.output_tokens * OUTPUT_COST_PER_TOKEN +
    response.usage.cache_read_input_tokens * CACHE_READ_COST_PER_TOKEN
)
metrics.record("api_cost", cost, tags={"feature": "contract_review", "model": model})

Compliance audit logging. For regulated environments, log:

• Timestamp and request ID
• Model ID used (not alias — the resolved version)
• Input token count (not the content, if PHI)
• Output token count
• Tool calls made (names and latencies)
• User or session ID (for audit trails)

Do NOT log raw prompt content in systems that process PHI — log metadata only.

5.7 Trust Boundaries in Multi-Component Systems

A production Claude application typically involves multiple components: an orchestrator, one or more agents, MCP servers, databases, external APIs. Each component boundary is a trust boundary.

Trust boundary rules:

1. Each component authenticates independently. An agent should not pass its credentials to a subagent. Each component has its own credentials scoped to its responsibilities.

2. Outputs from other agents are untrusted. If Agent A receives output from Agent B, treat it as user-supplied data — validate it, don't execute arbitrary instructions from it.

3. MCP server results are untrusted. A tool result returned by an MCP server may contain attacker-controlled content if the tool fetched data from an external source. Apply prompt injection defences when injecting tool results into the model's context.

4. Least privilege per component. Scope each component's permissions to only what it needs:

Orchestrator → reads task queue, writes to result store (no DB access)
Customer-data agent → reads customer DB (no write, no cross-tenant queries)
Email agent → sends email via SMTP relay (no read access to customer data)

Threat model for multi-agent systems:

5.8 Comparing Platforms for Enterprise Decisions

When advising an enterprise on platform choice, evaluate on five dimensions:

The compliance precondition rule. If one option has a confirmed compliance agreement already in place (e.g., an existing AWS BAA confirmed for the target region), that option wins before any other trade-off is considered. Negotiating a new compliance agreement takes weeks to months; using existing coverage is an immediate advantage.

M5 Checkpoint

• Three accelerator formats: agent template, MCP server package, eval suite
• Cookbook entry quality = working code + real use case + choice rationale + eval
• Capability ≠ feasibility — a verdict requires volume/latency/size constraints
• Four deployment platforms: Anthropic API, Bedrock, Vertex AI, Azure AI Foundry — choose based on residency and infra fit
• Alias in dev; pinned ID in prod — every model swap requires full eval re-run
• TTFT = time to first token — primary latency metric for streaming UIs
• Trust boundaries are per-component — each agent authenticates independently; outputs from other agents are untrusted
• Existing compliance coverage beats negotiating new — when in doubt, pick the platform where BAA/ZDR is already confirmed