DEV Community: Saurabh "Rob" Dahal

Help Your Coding Assistant Find the Right Code in Large Repos

Saurabh "Rob" Dahal — Fri, 16 Oct 2026 16:53:48 +0000

Get the starter: sdahal1/repo-search-workshop on GitHub. The reproduction, searches, tests, and typecheck were rehearsed locally on October 16, 2026, with Node.js 24.10.0, npm 11.6.0, ripgrep 15.2.0, and ast-grep 0.51.0. The published repository was cloned and its starter revision verified. The supplied local folder and Git bundle also work for this guide.

Author: Saurabh Rob Dahal, Developer Advocate, AWS

Description: Investigate a TypeScript retry bug using repository mapping, ripgrep, ast-grep, symbol navigation, and an evidence note you can use with different coding assistants.

Level: Beginner · Time: 60 minutes with a facilitator, after setup

A coding assistant can suggest a plausible fix before it understands a repository. A useful investigation makes its reasoning checkable: where does the behavior live, what evidence explains it, and which checks would distinguish a correct fix from a partial one?

In this workshop, you will investigate one prepared bug. A client configured with maxRetries: 0 still makes three requests when its transport fails. You will follow that setting across files, ask an assistant for a supported explanation, and make a small change.

The bug is deliberately small. The practice is learning how to approach unfamiliar code without reading every file or accepting the first plausible explanation. The same approach is useful when an application setting behaves unexpectedly, a wrapper changes an argument, or an error originates in another package.

Each step answers a different question. If the evidence is incomplete, return to a focused lookup before editing.

You can follow along with Kiro, Codex, Claude Code, or another assistant that can read your project, run shell commands, and edit files. Choose a coding model supported by your tool. The exercise uses ordinary commands and a Markdown note, so it does not depend on a particular model, context window, or project-memory format.

Your editor supplies definition and reference navigation. No AWS account, credentials, or cloud deployment is required. If you are working independently, pause at the evaluation prompts and take the time you need.

Before the workshop

You need Git, Node.js 24 with npm, ripgrep, and an editor with TypeScript definition and reference navigation. You should be comfortable opening a terminal and editing a text file. Complete your chosen assistant's sign-in before the session.

The commands use a Bash-compatible shell: Terminal on macOS, a Linux terminal, or WSL on Windows. Run commands from the repository root unless a step says otherwise. Copy the contents of a command block without adding a leading $ prompt.

Install ripgrep using the official installation instructions. On a Mac with Homebrew:

brew install ripgrep

Use a fresh checkout. Choose one of these routes, then run the shared setup below. Clone the workshop starter repository:

git clone https://github.com/sdahal1/repo-search-workshop.git repo-search-workshop
cd repo-search-workshop

If you already have the supplied local folder, skip cloning and enter it:

cd repo-search-workshop

If you have repo-search-workshop.bundle in your current directory, create a checkout from that local Git bundle instead:

git clone --branch starter ./repo-search-workshop.bundle repo-search-workshop
cd repo-search-workshop

From the repository root, pin the workshop's starter revision and install its dependencies:

git checkout --detach 5280be1e6659942e2335b10bde88b1fccdf9b76d
git switch -c workshop/my-investigation
node --version
npm --version
rg --version
npm ci
npx --no-install ast-grep --version
git status --short

The checkout puts everyone on the same source revision. The new branch gives you a place to keep your work. The starter pins @ast-grep/cli to 0.51.0 as a development dependency. npm ci installs dependencies from the committed lockfile without updating it. npm ci documentation

Check your setup: Node should report version 24, ast-grep should report 0.51.0, and git status --short should produce no output in this fresh checkout. Open the entire repository folder in your editor so it can find the TypeScript project configuration.

The npx commands use the installed project executable. If npm offers to download a package, stop and check that installation succeeded and that you are in the repository root.

The starter provides a fake transport, a failing regression test, an investigation template, and a saved AST rule. A transport is the component that performs the underlying request. Here, a small local function stands in for it, records calls, and fails predictably. No real service is involved.

You may type each command yourself or ask the assistant to run the exact command. For the first pass, run the searches yourself so you can connect their inputs to their results. Later, delegate those same steps with an explicit scope.

1 Show the failure

Time: 0–4 minutes

Concept: A reproduction turns a report into an observable difference between expected and actual behavior. It also gives you a check to run after editing.

The report says: “I set maxRetries to zero, but the client still retries.” Before investigating, define what counts as a retry. In this project, it is an additional attempt after the initial request. Therefore:

total attempts when every request fails = 1 + allowed retries
zero retries = one initial attempt

Count transport calls, including the initial request. The symptom does not yet tell us which function is responsible.

Task: Run the demo, then the focused test:

npm run demo
npm run test:repro

Expected result before the fix: The demo records three transport calls for maxRetries: 0. The focused test fails because it expects one call and observes three. A failing assertion is intentional here; a missing-module or command-not-found error is a setup problem.

The local rehearsal confirmed this failure. The full starter suite ran 11 tests: 10 passed, and only the zero-retries reproduction failed. Typechecking passed before the fix, showing that this behavioral bug is not a type error.

Evaluate: Open packages/client/test/client.test.ts. Find where the test supplies zero to the public client API, where the fake transport increments its counter, and where the test checks the final count. Confirm that the test observes behavior through the public API rather than directly testing a helper expression.

Write the reproduction command, expected count, and actual count in workshop/INVESTIGATION.md. Do not change an assertion to match the current behavior.

Teaching moment: “The transport ran three times” is evidence. “The retry loop is off by one” is a hypothesis. Other explanations are possible: the option might be dropped, defaulted incorrectly, or interpreted differently. Keep those possibilities open until you trace the value.

2 Map the repository

Time: 4–12 minutes

Concept: A repository map identifies responsibilities and boundaries. It helps you choose where to look before spending time on implementation details.

Task: Run:

git ls-files
git ls-files 'README*' '*package.json' '*tsconfig*.json'
git ls-files 'packages/client/*'

The first command shows tracked paths. The next commands narrow that inventory to project descriptions, manifests, TypeScript configuration, and the client package. Quoting the patterns passes them to Git instead of asking the shell to expand them. git ls-files documentation

Open README.md, the root package.json, packages/client/package.json, and docs/client-options.md. Find the test scripts and the meaning of maxRetries. A manifest describes a package's dependencies, scripts, and entry points; it helps connect a folder to what the project runs.

Use the map to choose a starting area. The relationships must still be confirmed in source and tests.

Ask your assistant:

Map this repository using its tracked file paths, README, package
manifests, and docs/client-options.md. Do not edit files.

Identify the package most likely to own the reported retry behavior.
Explain your choice using paths and documented responsibilities.
Do not read every implementation file yet.

Expected result: packages/client is the likely owner. Its src directory contains implementation and its test directory contains the reproduction. The option documentation establishes that zero is valid.

Evaluate: Write one sentence explaining why the client package is relevant. “It has client in its name” is a starting clue. A documented responsibility and a reproduction that imports the package are stronger support.

Also identify the package's test command before editing. That prevents the assistant from guessing how the project is verified.

Teaching moment: A map is a working hypothesis about ownership. Expand your scope if imports lead elsewhere. git ls-files is an inventory of tracked files; it does not include every untracked file on disk, and it does not describe runtime behavior.

3 Search by text

Time: 12–18 minutes

Concept: Text search is useful when you know a name, error, or literal value. It finds mentions in code, tests, comments, and documentation.

Task: Search the owning package and option documentation:

rg -n -F 'maxRetries' packages/client docs/client-options.md
rg -n -C 3 -F 'maxRetries' packages/client/src

rg runs ripgrep. -n displays line numbers, -F treats the query as literal text, and -C 3 includes three surrounding lines. The final arguments select where to search. ripgrep guide

Expected result: Matches lead to the option type, request path, retry implementation, and regression test. Read a result as a location to inspect, not a complete explanation. Open the enclosing function when three surrounding lines are insufficient.

Choose the search that matches your question. These tools complement one another throughout an investigation.

Evaluate: Classify useful matches by their role:

Kind of match	What to learn from it
Option definition	Which values the API accepts
Caller or wrapper	Whether the value is forwarded or transformed
Implementation	How the value affects behavior
Test	Which behavior is asserted
Documentation	What behavior is promised

Add useful paths and symbols to your investigation note. Record actual line numbers from your checkout; the article does not prescribe fixed line numbers.

If the search returns nothing, first check spelling, case, and your directory. A zero-result search means no matching text was found in the searched scope. It does not prove the behavior is absent from the program.

Teaching moment: A matching name does not establish a call relationship. Two modules may declare independent variables with the same spelling. Text search finds candidates; symbol navigation will help you distinguish them.

4 Search by structure

Time: 18–23 minutes

Concept: An abstract syntax tree, or AST, represents code through syntax nodes and their relationships. An expression such as left || right has an operator and two operands. Structural search asks for that arrangement while allowing selected parts to vary. ast-grep core concepts

You already know the option's name. Now ask a second question: where does the code use an OR expression that might supply a fallback? This is useful when the same structure appears under different variable names or across multiple lines.

Task: Start with the operator as literal text:

rg -n -F '||' packages/client/src

Keep -F: the pipe character has special meaning in regular expressions. Then run the prepared structural query:

npx --no-install ast-grep run --lang ts \
  --pattern '$VALUE || $FALLBACK' packages/client/src

Here, run performs a one-time search, --lang ts selects TypeScript, and --pattern supplies the code shape. There is no rewrite argument, so this command does not modify code. ast-grep run reference

Understand the placeholders

$VALUE and $FALLBACK are metavariables that match syntax nodes. Leave those names in the command. Keep the single quotes so the shell passes the dollar signs unchanged instead of expanding shell variables. ast-grep quick start

For this candidate:

options.maxRetries || DEFAULT_MAX_RETRIES

the left capture is options.maxRetries and the right capture is DEFAULT_MAX_RETRIES. The names VALUE and FALLBACK are labels we chose; they do not tell ast-grep what the author intended.

The simplified tree shows what stays fixed—the OR operator—and what the metavariables can capture.

Compare matches and counterexamples

Consider these illustrative snippets. They explain the pattern; they are not claimed to be exact starter files.

const a = options.maxRetries || DEFAULT_MAX_RETRIES;

const b = options.timeoutMs
  ||
  5000;

const allowed = isAdmin || isOwner;

// options.maxRetries || DEFAULT_MAX_RETRIES
const explanation = "options.maxRetries || DEFAULT_MAX_RETRIES";

const enabled = isReady && hasPermission;

The broad pattern matches the OR expressions assigned to a, b, and allowed. The multiline expression still has the requested shape. The comment and string are not executable OR expressions, and the final expression uses a different operator. ast-grep pattern syntax

isAdmin || isOwner is a valuable counterexample: it matches, but the boolean logic may be entirely correct. A syntax match is not a bug diagnosis. The tool does not know whether zero is meaningful to this particular API.

Narrow and save the query

Require the property name while leaving the object and right-hand expression variable:

npx --no-install ast-grep run --lang ts \
  --pattern '$OPTIONS.maxRetries || $FALLBACK' packages/client/src

Expected result: The candidate in packages/client/src/retry.ts remains. The object name can vary, so config.maxRetries || 2 also matches. However, this narrower pattern would miss options['maxRetries'] || 2 or a property read first assigned to a local variable. That is a reason to inspect the surrounding code, not a reason to search every possible expression at once.

The starter's workshop/defaulting.yml saves the broad query:

id: find-or-expressions
language: TypeScript
rule:
  pattern: $VALUE || $FALLBACK

Run it with:

npx --no-install ast-grep scan \
  --rule workshop/defaulting.yml packages/client/src

The rule gives the query a name and language so someone else can repeat it. ast-grep rule essentials

In the pinned starter, the broad query returns four candidates: the multiline request-label expression, the trace expression, the retry-input validation condition, and the retry-setting expression. The first three implement intentional behavior. The narrowed query returns only the candidate in retry.ts. Compare these results with the literal text search, which also finds mentions inside a comment and a string.

Evaluate: Explain why each relevant match deserves inspection. Compare what text search found with what the structural query found. Save the candidate and its enclosing symbol in your note.

Teaching moment: Structural search reduces ambiguity about code shape. It does not establish runtime values, symbol identity, or business intent. Those need different evidence.

5 Follow the symbols

Time: 23–28 minutes

Concept: Symbol navigation resolves an identifier to its declaration and finds uses of that declaration. It helps answer which function is actually involved when names repeat or imports are renamed.

For example, a module could import withRetry as runWithRetries. Searching only for the original name might find the import but miss calls written with the alias. Definition navigation can connect those uses through the project language service.

Task: In your editor:

Open the reproduction test and use Go to Definition on createClient.
In packages/client/src/client.ts, locate the request path and the call to withRetry.
Use Go to Definition on withRetry to reach packages/client/src/retry.ts.
Use Find References on its definition to inspect the callers.
Inspect ClientOptions in packages/client/src/types.ts and compare it with the documented contract.

Use the editor's context menu or command palette to find these actions. The names and shortcuts can differ; for one concrete implementation, see TypeScript navigation in Visual Studio Code.

Confirm the arrows by navigating definitions and inspecting callers. The picture illustrates the starter's relationships; it is not a screenshot or a generated runtime trace.

Expected result: You can follow the option from the public client API to the retry implementation. Check whether the wrapper forwards zero unchanged before interpreting the defaulting expression.

Evaluate: Record the caller and callee paths and symbols. A reference result may be a declaration, import, or call. Read it before recording a call relationship. Navigation also does not prove that a branch executed during the reproduction; combine it with the test and implementation.

Teaching moment: Language Server Protocol, or LSP, standardizes communication for code intelligence. Editors can also provide TypeScript navigation through their own language-service integrations. The shared requirement here is working definition/reference navigation. There is no universal lsp terminal command, and your assistant does not need direct LSP access. LSP specification

6 Gather evidence before asking for a fix

Time: 28–36 minutes

Concept: A short investigation note separates observations from interpretations and makes your context portable. Another assistant or teammate can inspect the same evidence without reconstructing a long conversation.

Keep the evidence compact enough to review, but specific enough to reproduce and challenge.

Task: Complete workshop/INVESTIGATION.md:

# Investigation

## Observed behavior
Reproduction command:
Expected behavior:
Actual behavior:

## Repository area
Owning package and evidence:

## Relevant code
Paths, symbols, actual line numbers, and caller relationships:

## Constraints
Preserve the public API and omitted-option behavior.
Keep the fake transport and meaningful assertions.

## Root cause hypothesis
Leave blank until the next step.

## Proposed modification points
Leave blank until the next step.

## Verification
npm run test:repro
npm test
npm run typecheck
git status --short
git diff
git diff --check

An evidence entry might say, “The reproduction passes zero at the public API and observes three transport calls.” Attach the actual test location. A hypothesis would say, “A defaulting expression may replace zero before the loop runs.” Keeping these in different sections makes it easier to notice what remains unproven.

Include a short reason beside each source location. “This wrapper forwards the option” is more useful than a list of six paths with no explanation. Leave out unrelated search results and large copied files; the assistant can open the referenced code.

Evaluate: Could someone who missed the walkthrough reproduce the failure and locate the relevant expressions from your note? Could they tell which claims you observed and which still require checking?

Teaching moment: Good context is selected evidence with an explicit purpose. Paths and symbols help someone relocate it; line numbers identify positions in this checkout and may move after edits.

7 Explain the root cause before editing

Time: 36–43 minutes

Concept: A supported hypothesis connects the input, the transformation, and the observed output. Evaluate that connection before changing code.

Task: In a fresh or existing assistant conversation in the same checkout, paste:

Read workshop/INVESTIGATION.md. Do not edit files.

Inspect the referenced code and explain the failing behavior.
If evidence is missing, identify the next focused lookup needed.

Return:
- Your root-cause hypothesis.
- Supporting paths, symbols, and actual line numbers.
- Any uncertainty or competing explanation.
- The smallest proposed change and expected modified files.
- Tests that distinguish a correct fix from a partial fix.

Stop before editing.

You may use a plan or read-only mode if your tool provides one. The explicit instruction is still useful because it tells the assistant what deliverable you want at this stage.

Expected explanation: 0 || DEFAULT_MAX_RETRIES selects the default because zero is falsy. With a default of two retries, the always-failing transport receives one initial call plus two retries. The ?? operator uses its fallback only for null or undefined, preserving zero. TypeScript nullish coalescing documentation

The operator table explains language behavior. Its null, false, and empty-string examples do not expand the client's numeric input contract.

For a text version of the diagram:

| Left value (x) | x \|\| 2 | x ?? 2 | API meaning here |
| --- | --- | --- | --- |
| 0 | 2 | 0 | Valid: disable retries |
| undefined | 2 | 2 | Omitted option: use the default |
| 1 | 1 | 1 | Valid: allow one retry |
| null | 2 | 2 | Language example, outside the option type |
| false | 2 | false | Language example, outside the option type |
| '' | 2 | '' | Language example, outside the option type |

Neither operator validates input. The proposed change corrects defaulting for values already allowed by the API.

Evaluate: Check three links in the explanation:

The public contract allows zero, and the wrapper delivers it unchanged.
The identified expression replaces zero with the documented default of two.
The retry loop interprets two as additional attempts, producing three total calls.

If one link is missing, perform the next focused lookup. An answer that simply recommends ?? has not yet explained the whole symptom. A proposed loop change also needs evidence that the loop itself is wrong.

Optional self-check in your terminal:

node -e 'console.log({ or: 0 || 2, nullish: 0 ?? 2 })'

The expected values are or: 2 and nullish: 0. This checks language behavior in isolation; it does not prove the repository's value follows that path. The earlier evidence establishes that connection.

Update the hypothesis and proposed modification sections of your note. Do not broaden the API to accept null, strings, or booleans just because the operator table includes them.

Teaching moment: Different models may phrase the explanation differently. Judge the evidence and predicted behavior. A useful hypothesis also tells you what you should observe after the fix.

8 Make the narrow change and verify it

Time: 43–56 minutes

Concept: A fix must correct the reported behavior and preserve the surrounding contract. Test results and diff review provide different parts of that evidence.

Task: After checking the explanation, tell the assistant:

Apply the smallest change supported by our investigation.
Preserve the public API and default retry behavior.
Keep the reproduction's original assertion intact.
Add focused regression coverage only where it is missing.
Do not refactor unrelated code or update dependencies.
Do not stage or commit the changes.
Run the verification commands in workshop/INVESTIGATION.md.
Report the modified files and actual results, including failures.

The expected production change is:

- const retries = options.maxRetries || DEFAULT_MAX_RETRIES;
+ const retries = options.maxRetries ?? DEFAULT_MAX_RETRIES;

If you are editing manually, make the same justified change in the editor. Avoid a global replacement of ||: other matches may intentionally use boolean logic or falsy-value defaults.

Run the checks yourself if the assistant has not run them:

npm run test:repro
npm test
npm run typecheck
npm run demo
git status --short
git diff
git diff --check

Evaluate the behavior

A useful test matrix checks the repaired boundary and nearby behavior that should remain valid.

With the fake transport failing on every attempt, verify:

Input	Expected total transport calls after the fix	Why check it
`maxRetries: 0`	1	Reproduces the reported boundary
Option omitted, default of 2	3	Preserves the default
`maxRetries: 1`	2	Preserves explicit positive values

Also preserve immediate success: when the first request succeeds, there should be one call, regardless of a larger retry allowance. A retry budget allows extra attempts after failure; it does not require them after success.

The rehearsed solution passed the reproduction, all 11 tests, and typechecking; its demo showed one call for zero retries. Those are the expected results for your fix. Read the test output rather than accepting a summary that says “looks good.” Check which command ran and whether it completed successfully.

Evaluate the change

Inspect every changed file. The investigation note is expected to change. Production edits should be limited to the justified implementation; test edits should strengthen coverage while preserving the reproduction's original assertion.

Ask why any dependency lockfile, public type, unrelated helper, or large formatting block changed. Such edits need their own justification. Also inspect untracked files reported by git status, because a normal diff does not display their contents.

git diff shows unstaged tracked changes. If you staged anything, also run git diff --cached. git diff --check checks whitespace errors; silence does not establish behavioral correctness. git diff documentation

Teaching moment: The reproduction checks the bug. Nearby tests check preserved behavior. Typechecking checks type compatibility. Diff review checks the scope and meaning of edits. A passing check cannot answer all four questions.

Finish with a reusable investigation

Time: 56–60 minutes

Explain the bug to a partner in three sentences: what failed, where the value changed meaning, and how you verified the fix. Point to evidence for each sentence.

Then name the question each tool answered. Text search found mentions. AST search found a code shape. Symbol navigation connected definitions and uses. Tests observed behavior. Your investigation note connected those findings into an explanation someone else could review.

On your next unfamiliar repository, start with a reproducible symptom and a small map. Choose searches according to the question you need answered. Expand the scope when the evidence requires it, and give your assistant a clear boundary between investigating and editing.

If a step behaves differently

Symptom	Next check
`rg` is not found	Install ripgrep, reopen the terminal, and run `rg --version`.
ast-grep is missing or the version differs	Return to the repository root; confirm `npm ci` succeeded with development dependencies installed.
AST search has no matches	Check the directory, TypeScript language flag, and single quotes. Confirm you still have the unfixed starter.
Definition navigation fails	Open the repository root, install dependencies, and confirm the editor recognizes the TypeScript project. Follow imports manually while fixing navigation.
The reproduction already passes	Inspect the checkout and existing diff. You may have the solution or a previous edit. Preserve your work and use a fresh starter checkout.
A test reports a setup error	Resolve that error before interpreting it as evidence of the retry bug.
The assistant edits during investigation	Inspect the diff before continuing. Preserve your note and use a fresh starter checkout if needed.
The fix passes one test but breaks another	Compare the failing case with the documented contract; revisit the hypothesis instead of weakening an assertion.

No cloud resources are created by this exercise, so there is no AWS cleanup step. Keep your checkout to reuse the investigation note and commands.

Setting up the Agent Toolkit for AWS in Kiro (and Codex, Claude Code, and Cursor)

Saurabh "Rob" Dahal — Tue, 30 Jun 2026 12:59:54 +0000

If you've let a coding agent loose on AWS, you've watched it guess. It invents API parameters that don't exist, or hands you an S3 bucket a security review will bounce on sight. The Agent Toolkit for AWS is built to stop that. By the end of this post you'll have it running in whatever editor you use, plus a tour of what's in it and three workflows worth pointing it at.

I use Kiro day to day, so I'll walk through that setup first. It also works with Codex, Claude Code, Cursor, and any other agent that speaks MCP, the Model Context Protocol, which is the open standard agents use to connect to outside tools and data. I'll cover those too.

What is the Agent Toolkit for AWS?

The Agent Toolkit for AWS is a free, AWS-supported set of tools that gives AI coding agents secure access to AWS, current documentation they can read mid-task, and tested procedures for the work they tend to fumble. It plugs into the agent you already use rather than asking you to switch. In practice, that shows up in a few ways, all detailed in the AWS user guide.

The agent stops guessing about APIs it never saw. The models behind these agents trained on data that's months or years old, so anything AWS shipped recently is missing or wrong in their heads, and the toolkit hands them current docs and references at request time. For multi-step work like least-privilege IAM or a production serverless stack, it follows a vetted skill instead of reconstructing the steps from half-memory. Every call goes through your own IAM credentials, shows up in CloudWatch, and gets logged to CloudTrail, so you can scope an agent to read-only even when your role can write. And the toolkit costs nothing on its own; you pay only for the AWS resources the agent creates.

It's the successor to the MCP servers, skills, and plugins AWS shipped under AWS Labs in 2025. Two things make me reach for it over a raw MCP setup: condition keys that let a policy tell an agent apart from a human, and skills that have been evaluated end to end rather than thrown over the wall.

What's included: the MCP server, skills, plugins, and rules files

Four components work together (reference).

The AWS MCP Server is the access layer, a single endpoint that reaches 300+ AWS services. It runs in two modes depending on what you ask for. Searching AWS docs, pulling service info, and discovering skills need no credentials at all, so the server is useful the moment you connect it. Anything that touches your account, real API calls and the sandboxed Python run_script tool, runs as you through your local AWS credentials. It also stamps two condition keys on every request, aws:ViaAWSMCPService and aws:CalledViaAWSMCP, so your policies can single out agent traffic.

Skills are curated packages of instructions, scripts, and reference material for one task. The agent loads a skill only when it needs it, so they barely touch your context until they're relevant.

Plugins bundle the MCP config and a curated skill set into one install. They're available for Claude Code, Codex, and Cursor; Kiro and other MCP agents connect to the server directly instead, which I cover in the setup steps below. Four ship today:

Plugin	Covers
`aws-core`	Service selection, CDK/CloudFormation, serverless, containers, storage, observability, billing, SDK usage, deployment. Start here.
`aws-agents`	Building AI agents on AWS with Amazon Bedrock and AgentCore.
`aws-data-analytics`	Data lake, analytics, and ETL with S3 Tables, AWS Glue, and Athena.
`aws-agents-for-devsecops`	Incident investigation, code review, UAT, vulnerability scanning, and pen testing with AWS DevOps Agent and AWS Security Agent.

Rules files are project-level config that sets guardrails: use the MCP Server, find a skill before acting, check the docs, prefer infrastructure-as-code. Rules decide how the agent behaves; skills supply what it does for a given job.

Which skills does the Agent Toolkit include?

The skills are the part I underestimated at first. There are around 64 today (browse the skills/ directory for the live list), split into core and specialized.

Core skills, which ship with aws-core:

amazon-bedrock, aws-billing-and-cost-management, aws-blocks, aws-cdk, aws-cloudformation, aws-containers, aws-iam, aws-messaging-and-streaming, aws-observability, aws-sdk-js-v3-usage, aws-sdk-python-usage, aws-sdk-swift-usage, aws-serverless, signing-in-to-aws.

Specialized skills, grouped by domain (a few from each):

Serverless (9): connecting-lambda-to-api-gateway, connecting-lambda-to-dynamodb, debugging-lambda-timeouts, processing-s3-uploads-with-step-functions
Analytics (10): querying-data-lake, ingesting-into-data-lake, managing-amazon-msk, amazon-opensearch-service
Database (8): amazon-aurora-postgresql, amazon-elasticache, exporting-rds-to-s3, rds-db2
Networking (5): creating-production-vpc-multi-az, routing-traffic-with-route53-and-cloudfront
Storage (5): securing-s3-buckets, creating-data-lake-table, storing-and-querying-vectors
EC2 (3), Operations (3), System table (3), Migration (2), Security and identity (1), Web and mobile (1)

Don't memorize the list. When you ask for "a Lambda behind API Gateway writing to DynamoDB," the agent pulls the matching skills on its own.

Prerequisites

A handful of things need to be in place first. None take long.

An AWS account. Anything that touches AWS needs one. Sign up here if you don't have one yet.
AWS credentials on your machine, for the parts that act on your account. The server still connects and answers documentation and skill questions without them, but API calls and run_script need them. The proxy reads the standard AWS credential chain, so aws configure, an SSO login, a named profile, or the usual environment variables all work. New to this? Configuring the AWS CLI is the simplest path. The CLI is the common way to set credentials, not a hard requirement.
uv, a Python package tool that runs the MCP proxy. Install it with brew install uv on macOS, or the official installer elsewhere. The uvx command in the Kiro config below comes bundled with it.
Node.js, which gives you the npx command used to install skills. If npx --version prints nothing, install it from nodejs.org.
AWS CLI 2.35.0 or later, but only if you use the one-command wizard below. Check with aws --version.

How to set up the Agent Toolkit for AWS

The quickest route is the AWS CLI wizard, which configures every agent you have at once. Prefer to do it by hand, or only use one editor? Skip to the per-agent steps below.

Set up every agent at once with the AWS CLI

On a recent AWS CLI, one command detects your installed agents, installs default skills, and configures the MCP Server for all of them:

aws configure agent-toolkit

One gotcha worth calling out, because I hit it. On an older CLI you'll see:

aws: [ERROR]: argument subcommand: Found invalid choice 'agent-toolkit'

That means your AWS CLI predates 2.35.0. Update it (instructions), confirm with aws --version, and rerun. Restart your agent afterward so it picks up the new MCP config.

If you only use one agent, or you want to see exactly what gets wired up, the per-agent steps below do the same thing by hand.

Kiro

Open your Kiro MCP config and add the AWS server. Use .kiro/settings/mcp.json for the current project, or ~/.kiro/settings/mcp.json to turn it on everywhere. Create the file if it doesn't exist yet:

{
  "mcpServers": {
    "aws": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@1.6.3",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--metadata", "AWS_REGION=us-west-2"
      ]
    }
  }
}

If your config already lists other servers under mcpServers, add the aws entry next to them instead of replacing the block, and keep the JSON valid (mind the commas). Change AWS_REGION to the region you work in.

Pin the proxy version rather than tracking latest. You get reproducible behavior and a guard against a bad release. Check PyPI every few weeks and bump it on purpose.

Then install the skills:

npx skills add aws/agent-toolkit-for-aws/skills

Open Kiro's MCP Server view (the Kiro panel in the sidebar, or search "MCP" in the command palette), reconnect the aws server, and you're live.

Codex

Add the marketplace, then install from inside Codex:

codex plugin marketplace add aws/agent-toolkit-for-aws

Launch Codex, run /plugins, and install aws-core.

Claude Code

The plugins live on the official Anthropic marketplace, included by default:

/plugin install aws-core@claude-plugins-official

Hit Plugin not found? Refresh the index with /plugin marketplace update claude-plugins-official and try again. Add aws-agents, aws-data-analytics, or aws-agents-for-devsecops the same way.

Cursor

Add the repo as a team marketplace: Settings → Plugins → Team Marketplaces → Add Marketplace → Import from Repo, pointed at aws/agent-toolkit-for-aws. Open the Plugins panel and install aws-core first, then the others as needed.

Other agents (Windsurf, Cline, and more)

Anything that speaks MCP works, including Windsurf and Cline. Configure the AWS MCP Server directly (see the server setup guide), then run npx skills add aws/agent-toolkit-for-aws/skills.

How do I check it's working?

Start a fresh conversation and ask: "What AWS Regions are available?" If the agent returns a list, the MCP Server is connected. For a skill check, ask it to "secure an S3 bucket" and watch it load securing-s3-buckets before it writes anything. An authentication error instead means your local credentials aren't reaching the server; see Prerequisites for how to set them up.

Three workflows that show the payoff

Setup is the boring part. The workflows below are where it pays off, and each one names the skills and components doing the work.

1. Stand up a serverless API, end to end

Prompt: "Build a REST API: API Gateway in front of a Lambda that reads and writes a DynamoDB table, deployed with CDK."

This is the kind of task agents usually botch, because it spans four services and the IAM glue between them. The agent pulls aws-serverless, connecting-lambda-to-api-gateway, connecting-lambda-to-dynamodb, and aws-cdk, then uses the MCP Server's API tools to provision and the run_script sandbox for multi-step setup. The skills carry the wiring, so the Lambda role scopes to your specific table instead of granting access to everything (*), and the CDK stack follows current patterns instead of a 2023 blog post the model half-remembers.

2. Troubleshoot a production issue you can't reproduce

Prompt: "My checkout Lambda times out intermittently and error rates spiked this morning. Help me find why."

Point the agent at the symptom and it follows a real diagnostic path. debugging-lambda-timeouts and troubleshooting-application-failures give it the procedure, while aws-observability and querying-aws-cloudwatch let it read the actual logs and metrics through the MCP Server. It checks the configured timeout against duration metrics, looks for cold starts, and inspects downstream calls that block, then tells you what it found. You get an actual investigation rather than a guess.

3. Hand an agent production access without losing sleep

Prompt: "Audit this account's S3 buckets and secrets, and flag anything risky."

This is the workflow that separates the toolkit from wiring up a raw MCP server. Before you run it, scope the agent's IAM role to read-only with the condition keys the MCP Server attaches, aws:ViaAWSMCPService and aws:CalledViaAWSMCP, so it can inspect and plan but cannot change anything, even though your own role can. Writing that policy is an advanced step, and the user guide explains how the condition keys fit in; you can skip it the first time through and still get value from the audit. The agent uses securing-s3-buckets and creating-secrets-using-best-practices as its rubric for what counts as risky, and every call lands in CloudTrail for you to review later.

How to update and remove skills

On AWS CLI 2.35.0+, the aws agent-toolkit command group manages skills across all your agents from the terminal:

aws agent-toolkit list-installed-skills
aws agent-toolkit add-skill --skill-name aws-serverless
aws agent-toolkit update-skill --skill-name aws-serverless
aws agent-toolkit remove-skill --skill-name aws-cdk --agent kiro

There's also search-skills, list-available-skills, and get-skill-metadata for browsing the catalog from the terminal. Without the CLI, re-run npx skills add aws/agent-toolkit-for-aws/skills to pull new skills, and remove them with npx skills remove <skill-name>. The MCP Server itself is AWS-hosted, so its API coverage and docs stay current on their own. The one thing you pin and bump yourself is the proxy version in your config.

Frequently asked questions

Is the Agent Toolkit for AWS free?
Yes. The toolkit costs nothing to install or use. You pay only standard AWS rates for the resources your agent creates or calls.

Which AWS CLI version do I need for aws configure agent-toolkit?
Version 2.35.0 or later. Older versions don't recognize the command and fail with Found invalid choice 'agent-toolkit'. Check yours with aws --version.

How do I fix "Found invalid choice 'agent-toolkit'"?
Upgrade the AWS CLI to 2.35.0 or later, since the command shipped in that release. On macOS with Homebrew, run brew upgrade awscli, then confirm with aws --version.

Do I need an AWS account and credentials?
Credentials are needed only for actions that touch your account, like API calls and run_script. Documentation search and skill discovery work with no credentials. Anything that provisions or reads real resources needs an AWS account.

Which coding agents does it work with?
Kiro, Claude Code, Codex, and Cursor have first-class setups, and any MCP-compatible agent works too, including Windsurf and Cline. Plugins cover Claude Code, Codex, and Cursor; Kiro and the rest connect to the MCP server directly.

How is it different from the AWS Labs MCP servers?
It's the successor to AWS Labs. The differences that matter: IAM condition keys that separate agent actions from human ones, CloudWatch and CloudTrail on every request, and skills evaluated end to end.

How do I give a coding agent read-only access to AWS?
Scope its IAM role with the condition keys the MCP server attaches, aws:ViaAWSMCPService and aws:CalledViaAWSMCP, to allow reads and deny writes. The agent can inspect and plan but not change anything, even when your own role can.

How do I update or remove skills?
On AWS CLI 2.35.0+, use aws agent-toolkit update-skill and aws agent-toolkit remove-skill. Otherwise re-run npx skills add aws/agent-toolkit-for-aws/skills to update, and npx skills remove <skill-name> to remove.

What to try next

Build the serverless API above, then ask the agent to add a CloudWatch alarm with setting-up-cloudwatch-alarm-notifications and watch it connect the alarm to an SNS topic.
Set up the read-only profile from workflow 3, hand it a real account, and confirm the agent can plan a change but not apply one. That's what makes me comfortable letting one near production.

About the author

Saurabh Dahal is a developer advocate at AWS, working with the latest agentic and AI tools for developers to help boost developer productivity. He set up the Agent Toolkit for AWS across Kiro, Codex, Claude Code, and Cursor for this guide.

Published June 30, 2026. Last updated June 30, 2026.

Setting up the Agent Toolkit for AWS in Kiro (and Codex, Claude Code, and Cursor)

Saurabh "Rob" Dahal — Tue, 30 Jun 2026 12:30:56 +0000

What is the Agent Toolkit for AWS?

What's included: the MCP server, skills, plugins, and rules files

Four components work together (reference).

Skills are curated packages of instructions, scripts, and reference material for one task. The agent loads a skill only when it needs it, so they barely touch your context until they're relevant.

Plugin	Covers
`aws-core`	Service selection, CDK/CloudFormation, serverless, containers, storage, observability, billing, SDK usage, deployment. Start here.
`aws-agents`	Building AI agents on AWS with Amazon Bedrock and AgentCore.
`aws-data-analytics`	Data lake, analytics, and ETL with S3 Tables, AWS Glue, and Athena.
`aws-agents-for-devsecops`	Incident investigation, code review, UAT, vulnerability scanning, and pen testing with AWS DevOps Agent and AWS Security Agent.

Which skills does the Agent Toolkit include?

The skills are the part I underestimated at first. There are around 64 today (browse the skills/ directory for the live list), split into core and specialized.

Core skills, which ship with aws-core:

Specialized skills, grouped by domain (a few from each):

Serverless (9): connecting-lambda-to-api-gateway, connecting-lambda-to-dynamodb, debugging-lambda-timeouts, processing-s3-uploads-with-step-functions
Analytics (10): querying-data-lake, ingesting-into-data-lake, managing-amazon-msk, amazon-opensearch-service
Database (8): amazon-aurora-postgresql, amazon-elasticache, exporting-rds-to-s3, rds-db2
Networking (5): creating-production-vpc-multi-az, routing-traffic-with-route53-and-cloudfront
Storage (5): securing-s3-buckets, creating-data-lake-table, storing-and-querying-vectors
EC2 (3), Operations (3), System table (3), Migration (2), Security and identity (1), Web and mobile (1)

Don't memorize the list. When you ask for "a Lambda behind API Gateway writing to DynamoDB," the agent pulls the matching skills on its own.

Prerequisites

A handful of things need to be in place first. None take long.

An AWS account. Anything that touches AWS needs one. Sign up here if you don't have one yet.
AWS credentials on your machine, for the parts that act on your account. The server still connects and answers documentation and skill questions without them, but API calls and run_script need them. The proxy reads the standard AWS credential chain, so aws configure, an SSO login, a named profile, or the usual environment variables all work. New to this? Configuring the AWS CLI is the simplest path. The CLI is the common way to set credentials, not a hard requirement.
uv, a Python package tool that runs the MCP proxy. Install it with brew install uv on macOS, or the official installer elsewhere. The uvx command in the Kiro config below comes bundled with it.
Node.js, which gives you the npx command used to install skills. If npx --version prints nothing, install it from nodejs.org.
AWS CLI 2.35.0 or later, but only if you use the one-command wizard below. Check with aws --version.

How to set up the Agent Toolkit for AWS

The quickest route is the AWS CLI wizard, which configures every agent you have at once. Prefer to do it by hand, or only use one editor? Skip to the per-agent steps below.

Set up every agent at once with the AWS CLI

On a recent AWS CLI, one command detects your installed agents, installs default skills, and configures the MCP Server for all of them:

aws configure agent-toolkit

One gotcha worth calling out, because I hit it. On an older CLI you'll see:

aws: [ERROR]: argument subcommand: Found invalid choice 'agent-toolkit'

That means your AWS CLI predates 2.35.0. Update it (instructions), confirm with aws --version, and rerun. Restart your agent afterward so it picks up the new MCP config.

If you only use one agent, or you want to see exactly what gets wired up, the per-agent steps below do the same thing by hand.

Kiro

{
  "mcpServers": {
    "aws": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@1.6.3",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--metadata", "AWS_REGION=us-west-2"
      ]
    }
  }
}

Pin the proxy version rather than tracking latest. You get reproducible behavior and a guard against a bad release. Check PyPI every few weeks and bump it on purpose.

Then install the skills:

npx skills add aws/agent-toolkit-for-aws/skills

Open Kiro's MCP Server view (the Kiro panel in the sidebar, or search "MCP" in the command palette), reconnect the aws server, and you're live.

Codex

Add the marketplace, then install from inside Codex:

codex plugin marketplace add aws/agent-toolkit-for-aws

Launch Codex, run /plugins, and install aws-core.

Claude Code

The plugins live on the official Anthropic marketplace, included by default:

/plugin install aws-core@claude-plugins-official

Hit Plugin not found? Refresh the index with /plugin marketplace update claude-plugins-official and try again. Add aws-agents, aws-data-analytics, or aws-agents-for-devsecops the same way.

Cursor

Other agents (Windsurf, Cline, and more)

Anything that speaks MCP works, including Windsurf and Cline. Configure the AWS MCP Server directly (see the server setup guide), then run npx skills add aws/agent-toolkit-for-aws/skills.

How do I check it's working?

Three workflows that show the payoff

Setup is the boring part. The workflows below are where it pays off, and each one names the skills and components doing the work.

1. Stand up a serverless API, end to end

Prompt: "Build a REST API: API Gateway in front of a Lambda that reads and writes a DynamoDB table, deployed with CDK."

2. Troubleshoot a production issue you can't reproduce

Prompt: "My checkout Lambda times out intermittently and error rates spiked this morning. Help me find why."

3. Hand an agent production access without losing sleep

Prompt: "Audit this account's S3 buckets and secrets, and flag anything risky."

How to update and remove skills

On AWS CLI 2.35.0+, the aws agent-toolkit command group manages skills across all your agents from the terminal:

aws agent-toolkit list-installed-skills
aws agent-toolkit add-skill --skill-name aws-serverless
aws agent-toolkit update-skill --skill-name aws-serverless
aws agent-toolkit remove-skill --skill-name aws-cdk --agent kiro

Frequently asked questions

Is the Agent Toolkit for AWS free?
Yes. The toolkit costs nothing to install or use. You pay only standard AWS rates for the resources your agent creates or calls.

What to try next

Build the serverless API above, then ask the agent to add a CloudWatch alarm with setting-up-cloudwatch-alarm-notifications and watch it connect the alarm to an SNS topic.
Set up the read-only profile from workflow 3, hand it a real account, and confirm the agent can plan a change but not apply one. That's what makes me comfortable letting one near production.

About the author

Published June 30, 2026. Last updated June 30, 2026.

I Let My AI Agent Build a Bedrock RAG Knowledge Base, Here Are the 2 Mistakes the AWS Agent Toolkit Caught

Saurabh "Rob" Dahal — Thu, 25 Jun 2026 18:29:01 +0000

Provisioning a Bedrock RAG knowledge base with S3 Vectors, without the hallucinated API calls.

If you've asked an AI coding agent to set up AWS, you've seen it confidently invent a parameter, reach for a deprecated service, or burn ten minutes retrying against a service it never saw in training. The failure mode that bites hardest is the silent one: the agent thinks it succeeded, and you find out an hour later.

I hit two of these while standing up the retrieval layer for a LangGraph support bot, an Amazon Bedrock Knowledge Base backed by Amazon S3 Vectors. I'd love to say I caught both with deep AWS expertise. I caught them because the Agent Toolkit for AWS read the docs I hadn't. Both would have shipped, and neither did.

The 30-second setup

The goal: take a folder of markdown product docs and make them queryable by meaning, so an agent can answer "is this safe for color-treated hair?" from the real docs instead of guessing. Think of it as giving the agent a library it can search instead of making things up. That's the retrieval half of RAG, the foundation a LangGraph agent will later call as a tool.

Four moving parts, wrapped in one managed service:

Source bucket: an S3 bucket holding the docs.
Embeddings: Amazon Titan Text Embeddings V2 (1024-dim vectors).
Vector store: Amazon S3 Vectors. I chose it over OpenSearch Serverless because it has no always-on compute, the difference between cents and a monthly surprise for a demo that sits idle.
Knowledge Base: Amazon Bedrock Knowledge Bases ties it together into one thing you can query with a retrieve call.

To follow along, you need an AWS account, a non-root IAM identity with credentials configured locally, uv installed, and the toolkit installed in your agent. The fastest path across Kiro, Claude Code, Cursor, and Codex is the AWS CLI installer, aws configure agent-toolkit; in Kiro you can instead add the AWS MCP Server to .kiro/settings/mcp.json (pin the mcp-proxy-for-aws version) and run npx skills add aws/agent-toolkit-for-aws/skills. The toolkit plugs into the agent you already use and loads task-specific skills on demand; I used the amazon-bedrock skill, which carries the validated, current procedure for building a Knowledge Base. That word, "current," is the whole story.

Gotcha #1: the model id was already dead

My first instinct, straight from an older tutorial, was anthropic.claude-3-5-sonnet-20240620-v1:0. Calling it returned:

ResourceNotFoundException: This model version has reached the end of its life.

The fix the toolkit's doc search surfaced: current Anthropic models on Bedrock are inference-profile only. You invoke them through a cross-region profile id like us.anthropic.claude-sonnet-4-5-20250929-v1:0, not the bare on-demand id.

On its own, an agent might not even diagnose this correctly. "Not found" reads like a permissions or region problem, so it could swap in another stale id and hit "on-demand throughput isn't supported" instead, flailing sideways. The toolkit got it right because it read the current model docs, not because it happened to remember them.

Gotcha #2: Bedrock won't create the S3 Vectors index for you

I created the vector bucket, pointed the Knowledge Base at an index name, and assumed Bedrock would create the index. It didn't:

ValidationException: The specified index could not be found (S3Vectors 404)

The real requirement, from the S3 Vectors docs: you create the index yourself, and it must declare two non-filterable metadata keys that Bedrock uses to store chunk text and metadata. Miss them and ingestion fails later with a cryptic error far from the cause. The working command:

aws s3vectors create-index \
  --vector-bucket-name <VECTOR_BUCKET> \
  --index-name <INDEX_NAME> \
  --data-type float32 --dimension 1024 --distance-metric cosine \
  --metadata-configuration '{"nonFilterableMetadataKeys":["AMAZON_BEDROCK_TEXT","AMAZON_BEDROCK_METADATA"]}' \
  --region us-east-2

This is the one that best captures why current docs matter. S3 Vectors launched in 2025, so the requirement isn't in most models' training data. A toolkit-less agent would most likely create the index, think it succeeded, and only hit the wall at ingestion time, then burn an afternoon recreating it with the wrong config. The dimension (1024) and distance metric here aren't arbitrary either: they have to match the Titan embedding model, which is the kind of cross-resource constraint an agent gets wrong when it's guessing.

The rest fell into place, and it works

With those two out of the way, the validated sequence ran clean: create the IAM service role (trust bedrock.amazonaws.com with confused-deputy conditions, so another customer can't trick the role into acting on their resources, plus least-privilege permissions to invoke Titan, read the bucket, and use the vector index), create the Knowledge Base, attach the S3 data source with fixed-size chunking (300 tokens, 20% overlap), and run ingestion. Result: 10/10 documents indexed, zero failures.

The proof is a retrieval query:

aws bedrock-agent-runtime retrieve \
  --knowledge-base-id <KB_ID> \
  --retrieval-query '{"text":"Is the Curl Cream safe for color-treated hair?"}' \
  --region us-east-2

Top hit came back at 0.86 similarity, on the exact product doc with the right answer. The library is stocked.

What it bought me, and what I'd do differently

Strip away the demo and the toolkit changed two things: it handed the agent the validated setup order up front (no trial-and-error), and it caught two mistakes a model trained months ago wouldn't know, because it checks current docs and ships procedures AWS maintains. AWS reports developers see fewer iterations and errors with it; on this build, the two catches alone saved me an afternoon.

Two honest gaps. First, the toolkit's own rules recommend infrastructure-as-code over direct CLI, and I didn't follow that. I ran CLI calls and tracked them in a tagged manifest for teardown. It works, but CDK or CloudFormation would be the reproducible artifact a reader could clone. Second, I left the IAM role's trust policy scoped to knowledge-base/* instead of the specific KB id; tightening that aws:SourceArn is the obvious hardening step before this is anything but a demo.

What's next

This is the retrieval foundation, not the whole app. Two concrete next steps, and you could take either:

Close the loop. Wire a LangGraph agent to call this Knowledge Base as a tool, so it retrieves and generates grounded answers. That's when "RAG knowledge base" graduates to "RAG application."
Make it reproducible. Convert the ad-hoc CLI provisioning into CDK or CloudFormation, so the whole stack stands up and tears down with one command, the way the toolkit's own rules recommend.

If you take one thing: the toolkit's real value isn't typing commands for you, it's making better decisions, grounded in current docs, on the things an AI agent gets wrong in ways you don't notice until an hour later.

DEV Community: Saurabh "Rob" Dahal

Help Your Coding Assistant Find the Right Code in Large Repos

Before the workshop

1 Show the failure

2 Map the repository

3 Search by text

4 Search by structure

Understand the placeholders

Compare matches and counterexamples

Narrow and save the query

5 Follow the symbols

6 Gather evidence before asking for a fix

7 Explain the root cause before editing

8 Make the narrow change and verify it

Evaluate the behavior

Evaluate the change

Finish with a reusable investigation

If a step behaves differently

Setting up the Agent Toolkit for AWS in Kiro (and Codex, Claude Code, and Cursor)

What is the Agent Toolkit for AWS?

What's included: the MCP server, skills, plugins, and rules files

Which skills does the Agent Toolkit include?

Prerequisites

How to set up the Agent Toolkit for AWS

Set up every agent at once with the AWS CLI

Kiro

Codex

Claude Code

Cursor

Other agents (Windsurf, Cline, and more)

How do I check it's working?

Three workflows that show the payoff

1. Stand up a serverless API, end to end

2. Troubleshoot a production issue you can't reproduce

3. Hand an agent production access without losing sleep

How to update and remove skills

Frequently asked questions

What to try next

Further reading

About the author

Setting up the Agent Toolkit for AWS in Kiro (and Codex, Claude Code, and Cursor)

What is the Agent Toolkit for AWS?

What's included: the MCP server, skills, plugins, and rules files

Which skills does the Agent Toolkit include?

Prerequisites

How to set up the Agent Toolkit for AWS

Set up every agent at once with the AWS CLI

Kiro

Codex

Claude Code

Cursor

Other agents (Windsurf, Cline, and more)

How do I check it's working?

Three workflows that show the payoff

1. Stand up a serverless API, end to end

2. Troubleshoot a production issue you can't reproduce

3. Hand an agent production access without losing sleep

How to update and remove skills

Frequently asked questions

What to try next

Further reading

About the author

I Let My AI Agent Build a Bedrock RAG Knowledge Base, Here Are the 2 Mistakes the AWS Agent Toolkit Caught

The 30-second setup

Gotcha #1: the model id was already dead

Gotcha #2: Bedrock won't create the S3 Vectors index for you

The rest fell into place, and it works

What it bought me, and what I'd do differently

What's next