CCA Developer · M5 — Accelerators, IP & Deployment

5.1 What Is an Accelerator?

An accelerator is a packaged, reusable Claude integration pattern that another developer can adopt without starting from scratch. It is not a one-off script — it is a shareable artifact with documentation, clear inputs/outputs, and a demonstrated use case.

Three standard accelerator formats:

A high-quality accelerator includes at least: a working example, the system prompt(s), the tool definitions, a README explaining the use case and constraints, and an eval suite validating the key behaviours.

5.2 Contributing to the Anthropic Cookbook

The Anthropic Cookbook is a public repository of Claude integration patterns. Contributing makes your accelerator discoverable by the entire Claude developer community.

What makes a high-quality Cookbook entry:

1. Working code. The example must execute correctly. Include a requirements.txt or package.json and instructions for running it.
2. Real use case. The example should demonstrate a genuine problem being solved, not a toy scenario. Real constraints (error handling, token limits, streaming) make the example useful.
3. Clear explanation of choices. Why this model? Why this prompting technique? Why this tool structure? The explanation is what turns an example into a learning resource.
4. Eval included. A set of test cases that validate the key behaviour. This lets adopters confirm the pattern works in their environment.

Rights and attribution. Code contributed to the Anthropic Cookbook is typically licensed under MIT. Make sure any dependencies you use are compatible. Keep API keys out of the committed code — use environment variables and document the required keys in the README.

Channel matching. Before contributing, check whether the pattern already exists in the Cookbook. A duplicate entry fragments the community's attention. If a similar pattern exists but yours covers a specific gap (different model, different language, different use case), make that difference explicit in the title and README.

5.3 Requirements Capture

Building a production Claude integration requires gathering two categories of requirements before writing any code.

Functional requirements: What the system must do.

• What is the user's task? What does success look like?
• What are the inputs (format, size, source)?
• What are the outputs (format, destination)?
• What tools does the agent need access to?
• What human escalation conditions exist?

Infrastructure requirements: What constraints the system must satisfy.

• Latency: What is the acceptable time-to-first-token? End-to-end response time?
• Cost: What is the per-request or per-month budget?
• Data residency: Can data leave a specific region? GDPR/HIPAA constraints?
• Compliance: Are there audit log requirements? Data retention limits?
• Scale: How many concurrent requests? Peak volume?

Systems lifecycle phases. A Claude integration moves through seven phases:

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