DEV Community: Aj

AWS Bedrock in 2026: what it actually is and how to build your first AI agent on it

Aj — Sun, 05 Apr 2026 16:47:42 +0000

Most AWS Bedrock content is either marketing copy or academic papers. Neither is useful if you're trying to actually build something.

This is the architecture, the real code patterns, and the things that actually trip people up in production.

What AWS Bedrock actually is

AWS Bedrock is Amazon's managed AI inference platform. It gives you API access to foundation models — Claude, Llama, Titan, Mistral — without managing the infrastructure those models run on.

The reason it's become the foundation of most enterprise AI deployments is simple: it sits inside your existing AWS infrastructure. Your IAM roles, VPCs, CloudWatch, Lambda functions — they all work with Bedrock the same way they work with S3 or DynamoDB.

Four primitives make it powerful beyond raw model access:

Knowledge Bases — managed RAG. Connect an S3 bucket of documents, Bedrock handles embedding, vector storage, and retrieval automatically.
Agents — managed agentic orchestration. Define tools (Lambda functions) the model can call, Bedrock manages conversation history and the agentic loop.
Guardrails — content filtering, PII detection, topic restrictions at the platform level, not in your application code.
Prompt Management — versioned, managed prompts. Test variants, roll back bad changes, maintain consistency across environments.

The core pattern: how a Bedrock agent works

Every Bedrock agent follows the same underlying pattern:

User sends message
    ↓
Model receives message + tool definitions + conversation history
    ↓
Model returns: stopReason = "tool_use" OR "end_turn"
    ↓
If tool_use: execute the Lambda, append result, loop again
If end_turn: return response to user

The model does not execute tools — it requests them. Your code executes them and feeds the result back.

Here is the full implementation:

import boto3
import json

client = boto3.client("bedrock-runtime", region_name="us-east-1")

tools = [
    {
        "toolSpec": {
            "name": "get_s3_file_list",
            "description": "List files in an S3 bucket. Use when the user asks about files or data stored in S3.",
            "inputSchema": {
                "json": {
                    "type": "object",
                    "properties": {
                        "bucket_name": {
                            "type": "string",
                            "description": "The S3 bucket name to list"
                        },
                        "prefix": {
                            "type": "string",
                            "description": "Optional prefix to filter results"
                        }
                    },
                    "required": ["bucket_name"]
                }
            }
        }
    }
]


def execute_tool(tool_name: str, tool_input: dict) -> str:
    if tool_name == "get_s3_file_list":
        s3 = boto3.client("s3")
        response = s3.list_objects_v2(
            Bucket=tool_input["bucket_name"],
            Prefix=tool_input.get("prefix", "")
        )
        files = [obj["Key"] for obj in response.get("Contents", [])]
        return json.dumps({"files": files, "count": len(files)})
    return json.dumps({"error": f"Unknown tool: {tool_name}"})


def run_bedrock_agent(user_message: str) -> str:
    messages = [{"role": "user", "content": [{"text": user_message}]}]
    system = [{"text": "You are an AWS assistant. Use tools to get real data rather than guessing."}]

    for _ in range(10):
        response = client.converse(
            modelId="anthropic.claude-3-sonnet-20240229-v1:0",
            system=system,
            messages=messages,
            toolConfig={"tools": tools}
        )

        stop_reason = response["stopReason"]
        output = response["output"]["message"]
        messages.append(output)

        if stop_reason == "end_turn":
            for block in output["content"]:
                if "text" in block:
                    return block["text"]

        elif stop_reason == "tool_use":
            tool_results = []
            for block in output["content"]:
                if "toolUse" not in block:
                    continue
                tool = block["toolUse"]
                result = execute_tool(tool["name"], tool["input"])
                tool_results.append({
                    "toolResult": {
                        "toolUseId": tool["toolUseId"],
                        "content": [{"text": result}]
                    }
                })
            messages.append({"role": "user", "content": tool_results})

    return "Agent reached iteration limit"


print(run_bedrock_agent("How many files are in my data-lake-prod bucket?"))

stopReason is your only control signal. "tool_use" means keep looping. "end_turn" means stop. Everything else is implementation detail.

What Bedrock adds over raw API access

If you are already calling Claude's API directly, three things matter in production:

IAM-native access control — Use IAM roles instead of API keys. No secrets to rotate, no credential leaks. Your Lambda gets a role, that role gets a Bedrock policy.

Built-in observability — Every Bedrock call shows up in CloudWatch automatically. Latency, token usage, error rates, throttling — zero instrumentation required from you.

VPC isolation — Model calls can run inside your VPC. For healthcare, finance, or regulated workloads this is the difference between a viable architecture and a compliance non-starter.

The three bugs that break Bedrock agents in production

Bug 1 — Checking content type instead of stopReason

# This breaks silently on complex tasks
if response["output"]["message"]["content"][0]["type"] == "text":
    return  # Agent stops before the tool ever runs

# This is correct
if response["stopReason"] == "end_turn":
    return

Claude returns explanatory text alongside tool_use blocks. If you check content type to detect completion, you terminate the loop before the tool executes.

Bug 2 — Missing assistant message before tool results

# Missing a critical step
messages.append(tool_result_message)

# Correct — append assistant response first, then the tool result
messages.append(output)               # The assistant's tool_use request
messages.append(tool_result_message)  # Then the result

Without the assistant message in history, the model cannot connect the tool result back to its own request. You get confused or looping responses.

Bug 3 — Using the iteration cap as your primary stop

The for _ in range(10) is a safety net against runaway loops — not your stopping condition. stopReason is how the model signals it is finished. Cap is a ceiling, not a controller.

What comes next after the basics

Once the core loop works, the natural Bedrock progression is:

Knowledge Bases — connect documents, let the model ground answers in your actual data
Bedrock Guardrails — content filters and PII detection the model cannot be prompted around
Multi-agent coordination — coordinator agent delegating to specialist subagents via tool calls, each with an isolated context window
CloudWatch observability — latency distribution, token cost, tool call frequency, error rates per agent

Getting hands-on

Understanding the architecture is step one. Building intuition for what breaks in production — failed tools, bad tool inputs, sessions that run longer than expected — requires actually running the system.

If you want to work through these patterns in a real AWS Bedrock sandbox — agentic loops, tool sequencing, Guardrails, CloudWatch dashboards — Cloud Edventures has a hands-on track covering exactly this. The CCA-001: Claude Certified Architect track runs in isolated AWS sandboxes with automated validation. No AWS account needed.

👉 cloudedventures.com/labs/track/claude-certified-architect-cca-001

What is the most confusing part of Bedrock for you? Drop a comment — happy to go deeper on any section.

5 tools that turn Claude Code from good to unstoppable (exact install commands)

Aj — Thu, 26 Mar 2026 11:17:03 +0000

Most developers use Claude Code the same way they used Stack Overflow. Ask a question, get an answer, move on.

The developers shipping fastest in 2026 use a specific stack around it. Five tools. Each one fixes a specific failure mode. Here they are with exact install commands.

The three things that break Claude Code

Context rot — Quality drops at ~50% context usage, not at the limit. Most developers don't notice until Claude writes duplicate code it wrote 20 messages ago.

Hallucinated APIs — Training data is 6–12 months behind. Claude confidently suggests functions that were renamed, deprecated, or never existed in your version.

No planning phase — Claude dives into code on your first vague prompt. No spec. No architecture. Three hours later you're rewriting everything.

Each tool below attacks one of these.

Tool 1 — cc-statusline

Fixes: Context rot — you can't manage what you can't see

npx cc-statusline@latest

Adds a status bar to your terminal showing model, context%, session cost, and git branch in real time.

Configure your lines:

Line 1: model | context% | session_cost | session_clock  
Line 2: git_branch | git_worktree

The rule: When context hits 50%, stop and /clear. Don't use /compact — it's lossy compression that keeps context poisoning. /clear reloads your CLAUDE.md and starts completely fresh with zero information loss.

Built-in alternative: type /statusline directly in Claude Code and it generates a script for you.

Tool 2 — Superpowers plugin

Fixes: Vague prompts → vague code. No planning phase.

Stats: 99,000+ GitHub stars. Official Anthropic marketplace.

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

Restart. Skills activate automatically — no manual triggers needed.

The three-step workflow it enforces:

Brainstorm — Claude asks clarifying questions, proposes 2–3 approaches, produces a design doc you approve. Code doesn't start until you sign off.

Write Plan — Breaks your spec into 2–5 minute tasks with exact file paths and complete code. A proper plan is 300–500 lines. Not a vague outline.

Execute Plan — Dispatches subagents, each in their own isolated context window. Main instance only gets small update summaries. Context never bloats.

This is spec-driven development. The biggest tech companies use it. Now you can with two install commands.

Tool 3 — Context7 MCP

Fixes: Hallucinated APIs from stale training data

claude mcp add context7 -- npx -y @upstash/context7-mcp@latest

Or add to ~/.claude/mcp.json:

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp@latest"]
    }
  }
}

How to use: Append "use context7" to any library-related prompt.

Build a Next.js 15 server component that fetches from Supabase. use context7

Context7 fetches current documentation from the official source and injects it before Claude generates code. Claude then uses actual APIs instead of guessing from 12-month-old training data.

Works with React, Next.js, Supabase, Tailwind, Prisma, and thousands of other libraries.

Tool 4 — Warp terminal

Fixes: Claude is a black box — you can't see what it's building while it builds

Free at warp.dev (macOS and Linux)

Three features that matter:

Side panel — Open your file tree alongside Claude. Review generated code as it's written, not after.

Split terminals (Cmd+D) — Run multiple Claude Code instances in parallel. One building, one reviewing, one testing.

Tabs (Ctrl+T) — Multiple projects open simultaneously without losing session state.

Core habit: keep your file tree open in the side panel while Claude executes a plan. Review each file as it's generated. Catch bad decisions before they compound.

Tool 5 — Sequential Thinking MCP

Fixes: Claude jumping to solutions before reasoning through the problem

Tell Claude: "Please install the sequential thinking MCP server"

Claude finds the package, installs it, and configures everything. Restart when done.

Forces chain-of-thought reasoning before Claude produces an answer. Pairs especially well with Superpowers brainstorming — design doc quality improves noticeably.

Use for: architecture decisions, complex debugging, designing systems that will be hard to change later.

Skip for: simple tasks, variable renames, quick fixes. Adds latency and tokens — match it to the complexity.

The full stack in action

1. Open Warp → start Claude Code
2. Status bar shows context% (cc-statusline)
3. Describe the feature
4. Superpowers brainstorm activates automatically
5. Claude reasons through approaches (sequential thinking)
6. Mention a library → Context7 fetches live docs
7. Approve spec → Superpowers writes detailed plan
8. Review plan in Warp side panel
9. Execute → subagents build in isolated context windows
10. Context% stays low (subagents handle heavy lifting)
11. Main context hits 50% → /clear and reload

Production-quality code. No hallucinated APIs. Documented plan you can review and hand off.

Install priority if you have 10 minutes

cc-statusline — visibility first, 2 min
Context7 — eliminates the most common failure mode, 2 min
Superpowers — biggest quality improvement, 3 min
Warp — quality of life, 5 min
Sequential Thinking — just ask Claude, 1 min

For hands-on labs building the agentic patterns these tools enable — coordinator-subagent systems, MCP servers, production Claude/Bedrock architectures — Cloud Edventures CCA-001 track, 22 labs, real AWS sandboxes.

Search: Cloud Edventures CCA-001

Which tool made the biggest difference in your setup? Drop a comment.

Your CLAUDE.md is probably broken — 5 silent failure patterns and how to fix them

Aj — Wed, 25 Mar 2026 18:27:00 +0000

CLAUDE.md is the most important file in your Claude Code setup. It's also the easiest to get silently wrong.

Here's the uncomfortable truth: Claude actively filters what it follows from your CLAUDE.md — it doesn't treat everything as a permanent command. Most production CLAUDE.md files are broken and developers don't know it.

TL;DR

Claude has an instruction budget of ~100–150 slots after its own system prompt
Files over 60 lines cause Claude to silently ignore rules mid-session
"Never do X" rules without alternatives cause Claude to freeze and ask permission
@file embeds burn context on every session — reference instead
CLAUDE.md is advisory (80% compliance) — hooks are deterministic (100%)

The budget problem nobody talks about

Claude Code injects a system reminder above your instructions: "This context may or may not be relevant to your tasks." Claude actively decides which rules to follow per turn.

Frontier models follow roughly 150–200 instructions before compliance drops. Claude Code's own system prompt uses ~50 of those slots. That leaves you about 100–150 slots.

If your CLAUDE.md has 60+ rules, Claude is silently ignoring some. You just don't know which ones.

Failure 1 — The kitchen sink file

# TOO LONG — Claude starts ignoring rules mid-session
- Use TypeScript strict mode
- Prefer functional components  
- Use arrow functions
- Destructure props
- Use const over let
- Avoid any type
- Use interface over type
- Always handle errors
- Use async/await not .then()
- Add JSDoc to public functions
... (30 more rules)

When context fills, Claude weights early rules heavily and discards later ones. The rules you care most about are usually at the bottom.

Fix: Keep it under 60 lines. For each rule ask: "Would removing this cause Claude to make a mistake?" If not, cut it.

Failure 2 — Prohibitions without alternatives

# BAD — Claude freezes every time
- Never use console.log
- Never use var
- Never commit to main

# GOOD — Claude has a path forward
- Never use console.log; use src/utils/logger.ts
- Never use var; use const, or let for reassigned variables
- Never commit to main; create feature/description branch

Every "never" needs an "instead, do this." Without it, Claude pauses and asks permission every time it hits the rule, breaking flow.

Failure 3 — @file embeds killing your context

# BAD — embeds entire files on every session start
@src/utils/api-client.ts
@docs/architecture.md
@docs/design-system.md

# GOOD — reference, don't embed
- For API patterns, see src/utils/api-client.ts
- For architecture decisions, see docs/architecture.md
- For design system, see docs/design-system.md

@file embeds the full file content into every conversation. A 500-line architecture doc loaded every session burns context before you've typed a word.

Failure 4 — Missing bash commands

The most commonly skipped section. The most valuable one.

## Commands
- Build: npm run build
- Test (single file): npm run test -- --testPathPattern=
- Type check: npm run typecheck
- Lint + fix: npm run lint:fix
- Dev: npm run dev

Three things matter here: the single-test command (Claude should never run your full suite for one file), typecheck (Claude should run this after every change), and your deployment scripts (Claude cannot guess them).

Failure 5 — Sprint context in a permanent file

# BAD — this gets forgotten when context rotates
## Current Sprint
- Working on payment flow redesign
- UserCard component is being deprecated
- Don't touch legacy auth module this sprint

CLAUDE.md loads every session. Sprint context belongs in dev-docs/current-sprint.md, loaded explicitly when needed.

CLAUDE.md is for permanent project truth. Current state goes in session-specific files.

What a production CLAUDE.md actually looks like

# Project: [Name]
[One sentence. What it does.]

## Commands
- Build: npm run build
- Test (single): npm run test -- --testPathPattern=
- Type check: npm run typecheck
- Lint: npm run lint:fix
- Dev: npm run dev

## Stack
- TypeScript strict mode
- React 18 hooks only — no class components
- Tailwind — no custom CSS unless unavoidable
- Zustand for state — see src/stores/

## Rules
- ES modules only — never require()
- Always handle errors explicitly — no silent catches
- Never use console.log; use src/utils/logger.ts instead
- No implicit any, no type assertions without explanatory comment

## Architecture
- API calls only through src/queries/ — never direct fetch in components
- Shared utilities in src/utils/
- Colocate tests with components

## What Claude gets wrong here
- Adds index.ts barrel exports — don't, breaks tree shaking
- Forgets typecheck after changes — always run npm run typecheck
- Uses default exports — always use named exports

Notice: no sprint info, no @file embeds, no prohibitions without alternatives, no style rules that don't affect correctness.

The 5-minute diagnostic

The Tinkleberry test
Add one line: Always address me as "Chief." Have a 10+ message session on a real task. If Claude stops using "Chief" mid-session, your file is too long and rules are being lost.

The direct question test
Ask Claude: "What are the rules in CLAUDE.md about error handling?" If Claude can't recite them accurately, they're too buried, too ambiguous, or too many.

The repeated mistake test
If Claude makes the same mistake twice despite a rule against it, that rule needs one of:

Shorter and clearer wording
An "instead, do this" alternative
To be a hook instead of a rule

CLAUDE.md vs hooks — the most important distinction

CLAUDE.md is advisory — Claude follows it ~80% of the time.
Hooks are deterministic — 100% every time.

// .claude/settings.json — things that MUST happen
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npm run lint:fix"
          }
        ]
      }
    ]
  }
}

If something must happen without exception — formatting, linting, security checks — make it a hook. CLAUDE.md is for guidance. Hooks are for guarantees.

The three-layer system

CLAUDE.md  → permanent project rules    (always loads, max 60 lines)
Skills     → domain knowledge           (loads on demand, no session cost)
Hooks      → non-negotiable actions     (deterministic, not advisory)

Most developers only use CLAUDE.md. The developers getting the best results from Claude Code use all three.

For hands-on labs building production CLAUDE.md hierarchies, slash command registries, and CI/CD integration with Claude Code — Cloud Edventures CCA-001 track, 22 labs, real AWS sandboxes.

Search: Cloud Edventures CCA-001

What does Claude keep ignoring in your CLAUDE.md? Drop a comment — I'll diagnose which failure pattern it is.

Why your RAG system fails in production — and the agentic loop fix

Aj — Tue, 24 Mar 2026 17:54:18 +0000

Your RAG demo worked perfectly. Then real users arrived and it started giving confidently wrong answers.

This is the most common production AI failure in 2026. And it's not a chunking problem or an embedding problem. It's an architectural one.

TL;DR

Standard RAG is a one-shot pipeline with no decision point between retrieval and generation
When retrieval is weak, the LLM hallucinates confidently using bad context
Agentic RAG adds a control loop: retrieve → evaluate → retry or proceed
The evaluation step is the entire value add — use a cheap fast model for it
2–4x token cost vs single-pass — worth it when wrong answers have real consequences

What standard RAG actually does

User query
    ↓
Embed → search vector DB → retrieve top-K chunks
    ↓
Inject chunks into LLM context
    ↓
Generate answer
    ↓
Return to user (no checkpoint, no second chance)

Works fine for simple direct questions. Breaks silently on ambiguous, multi-hop, or cross-source queries. The LLM has no way to signal "my context was bad" — it just generates something plausible-sounding and wrong.

The agentic RAG pattern

User query
    ↓
Agent decides which source to query
    ↓
Retrieve chunks
    ↓
┌─── DECISION POINT ──────────────────┐
│  Evaluate: is this sufficient?       │
│  → SUFFICIENT: generate answer       │
│  → RETRY: rewrite query, search again│
│  → ESCALATE: cannot answer reliably  │
└─────────────────────────────────────┘
    ↓
Generate grounded answer with citations

The decision point between retrieval and generation is the entire architectural difference. Something now asks "was this retrieval good enough?" before the LLM generates.

Complete implementation on AWS Bedrock

import boto3
import json

client = boto3.client("bedrock-runtime", region_name="us-east-1")

retrieval_tools = [
    {
        "toolSpec": {
            "name": "search_knowledge_base",
            "description": """Search the primary knowledge base for relevant information.
            Use this first for any factual question.
            Returns chunks with relevance scores.""",
            "inputSchema": {
                "json": {
                    "type": "object",
                    "properties": {
                        "query": {"type": "string"},
                        "max_results": {"type": "integer"}
                    },
                    "required": ["query"]
                }
            }
        }
    },
    {
        "toolSpec": {
            "name": "evaluate_retrieval_quality",
            "description": """Evaluate whether retrieved chunks are sufficient to answer the question.
            Use after every retrieval. Returns SUFFICIENT, RETRY, or ESCALATE.""",
            "inputSchema": {
                "json": {
                    "type": "object",
                    "properties": {
                        "original_query": {"type": "string"},
                        "retrieved_chunks": {"type": "string"}
                    },
                    "required": ["original_query", "retrieved_chunks"]
                }
            }
        }
    }
]

def search_knowledge_base(query: str, max_results: int = 3) -> dict:
    # Replace with your actual vector DB call (Pinecone, pgvector, Bedrock KB)
    return {
        "chunks": [
            {"text": f"Retrieved chunk for: {query}", "score": 0.87},
            {"text": f"Second chunk for: {query}", "score": 0.72}
        ]
    }

def evaluate_retrieval_quality(original_query: str, retrieved_chunks: str) -> dict:
    """
    Use a cheap fast model to evaluate — save expensive model for generation.
    This is the decision point that makes the loop work.
    """
    eval_prompt = f"""Evaluate if the retrieved content is sufficient to answer the question.

Question: {original_query}
Retrieved: {retrieved_chunks}

Respond with exactly: VERDICT|reasoning|suggested_query_if_retry
VERDICT must be: SUFFICIENT, RETRY, or ESCALATE"""

    response = client.converse(
        modelId="anthropic.claude-3-haiku-20240307-v1:0",  # Cheap model for evaluation
        messages=[{"role": "user", "content": [{"text": eval_prompt}]}]
    )
    result = response["output"]["message"]["content"][0]["text"]
    parts = result.split("|")
    return {
        "verdict": parts[0].strip(),
        "reasoning": parts[1].strip() if len(parts) > 1 else "",
        "suggested_query": parts[2].strip() if len(parts) > 2 else ""
    }

def tool_router(tool_name: str, tool_input: dict) -> str:
    if tool_name == "search_knowledge_base":
        return json.dumps(search_knowledge_base(
            tool_input["query"],
            tool_input.get("max_results", 3)
        ))
    elif tool_name == "evaluate_retrieval_quality":
        return json.dumps(evaluate_retrieval_quality(
            tool_input["original_query"],
            tool_input["retrieved_chunks"]
        ))
    return json.dumps({"error": f"Unknown tool: {tool_name}"})

def run_agentic_rag(user_query: str) -> str:
    system = """You are a precise Q&A agent.

Process:
1. Search knowledge base
2. Evaluate retrieval quality — ALWAYS do this before generating
3. RETRY if evaluation says so (max 3 retries)
4. ESCALATE if cannot find sufficient information
5. Generate grounded answer with citations only if SUFFICIENT

Never generate before evaluating. Cite sources in your answer."""

    messages = [{"role": "user", "content": [{"text": user_query}]}]

    for _ in range(8):  # Safety cap
        response = client.converse(
            modelId="anthropic.claude-3-sonnet-20240229-v1:0",
            system=[{"text": system}],
            messages=messages,
            toolConfig={"tools": retrieval_tools}
        )

        stop_reason = response["stopReason"]
        output = response["output"]["message"]
        messages.append(output)

        if stop_reason == "end_turn":
            return output["content"][0]["text"]

        if stop_reason == "tool_use":
            tool_results = []
            for block in output["content"]:
                if "toolUse" not in block:
                    continue
                tool = block["toolUse"]
                result = tool_router(tool["name"], tool["input"])
                tool_results.append({
                    "toolResult": {
                        "toolUseId": tool["toolUseId"],
                        "content": [{"text": result}]
                    }
                })
            messages.append({"role": "user", "content": tool_results})

    return "Max iterations — could not generate reliable answer"

print(run_agentic_rag(
    "How does our refund policy work for enterprise customers upgrading mid-cycle?"
))

Three things that make this work

The evaluation tool is the entire value add

evaluate_retrieval_quality uses Haiku (fast, cheap) to judge relevance before the main model generates. That decision point is where quality improvement comes from. Don't use your expensive model for this step.

Tool descriptions are your routing logic

Write them as instructions: "Use this first for any factual question" — not labels like "knowledge base search". The agent routes entirely based on these descriptions.

The system prompt is your quality contract

"Never generate before evaluating" is the single most important instruction. Without it the agent sometimes skips evaluation and hallucinates from bad context.

When to use each pattern

Pattern	Use when	Token cost
Standard RAG	Simple single-hop Q&A, latency-sensitive	1x
Agentic RAG	Ambiguous queries, multi-hop, quality matters	2–4x

Agentic RAG costs more per query. Worth it when wrong answers have real consequences. Overkill for simple doc lookups.

Production tips

Log every iteration. Which queries needed retries, and why, reveals exactly where your knowledge base has gaps.

Cap at 5–6 iterations. Queries needing more are usually unanswerable from your KB and should escalate instead of burning tokens.

Latency is now a distribution. Some queries resolve in one pass (fast). Some need three (slower). Monitor p95, not average.

For hands-on labs building a full RAG system with Bedrock Knowledge Bases in a real AWS sandbox — Cloud Edventures CCA-001 track, 22 labs, no AWS account needed.

Search: Cloud Edventures CCA-001

Where does your RAG system break down most in production? Drop a comment.

The coordinator-subagent pattern: the foundation every Claude multi-agent system is built on

Aj — Mon, 23 Mar 2026 12:49:43 +0000

Agent Teams landed in Claude Opus 4.6. Everyone's excited. But before you touch experimental features, understand the foundational pattern everything is built on.

TL;DR

Coordinator receives task, delegates to specialists via tool calls
Each subagent gets its own isolated context window and system prompt
Subagents cannot talk to each other — everything routes through coordinator
Same stopReason loop as single-agent, tool calls just dispatch to separate API calls
3–4x token cost vs single agent — only use when specialist quality justifies it

Pattern 1 — Coordinator-subagent (pure API)

The flow looks like this:

User Request
     ↓
Coordinator Agent  ←── stopReason: tool_use
     ↓
  Route to specialist
     ↓
┌──────────────────────────────────┐
│ research_agent │ writer_agent    │  ← Each: isolated context,
│ reviewer_agent │ any_specialist  │    own system prompt, own tools
└──────────────────────────────────┘
     ↓
Tool result back to coordinator
     ↓
stopReason: end_turn → return answer

Here's the full working implementation:

import boto3

client = boto3.client("bedrock-runtime", region_name="us-east-1")

subagent_tools = [
    {
        "toolSpec": {
            "name": "research_agent",
            "description": "Research specialist. Use for finding and analyzing information.",
            "inputSchema": {
                "json": {
                    "type": "object",
                    "properties": {"task": {"type": "string"}},
                    "required": ["task"]
                }
            }
        }
    },
    {
        "toolSpec": {
            "name": "writer_agent",
            "description": "Writing specialist. Always pass research as context.",
            "inputSchema": {
                "json": {
                    "type": "object",
                    "properties": {
                        "task": {"type": "string"},
                        "context": {"type": "string"}
                    },
                    "required": ["task", "context"]
                }
            }
        }
    }
]

def run_subagent(name: str, **kwargs) -> str:
    prompts = {
        "research_agent": "You are a research specialist. Be factual and concise.",
        "writer_agent": "You are a writing specialist. Use only facts from the context provided."
    }
    content = "\n".join(f"{k}: {v}" for k, v in kwargs.items())
    response = client.converse(
        modelId="anthropic.claude-3-sonnet-20240229-v1:0",
        system=[{"text": prompts[name]}],
        messages=[{"role": "user", "content": [{"text": content}]}]
    )
    return response["output"]["message"]["content"][0]["text"]

def run_coordinator(request: str) -> str:
    messages = [{"role": "user", "content": [{"text": request}]}]
    system = [{"text": "Coordinate specialists. Research first, then write."}]

    for _ in range(10):  # Safety cap
        response = client.converse(
            modelId="anthropic.claude-3-sonnet-20240229-v1:0",
            system=system,
            messages=messages,
            toolConfig={"tools": subagent_tools}
        )
        output = response["output"]["message"]
        messages.append(output)

        if response["stopReason"] == "end_turn":
            return output["content"][0]["text"]

        tool_results = []
        for block in output["content"]:
            if "toolUse" not in block:
                continue
            tool = block["toolUse"]
            if tool["name"] == "research_agent":
                result = run_subagent("research_agent", task=tool["input"]["task"])
            elif tool["name"] == "writer_agent":
                result = run_subagent("writer_agent", **tool["input"])
            tool_results.append({
                "toolResult": {
                    "toolUseId": tool["toolUseId"],
                    "content": [{"text": result}]
                }
            })
        messages.append({"role": "user", "content": tool_results})

    return "Safety cap reached"

print(run_coordinator("Write a post about why hands-on labs beat certifications alone"))

Pattern 2 — Claude Code subagents

Claude Code Session
      ↓
Main agent → Task tool → specialist-1  (isolated context)
           → Task tool → specialist-2  (isolated context)
           → Task tool → specialist-3  (isolated context)
      ↓
All report back to main agent only — no sideways talk
      ↓
Main agent synthesizes output

Same one-way reporting as Pattern 1, but running inside Claude Code via the Task tool. Use for local dev workflows — security reviews, test runs, documentation. Stable and production-ready today.

Pattern 3 — Agent Teams (experimental)

Team lead
   ↙         ↓         ↘
Researcher ⟺ Writer ⟺ Reviewer
   ↘         ↓         ↙
Team lead synthesizes

⟺ = direct peer-to-peer communication

The key difference: teammates message each other directly without going through the lead. Requires CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. Known issues with session resumption and shutdown. Keep off production.

Three patterns compared

Pattern	Peer talk	Production	Token cost	Use when
Coordinator-subagent (API)	No	✅ Yes	3–4x	Production API agents
Claude Code subagents	No	✅ Yes	3–4x	Local dev workflows
Agent Teams	Yes	⚠️ Experimental	3–4x+	Peers need mid-task sharing

The critical mistake

Subagents share nothing. If your writer needs the research output, you must pass it explicitly.

# WRONG — writer has zero context
research = run_subagent("research_agent", task="research Lambda limits")
writer = run_subagent("writer_agent", task="write about Lambda")

# RIGHT — explicitly pass context through coordinator
research = run_subagent("research_agent", task="research Lambda limits")
writer = run_subagent("writer_agent", task="write about Lambda", context=research)

Isolation is the feature, not the bug. Design for it explicitly.

What comes next

Retry logic — coordinator decides whether to retry a failed subagent or escalate to a human
Parallel subagents — multiple tool calls in one response run simultaneously, cutting latency
Decision routing — confidence scores from one subagent pick the next specialist

Build it hands-on

For hands-on labs covering the full multi-agent coordinator pattern in real AWS Bedrock sandboxes — Cloud Edventures CCA-001 track, 22 labs, automated validation, no AWS account needed.

👉 cloudedventures.com/labs/track/claude-certified-architect-cca-001

Are you building production API agents or Claude Code workflows? Drop a comment.

Claude's agentic loop explained: stopReason, tool_use, and the pattern behind every AI agent

Aj — Fri, 20 Mar 2026 18:49:16 +0000

If you've tried building an AI agent with Claude and Bedrock, you've hit stopReason. Maybe you ignored it, maybe you cargo-culted the pattern from a tutorial. Either way — here's what's actually happening and why it matters for production systems.

TL;DR

stopReason: "tool_use" → execute the tool, append result, loop again
stopReason: "end_turn" → agent is done, return the response
Always append the assistant message before tool results
Never use text content checks as your stop condition

Why this pattern exists

Claude on Bedrock doesn't magically "know" to use tools. You have to implement the loop that lets it. The model's job is to reason about your task and signal what it needs — your code's job is to listen to that signal and respond correctly.

The signal is stopReason. Everything else follows from there.

The loop, step by step

1. Send message + tool definitions to Claude
2. Read stopReason from response
3a. If "tool_use"  → run the tool → append result → go to step 1
3b. If "end_turn"  → return the final response

That's it. Here's the full working implementation:

import boto3

client = boto3.client("bedrock-runtime", region_name="us-east-1")

# Define your tools
tools = [{
    "toolSpec": {
        "name": "get_order_status",
        "description": "Look up the status of a customer order by order ID",
        "inputSchema": {
            "json": {
                "type": "object",
                "properties": {
                    "order_id": {"type": "string"}
                },
                "required": ["order_id"]
            }
        }
    }
}]

def run_tool(tool_name, tool_input):
    if tool_name == "get_order_status":
        return {"status": "shipped", "eta": "2 days"}
    return {"error": "unknown tool"}

def run_agent(user_message):
    messages = [{"role": "user", "content": [{"text": user_message}]}]

    for _ in range(20):  # Safety cap — not your primary stop mechanism
        response = client.converse(
            modelId="anthropic.claude-3-sonnet-20240229-v1:0",
            messages=messages,
            toolConfig={"tools": tools}
        )

        stop_reason = response["stopReason"]
        output_message = response["output"]["message"]

        # Step 1: Always append Claude's response first
        messages.append(output_message)

        # Step 2: Check stopReason — not content type
        if stop_reason == "end_turn":
            for block in output_message["content"]:
                if "text" in block:
                    return block["text"]

        elif stop_reason == "tool_use":
            tool_results = []
            for block in output_message["content"]:
                if "toolUse" in block:
                    tool = block["toolUse"]
                    result = run_tool(tool["name"], tool["input"])
                    tool_results.append({
                        "toolResult": {
                            "toolUseId": tool["toolUseId"],
                            "content": [{"json": result}]
                        }
                    })

            # Step 3: Append tool results and loop
            messages.append({"role": "user", "content": tool_results})

    return "Safety cap reached"

print(run_agent("What's the status of order ORD-12345?"))

The three bugs that will waste your afternoon

Bug 1 — Missing assistant message append

# What most tutorials show (broken)
messages.append(tool_results_message)

# What you actually need
messages.append(output_message)       # Claude's response FIRST
messages.append(tool_results_message) # Then your tool results

Claude needs to see its own previous response to connect tool results back to the tool call it made. Skip this and you'll get confused responses or infinite loops.

Bug 2 — Content type check as stop condition

# Breaks silently on complex tasks
if response["output"]["message"]["content"][0]["type"] == "text":
    return response  # WRONG

# Correct
if response["stopReason"] == "end_turn":
    return response  # RIGHT

Claude can return {"type": "text", ...} blocks alongside tool_use blocks. A message like "I'll look that up now" followed by a tool call has text in position [0] — your agent terminates before the tool ever runs.

Bug 3 — Iteration cap as primary stop

# This is a safety net, not a strategy
for i in range(10):
    if i == 9:
        break  # Wrong use of cap

Caps prevent runaway agents. They don't signal completion. A task that genuinely needs 12 iterations gets cut off at 10. A task that finishes in 3 wastes 7 loops. The model signals completion via stopReason — listen to it.

Where this goes next

Master the core loop and these patterns become straightforward:

Multi-step tool sequencing — Claude chains multiple tool calls across iterations, reasoning about each result before deciding the next action.

Multi-agent systems — coordinator agents treat subagents as tools. Same tool_use / end_turn cycle, one level up.

Human escalation — on low-confidence results, append a special toolResult that prompts Claude to request human input instead of proceeding.

Error propagation — structured error responses in tool results let Claude decide whether to retry, use a fallback tool, or surface the failure cleanly.

Want to build this in a real AWS Bedrock sandbox?

This is Mission 1 of the CCA-001: Claude Certified Architect track — 22 labs covering agentic loops, MCP servers, multi-agent systems, Bedrock Guardrails, CI/CD with Claude Code, and observability dashboards. Real AWS sandbox, automated validation, no account setup needed.

👉 cloudedventures.com/labs/bedrock-agentic-loop-stopreason

Also join r/ClaudeCertifications on Reddit — building a community for Claude and Bedrock practitioners.

Drop a comment if anything's unclear — what part of the loop trips you up most?

Claude Certified Architect (CCA-001): The First Hands-On AI Certification That Actually Matters

Aj — Thu, 19 Mar 2026 20:19:57 +0000

There's a new certification making waves in the AI engineering space, and it's not from AWS, Google, or Microsoft.

The Claude Certified Architect (CCA-001) is the first certification focused entirely on building production-grade AI systems with Anthropic's Claude — and unlike most AI certifications, it's 100% hands-on. No multiple choice. No memorizing API parameters. You either build working agentic systems or you don't pass.

Here's why that matters, and why AI engineers should pay attention.

The AI Certification Problem

Let's be real: most AI certifications are glorified reading comprehension tests. You memorize which model has which context window, learn the difference between fine-tuning and RAG, and select the right answer from four options.

Then you get to an actual job and realize none of that prepared you to build a multi-agent system that handles failures gracefully, or to design tool-calling patterns that don't hallucinate, or to implement guardrails that actually work in production.

The gap between "I know what agentic AI is" and "I can build reliable agentic AI systems" is enormous. That's the gap CCA-001 is designed to close.

What CCA-001 Actually Covers

The certification spans 5 domains, 22 hands-on missions, and roughly 40 hours of work in real AWS Bedrock sandbox environments. Here's what you're building:

Domain 1: Agentic Architecture

This isn't theory. You're designing and deploying complete agentic systems — agents that can reason, use tools, and maintain context across complex multi-step tasks. You learn how to structure CLAUDE.md hierarchies, build plan-execute pipelines, and handle the messy reality of agents that don't always do what you expect.

Domain 2: Tool Design & Integration

Every useful AI agent needs tools. You'll build custom tool schemas, implement function calling patterns, and learn why most tool designs fail in production (hint: it's usually the schema descriptions, not the code).

Domain 3: Prompt Engineering at Scale

Not "write a better prompt" basics. This covers system prompt architecture for complex applications, dynamic prompt composition, and the engineering patterns that make prompts maintainable across a team — not just one developer's magic strings.

Domain 4: Reliability & Guardrails

The domain that separates demo projects from production systems. You'll implement retry strategies, circuit breakers, output validation, content filtering, and the observability patterns you need to trust an AI system with real users.

Domain 5: Multi-Agent Systems

The most advanced domain. Building systems where multiple AI agents coordinate, share context, handle handoffs, and recover from failures. This is where most teams struggle, and it's where the certification gets genuinely hard.

Why Employers Care About This

Three trends are converging that make CCA-001 uniquely valuable right now:

1. Claude is dominating the enterprise AI stack. Anthropic's models are increasingly the default choice for companies building AI applications. AWS Bedrock makes Claude accessible at enterprise scale, and companies need engineers who know how to build with it.

2. "AI Engineer" is the fastest-growing role. Every job board shows it — companies are hiring specifically for people who can build AI-powered applications, not just data scientists who train models. CCA-001 maps directly to what these roles require.

3. Agentic AI is the current frontier. The shift from simple chatbots to autonomous agents that can reason, use tools, and complete complex tasks is happening now. Most engineers are still figuring out the basics. A certification that proves you can build reliable agentic systems is a genuine differentiator.

The Hands-On Difference

Here's what makes CCA-001 fundamentally different from other certifications:

Every mission runs in a real AWS Bedrock sandbox. You're not answering questions about Bedrock — you're deploying actual agents, calling real Claude APIs, and building infrastructure that gets automatically validated.

Automated validation checks your work. You can't fake it. The system verifies that your agent actually works, your tools return correct responses, your guardrails catch what they should, and your multi-agent system handles failures properly.

You build a verified portfolio. Every completed mission becomes a portfolio piece with proof of completion. When you tell an interviewer "I built a multi-agent system with tool calling and guardrails," you can show them the verified project, not just talk about it.

Who Should Get Certified

CCA-001 makes the most sense if you're:

A backend or full-stack engineer adding AI capabilities to your skill set
A cloud engineer who wants to specialize in AI infrastructure
An AI/ML engineer who works with LLMs and wants formal proof of agentic architecture skills
A solutions architect designing AI systems for enterprise clients
A career changer targeting the AI engineering role specifically

If you're still learning basic cloud concepts, get comfortable with AWS first (the Cloud Explorer and Automation Captain paths are good starting points), then come back to CCA-001.

How to Prepare

The certification is designed to be self-contained — each mission builds on the previous one. But you'll get more out of it if you have:

Basic AWS experience (Lambda, API Gateway, IAM)
Familiarity with at least one programming language (Python recommended)
General understanding of what LLMs are and how they work

You don't need prior experience with Claude specifically or with building AI agents. The certification teaches those skills through the missions.

The 22-Mission Path

The missions follow a progressive structure:

Navigator's Compass (4 missions) — Start with CLAUDE.md configuration, slash commands, plan-execute pipelines, and CI/CD integration for AI systems.

Then you work through each domain with increasingly complex projects, culminating in multi-agent orchestration systems that mirror what companies are actually building in production.

Each mission takes between 60-120 minutes, and you're working in isolated Bedrock sandboxes the entire time. No risk of runaway API costs, no configuration headaches — just building.

The Bottom Line

The AI job market in 2026 is flooded with people who "know about" AI. What's scarce is engineers who can prove they've built reliable, production-grade AI systems.

CCA-001 is the first certification I've seen that actually tests this. It's not easy — 40 hours of hands-on work is a real commitment. But that difficulty is exactly what makes it valuable. A certification that's hard to get is a certification worth having.

If you're serious about AI engineering, this is worth your time.

I built Cloud Edventures specifically to provide hands-on sandbox environments for certifications like this. The CCA-001 path gives you all 22 missions with real Bedrock sandboxes and automated validation. You can start the Claude Architect path here.

Already working on AI certifications? What's your experience been? I'd love to hear in the comments.

I Passed the AWS Certification. Here's Why I Still Couldn't Get Hired.

Aj — Sun, 15 Mar 2026 19:22:13 +0000

You passed the AWS Solutions Architect exam. You updated your LinkedIn. You started applying.

Silence.

If that sounds familiar, you're not alone. I've talked to dozens of cloud job seekers who hit this exact wall, and after digging into what hiring managers at companies like Stripe, Datadog, and mid-size startups actually screen for, the pattern is clear.

Certifications prove you studied. Projects prove you can build.

The Certification Trap

Here's the uncomfortable truth: over 1 million AWS certifications were earned in the last two years alone. When every candidate has one, it stops being a differentiator and becomes table stakes.

I'm not saying certs are useless. They're a solid foundation. But think about it from the hiring manager's perspective — they see 200 resumes, 180 of them have "AWS Certified Solutions Architect" listed. What makes you different?

Nothing. Unless you can show what you've actually built.

What Hiring Managers Actually Screen For

After researching job postings, talking to engineering leads, and analyzing what gets people past the resume screen, here are the three things that matter most:

1. Evidence You've Solved Real Problems

Not "completed a lab" — actually made architectural decisions, handled failures, and dealt with trade-offs.

A hiring manager at a Series B startup told me: "I'd rather see someone who deployed a messy but working application on ECS and had to debug networking issues than someone who scored 900 on the SAA exam."

The key is showing the thinking, not just the result. Why did you choose Fargate over Lambda? What broke and how did you fix it? What would you do differently?

2. A Portfolio That's More Than a GitHub Graveyard

Most cloud portfolios are either empty or full of abandoned tutorial repos. What stands out:

Architecture diagrams that show you understand how services connect
Cost analysis proving you thought about real-world budget constraints
Documentation that reads like you'd actually hand it to a teammate
Working endpoints they can actually hit and test

One candidate I know landed three interviews in a week after adding a single project to their portfolio: a fault-tolerant data pipeline on AWS that included a cost breakdown showing it ran for under $5/month. That cost detail alone showed more business awareness than any certification.

3. Proof You Can Debug Under Pressure

Every cloud job involves 3am incidents and mysterious 502 errors. Hiring managers want to see that you've been in the trenches.

This is where hands-on experience in real AWS environments is irreplaceable. When you've actually seen a Lambda function timeout because of a VPC cold start, or watched your ECS tasks fail because of a misconfigured security group, you develop an intuition that no exam can test.

The Winning Combination: Cert + Portfolio

The ideal candidate in 2026 has both:

Certification = "This person understands AWS concepts and terminology"

Portfolio of real projects = "This person can actually build and ship"

Together, they tell a complete story. The cert gets you past the ATS keyword filter. The portfolio gets you past the hiring manager.

How to Build Projects That Actually Impress

Here's a practical framework:

Pick Problems, Not Technologies

Don't build "an S3 bucket with lifecycle policies." Instead, build "a cost-optimized media storage system that automatically moves files to cheaper storage tiers based on access patterns."

Same AWS services. Completely different story.

Include the Messy Parts

Document what went wrong. The best portfolio projects I've seen include sections like:

"First attempt: I tried using API Gateway + Lambda but hit the 29-second timeout on large file uploads"
"Pivot: Moved to a pre-signed S3 URL approach, which reduced upload time by 80%"
"Lesson learned: Always check service quotas before architecting"

This is gold to hiring managers. It proves you've actually done the work.

Make It Verifiable

Anyone can write "Built a serverless API on AWS" on their resume. What if there was a way to prove it — with automated validation that your infrastructure actually works, your endpoints return correct responses, and your architecture follows best practices?

That's exactly the gap I've been trying to solve. We built Cloud Edventures — a platform where you complete guided missions in real AWS sandbox environments, and every project you build gets automatically validated and added to a verified portfolio you can share with employers.

It's not the only way to build a portfolio, but it solves the "trust" problem. When a hiring manager sees a verified badge on your project, they know it's not just a README with no working code behind it.

The 30-Day Action Plan

If you're certified but not getting interviews, here's what to do this month:

Week 1: Pick one real-world problem to solve on AWS. Not a tutorial — an actual problem. "Build a notification system that alerts when AWS spending exceeds a threshold" is a good one.

Week 2: Build it. Use real AWS services, not LocalStack. Document your architecture decisions and trade-offs as you go.

Week 3: Break it on purpose. Simulate failures. What happens when your Lambda hits concurrency limits? When your DynamoDB table gets throttled? Document the debugging process.

Week 4: Package it. Create an architecture diagram, write a clear README, include cost analysis, and make it publicly accessible. Add it to your resume and LinkedIn.

One project, done right, is worth more than three certifications.

The Bottom Line

AWS certifications are a starting point, not a finish line. In 2026, the cloud job market rewards people who can demonstrate real skills with real evidence.

If you're sitting on a certification wondering why the interviews aren't coming, the answer isn't another exam. It's building something real, documenting the journey, and making it easy for hiring managers to see what you can do.

Your cert proves you know the theory. Now prove you can do the work.

What's your experience? Did certifications alone help you land a cloud role, or did you need projects to back them up? Drop your thoughts in the comments.

If you want to start building a verified AWS portfolio, check out Cloud Edventures — guided missions, real sandboxes, and portfolio proof that hiring managers actually trust.