DEV Community: Martín Rivadavia

Loop Engineering on AWS: Stop Writing Prompts, Design the System That Writes Them

Martín Rivadavia — Tue, 21 Jul 2026 19:00:05 +0000

Stop being the person who writes prompts. Become the person who designs the system that writes them for you.

That's the whole idea behind a phrase Addy Osmani (engineering lead on Chrome DevTools at Google) dropped on LinkedIn on June 9, 2026. He called it loop engineering, and the post landed with 1,277 likes and 124 comments. His definition is short enough to memorize:

"Loop engineering: replacing yourself as the person who prompts the agent. You design the system that does it instead. A loop is a recursive objective where AI iterates until complete."

Osmani didn't invent the practice. The best teams were already doing it. He named it, and naming is what turns a scattered practice into shared vocabulary. Once someone with his credibility gives it a word, the industry starts using that word to argue about architecture.

I build agent loops every day in my own tooling. Not a demo, not a weekend toy. A running system of scheduled tasks, skills, sub-agents, and memory that runs discovery and drafting on a cron tick, then hands me decisions instead of asking me to type. So when Osmani listed the pieces of a loop, I recognized every one of them. What his post doesn't give you is the part I care about most: where does each piece actually live when you run it on AWS?

That's the gap this article fills. Every component, a concrete service, one minimal loop you can trace end to end. And a warning at the end that I think matters more than any of the wiring.

The components, and why the timing is not an accident

Osmani lists five components: automations, worktrees, skills, plugins (MCP), and sub-agents, plus memory as what he calls the sixth thing, state that lives outside the single conversation. Read that list as an architecture. Each part answers a different question. What triggers the work. Where the work runs in isolation. What the agent knows. How it reaches tools. Who does the specialized labor. And what it remembers between runs.

The reason this is worth writing now is that the AWS side matured on almost the same calendar as Osmani's post. AWS MCP Server hit GA in May 2026. AgentCore Policy went GA in March, AgentCore Evaluations the same month, and the AgentCore harness reached GA in June 2026, per the AgentCore release notes. Two threads, the mental model and the infrastructure, arrived at the same knot in the same month.

Here is the map I keep coming back to.

Osmani's six loop components on the left, the AWS service each one lives on when you run it in production on the right.

Component (Osmani)	What it does	AWS service	Key config
Automations	Scheduled discovery. The loop fires itself, no human prompt.	EventBridge (scheduled rules + event bus) → Lambda	Cron expression or event pattern; Lambda as dispatcher
Worktrees	Isolated branch per agent so parallel runs don't collide	AgentCore Runtime (microVM per session)	Each session gets its own `/mnt/workspace`; git stays the coordination layer
Skills	Reusable project knowledge the agent loads into context	Bedrock Knowledge Bases (Smart Parsing)	Pre-computed chunking + embeddings; structured S3 too
Plugins / MCP	Standard connection to external tools	AWS MCP Server (GA May 2026)	The new default; replaced custom integrations
Sub-agents	Specialists orchestrated by a coordinator	AgentCore harness (GA June 2026)	Orchestrator harness routing to specialist agents
Memory files	State that survives between sessions	S3 (long-term) + DynamoDB (short-term)	S3 for context files; DynamoDB for fast state

Sources: Addy Osmani, LinkedIn (June 9, 2026); AWS MCP Servers announcement; Amazon Bedrock AgentCore.

Let me walk each row, because a table hides the interesting decisions.

Automations: the loop has to fire itself

This is the line that separates a loop from a chatbot. If a human still has to type "go," it's not a loop. It's a prompt with extra steps.

On AWS, the trigger is EventBridge. A scheduled rule handles the "run discovery every morning" case with a cron expression. An event bus handles the "react when something lands in this bucket" case with an event pattern. Either way, EventBridge doesn't run your logic. It wakes up a Lambda function, and that Lambda is your dispatcher, the thing that decides what the loop should do this cycle and calls the orchestrator.

# Lambda dispatcher — invoked by an EventBridge scheduled rule.
# Job: decide what this cycle's objective is, then hand it to the orchestrator.
# IAM: this function's role needs bedrock-agentcore:InvokeAgentRuntime on the runtime ARN.
import json
import boto3

agentcore = boto3.client("bedrock-agentcore")

def handler(event, context):
    # EventBridge gives us the trigger; we set the recursive objective.
    objective = build_objective_from(event)   # cron tick or event payload
    response = agentcore.invoke_agent_runtime(
        agentRuntimeArn="ORCH_RUNTIME_ARN",
        runtimeSessionId=session_for(event),   # ties back to memory, see below
        payload=json.dumps({"prompt": objective}),
    )
    return {"status": "dispatched", "objective": objective}

Why put a Lambda between EventBridge and Bedrock at all? Because the dispatcher is where you set the objective and, later, where you'll bolt on a circuit breaker. That thin layer is cheap insurance. I'll come back to why I never skip it.

Worktrees: isolation so parallel agents don't step on each other

Osmani's "worktrees" borrows from git: each agent gets its own branch so two agents editing the same tree don't corrupt each other's state. When agents run in parallel, shared mutable state is how you get a mess that's impossible to debug.

The AWS translation is isolation per agent session: AgentCore Runtime runs each session in its own microVM. Each run gets a clean, isolated environment and tears down after.

I flagged this row as a seam in an early draft, and running it to ground made the map better. Osmani's worktrees are literally git worktrees inside a running coding agent, and AWS doesn't reproduce them. It replaces them. Each AgentCore session gets its own microVM with its own /mnt/workspace, so the isolation that git worktrees fake at the directory level happens at the machine level, with git left in place as the coordination layer. AWS's own write-up on hosting coding agents is explicit: no worktree management needed, because the filesystem itself is per-session. Treat this row as "isolation, upgraded," not "git worktrees, reproduced."

Skills: what the agent knows before it starts

Skills are reusable project knowledge the agent pulls into context, so it doesn't relearn your conventions every cycle. On AWS that's Bedrock Knowledge Bases with Smart Parsing: you pre-compute chunking and embeddings, and the agent retrieves against them at run time. For flatter, more structured knowledge, a well-organized S3 layout does the job without the retrieval overhead.

The decision I'd surface here is when Knowledge Bases earns its cost. Retrieval isn't free, and for a small, stable skill set, structured S3 files the agent reads directly can beat a vector round-trip. I default to S3 for anything the agent needs every single run, and reserve Knowledge Bases for the large, changing corpus where retrieval actually saves tokens.

Plugins and MCP: the part that quietly became the standard

This is the row that changed the most in 2026. The Model Context Protocol went from "interesting" to the default way agents reach tools. The production-stack write-up from @codewithbrij (Instagram, ~May 2026, 649 likes) put it bluntly: MCP replaced custom integrations, and the whole stack stopped growing taller and instead thinned out in the middle and thickened at the edges. Fewer bespoke connectors, more standard ones.

AWS MCP Server reaching GA in May 2026 is what makes this real on AWS, and per Prasad Rao (AWS Principal SA, LinkedIn, May 2026) it's pay-as-you-go with no extra charge for the server itself, which AWS's GA announcement confirms: you pay only for the resources your agents use. Practically, MCP is how your orchestrator calls out to external tools without you writing and maintaining glue code for each one.

Sub-agents: specialists with a coordinator

A single agent doing everything is a single agent doing everything badly. Osmani's loop uses sub-agents: specialists, each good at one thing, orchestrated by a coordinator.

On AWS this now lives in one place: the AgentCore harness, GA since June 2026, holds an orchestrator and its specialists together in production. (If you were about to reach for Bedrock Agents for this row, don't. That service is now Bedrock Agents Classic and closes to new customers on July 30, 2026; AWS points migrations at AgentCore.) And "in production" comes with numbers you should know before you design: AgentCore's June 2026 quotas are 200 TPS per agent and 5,000 active sessions per account in us-east-1 and us-west-2, 2,500 in other Regions (AgentCore release notes). Agents hold sessions, sometimes for a long time, so the session ceiling is the one I'd model first. It's easy to blow past 5,000 concurrent sessions with a fleet of long-lived loops and never touch the TPS limit.

This is also where Osmani's other framing clicks into place. A month before the LinkedIn post, he wrote on O'Reilly Radar about "agent harness engineering," and the line worth taping to your monitor is: "A decent model with an excellent harness outperforms an excellent model with a poor harness." The harness and the loop are the same idea named for two audiences. The AgentCore harness is AWS's answer to exactly that sentence.

Memory files: state that outlives the session

The last component is memory: what the agent carries across runs so cycle two knows what cycle one did. The seed splits this cleanly, and I agree with the split. S3 for long-term context, the files and artifacts the agent should still see next week. DynamoDB for short-term, fast state: the session pointer, the last checkpoint, the "where was I" record that every dispatch reads and writes.

That session ID in the dispatcher code above is the thread. It ties EventBridge's trigger to DynamoDB's state to S3's context, and it's how a set of independent Lambda invocations becomes one continuous loop instead of six strangers.

The minimal viable loop, wired end to end

Put the six together and you get a loop small enough to draw and real enough to run.

EventBridge rule (cron / event)
  -> Lambda (dispatcher, sets objective + circuit breaker)
    -> AgentCore harness (orchestrator)
        |- MCP Server (external tools)
        |- Knowledge Base (context / skills)
        |- Sub-agents (specialists)
  -> S3 / DynamoDB (memory files)
  -> CloudWatch (loop observability)

The permission chain is short. EventBridge needs invoke on the Lambda, and the Lambda's role needs bedrock-agentcore:InvokeAgentRuntime on the orchestrator's runtime ARN (invoke docs). That's the whole chain.

Notice observability is on the diagram, not a footnote. The @codewithbrij write-up made the point that stuck with me: in 2026 you don't bolt observability on at day 100. It runs vertically through the whole thing from day 1, as a rail. On AWS that rail is X-Ray for distributed traces across the full loop (trigger to agent to tool to response), CloudWatch for latency and token metrics, and CloudTrail for the audit log of what the agent decided. If you're doing this for an enterprise, CloudTrail is the row compliance will ask about first.

Which brings up the reason a serious team picks Bedrock at all. Per Prasad Rao, running Claude Code over Bedrock rather than straight against the model adds IAM-based access control, data residency inside your VPC and region, CloudTrail audit on every model call, and unified billing that lands in your existing AWS budget instead of a separate card. None of that is glamorous. All of it is what stands between a demo and something legal will let you ship.

The warning, which is the actual point

Here's where I part ways with most of the "build agents" content. The wiring is the easy part. The hard part is not surrendering your own judgment to a system you built specifically to act without you.

Osmani names three risks, and each one has an AWS-shaped answer, but the answers are guardrails, not cures. Verification stays a human job; the loop does not check itself. AWS gives you AgentCore Evaluations (13 built-in evaluators plus Ground Truth) and you can drop a checkpoint Lambda before any final output, but a human still reads the checkpoint. Comprehension debt piles up faster when the loop is automated, because you stop watching the steps; X-Ray traces and a CloudWatch decision dashboard exist so you can watch, not so you don't have to. And the deepest one, what he calls cognitive surrender, accepting outputs passively because the system sounds confident: AgentCore Policy plus Guardrails and a Step Functions human-approval step before anything irreversible are the technical brakes. The judgment behind them is still yours.

I feel this one personally, because I run these loops daily. The temptation is real. When the system has been right forty times, you stop reading the forty-first output. That's the moment the engineering fails, and no service on the diagram catches it. Osmani says it better than I can, so I'll give him the close:

"Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go."

What I'd tell you to do next

Start smaller than the diagram. One EventBridge rule, one Lambda dispatcher, one AgentCore agent, and DynamoDB for state. Skip the sub-agents, skip the Knowledge Base, skip MCP until the two-box loop runs clean. Add each component only when the loop's actually straining without it. A loop you understand beats a loop that impresses.

If you want to go deeper: take the six-row table above and, for one component, write the ADR. Automations is the easiest place to start. Why EventBridge scheduled rule over a Step Functions timer? What's your circuit breaker in the dispatcher? Write down the decision and the trade-off you rejected, because that's the artifact that makes the loop yours instead of a copy of mine.

And if you build one, come tell me where the six-component map broke for you. Two seams I flagged in an early draft (worktrees, and the exact IAM chain) got run to ground during verification, and both answers made the map stronger. Find me the next one. I want the correction more than I want to be right. That's the whole point of building in public.

Build the loop. Stay the engineer.

Sources: Addy Osmani, "Loop engineering," LinkedIn (June 9, 2026) and "Agent Harness Engineering," O'Reilly Radar (May 2026); @codewithbrij, "The AI Production Stack — May 2026 Edition" (Instagram); Prasad Rao (AWS Principal SA), Claude Code on Bedrock enterprise setup (LinkedIn, May 2026); AWS MCP Servers, Amazon Bedrock AgentCore, Bedrock Agents Classic maintenance mode, AgentCore release notes, AgentCore Evaluations GA.

The CEO of Y Combinator Open-Sourced His AI Agent Team. What Happens When You Put It on AWS Bedrock?

Martín Rivadavia — Tue, 14 Jul 2026 14:56:54 +0000

Garry Tan runs Y Combinator. In March he open-sourced his Claude Code setup, and it isn't a clever alias or a tidy prompt. It's a team. It picked up 10,000 GitHub stars in its first 48 hours, and four months later I still can't find anyone showing what that pattern actually costs to run in production.

gstack is 23 opinionated tools acting as six roles that turn a single conversation into a pipeline. A CEO agent asks why the thing should exist before anyone writes code. An engineering manager sets the architecture. A designer generates variants and picks one. A release manager runs the ship cycle. A doc engineer and a QA close the loop. You install it in about 30 seconds, and suddenly your one-person project has a chain of command.

That's the part worth sitting with. When the person running the most influential accelerator on earth ships his multi-agent workflow as a public repo, the "is multi-agent real or just demo-ware" question is settled. It's real. People do actual work this way.

I run multi-agent setups in Claude Code every day, so none of this surprised me. What caught my attention was the gap nobody talks about. "Install in 30 seconds" quietly means "on your laptop, with your credentials, no audit trail, no per-role access control, no shared bill." For a solo developer that's perfect. For a company that wants the same pattern in production, it's the start of a different problem.

This article is about that gap. What does gstack look like when you rebuild it on AWS Bedrock, and when is the extra work actually worth it?

gstack is the pattern, not the code

Let me be precise about what I'm porting. I'm not lifting Garry Tan's files onto AWS. gstack is written for Claude Code, and it belongs there. What travels is the idea: a small set of specialized agents, each with one job, coordinated so the output of one feeds the next.

The way I think about Claude Code maturity: five levels, roughly Prompt, Skill, Skill Chain, Agent, and Agent Team, with the payoff climbing at each step. Level five, the agent team, is where the big multiplier lives. gstack is a level-five artifact. A team you can install.

So the real question was never "how do I copy gstack." The question is: I like level five, so how do I run it where a team of engineers, an auditor, and a finance lead can all live with it? That's the Bedrock conversation.

Mapping the six roles to AWS services

Bedrock's answer to this shape is AgentCore: one orchestrator agent routing work to specialized sub-agents. (If you knew this pattern as Bedrock Agents multi-agent collaboration: AWS renamed that service "Classic" and closes it to new customers on July 30, 2026. AgentCore is where the pattern lives now.) That maps onto gstack's roles almost one to one. The interesting part is which AWS service backs each role, because that's where the local pattern gains its production teeth.

The six roles line up like this.

gstack role	What it does	AWS Bedrock equivalent
CEO	Validates the business case before any code ("why does this need to exist?")	Sub-agent fronted by Bedrock Guardrails to filter requests with no business justification
Engineering Manager	Sets architecture up front	Sub-agent backed by a Knowledge Base of your internal architecture, plus the Well-Architected Tool
Designer	Generates 4-6 variants, picks the best	Parallel model invocations, scored with AgentCore evaluations
Release Manager	Runs the release cycle	Sub-agent with CodePipeline and CodeBuild access through an MCP server
Doc Engineer	Keeps the docs in step with what shipped	Sub-agent writing to the docs repo through an MCP server, grounded on the same Knowledge Base
QA	Tests before the release manager ships	Sub-agent gated on AgentCore evaluations, running tests via CodeBuild

(A precision note: gstack is technically 23 tools that act as these six roles. I'm mapping the roles because that's the layer that transfers.)

Forget the specific service names for a second. What the table really shows is a shift in what "a role" means. On your laptop, the CEO agent is a system prompt. On Bedrock, that same agent is a system prompt plus a guardrail policy plus an IAM role that literally cannot touch your deploy pipeline. The role stops being a suggestion. It becomes an enforced boundary.

The orchestrator routes to each specialized sub-agent, and every one of them runs on top of the same audit floor: CloudTrail for decisions, CloudWatch for metrics, IAM for least-privilege access.

The architecture, in one picture

Strip away the service logos and the Bedrock version looks like this:

User / Event
     │
     ▼
Orchestrator Agent on AgentCore  (the coordinator)
     ├── CEO Agent                  → Guardrails + Claude
     ├── Engineering Manager Agent  → internal KB + Claude
     ├── Designer Agent             → parallel invocations + evaluations
     ├── Release Manager Agent      → CodePipeline via MCP + Claude
     ├── Doc Engineer Agent          → docs repo via MCP + KB
     └── QA Agent                    → evaluations + CodeBuild
     │
     ▼
CloudTrail   → every tool call and agent decision, logged
CloudWatch   → latency and token metrics per agent
IAM          → each agent gets its own least-privilege role

The three lines at the bottom are the whole reason to do this. On a laptop, all six agents run as you. They share your credentials, your shell, your access to everything. On Bedrock, the Release Manager agent can reach CodePipeline and nothing else. The CEO agent can read the request and write a verdict, but it can't deploy. If someone asks later "why did the system approve this change," CloudTrail has the answer with a timestamp.

That's not a feature you notice on day one. It's the feature you're grateful for during the incident review six months later.

What actually changes: local vs. Bedrock

This is the part the migration blog posts skip. The pattern is identical. The operational reality is not.

Dimension	gstack local (Claude Code)	gstack pattern on Bedrock
Audit	No trail. You can't reconstruct what each agent decided	CloudTrail logs every tool call and decision
Access control	Everything runs with the developer's credentials	Each agent gets its own IAM role, least privilege
Billing	Individual subscription	Centralized in AWS, visible by team, project, environment
Scale	One developer, one session	Many developers, parallel sessions, no collision
Governance	No formal guardrails	AgentCore policy plus Guardrails on each agent
Integration	The developer's local tools	AWS MCP server for any AWS service

Read that table as a translation of one word: ownership. Local gstack is owned by a person. Bedrock gstack is owned by an organization. Everything in the right column is what "owned by an organization" costs and buys.

The 30 seconds vs. the several hours

gstack's pitch is "install in 30 seconds." That's true, and it's the right pitch for what it is.

The Bedrock version has no such pitch. You're defining IAM roles, writing agent definitions, standing up a Knowledge Base, wiring MCP integrations, and turning on CloudTrail. That's not a 30-second job. Anyone who tells you otherwise is selling something.

I'm not going to hand you a fake stopwatch number here, because I haven't run this exact port end to end, and inventing a duration would be the kind of thing this whole series exists to push back against. What I can tell you from running multi-agent work daily is where the time goes. It goes into IAM. It always goes into IAM. The agents are the easy part. The least-privilege role for each one, tested so it can do its job and nothing more, is the work. I'm building a scoped version of this port in my lab, meters on, and the measured numbers will get their own article.

So is it worth it? That depends entirely on who's asking.

If you're a solo developer or a two-person startup, almost certainly not. The audit trail protects you from a compliance question nobody is asking yet. The per-agent IAM roles guard against a blast radius that, at your size, is just your own laptop. Stay on gstack. Ship. The 30 seconds is the correct answer.

If you're a team of five or more engineers, or anyone with a compliance obligation, the math flips. The moment "which agent approved this deploy" becomes a question a real human has to answer, CloudTrail stops being overhead and starts being the cheapest insurance you own. The moment two developers run the pattern at once, shared IAM and centralized billing stop being bureaucracy and start being the thing that keeps the wheels on.

Same six agents, same four dimensions. On the left they read as overhead; on the right, as insurance. The scale is what flips the answer.

The dishonest version of this article sells Bedrock as the universal upgrade. That's not what it is. Bedrock earns its place at a specific scale, and naming that scale out loud is more useful than another "why you should migrate everything" post.

What I'd tell you before you start

A few things I'd want to know before rebuilding this pattern, learned from running agent teams rather than from this specific port.

The orchestrator is where your design lives or dies. gstack's magic is the handoff between roles, and on Bedrock that handoff is the orchestrator's routing logic. Get that wrong and you have six agents talking past each other. Spend your design budget there. The individual agents are the easy part.

Guardrails on the CEO agent are the entire point of it. The whole reason a "business validation" agent earns its slot is that it says no. If its guardrail is loose, it's a rubber stamp with a token bill attached.

And least privilege is the feature you came for. It's tempting to give every agent broad permissions to get things working, then tighten later. Later never comes. If you're going to pay the setup cost of Bedrock at all, the per-agent IAM boundary is the thing you're paying for. Don't skip it and keep the overhead.

Build. Document. Share. Repeat. This series was never here to tell you Bedrock wins. It's here to show the actual trade, so you can make the call for your own team, at your own scale.

Your turn

Three ways to take this further, pick your commitment level.

Low: Go read gstack. It installs in 30 seconds and it'll change how you think about a single Claude Code session, whether or not you ever touch Bedrock. Then tell me in the comments which of the six roles you'd actually keep. I suspect not everyone needs all six.

Medium: If you've mapped a multi-agent pattern onto Bedrock AgentCore, I want the part I left out: what did the setup actually cost you in time and dollars? I skipped the stopwatch on purpose. Yours would make this article better.

High: Do the real port. Take the pattern, build the orchestrator plus the four documented agents on Bedrock, log every decision to CloudTrail, and write up where the design fought you. That's the article I'd read next, and if you write it, I'll link it here.

The pattern is Garry Tan's. Full credit to him and to gstack for making level-five agent teams something you can install instead of theorize about. The question of where to run it is the one worth arguing over.

Sources: gstack by Garry Tan (open-sourced March 2026), covered by Charlie Hills on LinkedIn; Amazon Bedrock AgentCore (Bedrock Agents "Classic" closes to new customers on July 30, 2026), CloudTrail, and IAM.

BuildToLearn #AWSCommunity #LearnInPublic

AWS Runs Kiro and Amazon Q on Strands. Why Isn't It in Your Stack Evaluation?

Martín Rivadavia — Wed, 08 Jul 2026 19:05:56 +0000

Open any "which agent framework should I use" post from the last six months. You'll see LangGraph. You'll see CrewAI. Maybe LlamaIndex, maybe OpenAI's Agents SDK. You almost never see Strands.

That's odd, because Strands is the framework AWS trusts with its own products. Kiro runs on it. So do Amazon Q, AWS Glue, and AWS Transform for .NET (AWS's own announcement names them). It crossed 25 million downloads by its one-year anniversary in May 2026, hit v1.7.0 on June 25, and sits at 6.4k GitHub stars. Cox Automotive runs 17 production agents on it. This is not a science project.

So the gap isn't coverage anymore. A year ago you could barely find a tutorial. Now a Medium series, an InfoQ writeup, and YouTube playlists all exist. The gap moved. It's an evaluation gap. Everyone benchmarks LangGraph against CrewAI and quietly leaves out the framework AWS runs Kiro on. If you're picking an agent framework on AWS and Strands isn't even on your shortlist, that's worth a second look.

Full disclosure before we go further. I have not shipped a production system on Strands. I have run every code example in this article against Bedrock Nova (they work as printed; 2-3 seconds per agent call, under a cent total), read the documentation, and pulled together what the adopter evidence actually shows so you don't start from a blank page. When I'm guessing, I'll say so.

What Strands actually is

Strands is an open-source SDK from AWS for building AI agents. The pitch, once you strip the marketing, is model-driven agents: you give the model a set of tools and a prompt, and the model itself decides how to plan, when to call a tool, and when it's done. You are not hand-wiring a state machine of "if the model says X, call Y." The loop that connects the model to its tools is the framework's job.

That framing matters because it's the opposite of how a lot of people first build agents. My own instinct, and probably yours, is to reach for something explicit. Step Functions. A big orchestration graph. Nodes and edges you can point at. Strands bets that the model is good enough now that most of that scaffolding is wasted effort.

The core of a Strands agent is small enough to fit in your head:

from strands import Agent
from strands_tools import calculator

# The agent is: a model + a set of tools + a prompt.
# You don't write the plan-act-observe loop. The SDK runs it,
# and the MODEL decides which tools to call and when to stop.
agent = Agent(tools=[calculator])

agent("What is 3111696 divided by 48?")

That's the whole thing. No graph. No explicit routing. Defining your own tool is a decorator on a Python function, which is the part that clicked for me. The docstring and type hints become the tool's contract that the model reads:

from strands import Agent, tool

@tool
def get_invoice_total(account_id: str) -> float:
    """Return the current month's invoice total for an AWS account.

    Args:
        account_id: the 12-digit AWS account number
    """
    # Your real logic goes here. The docstring above is what the
    # model actually reads to decide when to call this tool, so the
    # docstring IS the interface. Write it for the model, not just for humans.
    return 1284.50

agent = Agent(tools=[get_invoice_total])
agent("How much did account 123456789012 spend this month?")

The interesting design choice is that the docstring is not documentation sitting next to the code. It is the interface the model sees. Sloppy docstring, sloppy tool use. That single detail tells you the whole framework leans on the model's judgment instead of your control flow.

Why AWS built this instead of pointing you at Bedrock Agents

This was my first real question. AWS already has Bedrock Agents, a managed service where you define an agent in the console, attach action groups, and let Bedrock run it. So why ship a separate SDK?

The honest answer, from what I can piece together, is that they solve different problems. Bedrock Agents is managed and console-first. It's great until you want your agent logic to live in your codebase, in version control, tested like the rest of your application, running wherever your code runs. Strands is code-first and model-agnostic. It works with Bedrock and Nova, but the SDK is not locked to a single model provider.

Here's the mental model, and this one I can back with AWS's own words. Think of it the way infrastructure tooling splits. The runtime that executes your workload is one layer. The framework you write to define that workload is another. Strands is the framework you write. AgentCore is the managed runtime that hosts and scales it. The AgentCore FAQ says it directly: AgentCore Runtime deploys and scales agents built with "any open-source framework (such as CrewAI, LangGraph, LlamaIndex, Google ADK, OpenAI Agents SDK, or Strands Agents)." You author with Strands. You deploy and run at scale with AgentCore.

That split explains why the two names keep showing up together. You author with the framework, then deploy with the runtime. It also explains why "Strands vs. AgentCore" is the wrong question. They're not competing. One writes the agent, the other runs it at scale.

The split that makes "Strands vs. AgentCore" the wrong question: you write one, the other runs it.

Getting to a first agent

The setup path is standard Python, and standard AWS credentials, which is a relief after some agent frameworks that ask you to adopt a whole platform first.

# Strands is just a Python package. No console clicking to get started.
pip install strands-agents strands-agents-tools

# It talks to Bedrock through your normal AWS credentials.
# Same profile, same region, same IAM you already use for boto3.
export AWS_PROFILE=your-profile
export AWS_REGION=us-east-1

One detail will save you a confused hour. Most tutorials still tell you to go enable model access in the Bedrock console first. That advice is stale. Since October 2025, Bedrock enables serverless foundation models automatically in every commercial region. The manual "Model access" page is gone. The one exception: Anthropic models still ask for a one-time usage form before first use. Nova models need nothing. If a guide sends you hunting for a console page that no longer exists, that's the guide's age showing, not your mistake.

With credentials sorted, pointing the agent at a specific model is explicit:

from strands import Agent
from strands.models import BedrockModel

# Being explicit about the model is a cost and capability decision,
# not a detail. Nova Pro is AWS's own model and is cheaper per token
# than the top-tier Claude models; a strong Claude model reasons harder
# but costs more. For an agent that loops and calls tools many times
# per task, that per-call cost multiplies fast.
model = BedrockModel(
    model_id="us.amazon.nova-pro-v1:0",  # US cross-region inference profile
    temperature=0.3,  # lower temp: more deterministic tool selection,
                      # which is usually what you want for agents that act
)

agent = Agent(model=model, tools=[get_invoice_total])

That temperature=0.3 is a deliberate choice worth explaining. For a chatbot you might want warmth and variety, so you run it hot. For an agent that picks tools and takes actions, you want it boring and repeatable. High temperature means the model might improvise a different tool sequence run to run, and non-determinism in something that touches your systems is a debugging nightmare. Lower temperature, more predictable actions.

Pairing Strands with Nova Pro is the same kind of decision made at the model layer. Nova is AWS's own model family, and it tends to cost less per token than the premium models. When your agent loops, plans, calls a tool, reads the result, and plans again, you pay for every hop. A model that's marginally smarter but several times more expensive can quietly turn a cheap task into a real bill. Running the agent on Nova reads as an intentional cost posture, not just AWS promoting its own model.

Where I got skeptical

I don't want to write the breathless "this changes everything" piece, because that's exactly the content this topic doesn't need. So let me lay out my honest doubt.

Model-driven control flow is elegant right up until you need to know why the agent did something. When the model owns the plan, your debugging surface changes. You are no longer reading a state machine. You are reading a transcript of what the model decided, and asking why it decided that. That's a real trade-off, and the docs are understandably optimistic about it. I'd want to see observability and tracing in a genuine multi-tool workload before I trusted it with anything that spends money or mutates data.

The other open question is what kind of production evidence exists. There's plenty of it now, and that's the good news. Smartsheet presented a Strands session at re:Invent 2025 (BIZ210). Cox Automotive runs 17 production agents on it. Jit, Landchecker, and Verisk show up in AWS's own writeup on delivering production agents at scale. And AWS runs Kiro, Amazon Q, and Glue on it, which is about as strong a bet as a vendor can place on its own tooling.

One caveat belongs front and center. Almost all of that evidence is AWS-authored. It's the vendor telling you its framework works, which is exactly what a vendor does. The independent post-mortem, the "we picked Strands over LangGraph for these reasons and this is where it hurt," barely exists yet. Setup tutorials, yes. Marketing vignettes, yes. A neutral engineer walking through six months of running it in anger, no. So the coverage gap closed, but a depth gap opened in its place. Being early to that depth still cuts both ways. You get the clean runway. You also get to find the sharp edges first.

Why this belongs in your evaluation

Step back from the code for a second. The reason to put Strands on your shortlist isn't that it beats LangGraph. I haven't run that comparison honestly enough to claim it, and neither has most of the internet yet. That's the part worth sitting with.

Frameworks are consolidating fast in 2026. AutoGen already got absorbed into Microsoft's Agent Framework. The market clearly wants fewer, cloud-native options. A first-party AWS framework with 25M downloads, a year of releases, and AWS running its own flagship products on it is a strong candidate to be one of the survivors. Leaving it out of a framework comparison because you hadn't heard of it a year ago is a decision you're making by accident.

Documentation isn't overhead. It's thinking made visible. Right now the thinking that's visible about Strands is AWS's own. Nobody outside the vendor has weighed it honestly against the frameworks everyone already benchmarks. That's the messy middle, and the messy middle is where learning lives.

Try it, then tell me where I'm wrong

If you have ten minutes: pip install strands-agents, run the calculator example, and watch the model pick the tool on its own. That's the whole "aha" in one command.

If you have an afternoon: build one real tool for something you actually use, an internal API, a cost lookup, a status check, and see how far the docstring-as-interface idea carries you before it strains.

If you have a weekend and you already run agents in production: put Strands next to LangGraph or CrewAI on a task you actually care about, and write down where each one hurt. That comparison is the missing artifact. Every framework roundup skips Strands, and every Strands writeup skips the comparison. Whoever publishes an honest head-to-head fills the one hole in the whole conversation.

I'll be doing the same, in the open, wrong turns included. If you've already built something on Strands, or you think my framework-versus-runtime read of the AgentCore relationship is off, tell me in the comments. I'd rather be corrected early than confident and wrong. Build. Document. Share. Repeat.

Sources: Introducing Strands Agents, an open-source AI agents SDK (AWS, names Kiro, Amazon Q, Glue, Transform for .NET) · Enabling customers to deliver production-ready AI agents at scale (AWS ML Blog, named adopters) · Strands Agents documentation · Strands Agents SDK on GitHub · Amazon Bedrock AgentCore · Amazon Nova

From Demo to Production: What GA Actually Means for AWS AI Agents

Martín Rivadavia — Tue, 07 Jul 2026 14:42:12 +0000

Two days. ~$363. That was my Knowledge Base lesson.

I was re-syncing a Bedrock Knowledge Base over and over, tuning it, watching it fail, fixing it, syncing again. Every sync re-embedded the documents. Every re-embed spent tokens. The tokens stacked up quietly in the background while I stared at retrieval quality, not the meter. The bill showed up two days later and taught me a rule I still use: ask about cost before the invoice, not after.

I bring that up because the AWS story in 2026 is no longer about picking a model. It's about running agents in production, for hours, sometimes days, on their own. And production is exactly where quiet meters, hidden quotas, and "we'll figure out cost later" turn into real money. The demo is free. Production sends you a bill.

So let me look at what "GA" actually means this year, using the specifics AWS published, not the keynote adjectives.

The pitch changed from "try this model" to "put agents to work"

At re:Invent 2025, the framing shifted. AWS stopped leading with "try this better model" and started leading with agents that operate as an extension of your team: Kiro, a Security Agent, a DevOps Agent, described as "frontier agents" that work for hours or days at a time (About Amazon).

That's a bigger claim than it sounds. A model call returns in seconds and you eyeball the result. An agent that runs for a day makes hundreds of decisions you never see, spends tokens you didn't budget line-by-line, and holds sessions open while it works. The moment an agent runs unattended, every question I learned to ask the hard way stops being optional. What does this cost? What are the limits? How do I know it's behaving?

The model catalog exploded in parallel. Bedrock went from roughly 60 to nearly 100 models, adding Mistral, Google, NVIDIA, OpenAI, MiniMax, Moonshot, and Qwen (AWS News Blog). That includes GPT-5.5, GPT-5.4, and Codex running on Bedrock (About Amazon). Amazon's own Nova 2 line went multimodal end to end. Nova 2 Omni handles text, image, video, and voice, and Nova 2 Sonic does speech-to-speech (AWS re:Invent 2025 top announcements).

The model count hides the real question. None of it matters if you can't operate the thing safely, which is why the announcements I actually care about aren't models at all.

The GA list nobody puts on a slide

The interesting graduations this year are the boring-sounding ones. The plumbing that separates a prototype from something you'd let touch production data.

Three pieces of Amazon Bedrock AgentCore reached general availability:

Component	What it does	Status
AgentCore harness	Takes you from idea to a running agent without writing your own orchestration	GA, June 2026 (AWS What's New)
AgentCore Evaluations	13 built-in evaluators plus Ground Truth to score agent behavior	GA (AWS What's New)
AgentCore Policy	Fine-grained control over which tools an agent can call, plus Guardrails	GA, March 2026 (AWS What's New)

Read that table again. Evaluation, policy, and guardrails going GA is the real signal — not another model. A market that's still doing demos doesn't ship evaluation frameworks. A market that's putting agents in front of customers does. AWS is telling you where it thinks the field is: past the "look, it works" phase and into "prove it works, and prove it stays inside the lines."

The harness matters because orchestration is where hand-rolled agents rot. You start with a clean loop: call model, run tool, feed result back. Six weeks later you're maintaining retry logic, session state, and timeout handling you never meant to own. A managed harness moves that burden to AWS. The trade-off, and I'll come back to this, is that you now depend on AWS's harness instead of your own.

Evaluations is the piece I'd reach for first, because it answers the question my $363 bill was really about: how do you know? Thirteen built-in evaluators plus Ground Truth means you can score an agent's output against expected answers instead of vibes. If you've ever shipped a RAG pipeline and "tested" it by asking it three questions you already knew the answers to, you know why this exists.

The specifics that decide whether you can afford it

Now the part the keynote skips. Running an agent in production runs into limits, and the limits have numbers.

Two quotas stand out. AgentCore raised per-agent throughput from 25 to 200 TPS, and set the default for active session workloads at 5,000 per account. That 5,000 only applies in US East (N. Virginia) and US West (Oregon). Every other region gets 2,500 (AgentCore release notes). Both are adjustable through Service Quotas, which changes the failure mode: you won't hit a wall, you'll hit a support ticket you didn't know you needed to file.

The session cap nobody mentions in the keynote: deploy outside the two big US regions and you start with half the ceiling.

Sit with those for a second. 200 transactions per second per agent is generous for most workloads. But if you're fanning out parallel tool calls, it's a ceiling you can hit. The active-sessions default is the one that bites quietly. An agent that "works for hours or days" holds a session the whole time. If your design spins up long-lived agents per user, per job, or per document, 5,000 concurrent isn't a lot. And if you deploy outside the two big US regions, you're working with half that. That's an architecture input, not a footnote. It's exactly the kind of number you want to know at design time — either you size under the default, or the quota-increase request goes in your launch checklist, not your incident retro.

This is where my near-miss from an earlier lab keeps echoing. In lab-01, my first design used one S3 bucket with two prefixes: input and output in the same bucket. Clean. Simple. Catastrophic. Lambda would have triggered on its own output, looped, and billed me into the thousands before I noticed. The docs saved me. I read the trigger scope carefully and split the buckets before I deployed. The lesson wasn't "S3 is dangerous." It was that autonomous systems find the failure mode you didn't design against. An agent running unattended for a day is that same class of problem, scaled up. It won't loop on an S3 event — it'll loop on a reasoning step, or hold sessions it never releases, or retry a failing tool 400 times. Same shape, bigger blast radius.

The cost picture is where I have to be honest with you, because the seed I built this from raised a question I can't fully answer yet: what does an AgentCore agent actually cost in production versus a hand-rolled Lambda plus Bedrock call? I don't have a real bill to show you. Anyone who hands you a confident number right now is guessing. What I can tell you is which meters are running: model tokens, session time, tool invocations, and any egress. The managed convenience of the harness is not free. If you take one thing from my Knowledge Base story: find the meters before you find the bill.

One data-residency angle is worth flagging too. AgentCore's Web Search runs with zero data egress from your AWS environment (AWS ML Blog), which matters if you're in a regulated shop and "the agent googled it" is not an acceptable data path.

A minimum path from idea to production

If I were starting an agent on this stack today (and I'll be doing exactly that in an upcoming lab), here's the order I'd follow. Not because it's the only way, but because it front-loads the questions that cost me money when I ignored them.

Five gates, one recurring question. The order matters: evaluation before scale, policy while the surface is small.

Start with the idea and the harness. Get a single agent running with the managed harness before you touch anything fancy. One agent, one tool, one clear job. Prove the loop closes.

Then wire up Evaluations before you scale, not after. This is the reversal of how I did RAG the first time. Define your Ground Truth (the answers you expect) and let the 13 evaluators score the agent against them. If you can't measure it, you can't trust it running unattended.

Next, set Policy and Guardrails while the surface is small. Decide which tools the agent may call and what it may never do. Locking down tool access on a two-tool agent is a five-minute job. Retrofitting it onto a sprawling one is a project.

Only then think about deploy and scale. When you do, check your session math against that 5,000 cap and your throughput against 200 TPS before you turn on real traffic. Ask the cost question at this step, out loud, with numbers. Model tokens, session duration, tool calls, egress. Write them down.

That's the whole path: idea → harness → evaluation → policy → deploy, with the cost question asked at every gate instead of after the invoice. It's the Build-to-Learn loop applied to agents: build the smallest real thing, document the decisions, share what broke, repeat. Documentation isn't overhead. It's thinking made visible, and it's the thing that saved me in lab-01.

What I'd measure in six months

So is this real infrastructure or another hype cycle? Honestly — both, and the split is the interesting part.

The plumbing is real. Evaluations, Policy, and Guardrails going GA is a market growing up. That's not marketing; that's AWS admitting the demo phase is over and betting on governance. I believe that part.

The claims I'd hold at arm's length are the autonomy claims. Nova Act is quoted at 90% reliability for browser automation (About Amazon). Ninety percent sounds great until you ask ninety percent of what. I dug into it: the figure comes from Amazon's own internal evals of specific hard UI actions (date pickers, dropdowns, popups) plus early-customer workflows (Amazon Science). Not an independent public benchmark. That doesn't make it fake; it makes it a number Amazon graded on Amazon's homework. And either way, a 10% failure rate on an agent that runs unattended for a day is a lot of failures nobody's watching.

There are open questions I genuinely can't answer yet, and I'd rather hand them to you than fake an answer:

What does an AgentCore agent cost in production versus a Lambda-plus-Bedrock build you wire yourself?
How does AgentCore compare to LangGraph, CrewAI, or the equivalents on Azure and Vertex, and what does choosing the AWS agent stack lock you into?
Where are the customer case studies, not the launch posts?

If you have a real bill or a real deployment on any of these, I want to hear it. That's not a rhetorical close. Those numbers are the content I don't have yet.

Your move

Low commitment: drop a comment with the one AgentCore quota or cost you wish AWS documented more clearly. I'll compile what comes back into a follow-up. Community-sourced FinOps beats guessing.

Medium commitment: if you've run AgentCore, LangGraph, or CrewAI in anything resembling production, tell me one thing that surprised you about the bill or the limits. One number is enough.

High commitment: build the minimum path above (one agent, evaluated, policy-locked) and write up what broke. Tag it and I'll link to it. The best answer to "is this real?" is a runnable repo, not another opinion.

I'll be putting an agent through this exact path in the next lab and publishing the meter readings, good or bad. Build. Document. Share. Repeat.

I Spent ~$363 in Two Days on Bedrock — Cheap Lesson or Expensive One?

Martín Rivadavia — Tue, 24 Mar 2026 16:48:50 +0000

The pricing page told me embeddings were "per thousand tokens." The bill told me what that actually means when you sync a corpus more than once while you are still learning.

This is the story of a two-day spike on my AWS account — mostly Amazon Bedrock — and what I took away from it. Spoiler: I do not think it was only money down the drain.

The receipt (literally)

I pulled up Cost Explorer after a weekend of experiments. Two consecutive days in December looked like this:

Roughly:

	Total (two days)
All services (shown)	~$363
Amazon Bedrock	~$353
Amazon OpenSearch Service	~$7

Most of that was not me chatting with Claude in the playground. It was Knowledge Base work: pointing Bedrock at data in S3, running ingestion / sync jobs, and re-running them while I changed chunking, parsers, and paths — before I had a clear picture of how embedding tokens accumulate across retries.

I had expected "some cost." I had not internalized how fast repeat syncs turn into repeat embeddings for the same underlying text.

What I thought I was doing

I was building a RAG-style pipeline over technical PDFs: extract text, get it into a Bedrock Knowledge Base, run retrieval, and eventually wire that into an application.

That sounds linear. In practice my early loop looked more like:

Upload or point at objects in S3.
Start a sync.
Notice something wrong — layout, chunk boundaries, metadata, or retrieval quality.
Change the preprocessing, upload again, sync again.
Repeat step 4 until I understood what "good" looked like.

Every pass felt like "fixing configuration." In billing terms, many passes looked like new embedding work. The console does not always feel like spending money; Cost Explorer does.

What the invoice taught me (that the docs had not fully sunk in yet)

GenAI on AWS is not one line item. For Knowledge Bases, the mental model that finally stuck:

Ingestion / embedding is where large PDFs hurt — you pay for tokens processed into the vector store, not for "having a PDF on disk."
Retrieval and downstream model calls are additional meters. Separating "sync cost" from "query cost" matters when you debug.
Re-syncing the same corpus while you tune chunking is not a free redo. You are often paying for another full pass over the same content unless you have designed for incremental or diff-aware updates.

None of that is a secret — it is all in the documentation. The bill was the tutorial that actually stuck.

¿Lección cara o barata?

If you judge only by the number on the screen, it was an expensive lesson.

If you judge by what I would pay for the same misunderstanding in production, under deadline, with a team and customer trust on the line — learning it on my own lab account starts to look cheap. I paid once in dollars and once in humility. I would rather do that before I ever optimize someone else's budget.

So my answer: it was both. Painful in the moment, valuable in context — and only "wasteful" if I pretended nothing needed to change afterward.

What I changed in how I build

1. Measure before sync.

I stopped treating "upload and sync" as the first step. I added local steps: approximate token counts, preview chunk boundaries, and sanity-check file sizes before triggering another full ingestion. That mindset is documented in Lab 02: KB Ingestion — Foundations First in the learning-journey repo — small CLI helpers, no cloud required for the first pass.

2. Separate "pipeline quality" from "vector store plumbing."

I invested in a clearer PDF → clean text → intentional chunks → S3 path in aws-pdf-rag-mr — the companion repo with the full pipeline code (Terraform, Lambda processor, Bedrock KB, S3 Vectors) that matches what Lab 02 points you toward after the foundations. That way Bedrock sees stable, deliberate chunks instead of whatever the default path produced on raw PDFs while I was still iterating.

3. Use the cloud bill as a design review.

Billing alerts and Cost Explorer by service are now part of my definition of done for experiments, not something I check when I get curious.

If you are about to do the same experiment

Start with tiny files — one short text, one sync, one retrieve — until the numbers make sense.
Read embedding and KB pricing as token math, then estimate tokens × price × number of sync attempts.
Treat re-sync as a budget line, not a config tweak.
Document decisions (I use ADRs) so the next you does not repeat the same loop "just one more time."

Closing

I did not write this to scare anyone away from Bedrock or Knowledge Bases. I still use them. I write it because the messy middle — including an invoice that made me stare at the screen — is part of learning in public honestly.

Documentation is not overhead. It is thinking made visible. So is a cost breakdown when it forces you to redraw your architecture.

If this story saved you one accidental full re-embedding of a giant PDF, it was worth more than those two days of spend.

Repos:

aws-genai-cert-learning-journey — learning path, ADRs, and Lab 02 docs (labs/lab-02-kb-ingestion-basics/).
aws-pdf-rag-mr — implementation code for the PDF → KB pipeline (the “after Lab 02” stack).

Tags I'll use when I share: #BuildToLearn #AWSGenAI #AmazonBedrock #LearnInPublic #RAG

Have you had a GenAI bill that taught you something the docs alone did not? I would genuinely like to hear what changed in your process afterward.

The Exam That Felt Like a Project Backlog: Passing AWS Certified Generative AI Developer – Professional

Martín Rivadavia — Thu, 12 Mar 2026 18:05:35 +0000

This is part of my Build-to-Learn with AWS GenAI series — where I share the messy middle of building production-grade GenAI systems on AWS, including the wrong turns.

Question 67. Beta exam. Eighty-five total questions. I almost lost it right there.

Not my composure, exactly — more like my thread. The kind of focused engagement you need to hold through a complex orchestration scenario when your cognitive reserves have been running for two-plus hours. For a moment, I felt the concentration starting to slip. And then something unexpected happened instead: my brain stopped trying to answer the question and started designing it. What if the routing layer worked this way? What if I extended this to handle the insurance claim pipeline I built? I caught myself, selected the answer, and kept moving. But the moment stayed with me.

That involuntary drift wasn't a lapse in focus. It was evidence. Evidence that the way I'd prepared had taken root at the right level — not as recall, but as judgment. I almost lost my thread at question 67. What I found instead was proof that months of building had encoded something harder to shake than concentration. And at the Professional tier, that kind of judgment is the only thing being tested.

I'd spent months preparing for this exam. More accurately: I'd spent months building, and the exam happened to follow.

AWS Certified Generative AI Developer – Professional · Early Adopter

Why This Certification, Why Now

The AWS Certified Generative AI Developer – Professional is new enough that when I signed up, there were no public pass rates to anchor expectations. No community wisdom about which topics showed up most. No data on what the difficulty curve felt like. I was taking it as a Beta, which meant I was part of the cohort helping AWS calibrate the exam itself — and it meant 85 questions instead of the standard 75.

That extra 10 is not trivial. By question 75 on an exam of this depth, your cognitive reserves have been running for hours. The later questions tend to be the more architecturally complex ones — multi-service integrations, guardrail trade-offs, agent orchestration patterns that require you to hold several moving parts in your head simultaneously. Adding 10 questions at the back end is a meaningful stamina tax, not just a scheduling footnote.

I signed up anyway, because it was the right next step in this series. If I'm building production GenAI systems on AWS and documenting every decision publicly, the Professional certification closes the loop. It says: I understand this domain deeply enough to reason through novel scenarios I've never seen before — not just reproduce patterns from documentation I've read.

There was a bonus I didn't know about when I registered: Beta cohort participants who pass receive an Early Adopter badge from AWS — a second credential recognizing that you helped define the exam itself. I didn't sign up for that badge. I signed up because the exam was there and the timing was right. But it's an accurate description of what taking a Beta actually means: you go in without a map, and if you make it through, you helped draw the map for everyone who comes after.

What I didn't fully appreciate until exam day was how much the work I'd already done would matter.

Starting With Skill Builder (And Why I Pivoted)

My first instinct was AWS Skill Builder. Official source. Authoritative. Comprehensive. The right instinct in principle.

Here's what I didn't anticipate: the material is genuinely good, and it is genuinely heavy. Skill Builder covers the conceptual foundations of foundation models, the architecture of Amazon Bedrock, the nuances of RAG pipelines, evaluation frameworks, responsible AI — all of it with the depth you'd expect from the people who built the services. For someone building their knowledge base from scratch, it's excellent. For someone who's already been building with these services and needs to sharpen scenario reasoning, reading through it sequentially felt like re-reading a reference manual.

I didn't abandon it. I still used Skill Builder as a reference layer — when a practice exam question surfaced a concept I couldn't fully explain, I went back to Skill Builder for the deep read. But it stopped being my primary study method about a month in, and I switched to two Udemy courses that fit how I actually learn.

The first — Ultimate AWS Certified Generative AI Developer Professional — gave me a more accessible conceptual ramp. Good structure, practical framing, the kind of explanations that build a mental model you can reason with rather than recall from. The second — Practice Exams AWS Certified Generative AI Developer Pro — I treated as a diagnostic tool rather than a score-chaser. Every wrong answer was a prompt for genuine investigation: not "why was I wrong" but "what would I build differently, and why?"

The combination worked. But neither was the real differentiator.

The Thing That Actually Mattered

In my previous article, I wrote about how a near-disaster — an infinite loop that would have cost thousands in AWS bills — crystallized the Build-to-Learn Framework. The lab that came out of that experience was Lab 01: an automated insurance claim document processing pipeline built on Amazon Bedrock, Lambda, and S3.

I built that lab months before finishing my certification prep. On purpose. That decision came with a risk I documented explicitly at the time:

ADR-002: Build Lab 01 Before Completing Certification Prep

Status: Accepted

Context:
  Conventional wisdom says finish studying before building.
  The Build-to-Learn thesis says building is the studying.
  Taking the Professional exam before completing all formal modules
  means entering with gaps in coverage.

Decision:
  Build Lab 01 now. Ship it. Write the ADR. Then return to formal study.

Rationale:
  Professional-level exams test scenario reasoning, not recall.
  Reasoning is built through decisions with real consequences.
  A production-adjacent lab creates those consequences in a way
  no module can replicate.

Consequences:
  - Risk: Formal knowledge gaps may surface on exam
  - Benefit: Implementation judgment built before exam; scenarios will feel familiar
  - Accepted tradeoff: depth of experience > breadth of coverage

The consequences played out exactly as written. There were moments on the exam where I wished I'd read one more Skill Builder module. There were far more moments where I recognized a pattern because I'd lived it.

The Build-to-Learn thesis is that building real systems before the exam encodes judgment, not just knowledge. And Professional-level exams don't test knowledge — they test judgment. They present scenarios you've never seen before and ask you to reason about what the right architecture would be, given a specific set of constraints and trade-offs. That kind of reasoning doesn't come from reading. It comes from having been in the situation.

When a question presented a multi-agent orchestration scenario, I recognized the architectural patterns because I'd designed one. When a question asked about guardrail configuration trade-offs, I'd made those decisions in code and felt the consequences. When a question surfaced the cost implications of different model invocation strategies, I'd worried about that in production. The hours spent debugging Lambda triggers, writing Architecture Decision Records, and arguing with IAM policies translated directly into the ability to reason through novel scenarios under pressure.

That's not a coincidence. That's the Framework, working.

What the Beta Exam Actually Feels Like

No study guide can prepare you for question 75 on an 85-question exam.

The experience is layered. The first 30 questions feel manageable — you're fresh, the cognitive load is still within capacity, and the scenarios are challenging but readable. By question 50, you're aware that you've been concentrating hard for a while. By question 70, your brain is doing something slightly different than it was at the start: it's working harder for the same output.

The Beta format adds its own texture. There's no score at the end. You complete the exam, submit, and walk out not knowing. AWS collects results from the Beta cohort, calibrates the difficulty model against how candidates performed, and notifies you later. The wait is a specific kind of uncomfortable — you can't iterate on what you don't know, so you just wait.

What I didn't expect was the moment at question 67 where my brain started drifting toward building rather than answering. It felt, in that moment, like distraction. In retrospect, it was a signal. The exam scenarios are written by people who think about these services the way builders think — as implementation decisions, not as trivia. When you've built with these tools, you speak the same language as the people writing the questions. The exam stops feeling like a test and starts feeling like a design discussion.

I passed. The score came through later, along with something I hadn't expected: an Early Adopter badge from AWS, issued to the Beta cohort who helped define the exam before it was publicly available. I didn't sign up for that badge — I signed up for the challenge. But it's a fitting symbol. Being early meant no benchmarks, no pass-rate data, no community notes to fall back on. It meant the only preparation that counted was the preparation you'd actually done.

The pass was less surprising than that moment at question 67 — because by then, the Framework had already proved its point. The Early Adopter badge just confirmed which cohort had been there first.

The Study Stack, Honestly Ranked

If you're preparing for this certification, here's what I'd actually recommend:

1. Build Something First

Not a tutorial. Not a sandbox. A real system with real architecture decisions, real trade-offs, and documentation that forces you to articulate why you made each choice. Write ADRs. Deploy it. Break it. Fix it. The judgment you build doing this is the single most transferable skill for a Professional-level exam.

2. Udemy Practice Exams — Scenario Reasoning Engine

Practice Exams AWS Certified Generative AI Developer Pro — Use these to find your gaps, then investigate the gaps with genuine curiosity. The questions are scenario-based at the right level of complexity. Don't chase scores. Chase understanding.

3. Udemy Course — Conceptual Architecture

Ultimate AWS Certified Generative AI Developer Professional — Good for building the mental model. More accessible than Skill Builder for daily study. Use it to cover the conceptual landscape before stress-testing it with practice exams.

4. AWS Skill Builder — Reference Layer

skillbuilder.aws — Use it for depth, not breadth. When something comes up in practice exams that you can't fully explain, this is where you go for the authoritative version. Don't try to read it front to back unless that's genuinely how you learn — treat it as a reference library.

What This Certification Actually Means

The certification isn't the story. The certification is the receipt.

What the receipt is for: months of building real systems, making architecture decisions with real stakes, documenting wrong turns, and learning in public. The exam measured the output of that process. It didn't create it.

I've said before that certifications are starting points, not destinations. Passing the Professional tier for GenAI development confirms that the domain knowledge is there — but it also clarifies what the next layer of questions looks like. The questions my brain was designing during the exam aren't going away. They're the next labs.

Build. Document. Share. Repeat.

What's Next

The GitHub repo for this series lives at github.com/rivadaviam/aws-genai-cert-learning-journey. Lab 01 is there with full code, architecture diagrams, and ADRs.

If you're preparing for this certification:

Low commitment: Star the repo and follow along as I build the next lab
Medium commitment: Try building your own version of Lab 01 before your exam. Document one decision with an ADR.
High commitment: Share what you build publicly. The accountability changes everything.

The messy middle is where learning lives. Welcome to it.

Have you taken this certification? What surprised you most about the exam? Drop it in the comments — I'd genuinely like to know.

BuildToLearn #AWSCommunity #LearnInPublic #AmazonBedrock

The Build-to-Learn Framework: How a Near-Disaster Taught Me to Learn in Public

Martín Rivadavia — Wed, 04 Feb 2026 22:20:47 +0000

I almost created an infinite loop that would have cost me thousands in AWS bills.

And I'm grateful it almost happened.

The Setup

When I decided to pursue the AWS Certified Generative AI Developer certification, I made myself a promise: I wouldn't just study for an exam. I would build real systems, make real mistakes, and share everything publicly—including the wrong turns.

The AWS Skill Builder course has these "Bonus Assignments" scattered throughout. Most people skip them or treat them as quick checkboxes.

I saw something different: each one was an invitation to build something production-ready.

My first assignment: an automated insurance claim processing pipeline using Amazon Bedrock.

User uploads to S3 → Lambda orchestrates 3-step Bedrock pipeline → Results saved to output bucket

The Near-Disaster

My initial architecture was elegant. One S3 bucket, two prefixes:

/input for uploaded documents
/output for processed results

Clean. Simple. Catastrophic.

Here's what happens with that design:

1. Document lands in /input
2. Lambda triggers, processes document
3. Result written to /output (same bucket)
4. S3 event triggers Lambda again
5. Lambda processes the output file...
6. → Infinite loop. Infinite cost.

I caught this because I was writing an Architecture Decision Record—ADR-002—explaining my bucket strategy.

The act of documenting forced me to think through the consequences. Mid-sentence, I realized what would happen in production.

# ADR-002: Separate S3 Buckets for Input and Output

## Decision
Use separate S3 buckets for input and output

## Consequences
- Prevents infinite loop scenarios
- Better security isolation
- Different lifecycle policies per bucket
- Slight increase in bucket management complexity

## Why This Choice
Following AWS best practices prevents production issues.
The slight complexity increase is worth avoiding infinite loops.

That ADR saved me real money. But more importantly, it taught me something:

Documentation isn't overhead. It's thinking made visible.

The Build-to-Learn Framework

That near-miss crystallized into a methodology I now follow for every lab: build real things, document every decision, and share the messy middle.

Not tutorials. Not sandboxes. Production-grade systems with real constraints — the kind where a wrong architecture choice costs actual money. For every significant decision, I write an Architecture Decision Record capturing the why, not just the what. And when I share the work, I don't polish away the wrong turns. The trade-offs, the moments of doubt, the diagrams I scrapped at midnight — those are the parts that actually help someone else learn.

The Implementation

Instead of one monolithic prompt, I designed a three-step AI pipeline where each step uses the optimal model:

Step	Model	Why
Document Understanding	Claude 3.5 Sonnet	Complex reasoning needed
Information Extraction	Claude 3.5 Sonnet	Precision for structured JSON
Summary Generation	Claude 3 Haiku	Cost-efficient for simple output

Step 1: Document Understanding

def process_document_understanding(document_text, model_id, template_manager):
    """Analyze and understand the document structure and content."""
    prompt = template_manager.get_prompt(
        "document_understanding",
        document_text=document_text
    )

    return invoke_bedrock_model(
        model_id,
        prompt,
        temperature=0.1,  # Low temperature for accuracy
        max_tokens=2000
    )

Why this step? Complex documents need context before extraction. Understanding the document type (auto claim vs. health expense) improves downstream accuracy.

Step 2: Information Extraction

def extract_information(document_text, model_id, template_manager):
    """Extract structured information from the document."""
    prompt = template_manager.get_prompt(
        "extract_info",
        document_text=document_text
    )

    result = invoke_bedrock_model(
        model_id,
        prompt,
        temperature=0.0,  # Zero temperature for deterministic output
        max_tokens=1500
    )
    return result

Key insight: Using temperature=0.0 ensures consistent, deterministic extraction. This matters when downstream systems depend on specific JSON fields.

Step 3: Summary Generation

def generate_summary(extracted_info, model_id, template_manager):
    """Generate a concise summary of the claim."""
    prompt = template_manager.get_prompt(
        "generate_summary",
        extracted_info=extracted_info
    )

    return invoke_bedrock_model(
        model_id,
        prompt,
        temperature=0.7,  # Higher temperature for natural language
        max_tokens=500
    )

Why Haiku here? The heavy lifting is done. We're just formatting extracted data into prose. Claude 3 Haiku does this well at ~10x lower cost than Sonnet.

This decision is captured in ADR-005:

# ADR-005: Use Claude 3 Haiku for Summary Generation

## Decision
Use Claude 3 Haiku for summary generation (not Sonnet)

## Rationale
- Summaries are the final step - context is already extracted
- Haiku is ~10x cheaper than Sonnet
- Quality is sufficient for 2-3 sentence summaries
- Maintains on-demand throughput support

## Trade-off
Slight quality reduction for significant cost savings

Model Selection: The Certification Question

If you're preparing for AIP-C01, model selection is a core exam topic — and this project gave me a real-world taste of the trade-offs involved.

One decision surprised me. Claude 3.5 Sonnet v2 is newer and, on paper, "better" than v1. But when I dug into availability, I discovered that on-demand throughput isn't guaranteed in all regions and might require Provisioned Throughput. For a learning project that other developers will clone and deploy in their own accounts, availability matters more than marginal quality improvements. So I chose v1 — a stable, widely available model that anyone can spin up without provisioning headaches. It was a small decision, but exactly the kind of reasoning the certification expects you to articulate.

The Infrastructure

The entire stack is defined in Terraform, which means anyone can deploy it with a single terraform apply. Here's the Lambda at the heart of it:

resource "aws_lambda_function" "processor" {
  function_name = "${var.project_name}-processor"
  runtime       = "python3.12"
  handler       = "lambda_handler.handler"
  timeout       = 300   # 5 minutes
  memory_size   = 512   # MB

  environment {
    variables = {
      OUTPUT_BUCKET               = aws_s3_bucket.output.id
      BEDROCK_MODEL_UNDERSTANDING = "anthropic.claude-3-5-sonnet-20240620-v1:0"
      BEDROCK_MODEL_EXTRACTION    = "anthropic.claude-3-5-sonnet-20240620-v1:0"
      BEDROCK_MODEL_SUMMARY       = "anthropic.claude-3-haiku-20240307-v1:0"
    }
  }
}

The numbers tell a story. A typical run — three sequential Bedrock calls — takes 30 to 90 seconds, but I set the timeout to 5 minutes to absorb cold starts, larger documents, and network latency. Memory sits at 512 MB: enough headroom for boto3 and JSON processing without overpaying for capacity the function will never touch. Both values came from testing, not guessing — another benefit of building before theorizing.

What I Learned (Beyond the Tech)

The biggest surprise wasn't technical — it was how much the act of writing things down changed my engineering decisions. ADRs forced me to justify every choice, and several times I reversed course mid-sentence because explaining a decision out loud revealed the flaw in it. Documentation isn't a chore you do after the code works; it's a design tool you use while the code is still taking shape.

Building locally first saved me real money, too. The system supports running the full pipeline on your own machine (python main.py --input claim.txt --output result.json), so I processed dozens of test documents before a single Lambda invocation or Bedrock API call ever hit my AWS bill.

And here's what connected everything back to the certification: every core topic from the Skill Builder course — model selection criteria, prompt engineering, cost optimization, security best practices, serverless patterns — showed up organically in this one project. I didn't have to memorize them. I had to use them, and that made them stick.

What's Next

This is just the beginning. I'm continuing to build through the AWS GenAI certification curriculum, turning each challenge into a production-ready implementation. More labs are coming — each one following the same Build-to-Learn principles: production-ready code you can actually deploy, every decision documented with ADRs, and the messy middle shared so you learn from my mistakes too.

Want to follow along? Star the repo or connect with me on LinkedIn to get notified when the next lab drops.

Try It Yourself

The entire project is open source. Clone it, read the ADRs, poke around the Terraform — and if you find a flaw in my implementation, open an issue. If you have a better approach, propose it.

rivadaviam / aws-genai-cert-learning-journey

Public learning journey for the AWS Generative AI Certification. Hands-on labs, bonus assignments, and real-world experiments designed to help others learn and build with AWS GenAI services.

AWS Generative AI Learning Journey

Learn in public, build in production. This repository is a hands-on journey through AWS Generative AI services, focusing on Amazon Bedrock and real-world use cases. Each lab is production-ready, well-documented, and designed to teach you not just what to build, but why we made these choices.

Why This Journey Exists

Generative AI is transforming how we build applications, but learning it can feel overwhelming. This repository breaks down complex AWS AI services into practical, reproducible labs. You'll build real systems, understand architectural trade-offs, and learn from decisions documented in Architecture Decision Records (ADRs).

What makes this different:

✅ Production-ready code - Not just demos, but real implementations
✅ Decision transparency - Every architectural choice is documented with rationale
✅ Learn from mistakes - We share what worked, what didn't, and why
✅ Community-first - Built to help others learn and contribute

Certification Context

This repository…

View on GitHub

# Clone and explore
git clone https://github.com/rivadaviam/aws-genai-cert-learning-journey.git
cd labs/lab-01-claims-doc-processing

# Read the full guide
cat README.md

# Deploy with Terraform
cd infra/terraform
terraform init && terraform apply

The Invitation

If you're preparing for a certification, don't just study. Build something real. Document your decisions. Share your journey. And if you build something using this framework, tell me about it — I want to see what you create.

Certifications prove you can learn.
Projects prove you can build.
Documentation proves you can teach.

The Build-to-Learn Framework asks: why not do all three?

Have questions? Connect with me on LinkedIn or drop a comment below.

Build. Document. Share. Repeat.

#BuildToLearn #AWSCommunity #LearnInPublic