💡 Getting Started with Claude on Amazon Bedrock — The Enterprise Setup Path

Amazon Bedrock is the managed AWS service for accessing Claude without operating model infrastructure yourself. For enterprise teams already inside AWS, Bedrock is usually the right deployment path: it handles authentication through IAM, keeps your data inside your AWS account boundary, and satisfies the security and compliance posture most enterprise procurement teams require. Here is what the setup path looks like in practice.

Step-by-step setup

• 1. Enable Bedrock in your AWS account: Navigate to Amazon Bedrock in the AWS console and request access to the Claude model family. Model access is granted per-region; enable it in every region you intend to deploy from. Cross-region inference profiles are available for latency and failover management.
• 2. Create an IAM role with Bedrock permissions: Attach the AmazonBedrockFullAccess policy for development, or scope it down to bedrock:InvokeModel and specific model ARNs for production. Avoid embedding API keys — use IAM roles attached to your EC2 instances, Lambda functions, or ECS tasks.
• 3. Choose the right Claude model: Claude Sonnet 4.5 is the best default for most production workloads — it balances speed, capability, and cost. Use Claude Opus 4.5 for tasks that require deep reasoning over complex documents. Use Claude Haiku 4.5 for high-throughput, cost-sensitive tasks like classification or short-form generation.
• 4. Use the Converse API for multi-turn: The Bedrock converse API normalises the request/response format across model families and supports streaming out of the box — prefer it over the raw invoke_model endpoint for new workloads.
• 5. Enable guardrails: Bedrock Guardrails let you apply content filtering, PII detection, and topic blocking as a managed layer independent of your system prompt. This separation of concerns makes the safety layer auditable and independent of the application code.

# Minimal Python example using boto3
import boto3, json

client = boto3.client("bedrock-runtime", region_name="us-east-1")
response = client.converse(
    modelId="anthropic.claude-sonnet-4-5-20251001",
    messages=[{"role": "user", "content": [{"text": "Summarise this contract in three bullet points."}]}],
    system=[{"text": "You are a legal document analyst. Be concise and accurate."}],
)
print(response["output"]["message"]["content"][0]["text"])

💡 Multi-Agent Orchestration — Parallel Execution, Agent Skills, and Checkpoint Systems

The most capable Claude deployments shown at AWS re:Invent 2025 were not single-model pipelines but multi-agent architectures where a coordinating Claude instance delegates sub-tasks to specialised agents. Anthropic's Agent Skills framework, available through the Claude API, provides the scaffolding for these workflows. Here are the key patterns that separate reliable multi-agent systems from brittle demos.

Core orchestration patterns

• Parallel tool execution: When Claude calls multiple tools in a single response, those calls can be parallelised on the infrastructure side. Structure tool calls so independent lookups (e.g., fetching user data and fetching product catalogue) happen simultaneously rather than sequentially.
• Specialised sub-agents: Rather than asking one Claude instance to be an expert at everything, route sub-tasks to agents with tightly scoped system prompts. A code-writing agent, a documentation agent, and a test-writing agent can each be tuned for their specific output type.
• Checkpoint systems for long-running tasks: Agentic tasks that run for minutes or hours need intermediate state persistence. Save progress to S3 or DynamoDB at logical breakpoints; if a step fails, resume from the checkpoint rather than restarting from scratch.
• Human-in-the-loop escalation: Define explicit conditions under which the agent should pause and request human review — particularly for irreversible actions like sending emails, modifying production data, or executing financial transactions. Claude's ask_human tool pattern is the standard hook for this.
• Subagent result validation: Before passing a subagent's output to the next stage, have the orchestrator run a brief validation prompt. A single "does this JSON conform to the expected schema and is it plausible?" check catches a high fraction of downstream failures cheaply.