DEV Community: AWS

Is stateless MCP just REST? I ran 180 tests to find out

Edoardo Dusi — Mon, 26 Oct 2026 16:22:52 +0000

In July 2026 the Model Context Protocol dropped sessions. The handshake is gone, the Mcp-Session-Id header is gone, and every request now stands on its own. Within a week the internet did what the internet does, compressing that change into a slogan: MCP is dead, REST won, it was always just REST with extra steps.

In the 2026-07-28 MCP spec, tools/list no longer varies per connection, and a server that needs cross-call state now mints an explicit handle and passes it back as an ordinary tool argument. In other words, a stateless MCP server is now a list of tool names with JSON schemas, presented to the model, which emits a tool call that the host dispatches.

Say that out loud and the REST comparison writes itself. Maybe even the slogan. A REST API is also stateless HTTP.

I always loved that "computer scientist" has the word scientist in it, so I want proof and measurements, even for silly slogans. I found no measurement, so I built one.

I took a single backend and exposed it twice, once as a stateless MCP server and once as a plain REST API, handed both to the same agent with the same tasks, and recorded what changed across 180 runs. I'm surprised that the result is less dramatic than the slogan and actually more useful: on a small tool surface the two are a tie, and on a realistic one they diverge for one structural reason each.

I'm not here to tell you "which protocol is better". But I will tell you that these two carry the same information in different places. MCP puts the tool surface in front of the model on every turn. REST puts the contract in front of the model once, then leans on a single generic HTTP call. That difference in placement is the whole ballgame, and it is measurable.

I'm giving you the data, the harness, and a way to make a decision based on your case, not your mood.

The experiment

I wanted any difference I measured to be the shape of the contract instead of the business logic. There is exactly one backend, a classic demo: a small store with products, inventory, orders and customers, that answers the same way every run.

Two interfaces wrap that same backend over the same six operations:

MCP is modeled as native tool use on Amazon Bedrock's Converse API, because this is exactly the stateless MCP shape: the model receives tool names and JSON schemas every turn and emits a toolUse block that the host dispatches
REST gives the model one tool, http_request, plus an OpenAPI-style contract in the system prompt, that is read once. The model constructs the path itself. This interface also implements a real ETag and 304 Not Modified cache, because conditional reads are the one thing REST can express that MCP tool use currently cannot

I gave both the same set of tasks: a simple lookup, a two-hop (order to customer name), an aggregate across a customer's orders, a missing-information recovery (an order that does not exist), a conditional (can I order an out-of-stock item?), and a repeated read that I use to test caching.

The setup:

Model: Claude Haiku 4.5 on Amazon Bedrock, eu-central-1, temperature 0. I picked this small, fast model because it keeps the sandbox cost down, and a smaller model is the harder test: it is quicker to fumble a schema or burn tokens, so a difference between the two interfaces shows up instead of being hidden by a frontier model's reasoning
Five trials per task per interface, so thirty runs each per condition
Metrics per run: success, input and output tokens, latency, round-trips, tool calls, cache hits. A round-trip here is one model turn, so a task that makes a single tool call and then answers counts as two

Result 1: on a small surface, it is a tie

With six tools, the internet slogan seems to be correct!

Six tools, five trials per task, thirty runs per interface.

Metric	MCP	REST
Success rate	100%	100%
Avg total tokens	2,838	2,867
Avg input tokens	2,705	2,692
Median latency	2,116 ms	2,070 ms
Avg round-trips	2.5	2.5
Cache hits (304)	0	5

You can see we have the same correctness, number of round-trips, token counts and latency. If you have a handful of tools, the choice between a small MCP server and a small REST contract is just a matter of taste, not efficiency. But look at that Cache hits column...I'll come back to it.

Result 2: the schema tax is real, and it scales

Then I changed the one thing I figured was about to matter: the API surface size. I ran the whole suite again with twenty-four extra endpoints, modeling a realistic store API with roughly thirty operations. On the MCP side those are twenty-four more tool schemas. On the REST side they are twenty-four more lines in a contract the model reads once.

Let's see how that changed our bill:

Thirty tools, five trials per task, thirty runs per interface.

Metric	MCP	REST	Delta
Success rate	100%	100%	tie
Avg total tokens	6,558	4,231	MCP +35%
Avg input tokens	6,406	4,038	MCP +37%
Median latency	1,996 ms	1,810 ms	MCP +9%
Avg round-trips	2.67	2.67	tie

Again, same success rate and same round-trips, but 35% more tokens. The reason is simple: a stateless MCP server re-sends every tool schema on every turn, so the model pays for the full catalog every time, even if it doesn't use every tool. REST's single http_request primitive does not grow when the API does, because the contract is only read once.

Per task, the gap is remarkable:

Task	MCP input tokens	REST input tokens	MCP overhead
order_status	4,673	2,850	+1,823
customer_total	4,732	2,910	+1,822
missing_order	4,647	2,805	+1,842
order_customer	7,181	4,500	+2,681
repeat_read	7,318	4,687	+2,631
stock_mech	9,884	6,475	+3,409

Roughly 1,800 extra input tokens for a one-call task, and more for multi-call tasks, because the schema tax is paid once per round-trip. The more the agent has to go back to the tools, the more times it re-reads the whole catalog.

To be fair, this is the worst case for MCP and the best case for REST. Prompt caching on the provider side, and filtering the tool list down to what a task plausibly needs, both cut this cost. But neither is free and neither is automatic, and the structural fact remains that MCP's token cost is a function of surface size in a way REST's is not.

This is my measurement, so I invite you to test on your own setup and challenge my findings.

Result 3: where REST wins outright

The repeat_read task asks the agent to read an order, report the total, then read it again to confirm it is unchanged. This is deliberate, to test caching.

The REST agent read the order, got an ETag, and on the second read sent If-None-Match with that tag. The server answered 304 Not Modified with an empty body, and the agent reused the value it already had. Five cache hits in five trials. The MCP agent could not do this, because MCP tool use has no standard notion of a conditional read or a revalidation header. It called the tool again and paid for the full result a second time. No cache, baby!

The boring and old HTTP protocol with its caching mechanisms, conditional requests and revalidation, easily beats the shiny new MCP protocol on re-reads, because when your agent calls a tool it always starts from scratch, even when reading multiple times data that rarely changes.

Result 4: where MCP wins outright

So far everything seems to be in favour of REST. I tried to build a scenario that should favour MCP.

Picture a strict, unfamiliar API. A reporting endpoint whose region codes are EUR, NAM and APC, not EU or Europe or EMEA. Metric names you cannot guess from a description. A date format that must be exactly YYYY-MM-DD. The kind of API an agent meets for the first time.

MCP gives the model its normal typed tool schema: the enum values are correctly spelled, the format is declared, and the host validates the call before it is dispatched. REST gets what people actually write for a terse API: a contract that names the endpoint and the parameters but does not enumerate every valid value. The agent has to infer them. I asked both, in plain language, questions like "what was net revenue in Europe on 2026-10-20?"

Strict API, one operation, six trials per task, thirty runs per interface.

Metric	MCP	REST (terse contract)
Final success	100%	100%
First-call success	100%	0%
Malformed calls	0	30 (one per task)
Avg tool calls	1.0	2.0
Avg round-trips	2.0	3.0
Avg total tokens	1,841	3,041 (+65%)
Median latency	1,720 ms	3,006 ms (+75%)

Both get there in the end, so this is not about MCP being "more correct." It is about getting it right the first time. The MCP agent mapped "Europe" to EUR on the first call, every single run, because the schema told it the allowed values up front. The REST agent guessed EU or Europe, got a 400, read the error, and fixed it on the second call, every single run. That self-correction is impressive, but it costs an extra round-trip, 65% more tokens and nearly double the latency, every time.

To be honest, I could make REST match MCP by pasting the full JSON schema, enums and all, into the contract. But that is exactly the per-turn token tax that made MCP lose Result 2. The schema has to live somewhere. MCP puts it in front of the model and pays for it every turn. A terse REST contract saves those tokens right up until the API is strict enough that the saving turns into a wrong guess. No free lunch, only a choice about where you spend.

What this does not measure

A benchmark you cannot poke holes in is a benchmark that is lying! Here are mine.

This is a very controlled scenario. One model, one small domain, six tasks. There is no authentication, no streaming, no human in the loop. The "wire bytes" I counted are a proxy, not a packet capture. Latency differences stayed inside the noise and were dominated by the model, not the protocol, so do not read the 9% as a protocol verdict.

And to be very clear, this measures per-request efficiency, which is not why most people reach for MCP. MCP's actual value is the ecosystem. Write one server and any agent can use it, without a previous knowledge of the contract. That portability is real and this harness does not price it. REST's hidden cost is the opposite: every consumer writes and maintains its own client, based on a shared contract.

Efficiency is one axis, but it's not the only one.

There is also a safety axis, which this harness does not touch: a stateless, per-request boundary is easier to reason about than a long-lived session, with authorization checked per call and no sticky server-side state to ride. That deserves its own measurement, so I'm thinking of a follow-up here.

How to decide

Is stateless MCP just REST with extra steps? No.

It is REST with no cache, but with a typed, self-describing discovery layer bolted on top. Batteries included. Which one you want depends on your specific scenario:

Small, stable, portable tool set that you want many agents to reuse: MCP wins. The schema tax is small and the ecosystem payoff is real.
Strict or unfamiliar API with non-obvious parameters: MCP wins again. Typed, validated discovery means the agent calls correctly on the first try instead of guessing, failing, and retrying.
Large, loose API with cache-heavy reads and a single consumer: a cache-friendly REST contract is the better developer experience. You avoid the schema tax and you get 304s for free.
Somewhere in between: measure it. That is the whole point of the harness.

There is no winner-take-all. It is a trade-off about where the cost of describing your API lives, and now I hope it is a trade-off you can put some numbers on.

Run it yourself

The full harness is on GitHub: mcp-vs-rest-bench. The backend, the two interfaces, the task suite, the runner, and the raw results JSON. It runs against Amazon Bedrock on demand, so there is nothing to tear down, no standing infrastructure, and a full five-trial sweep costs a few cents of Haiku tokens. Point it at your own stack, your own tasks, your own model, and settle your own version of the argument.

Don't decide with vibes. Decide with data.

Making my personal website callable for AI agents with WebMCP

Salih Guler — Tue, 20 Oct 2026 08:17:31 +0000

The first time someone mentioned WebMCP to me, I assumed it was a diagnostics tool for web apps. The name sounds like something you would open next to the network tab. My second guess was worse: I thought maybe it was a Playwright alternative. Luckily, I was wrong both times, and figuring out why is how I ended up adding it to salih.dev (where probably nobody would use).

A few months ago I wrote about building an agent-friendly personal website with specs. The site serves Markdown to agents, has an llms.txt, and answers a set of .well-known discovery files. One of those files was /.well-known/webmcp.json, and it said, politely, that there were no browser tools here. In case you don't know me, I am a very open person, if I don't have something, I would say "I don't have it". But I also don't take "No" for an answer, even to myself. So let's see how I added this very useful set of features on a not very useful scenario for the sake of learning.

The code is in the salih-dev repository: the tools are in PR #15, and the speaker kit and discovery changes are in PR #16.

What is WebMCP?

WebMCP is a proposed web standard from the W3C Web Machine Learning Community Group, written by people from Microsoft and Google. It lets a web page declare tools that an AI agent running in the browser can call. The page registers each tool with a name, a description, a JSON schema for its input and a function that runs it:

document.modelContext.registerTool({
  name: "list_events",
  description: "List the conferences where Salih speaks...",
  inputSchema: { type: "object", properties: { when: { type: "string" } } },
  execute: async (input) => { /* return the answer */ },
});

The "MCP" is the same Model Context Protocol you may already run on a server. The difference is where it lives. A server MCP exposes tools from a backend. WebMCP exposes tools from the page the user has open, with the user's session and the page's state.

The tools I added

My site has three kinds of content an agent might care about: blog posts, past talks and upcoming events. I wrote eight tools around them:

Tool	What it answers
`get_site_overview`	Where I am right now, content counts, my next event, the latest post, and the filter values the other tools accept
`search_site`	Full-text search across posts, talks and events
`list_blog_posts`	Posts filtered by tag, category or text
`read_blog_post`	The full Markdown of one post
`list_talks`	Past talks by topic, event type, year, or whether a recording exists
`list_events`	Upcoming, past or all events
`get_speaker_kit`	My bio, the topics I speak on, recent talks, where I am already booked, and how to reach me
`show_talks_on_page`	Applies a filter on the Talks page so the visitor sees it too

The first seven are read-only and registered on every page. The last one only exists on /talks/, and it is the one I like most. It presses the page's real filter button, so the person watching sees the same list the agent is describing. The page's own controller stays in charge of the state, including its aria-pressed attributes.

I kept everything read-only on purpose. There is a comment form on the site, and I thought about exposing it. An agent posting comments on my behalf is a decision I want to make separately, after I have watched how agents use the read tools.

Step 1: Bake an index at build time

The tools need data, and I did not want them scraping my own HTML. The site is built with Astro, so I added a static endpoint that writes everything the tools need into one JSON file.

Create it under src/pages/api/webmcp-index.json.ts:

export const GET: APIRoute = async () => {
  const [posts, talks] = await Promise.all([
    getPublishedPosts(),
    getPublishedTalksSnapshot(),
  ]);

  return jsonResponse(
    buildSiteIndex({
      siteName: site.name,
      siteUrl: site.url,
      posts,
      talkCards: projectTalkArchive(talks).cards,
      siteContent: getSiteContent(),
    }),
    { headers: { "Cache-Control": "public, max-age=300" } },
  );
};

It reads the same published posts and talks the pages use, so the tools never disagree with what a human sees.
buildSiteIndex flattens them into a small shape with titles, URLs, dates, tags and snippets.
The file is static. My content API starts the publisher build after every write, and that build regenerates the file, so there is no extra Lambda to run.

One detail took me a moment. Events move from "upcoming" to "past" on their own, and a baked file does not know what day it is. So the index stores dates, and the tools decide upcoming or past in the browser against the visitor's clock. An event that ended yesterday shows as past even if I have not rebuilt the site since.

Step 2: Register the tools only when the browser supports them

Most visitors use a browser without WebMCP, and I wanted them to see zero difference. The entry point checks for document.modelContext and returns if it is missing.

Add it to src/lib/webmcp/register-tools.ts:

export async function registerWebMcpTools(): Promise<void> {
  const context = document.modelContext;
  if (context === undefined) return;

  try {
    await registerContentTools(context);
    await registerTalksPageTool(context);
  } catch (error: unknown) {
    // A registration failure must never break the page for the human visitor.
    console.warn("WebMCP tool registration failed", error);
  }
}

Then load it from a component with no markup, src/components/WebMcpTools.astro, and add that component to the base layout:

<script>
  import { registerWebMcpTools } from "../lib/webmcp/register-tools";

  void registerWebMcpTools();
</script>

For types I used the webmcp-types package, pinned to 0.1.10, and referenced it from src/env.d.ts. That gives you WebMCP.ModelContext and the registerTool signature without writing your own copy of the API.

Step 3: Write descriptions for a model, and check every input

A tool description is a prompt. The agent reads it to decide whether to call the tool and what to pass. I wrote mine the way I would brief a colleague, including the defaults and the order of results:

description:
  "List the conferences and events where Salih Güler speaks or runs workshops. 'upcoming' (the default) lists events that have not ended yet, soonest first; 'past' lists finished events, most recent first; 'all' lists both.",

get_site_overview returns the exact tag, category and topic values the other tools accept, and its description tells the agent to call it first when it is unsure. That one line saves a lot of failed filter calls.

The spec does not promise that the browser validates input against your schema. So every execute function checks its input again before using it:

const query = optionalString(input.query);
if (query === undefined) throw new Error("query must be a non-empty string");

The search and filter logic lives in src/lib/webmcp/queries.ts as pure functions, which made it easy to test without a browser. There are 12 tests for it, covering search ranking, filters, the upcoming and past split, post lookup and the speaker kit.

Step 4: Add a speaker kit

The first version answered questions about my content. Then I thought about who actually looks me up. Most of the time it is an event organizer deciding whether to invite me, and they want a bio, the topics I cover, proof that I can give a talk, and a way to reach me. Before, an agent had to stitch that together from four tool calls and the About page.

So the index got a speaker block, built from the same src/config/site.ts that renders my About and Contact pages:

speaker: {
  role: input.speaker.role,
  bio: input.speaker.bioShort,
  longBio: [...input.speaker.bioLong],
  focusAreas: [...input.speaker.focusAreas],
  aboutUrl: absolute("/about/"),
  contactUrl: absolute("/contact/"),
  profiles: input.speaker.socials.map((social) => ({
    label: social.label,
    url: social.href,
  })),
},

And src/lib/webmcp/queries.ts got a speakerKit function that combines it with the talks and events. It counts how many talks I have given per topic, so the agent sees what I talk about most:

const topicCounts = new Map<string, { topic: string; talks: number; order: number }>();
for (const talk of index.talks) {
  for (const topic of talk.topics) {
    const key = normalize(topic);
    if (key.length === 0) continue;
    const entry = topicCounts.get(key);
    if (entry) entry.talks += 1;
    else topicCounts.set(key, { topic, talks: 1, order: topicCounts.size });
  }
}

The function returns the topics sorted by talk count, my five most recent talks with slides and recordings, the next five events I am booked for, and the contact routes. My site lists no email address, so the kit says that directly and points to the profiles on the contact page. An agent should not invent an address because the field looked empty.

Registering it looks like the other tools. The description names the situations where an agent should pick it:

await context.registerTool({
  name: "get_speaker_kit",
  title: "Speaker kit",
  description:
    "Get what an event organizer needs to invite Salih Güler as a speaker: his role and bio, focus areas, the topics he has spoken on with talk counts, his most recent talks with slide and recording URLs, the events he is already booked for, and how to contact him. Use this when someone wants to invite him, check his availability, or write a speaker introduction.",
  inputSchema: { type: "object", properties: {} },
  annotations: readOnly,
  execute: async (_input, { signal }) => speakerKit(await loadIndex(signal), today()),
});

Adding the speaker block changed the index shape, so I bumped its version from 1 to 2.

Step 5: Tell the humans too

The tools are invisible to a person reading the site. If someone finds this post and opens salih.dev, nothing on the page says what to ask. So the About page has a new section, "Use this site with an AI agent", with example prompts and the console check from the "Try it yourself" section below.

The About page also has a Markdown version for agents, and I did not want the two to drift apart. Both now render from one small module, src/lib/webmcp/visitor-guide.ts:

export const AGENT_GUIDE = {
  heading: "Use this site with an AI agent",
  promptsLead: "Some questions to try:",
  prompts: [
    "Where is Salih speaking next, and what has he talked about before?",
    "Find Salih's posts about AWS Amplify and summarize the newest one.",
    "Which of Salih's talks have a recording?",
    "Get Salih's speaker kit so I can invite him to our meetup.",
  ],
  // intro text, the Chrome flag, and the console call are here too
} as const;

about.astro maps over it for the HTML, and the Markdown serializer builds the same section from it.

Try it yourself

You can call the tools on salih.dev today. You need Chrome 150 or newer.

From the Chrome console

Open chrome://flags/#enable-webmcp-testing, set WebMCP for testing to Enabled, and relaunch Chrome.
Open salih.dev, then open DevTools and go to the Console.
List the tools and call one:

const tools = await document.modelContext.getTools();
tools.map((tool) => tool.name);

const kit = tools.find((tool) => tool.name === "get_speaker_kit");
await document.modelContext.executeTool(kit, {});

const search = tools.find((tool) => tool.name === "search_site");
await document.modelContext.executeTool(search, { query: "agents" });

You should see seven tools on most pages and eight on /talks/. If document.modelContext is undefined, the flag is not on yet. Some Chrome builds expect the input as a JSON string, so if executeTool complains, pass JSON.stringify({ query: "agents" }) instead.

On the Talks page, run show_talks_on_page with { filter: "All talks" } or one of the topic labels and watch the filter buttons on the page change.

With the MCP Inspector

If you want to see the calls before you hand them to an agent, use the MCP Inspector. It is the reference tool for testing MCP servers, and it can start Chrome DevTools MCP for you with the same flags as above:

npx @modelcontextprotocol/inspector \
  npx chrome-devtools-mcp@latest \
  --categoryExperimentalWebmcp \
  --chromeArg=--enable-features=WebMCP

It prints a URL with a one-time token, so open that URL rather than typing localhost:6274 yourself. Turn on the switch next to the server to connect, then switch to Tools. You are now doing by hand what Claude Code and Codex did on their own:

Run new_page with https://salih.dev/talks/ as the url. Chrome opens the page, and the result lists its page ID.
Run list_webmcp_tools with that pageId. You get all eight tools with their descriptions and input schemas, exactly as an agent receives them.
Run execute_webmcp_tool with the pageId, a toolName and the input as a JSON string, for example get_speaker_kit and {}.

Step 2 is the useful one when you write your own tools. You read each description the way the model reads it, flattened into one long block with its schema, so a description that only makes sense next to your page is easy to spot. The Protocol tab on the right shows the raw JSON-RPC for every call if you need to see exactly what was sent.

Every tool in the list has a small warning triangle. That is the Inspector's schema portability check on Chrome DevTools MCP's own schemas, not on my tools, and the calls work anyway.

From Claude Code, Codex or Kiro CLI

Claude Code, Codex and Kiro CLI run in a terminal, not in a browser tab, so they cannot see document.modelContext on their own. The bridge is Chrome DevTools MCP, Google's MCP server that gives a coding agent a real Chrome. It has an experimental WebMCP category with two tools: list_webmcp_tools lists what a page registers, and execute_webmcp_tool calls one of them with JSON input.

The category is off by default. You need two flags: --categoryExperimentalWebmcp turns on the two tools, and --chromeArg=--enable-features=WebMCP turns on WebMCP in the Chrome that the server starts. That Chrome uses its own profile, so the flag you set in chrome://flags does not carry over.

For Claude Code:

claude mcp add chrome-devtools --scope user -- \
  npx chrome-devtools-mcp@latest \
  --categoryExperimentalWebmcp \
  --chromeArg=--enable-features=WebMCP

For Codex:

codex mcp add chrome-devtools -- \
  npx chrome-devtools-mcp@latest \
  --categoryExperimentalWebmcp \
  --chromeArg=--enable-features=WebMCP

If you prefer editing ~/.codex/config.toml directly, this is the same server:

[mcp_servers.chrome-devtools]
command = "npx"
args = [
  "chrome-devtools-mcp@latest",
  "--categoryExperimentalWebmcp",
  "--chromeArg=--enable-features=WebMCP",
]

For Kiro CLI:

kiro-cli mcp add --name chrome-devtools --scope global \
  --command npx \
  --args '["chrome-devtools-mcp@latest","--categoryExperimentalWebmcp","--chromeArg=--enable-features=WebMCP"]'

That writes the server to ~/.kiro/settings/mcp.json. Use --scope workspace instead if you only want it in one project, in that project's .kiro/settings/mcp.json.

Restart the agent and ask it something about the site. I gave Codex this prompt:

Open https://salih.dev/ in the browser. Use the page's WebMCP tools to answer:
where is Salih speaking next, and which topics has he given talks on?
Then say which WebMCP tools you called. Do not read the page HTML.

It called list_webmcp_tools, then execute_webmcp_tool three times with get_site_overview, list_events and list_talks. The answer had CityJS Athens on 21 to 23 October as my next event, the two events after it, and the topics from both talks. It did not read the page HTML once.

I gave Codex a speaker question instead, and it went straight to get_speaker_kit after listing the tools. That one call was enough for my bio, focus areas and contact routes. It also repeated the kit's note that the site has no email address, which is the line I added so an agent would not make one up. One small lesson from that run: I asked for "three focus areas", the kit has four, and Codex merged two of them to match my number. The agent trusted my prompt over the data.

With Kiro CLI I asked which talks I have given and whether any of them has a recording. It opened the page, called list_webmcp_tools, and then made a single execute_webmcp_tool call with list_talks. The answer had both talks with their events and dates, and it said neither has a recording because videoUrl is empty for both. Kiro CLI asks before it runs each tool, so every one of those calls went through an approval prompt first.

Two things to know before you try this:

Chrome DevTools MCP can read and change anything in the browser it controls. The server prints that warning on start, and it is right. Use it on sites you trust, and keep it away from tabs with accounts you care about.
The site cannot see who is calling its tools or ask the visitor for permission. Your agent's own approval prompts are the only check, so read what it wants to call before you allow it. My tools only read, so it does not matter much here. It would matter on a site with a checkout tool.

Chrome's Debug WebMCP tools with AI agents page shows the same setup from the author's side: asking your coding agent to check that your own tools register and that their schemas are clear enough for a model.

With other agents

If your agent runs inside a browser that supports WebMCP, ask it one of the questions from my About page, for example "Where is Salih speaking next, and what has he talked about before?", and check which tools it calls.

An agent without a browser still gets the same answers. Point it at llms.txt. It lists the tools and links /api/webmcp-index.json, the data the tools read.

Resources

Enséñale a tu agente a usar AWS

Axel Espinosa — Fri, 16 Oct 2026 23:27:43 +0000

Cada día que pasa estamos sorprendidos por lo capaces que los agentes de código se han convertido. Muchos incluso predicen que ya no necesitamos ingenieros o ingenieras en el futuro y que se viene un apocalipsis donde las computadoras se van a rebelar contra nosotros y contra aquellos que no le decían por favor y gracias a sus agentes después de terminar una tarea.

Nada más alejado de la realidad. Cuando le preguntas algo a tu agente seguramente has notado que se inventa cosas que ni siquiera existen o que te da una solución que quizás no es la adecuada. Y es que el agente no tiene la culpa en sí de que no pueda darte la última versión de la API de una librería porque ellos tienen un corte en la información. Es decir, quedan congelados en el tiempo.

Por supuesto, existen herramientas que le ayudan al agente a encontrar información actualizada y con eso puede ponerle un parche a lo que le falta de información y completar la tarea. Hemos visto cómo pasamos de MCPs a skills y luego a un mix entre ellas.

Y es por eso que hoy quiero platicarte acerca de una herramienta que le va a ayudar a tu agente a hacer las cosas de la forma correcta cuando trabajas con AWS.

AWS no tiene que ser complicado

Sí... yo sé que alguien te dijo que usar AWS es difícil o que necesitas configurar demasiadas cosas. Pero algo que quizás nadie te ha dicho todavía es que mejoramos la plataforma para que puedas construir de manera más sencilla con AWS sin que tengas que gastar tantas horas configurando tu cuenta antes de empezar siquiera a construir.

La nueva experiencia de AWS te permite comenzar de manera más sencilla y sin tanto rollo. Aquí te dejo un blog post adicional por si quieres leer más al respecto.

Uno de los principales cambios para personas como tú y como yo que les gusta empezar rápido y sin tanto trámite es la forma en que puedes conectar tus agentes de IA para que trabajen por ti y te ayuden a construir en AWS.

¿Qué hace esta herramienta?

Como te dije antes, los agentes únicamente aprenden hasta cierta fecha y lo que hace esta herramienta es que te permite utilizar herramientas que quizás ya son familiares para ti como MCP y los Agent Skills para brindarle conocimiento a tu agente de cómo debe trabajarse en AWS de la forma CORRECTA, utilizando las mejores prácticas y aprovechando las bondades de la nueva experiencia.

Si quieres que tu agente tenga estas habilidades solo tenemos que realizar unas configuraciones. Pero lo bueno es que podemos copiar un prompt y pegarlo en nuestro agente para que haga el trabajo por nosotros. Sencillo, ¿no?

Vamos a instalarlo

Iniciemos sesión en nuestra cuenta. Si no tienes una cuenta todavía, te dejo un recurso para que crees tu cuenta. ¡Ahora puedes iniciar sesión hasta con GitHub!

Copiamos el prompt que aparece en nuestra pantalla:

El prompt le dice a nuestros agentes que deben configurar el Agent Toolkit. Y además, les da instrucciones para que usen la nueva experiencia de AWS.

Pegamos el prompt en nuestro editor y esperamos a que el agente termine. Solo necesitaremos ir dando permisos, ya que lo que hará es instalar la AWS CLI en caso de que no la tengamos, o la actualizará y muchas otras cosas.

Después de pegar el prompt empieza con esto. Verificando las herramientas que necesita:

Ya aquí mi agente verificó todo lo que necesita para empezar con la configuración:

En mi caso me pidió que le diera un nombre de perfil. Así que le puedo decir que use el default o darle un nombre. Yo elijo el default.

Esto sirve por si quieres trabajar en diferentes proyectos. Le dices al agente que proyecto tiene que usar y utilizará ese perfil.

Una vez definido el perfil me pide que inicie sesión. Solo necesitas aws login y se abrirá una ventana en tu navegador para terminar de hacer login y seleccionar el proyecto al que quieras acceder.

En mi caso yo estoy colaborando en un proyecto con un compañero por eso se ven dos tarjetas para elegir. Una que en particular dice: Owned by Ramsés.

Si quieres saber más acerca de los proyectos, checa este link, ya que es una ¡nueva feature!

Seleccionamos la opción que necesitemos y vamos a ver la siguiente pantalla:

Después de que haya seleccionado el proyecto se crean credenciales temporales para que pueda acceder a mi cuenta desde la terminal (este acceso lo usará el agente. Ojo, el agente nunca tiene acceso a mi token o contraseña).

Ya que tenemos el acceso listo, el agente configura las Agent Skills que contienen buenas prácticas para trabajar con AWS.

Esto le dará a nuestro agente instrucciones adicionales para que sepa qué hacer en ciertos momentos y que no invente cosas.

Después instalará las nuevas reglas e instrucciones para aprovechar al máximo la nueva experiencia de AWS.

Esto agregará las instrucciones a las guías de tu agente. En mi caso, estoy usando Kiro, así que configurará esas instrucciones en los Steering Files.

Al finalizar, el agente tiene todas las herramientas necesarias para trabajar con nuestra cuenta. Incluso a mí me aparece que puedo pedirle una nueva webapp.

Algo que también es útil es que le podemos preguntar acerca de la nueva experiencia de AWS.

Otra cosa que está genial en la nueva experiencia son los límites de gastos, que también nos los menciona.

Empecemos a crear

Ya que tenemos esto podemos crear lo que nosotros nos imaginemos y desplegarlo de inmediato en nuestra cuenta. Ya no tenemos que desperdiciar tanto tiempo configurando. Ahora podemos aprovechar ese tiempo construyendo, ya que AWS se encarga de darnos una cuenta con configuraciones sensatas por default para que no nos preocupemos.

Recuerda: cada vez que vayas a trabajar con AWS, únicamente escribe aws login para crear las credenciales temporales y que tu agente pueda desplegar tus recursos. ¡Ojo! No te olvides revisar cada acción que el agente tome por ti para siempre estar seguro de lo que estás haciendo 🙂.

¿Qué es lo primero que vas a crear con esta nueva experiencia? Deja tu comentario.

Build without stopping to set up IAM roles in the new AWS experience

Fabricio Flores — Tue, 13 Oct 2026 14:54:34 +0000

The new AWS experience removes two pieces of permission setup that often interrupt an early build. First, a project owner can now invite another person with an emailed invite, instead of having to set up an IAM user or IAM Identity Center. Second, when you create a resource using a supported AWS service, IAM role manager can automatically set up the IAM role for you so that your project resources can talk to each other.

Those actions involve different identities. Project access authorizes the person doing the work. An IAM role authorizes the service or application that runs afterward.

If you created your account through the new AWS experience, role manager is already turned on. When you create a supported resource, such as a Lambda function, AWS creates or reuses the role it needs and attaches it automatically.

Share a project with collaborators

A project owner can share access in two ways: invite someone from theTeam page and choose one or more projects, or open a specific project and invite them from its Members area. An invitation from the Team page does not automatically share every project the owner has; access applies only to the selected projects. After accepting, the team member has admin access to the resources and services available in those projects, including the ability to create access controls for services and applications. They cannot perform owner-only team-management, project, root, or financial actions. If you need to customize a team member’s access instead of granting project admin access, you must first activate advanced AWS features. For more details about sharing projects and team member access, see Invite team members to collaborate in AWS Settings.

To see the invitation process in action, watch Invite Your Teammate to Your AWS Project.

How role manager works

An IAM role defines what an AWS service is allowed to access and do. Setting one up usually means defining which service can assume the role, choosing what that service is allowed to do, and attaching the role to the resource.

IAM role manager automates that setup. When you create a resource in one of the supported services, role manager creates a role for it or reuses one that already fits. It then attaches the role as part of the same workflow, so you do not have to stop and set it up separately in IAM.

For accounts created through the new AWS experience, role manager is enabled by default. You cannot disable it until the account owner activates advanced AWS features.

This restriction is enforced by an AWS-managed service control policy (SCP). In the new experience, AWS manages the SCPs and resource control policies (RCPs) that protect your projects' preconfigured defaults, so you do not set up or edit these guardrails. For details, see Managed policies for your organization.

After advanced features are activated, you can manage role manager from Account settings in the IAM console.

How role manager sets up a Lambda execution role

Lambda is a useful example because AWS cannot know ahead of time which services your code will call. With role manager enabled, creating a function automatically attaches an execution role that the code can use immediately. You can narrow that role later, once you know what the function actually needs.

Because those permissions are unknown at creation time, role manager starts the role with the AWS managed PowerUserAccess policy. This gives the function broad access to AWS services, but it does not allow the function to manage IAM, AWS Organizations, or account settings. The role's trust policy allows only Lambda to assume it.

After the function is created, open its Configuration tab and choose Permissions. The Execution role panel shows the PowerUserRole that role manager attached.

Follow the role link to IAM. On the role's Permissions tab, choose PowerUserAccess to inspect the AWS managed policy and the access it grants.

Roles created by role manager are standard IAM roles, so you can inspect their trust policies and permissions, edit them, or delete them. Each role records the AWS-managed template it came from, which lets you identify roles created by role manager. AWS CloudTrail records each role's creation.

Refine permissions before production

Least privilege means giving a workload only the actions and resource access it needs. Role manager's PowerUserAccess policy is useful while you are still discovering those needs, but it is intentionally broader than most production functions require.

Use IAM Access Analyzer policy generation to help refine the role's permissions toward least privilege. Editing the role removes it from role manager's control and makes it a standard role that you manage.

After activating advanced AWS features, you can disable role manager without affecting existing applications or removing their roles. Existing roles stay in place, but new resources use the standard service or IAM role-creation workflows.

Conclusion

Role manager automates the initial IAM role setup for supported AWS services. It creates or reuses a role and attaches it while you create the resource, but the result remains a standard IAM role that you can inspect and control.

Together with AWS-managed project sharing, this reduces the access setup required for both collaborators and the services they build. Before production, review how the workload actually behaves and use IAM Access Analyzer policy generation to replace broad permissions with a more focused policy.

To get started, create a resource in a supported service. In accounts created through the new AWS experience, role manager is already enabled. For more information about managing roles yourself, see IAM role creation.

Cut AI agent token costs with decision models for tool selection

Elizabeth Fuentes L — Tue, 13 Oct 2026 08:44:45 +0000

Give an AI agent a real toolset (25, 40, more) and every call pays for it. The agent reads every tool description to use one, so input tokens grow with each tool you add. And with many similar tools in view (search, search_hotels, search_flights...), the model picks the wrong one more often.

Two costs on every turn: tokens you did not need to spend, and picks you did not want. Giving the agent fewer tools is not the fix, because different turns need different tools. You want the full toolset available but only the relevant few in front of the model each turn.

In an earlier post I solved this with semantic tool selection over a vector store: embed every tool description into an index (FAISS), embed the query, and keep the nearest few. It works, and that walkthrough covers it in depth. But it has a cost of its own: you maintain an embedding index for your tools, every query pays an embedding call, and the index has to stay in sync as tools change.

A new class of model changes this. A decision model reads the request and the list of tools and returns a calibrated choice directly, with no embeddings and no index. It generates no text, so there is nothing to parse, and the choice comes with a confidence score.

Three have arrived recently: Strands Decider, an open-source 2B model that runs locally; Jev (TypeSafe), a hosted one; and the OpenAI Decisions API (gpt-6-luna, public beta since Oct 2026), also hosted. All three answer the same bounded question, which tool fits this request?, and all three skip the vector store entirely. You get the token and accuracy win of tool selection without building or maintaining an index.

How Strands fits in

Strands lets you plug any of these in the same way, through a hook that runs before the model and swaps the agent's tools for the turn. The selector inside the hook can be the vector store or a decision model, and the same idea extends to model routing, choosing which model serves the request.

class ToolFilterHook(HookProvider):
    def register_hooks(self, registry):
        registry.add_callback(BeforeModelCallEvent, self.filter)

    async def filter(self, event):
        tools = await self.select(query)      # vector, decider, Jev, or OpenAI Decisions
        swap(event.agent, tools)              # the model now sees only these

agent = Agent(tools=ALL_TOOLS, hooks=[ToolFilterHook(select)])

The agent is built once with every tool; the hook trims the registry per request. This is where Strands earns its place: it swaps tools on the live agent at runtime, so the conversation survives. Frameworks that force you to rebuild the agent to change its tools lose that history. Here you keep the memory, and you switch strategy by swapping select in one line.

The swap itself is a few lines against the agent's tool registry. Clear it and register the chosen tools; the running agent and its message history stay intact:

def swap(agent, tools):
    reg = agent.tool_registry
    reg.registry.clear()          # drop the previous turn's tools
    reg.dynamic_tools.clear()
    for t in tools:               # register only the ones picked this turn
        reg.register_tool(t)
    # agent.messages is untouched — the conversation is preserved

References: Strands hooks, hook events,
and model routing.

Keeping the live conversation is memory within a session. For memory that lasts across sessions, Strands has a dedicated
memory library: pluggable memory stores on a unified storage interface. You attach a store, a local file store for prototyping or Amazon Bedrock Knowledge Bases with semantic search for production (or your own backend), and the agent gets recall, automatic injection into the prompt, and extraction of new memories. So the hook keeps this turn's context, and the memory store carries durable knowledge between runs.

Model routing

The hook decides which tools. Strands model routing decides which model. Give a ModelRouter a few candidates and a strategy; the strategy picks one per request. A decision model fits this role well: picking the model is a choice among a few unordered options — exactly what these models are built for — and it votes with a calibrated pick instead of a chat call.

All three decision models plug into the same RoutingStrategy interface: Jev (hosted), Strands Decider (local 2B), and the OpenAI Decisions API (gpt-6-luna, a choice question over the candidate models). The example below uses Jev — the one wired in the demo (model_routing_with_jev.py); swapping in Strands Decider or OpenAI Decisions is a one-class change, so you pick on hosted-vs-local and which provider you are already on. Routing to a cheaper model for the easy requests is where this pays off — OpenAI reports a run that cut cost 54% by classifying each job before picking the model.

router = ModelRouter(models=[small, large], strategy=JevRoutingStrategy())
agent = Agent(model=router)

Same shape as the tool hook: a cheap decision in front, the expensive model only when it is needed.

The comparison

Same 12 queries, same ~25-tool pool, one demo run (AWS Bedrock Claude Haiku as the agent):

Approach	Accuracy	Chat tokens	Latency (end to end)
Send all tools	10 / 12	~56k	~1.1s, fastest
Hook + vector	11 / 12	~20k	~1.8s (+ an embedding call)
Hook + decision model	11 / 12	~16k	~2.3s (+ a decision call)

Both selectors reach the same accuracy and cut chat tokens by about two-thirds. But each adds a call before the model: vector embeds the query (and pays embedding tokens), the decision model runs one choice, so here they are slower end to end, not faster. At 25 tools, sending everything is the quickest.

That ordering flips as the toolset grows. The model's prefill (reading the prompt before it answers) scales worse than linearly with input length, so a bigger pile of tool descriptions makes every call slower, and an agent makes many calls. Past some tool count the baseline's growing prefill overtakes the fixed cost of one selection step, and selecting first becomes the faster path, not just the cheaper one.

So the real takeaway is not a fixed latency winner; it is that you spend a small, constant selection cost to keep the prompt, the token bill, and the prefill small, and that pays off more as you add tools.

Where the delay is

Follow the request through the pipeline and you can see exactly where each approach spends time:

Send all tools: one step, the model call. No selection, so nothing extra, but the model reads all ~25 tool descriptions.
Hook + vector: three steps before the answer: embed the query (a network call to the embedding model), search the index (local, microseconds), then the model call. The added delay is the embedding round-trip.
Hook + decision model: two steps before the answer: the decision (local inference for Strands Decider, or a network call for Jev), then the model call. The added delay is that one decision.

So the extra latency lives in the selection step, before the model runs. The model call itself is cheaper afterwards (a short tool list), but not cheap enough at this scale to beat skipping selection entirely.

Which selector should I use?

Already embedding things? Vector is the smallest add.
Want a calibrated pick and no index? A decision model.
Run a small model locally? Strands Decider 2B. Prefer a managed endpoint? Jev.
Already on OpenAI, or need image context? The OpenAI Decisions API — hosted, calibrated choice + confidence, billed on input tokens only ($0.10/1M), and it accepts images as well as text (which Jev does not yet).

They are not exclusive. The hook makes them interchangeable in one line.

A quick selection benchmark

Measuring only the pick — which tool each selector returns — over 20 labelled queries against a ~25-tool pool (warm, single run on 2026-10-07):

Selector	Accuracy	Mean	p50	Cost
Vector (FAISS/Titan)	95%	155 ms	144 ms	— (embedding call)
Jev (hosted)	100%	210 ms	200 ms	—
OpenAI Decisions (`gpt-6-luna`)	100%	275 ms	258 ms	$0.054 / 1k picks (538 input tok each)

Small set, one run — treat it as an early signal, not a verdict. Both decision models matched the right tool on every query here; vector missed one. (This is the selection step in isolation; the end-to end table above measures a different 12-query run including the agent's answer.)

Try it

All of this runs in the open-source demo (Demo 02),
why-agents-fail-sample-for-amazon-agentcore. It has chat.py (vector), chat_decider.py (local decision model), model_routing_with_jev.py (model routing), and a notebook that measures accuracy and tokens for each — including the hosted OpenAI Decisions API as a third selector.

FAQ

Does trimming tools hurt accuracy? No. In the demo it raised accuracy, because fewer similar tools means less confusion. The risk is dropping the right tool; tune how many you keep.

Why a hook instead of rebuilding the agent? Rebuilding loses the conversation. The hook changes the tools on the live agent, so memory survives and you switch strategy in one line.

Does a decision model save tokens? It sends fewer tool descriptions to the agent and generates no text itself. It is a separate, cheap call, not a chat turn.

Is this tied to Strands? The idea (filter before the model) is general. Strands makes it first-class: hooks, the tool-registry swap, and model routing are built in.

What do I need to run the OpenAI Decisions selector? An OPENAI_API_KEY and openai>=3.26.0 (or just POST to /v1/decisions). It is in public beta on gpt-6-luna, returns a typed choice with confidence, and bills input tokens only — no output or cache charges.

Gracias!

🇻🇪 Dev.to Linkedin GitHub Twitter Instagram Youtube

Elizabeth Fuentes LFollow

I help developers build production-ready AI applications through hands-on tutorials and open-source projects.

How I built this serverless API with the new AWS

Fabricio Flores — Thu, 08 Oct 2026 21:56:17 +0000

AI coding agents have shortened the path from an idea to working code. The updated AWS experience is designed to make deployment keep pace. It connects your agent to an AWS project, configures the AWS tools it needs, and handles permissions between the resources it creates.

I used that workflow to turn a short prompt into a Python API using Amazon API Gateway, AWS Lambda, and Amazon DynamoDB. The build starts by connecting the agent to AWS and ends with a working endpoint that I call from my terminal.

Connect a coding agent to the AWS project

After signing in, I followed the instructions in the Setup Agent Toolkit for AWS dialog and pasted its setup prompt into my coding agent.

The agent then:

installed the AWS Command Line Interface (AWS CLI),
used aws login to sign me in,
configured the AWS MCP server and core AWS skills, and
added customizable rules for building on AWS.

Describe the API in one prompt

With the agent connected, I described the service I wanted:

I specified Python, asked for a stateful response I could test, and told the agent to show me the architecture before deploying. I left the AWS service choices open.

Review the proposed architecture

Before creating resources, the agent proposed this architecture:

The detailed proposal defined GET /counter as an atomic increment of a value stored in DynamoDB. API Gateway would expose the public endpoint, a Python Lambda function would handle each request, and an on-demand DynamoDB table would maintain state across calls. The atomic update would prevent duplicate values during concurrent requests.

The plan also included conservative throttling, a least-privilege IAM role for the table update and function logging, CloudWatch log retention, local tests, and deployment through an AWS CloudFormation stack.

The agent explicitly said that no AWS resources had been changed and asked me to approve the architecture and public endpoint before continuing.

Let the agent build and deploy

After I approved the plan, the agent deployed the serverless-counter-api CloudFormation stack in us-east-2. The deployment included:

a public API Gateway endpoint,
a Python 3.12 Lambda function,
a DynamoDB table to store the counter, and
an IAM role giving the function the access it needed.

The API was intentionally public for this demo. Anyone with the URL could invoke it and generate usage, so a production API should use authorization appropriate to its callers and data.

Call the live endpoint

The agent verified the deployment by calling the endpoint three times. Each call returned HTTP 200 with {"value": 1}, {"value": 2}, and {"value": 3}. A consistent DynamoDB read confirmed that the stored value was 3.

Later, I set API_URL to the /prod/counter invoke URL and called it three times in a loop:

Those calls returned {"value": 7}, {"value": 8}, and {"value": 9}. The increasing values confirmed that the service was live and maintaining state across requests.

What I kept control of

I chose what the API should do, reviewed the proposed architecture, and approved the public deployment. The agent handled the tooling setup, implementation, deployment, and first tests.

Before wrapping up, I verified the result myself: Lambda updated DynamoDB atomically and returned the new value, the permissions were limited to what the function needed, and GET /counter worked. The agent reported success, but the final call was mine.

Try this with a coding agent you already use. Get started here, then give your agent a small AWS project and ask to see the plan before it deploys anything. You make the calls and check the result. Let the agent handle the setup and get the first version running.

Now go build something 😄.

How to use the OpenAI Decisions API with Strands Agents

Elizabeth Fuentes L — Wed, 07 Oct 2026 18:50:13 +0000

OpenAI shipped a Decisions API. It isn't a chat model you coax into choosing: it
answers a bounded question directly. You give it a request and a fixed list of
options, it returns one of them with a confidence. No generated text, no option
it invents, nothing to parse. The returned choice is always one you supplied.

An agent is full of bounded questions, so I wired it into a
Strands agent two ways. Both are in the repo and
both run. Here they are side by side.

A quick word on Strands

Strands Agents is an open-source SDK for building AI agents. You create one in a couple of lines: give it a model, a system prompt, and the tools it can call.

from strands import Agent
from strands.models import BedrockModel

agent = Agent(
    model=BedrockModel(model_id="global.anthropic.claude-haiku-4-5-20251001-v1:0"),
    system_prompt="You are a travel agent that helps people with hotels.",
    tools=[get_hotel_room_rates, book_hotel],
)
agent("How much is a room at the Cliffside Resort?")

Tools, hooks, a model router: they attach to the agent like Lego pieces. Add a tool and the agent can call it; add a hook and you run your own code at a point in the agent's lifecycle; swap the model for a router and the agent chooses its model per request. The agent stays the same two lines; you compose behavior by clicking pieces onto it. The two ways below are exactly that: one hook, one router.

The call, once

Both uses share one request shape, through the official async client:

from openai import AsyncOpenAI

oai = AsyncOpenAI()  # reads OPENAI_API_KEY
resp = await oai.decisions.create(
    model="gpt-6-luna",
    input="How much is a room at the Cliffside Resort?",
    questions=[{
        "type": "choice",
        "name": "pick",
        "instructions": "Which option best answers this request?",
        "choices": [            # one {value, description} per option
            {"value": "get_hotel_room_rates", "description": "Nightly room rates for a hotel"},
            {"value": "get_weather", "description": "Current weather for a city"},
        ],
    }],
)
answer = next(a for a in resp.answers if a.name == "pick")
answer.choice        # -> "get_hotel_room_rates"
answer.confidence    # -> 0.97

What changes between the two uses is only what the choices are: tools in one,
models in the other. Both are below. One narrows the toolbox a model sees; the
other picks which model runs. Pick the one your agent needs, or use both.

Way 1: choose the tool, and cut the tokens

Give a small model forty overlapping tools and it picks the wrong one or invents
one. Every tool is also tokens it pays for on every turn: name, description,
schema. Choosing the relevant tool before the model runs fixes both, and in
Strands that choice lives in a hook (BeforeModelCallEvent), because it
changes what the agent sees: the hook swaps the agent's tool registry down to
the pick. The selector is one function; everything else is the hook.

oai_choices = [{"value": t.tool_name, "description": t.tool_spec["description"]} for t in ALL_TOOLS]

async def openai_select(query):
    resp = await oai.decisions.create(
        model="gpt-6-luna", input=query,
        questions=[{"type": "choice", "name": "tool",
                    "instructions": "Which tool answers this request?", "choices": oai_choices}],
    )
    answer = next(a for a in resp.answers if a.name == "tool")
    return [BY_NAME[answer.choice]]

agent = Agent(model=AGENT_MODEL, tools=ALL_TOOLS, system_prompt=PROMPT,
              hooks=[ToolFilterHook(openai_select)], callback_handler=None)
await agent.invoke_async("How much is a room at the Cliffside Resort?")

Over the demo's 40-tool pool, each pick is a bounded choice rather than a
generated tool name:

get_hotel_room_rates   (confidence 1.00)  <- How much is a room at the Cliffside Resort?
get_weather_forecast   (confidence 0.99)  <- What's the weather forecast for Tokyo next week?
book_hotel             (confidence 0.97)  <- Book Cliffside Resort for John Smith for 2 nights

Way 2: choose the model, and match cost to the request

Not every request needs your strongest model. Routing the easy ones to a small,
cheap model and reserving the capable model for hard work keeps quality where it
matters without paying top price on trivial questions.

Strands routes each request to one of several models with ModelRouter, and the
choice is a pluggable RoutingStrategy. This choice does not live in a hook: you
pass the router as the agent's model, which is Strands' seam for picking the
model (the docs say so plainly: pass the router as the model, not through
plugins). Plug the Decisions API in as the classifier: the router's candidates
become the choices, and the decision model picks which model serves the turn. It
judges the request against each candidate's description, and knows nothing
about the models themselves.

class OpenAIDecisionsRoutingStrategy(RoutingStrategy):
    def __init__(self):
        self._oai = AsyncOpenAI()

    async def select(self, context, **kwargs):
        if context.attempts:          # route the opening attempt only
            return None
        query = _user_text(context)
        choices = [{"value": c.name, "description": c.description or c.name} for c in context.candidates]
        resp = await self._oai.decisions.create(
            model="gpt-6-luna", input=query,
            questions=[{"type": "choice", "name": "model",
                        "instructions": "Which model should handle this request?", "choices": choices}],
        )
        answer = next(a for a in resp.answers if a.name == "model")
        return next((c for c in context.candidates if c.name == answer.choice), None)

router = ModelRouter(models=[routine, advanced], strategy=OpenAIDecisionsRoutingStrategy())
agent = Agent(model=router, callback_handler=None)

The routine lookups go to the small model, the reasoning tasks to the strong
one:

routine   (confidence 1.0)   <- What time zone is Tokyo in?
routine   (confidence 1.0)   <- What is the capital of Australia?
advanced  (confidence 1.0)   <- Design a rollback-safe idempotency-key migration
advanced  (confidence 0.98)  <- Compare optimistic vs pessimistic locking, recommend one

So which one?

Both are the same one-call pattern behind different Strands seams: a hook for the
tool, a router for the model. A decision model is a chooser, so you stop asking
a generator to choose and hoping its text parses into a real option. How would
you point it at your agent? Which choice in your loop is the one you don't trust
a chat model to make?

Try it yourself

Both ways run end to end against your own questions. Set OPENAI_API_KEY and go:

git clone https://github.com/elizabethfuentes12/why-agents-fail-sample-for-amazon-agentcore
cd why-agents-fail-sample-for-amazon-agentcore/02-semantic-tools-demo
uv venv && uv pip install -r requirements.txt

If it saves you time, give the repo a ⭐. It helps others find it.

Resources

OpenAI Decisions API
Strands hooks
Strands model routing
Why AI Agents Fail (the companion repo)

¡Gracias!

🇻🇪🇨🇱 Dev.to Linkedin GitHub Twitter Instagram YouTube

Por que os assistentes de IA ainda erram tanto (e o que fazer sobre isso)

Giovana Armani — Fri, 02 Oct 2026 20:21:28 +0000

Em janeiro desse ano, perguntei para meu assistente de IA sobre AWS Lambda Durable Functions. Ele muito gentilmente me falou que eu estava ficando maluca, a AWS não tinha uma feature com esse nome...

Acontece que essa feature foi lançada em dezembro do ano passado e quando fiz a pergunta, estava usando um modelo de IA que tinha sido treinado vários meses antes. Meu assistente não tinha ferramentas que conectasse ele à documentação da AWS ou nenhuma instrução de quando ela deveria ser consultada.

Os desafios de trabalhar com IA

Conto essa história de frustração pessoal para dizer que trabalhar com IA não é um mar de rosas. Se você é desenvolvedor nos dias de hoje, você já sabe disso, mas quando tudo ao seu redor fala sobre como a IA vai dominar o mundo, é difícil entender porque ainda tem tantos problemas.

Para entender isso, é legal olhar para como os modelos de IA são construídos e como funcionam. Para começo de conversa, a maioria dos assistentes de IA atuais são construídos com LLMs (Large Language Models, ou em português, Grandes Modelos de Linguagem). Esses modelos são treinados com um volume gigante de dados que ajudam eles a entender, interpretar e produzir texto. Isso vale para linguagem humana e também para código.

Quando mandamos um prompt a um assistente de IA, o modelo por trás faz um cálculo probabilístico para nos dar uma resposta. Em outras palavras, o modelo produz o texto da resposta prevendo parte por parte qual é a próxima palavra mais provável de se encaixar no que o usuário espera. Isso nos traz resultados que parecem coerentes, mas não são necessariamente o que queremos ou a melhor solução para nosso problema.

Esse funcionamento traz vários desafios que vamos ver ao longo do artigo (e também como lidar com eles), mas também traz uma boa notícia para os desenvolvedores que vira e mexe me perguntam se a IA vai roubar o trabalho deles. Escrever código é diferente de construir software, assim como escrever texto é diferente de produzir conteúdo.

Quando falamos sobre escrever código, queremos dizer transformar instruções em implementação. Já quando falamos em software, nos referimos a transformar ideias abstratas em um sistema confiável. Ou seja, por mais poderosa que a IA fique, alguém ainda precisa entender o problema antes de ele virar código, acompanhar enquanto o sistema é desenvolvido e ser dono do software depois que ele existe. É aí que mora o perigo dos resultados que parecem certos, estão quase certos, mas não exatamente. Se a gente aceita tudo de olhos fechados, herdamos esses "quase" como se fossem nossos.

Como trabalhar melhor com IA

Vamos então falar mais especificamente sobre desafios do uso de IA no desenvolvimento e criação e o que podemos fazer sobre eles. Os assistentes de IA trazem várias features que podem nos ajudar a administrar esses desafios e trabalhar melhor com a ferramenta.

Vou usar o Kiro e suas features como base da discussão, mas a maioria das dicas aqui podem ser aplicadas com qualquer assistente.

O que fazer quando a IA te chama de maluca

Como vimos, os modelos de IA têm como base o conhecimento que receberam através de seus dados de treinamento. Se não conectamos eles a ferramentas ou fontes de informação externas, eles acabam ficando "presos no tempo", com o conhecimento limitado a esses dados. É isso que gera situações como a que eu descrevi no começo do artigo em que o Kiro me falou que não existia uma feature chamada AWS Lambda Durable Functions.

A forma mais comum de conectar seu assistente a ferramentas externas é o MCP, ou Model Context Protocol. Ele é um protocolo aberto que conecta assistentes de IA a ferramentas externas.

Um bom exemplo é o servidor MCP aws-knowledge, mantido pela própria AWS, que dá ao assistente acesso à documentação oficial sempre atualizada. Com ele conectado, o Kiro deixa de depender só do que aprendeu no treinamento e passa a consultar a fonte na hora de responder. Foi assim que resolvi meu problema lá no começo do ano enquanto estudava sobre Lambda Durable Functions. Com esse servidor configurado, em vez de me dizer que eu estava ficando maluca, o Kiro agora consulta a documentação, descobre que a feature existe sim, e me responde baseado nela.

{
  "mcpServers": {
    "aws-knowledge-mcp-server" : {
      "url" : "https://knowledge-mcp.global.api.aws",
      "disabled" : false
    }
  }
}

MCP - Melhores Práticas

É importante lembrar que além de leitura, um servidor MCP pode também ter acesso a ferramentas para criar, editar ou até apagar coisas por você. Por isso, vale tomar cuidado com o uso. Algumas melhores práticas que sugiro:

Revise antes de aprovar: Toda vez que o assistente quiser usar uma ferramenta MCP, ele pede sua aprovação. Não aprove no automático, antes leia o que ele vai fazer, confira os parâmetros e entenda o efeito. Se parecer suspeito, negue. Deixe o auto-approve apenas para ações que você sabe que são seguras e repetitivas, como uma consulta de leitura.
Bloqueie ações perigosas: Além do cuidado de revisar o que o assistente faz, você pode explicitamente configurar o que você jamais quer que ele faça. Por exemplo, se você conecta seu assistente com um MCP do GitHub, pode querer impedir que ele tome ações destrutivas como apagar repositórios ou forçar o merge de uma alteração. No Kiro, por exemplo, faríamos isso com disabledTools:

{
  "mcpServers": {
    "github": {
      "command": "uvx",
      "args": ["github-mcp-server@latest"],
      "disabledTools": ["delete_repository", "force_push"]
    }
  }
}

3 . Auto approve para ações seguras: Por outro lado, existem ações cotidianas que sabemos que são seguras e não queremos ficar clicando aprove o tempo todo, para isso podemos declarar as ferramentas que são automaticamente aprovadas.

{
  "mcpServers": {
    "github": {
      "command": "uvx",
      "args": ["github-mcp-server@latest"],
      "disabledTools": ["delete_repository", "force_push"],
      "autoApprove": ["search_repositories", "get_file_contents"]
    }
  }
}

4 . Proteja suas chaves e tokens: Muitos servidores MCP precisam de credenciais para funcionar. Nunca faça commit de uma config com segredos dentro, prefira variáveis de ambiente. E quando gerar um token, use o de menor permissão possível e rotacione de tempos em tempos.

Por que você recebe respostas genéricas mesmo com prompts gigantes

Outro problema que enfrentamos é de fazer a IA entender exatamente o que queremos. Costumamos achar que colocar o máximo de informação possível no prompt vai fazer com que as respostas sejam mais assertivas, o que muitas vezes até ajuda. Mas quando o assistente tem informação demais sem referência de prioridade, pode ter dificuldade de determinar o que é realmente importante. A verdade é que contexto irrelevante não é neutro, compete por atenção e piora a qualidade da resposta.

A solução para isso é direcionar o foco do seu assistente, e uma das formas mais práticas de fazer isso são os steering files. São arquivos markdown onde você registra as regras, padrões e preferências do seu projeto, e que o assistente passa a considerar na hora de responder. Em vez de repetir no prompt que você usa um certo padrão de nomes, que prefere uma biblioteca a outra ou que todo componente precisa ser acessível, você escreve isso uma vez em um steering file e o assistente lembra. No Kiro eles ficam na pasta .kiro/steering/.

Um detalhe importante é que você não precisa deixar todo esse contexto ligado o tempo todo, o que nos traria de volta o problema de contexto demais. Para isso existem os inclusion modes, que controlam quando cada arquivo entra na conversa. No Kiro, um steering file pode estar sempre ativo (always), ser carregado só quando você mexe em certos arquivos (fileMatch), entrar sob demanda quando você chama (manual), ou ser puxado por relevância com base na descrição (auto). Assim, o Kiro carrega cada regra no momento em que ela é realmente necessária.

Steering Files - Melhores Práticas

Para aproveitar bem os steering files, algumas boas práticas:

Um domínio por arquivo: Separe API, testes, deploy, etc em arquivos distintos, em vez de amontoar tudo em um arquivão só. É o mesmo princípio de um bom código. Isso traz dois ganhos. Primeiro, os inclusion modes só funcionam bem se cada arquivo tem um escopo único, afinal não dá para carregar "só a parte de testes" de um arquivo que mistura dez assuntos diferentes. Segundo, facilita a manutenção, já que arquivos focados geram diffs pequenos e legíveis, o que facilita a revisão.
Nomes claros e descritivos: Prefira nomes específicos como api-rest-conventions.md, testing-unit-patterns.md ou components-form-validation.md. A própria lista de arquivos vira um índice do que existe e de onde mexer, tanto para você quanto para o assistente.
Inclua o "porquê": Não registre só o "o quê" da regra, explique a razão por trás dela. Uma regra sem justificativa só funciona nos casos que ela previu literalmente, enquanto uma regra com justificativa funciona também nos casos que ninguém antecipou. Se o steering diz "fazemos X porque já tentamos Y e deu o problema Z", o assistente não vai tentar "consertar" uma decisão que foi deliberada.
Faça manutenção regular: Trate mudanças de steering como mudanças de código, com revisão. Revise os arquivos em momentos como planejamento de sprint ou mudanças de arquitetura, e confira as referências a arquivos depois de reestruturações, para não deixar o assistente seguindo uma regra que não vale mais.

Para quando não aguentar mais escrever os mesmos prompts

Já teve algum momento que você percebeu que vive sempre pedindo a mesma coisa para seu assistente de IA? E mesmo assim, a cada vez que pede tem que ir fazendo várias correçõezinhas no processo? Talvez esteja na hora de criar uma skill.

Skills são pacotes de conhecimento especializado e instruções que você empacota uma vez e reutiliza sempre que precisar. Em vez de reescrever o mesmo prompt detalhado e ir fazendo as mesmas correções toda vez, você formaliza aquele processo recorrente numa skill: o passo a passo, as regras principais e até scripts de apoio ou arquivos de referência. O resultado é mais assertividade, porque o assistente deixa de reinventar o processo a cada pedido e passa a seguir sempre o mesmo caminho que você já validou.

A diferença das skills para os steering files está em quando e como cada um atua. O steering é amplo e sempre lembra o assistente dos padrões do seu projeto. Já a skill é especializada e sob demanda. Dá para pensar assim: steering é "sempre tenha isso em mente", enquanto skill é "quando alguém pedir para fazer X, carregue todo esse conhecimento especializado e siga este workflow". No Kiro, as skills ficam em pastas (uma por skill, com um arquivo que descreve o que ela faz) e são ativadas automaticamente quando o pedido combina com a descrição que você escreveu, ou você pode chamá-las explicitamente.

Skills - Melhores Práticas

Para criar skills que realmente ajudam, valem algumas boas práticas:

Escreva descrições precisas: É a descrição que decide quando o assistente ativa a skill, então inclua palavras-chave e ações concretas. No início da conversa, só o nome e a descrição são carregados (um mecanismo chamado progressive disclosure, que evita encher o contexto do assistente), e o resto só entra quando a skill é acionada. Por isso quanto mais clara e precisa for sua descrição, mais fácil será para o assistente saber o momento de usá-la.
Use scripts para tarefas determinísticas: Tarefas determinísticas como validação, geração de arquivos e chamadas de API são mais confiáveis como scripts do que como código gerado pelo LLM na hora. Se o passo sempre acontece do mesmo jeito, deixe-o num script dentro da skill, em vez de contar com o modelo para recriá-lo a cada vez.
Escolha o escopo certo: Use o escopo global (~/.kiro/skills/) para workflows pessoais que você usa em qualquer projeto, e o escopo de workspace (.kiro/skills/) para procedimentos do time e convenções específicas daquele projeto. Nesse segundo caso, versione a pasta junto do código para que todo mundo compartilhe os mesmos workflows.

Como ser mais assertivo no vibe coding

Por último, vamos falar sobre o uso de IA quando desenvolvemos aplicações. Com o uso de IA para desenvolvimento de software, a produção de código está mais rápida do que nunca. Mas será que com tanta velocidade e volume, estamos sendo atentos à qualidade produzida? Temos clareza dos requisitos e certeza que o código os cumpre como esperado? Estamos seguindo os padrões de código que determinamos para facilitar revisão e manutenção?

Para nos ajudar com isso, o Kiro traz uma funcionalidade de spec-driven development, ou o Spec mode. Se trata de uma forma de desenvolvimento de features guiado por especificações. Você começa o desenvolvimento pela especificação de requisitos e documentação. Isso acontece no Kiro através da criação de 3 arquivos: um requirements.md com o que precisa ser feito, um design.md com as decisões técnicas e um tasks.md com o passo a passo da implementação. Só depois de alinhar esses documentos é que a IA parte para escrever o código, agora com um alvo claro em vez de um prompt solto. Se quiser saber mais sobre specs e o que eu construi usando esse modo, veja esse artigo sobre a aplicação que construí para acompanhar meus treinos.

Spec Driven Development - Melhores Práticas

Para tirar o melhor do spec-driven development, sugiro algumas boas práticas:

Uma spec por feature, não uma spec gigante: O padrão recomendado é ter várias specs no repositório, cada uma para uma feature, em vez de uma única spec tentando descrever o codebase inteiro. Algo como .kiro/specs/user-authentication/, .kiro/specs/product-catalog/, .kiro/specs/shopping-cart/. Isso mantém cada documento gerenciável e ainda permite que pessoas diferentes trabalhem em features diferentes em paralelo.
Itere nas specs: As specs não devem ser escritas em pedra no começo e esquecidas. Conforme o entendimento da feature evolui, atualize o requirements.md e o design.md, e mantenha o tasks.md sincronizado com o que realmente vai ser feito. A spec só continua útil enquanto reflete a realidade do que você está construindo.
Versione e compartilhe: Guarde as specs no repositório, junto do código, para que elas sejam versionadas da mesma forma.

O que levar dessa leitura

Começamos esse artigo com um assistente me chamando de maluca, e ao longo dele vimos que boa parte das dores de trabalhar com IA tem explicação, e também solução. Quando o modelo está preso no tempo, conectamos ferramentas externas com MCP. Quando ele se perde em contexto demais, direcionamos o foco com steering files. Quando ele dá respostas genéricas ou nos faz repetir o mesmo pedido mil vezes, empacotamos conhecimento em skills. E quando a pressa de produzir código ameaça atropelar os requisitos, trazemos método com o spec-driven development.

Nenhuma dessas técnicas precisa andar sozinha. Na prática, o melhor resultado vem de combinar várias (ou todas) delas, e de nunca abrir mão da revisão humana, principalmente nas etapas de criação e nas ações mais críticas. Porque, no fim do dia, por mais que a IA faça o trabalho pesado, é a gente que entende o problema antes dele virar código e responde pelo software depois que ele existe.

E apesar de eu ter usado ferramentas de desenvolvimento como exemplo, esse raciocínio vale para qualquer pessoa que trabalha com IA, seja escrevendo código, texto ou qualquer outra coisa. A IA é uma ferramenta poderosa, talvez a mais poderosa que a gente já teve nas mãos, mas continua sendo uma ferramenta. E toda orquestra, por melhores que sejam os instrumentos, ainda precisa de um maestro.

Se se interessou pelo Kiro e gostaria de saber mais, assista à playlist sobre Kiro no canal do YouTube mantido pelo meu time da AWS e me siga para mais conteúdos sobre IA, desenvolvimento e cloud! 😉

Kiro Crew + Discord: Running My Agent From My Phone

Laura Salinas — Fri, 02 Oct 2026 19:00:00 +0000

I've been working on coding projects in my terminal and my IDE for years, (shoutout to CodeBlocks for my C++ fans!) but as agents continue to make the case for streamlined task management in our development cycles, one thing that I found frustrating was the moment I had to step away, close the terminal or lost network access my tasks would stop or stall dead in their tracks.

A task is running, a review is halfway done, and then I decide I want to grab a coffee at the office and I'm on my phone in line with no way to check in on any of it.

So when Kiro Crew went open source and launched on August 4th, the feature that grabbed me wasn't the multi-agent orchestration or the scheduling (though they are neat!). It was the idea that you could connect to your agent sessions across multiple channels, Discord being one of them. That meant I could kick off work at my desk and check on my crew from my phone, without SSHing into anything or being chained to my laptop.

In this post I'll walk you through how I got started with Kiro Crew and how I wired up the Discord channel so I could interact with my agent session on the go. I'll cover a quick crash course on what Kiro Crew actually is for those who haven't heard of it yet, my setup steps, and the honest rough edges I hit along the way.

So what is Kiro Crew?

Kiro Crew is a persistent, open source development workspace that remembers your context and learns how you work. It runs locally or remotely on your own hardware. Think of it less like a chat window and more like a workspace that keeps going when you're not there. It's self-learning and self-evolving, which means it carries memory and context across sessions instead of starting cold every time.

Key characteristics:

Persistent - Sessions, memory, schedules, and task checkpoints survive beyond a single chat and across restarts.
Self-learning - Corrections you give it become durable lessons that change how it behaves later.
Self-evolving - Repeated patterns can turn into reusable skills you can inspect and edit.
Runs where you choose - Keep it on your own machine, in a local container, or on a remote box you control.
One Gateway, many surfaces - The desktop app, web dashboard, and CLI all talk to the same runtime, and so do channels like Slack, Discord, and Telegram, etc.

Interesting sidenote: Kiro Crew started internally at Amazon as "MeshClaw", built by 3 engineers as a side project to improve their own day to day workflows. In a couple months it was adopted by 39,000+ Amazon builders. If you're curious about the engineers and their story on this project, you can check out the blog post they wrote.

Getting Started with Kiro Crew

Step 1: Install the Desktop App

The easiest way to get started is trying the desktop app which can be downloaded directly from kiro.dev/crew/. During download Kiro Crew will recognize any existing agents you have installed locally (by default it picks up Kiro so you won't see it on the list).

⚠️ You will need the Kiro CLI installed as well given that Kiro Crew runs LLM use over ACP through the CLI. More info in the docs.

Next, the wizard will ask you to decide whether you want Kiro Crew to import agent settings from other coding agents as well. If you want to carry over existing skills, MCP servers, steering files etc this is where you can pick and choose.

Finally decide what your UI theme and mode will be and you're ready to start using your crew.

Step 2: Confirm It's Running

The UI can be a bit overwhelming on first glance, but once you understand where everything lives you'll be flowing through workflows easily.

The place where everything begins is your Sessions pane, and you start all your new agent sessions from here as well. Click "New chat" to begin your first session.

Type in the chat panel and press Enter. Each tab is an independent session with full tool access, ability to read/write files, run commands, browse the web, or call any configured MCP tool.

Enabling the Discord Channel 📲

Step 1: Create the Discord Bot

The connection I wanted to setup was Discord, to do so you can step through the in detail instructions in the docs, but I'll outline the major steps here.

⚠️ Any steps after this will require a Discord account (which is free!)

1/ Head to the Discord Developer Portal create a new "New Application" and give it a name you'll recognize to link with Kiro Crew.

2/ On the Bot pane in the left generate a new token by clicking "Reset Token" (you'll need this handy to paste back into the Kiro Crew settings)

3/ Log into your Discord account and head to Settings -> Developer -> Toggle "On" Developer Mode (this allows you to grab your user ID)

4/ Click on your account profile and now you'll see a "Copy User ID" button

Step 2: Bind It to Your Gateway

5/ Open up the Kiro Crew settings -> Messaging Channels -> Discord -> Toggle "On" Enable Discord

6/ Add in your Discord bot token and Allowed user IDs in their respective areas and when done don't forget to hit "Save Discord Settings" at the very bottom

Step 3: Talk to Your Crew from Discord

7/ The final step is to install your new Discord bot into your Discord server. I did this with the Install Link from the Installation pane in the developer portal.

I now go into my Discord and can start DM'ing my bot which will communicate to Kiro Crew and create a new instance on the desktop app that shows it's being "Driven from Discord DM"

I have this session linked up to my portfolio website repo locally on my Mac so the agent use is scoped only to that workspace. What that allows me to do though is exactly what I discussed earlier, I can now go get that coffee, run that errand or be away from my laptop while still getting work done through my agent or checking in on progress from previous interactions.

In the case of my portfolio website session, on the go I can now add new event resource pages from the events I'm presenting at, or wire up my content page to reflect any new videos or blogs I've been working on.

The On-the-Go Workflow in Practice

⚠️ Note that the setup I discuss here is using my Mac desktop app as the gateway for Kiro Crew, but you can run Kiro Crew remotely on your own hardware (like a Mac Mini/EC2 instance/Docker container/etc) and maintain a gateway that never shuts off, and thus have always on use of your sessions.

Challenges and Rough Edges 😵‍💫

Pain point 1 - Discord bot setup requires lots of moving back and forth across windows, developer settings and your Discord app to confirm everything was setup properly. I kept bot settings super simple and only had it be used through DMs so I didn't have to setup new Discord servers or threads in order to interact with the bot/agent session.
Pain point 2 - You are still bound by speed of light (network and model 😅) here so some interactions with the Kiro agent take a little longer to generate a response than others.

Final Takeaway

This channel connection ability, in addition to some Kiro Crew features like persistent sessions, built in memory and scheduling, make this the perfect time to explore this open source project for yourself. Kiro Crew uses your existing Kiro account to consume credits so one login works across the various Kiro surfaces (IDE/CLI/Crew/Web).

The team managing the repo is accepting and merging something like 143+ commits per week so if you're also someone interested in contributing to Kiro Crew, create a PR with your bug/feature request and see where it takes you. This experience is being built in the open, for developers by developers and I'd like to think it can only get better as more contributions are made.

Don't forget to give me a 🦄 if you got this far and let me know what you're using Kiro Crew for in the comments!

Additional Resources 📚

What Is an AWS Builder ID?

Sean Boult — Fri, 02 Oct 2026 16:00:00 +0000

yeah... you've probably heard of an "AWS Builder ID" but you're not quite sure what it means.

I'm going to break it down nicely so you have a good idea of what it is.

You may or may not have a Builder ID, but if you're reading this on builder.aws.com you do 😉. If not, today is your chance to create one, stick around til the end.

tl;dr: Builder ID is a personal login (your email) for most AWS tools, including AWS Builder Center, Amazon Quick and AWS Skill Builder. And now, for the new AWS experience too!

We just the launched new AWS experience this week, which makes it easier to get started with AWS, and Builder ID is also your AWS sign-in and billing identity. No root user or IAM user needed.

You can sign up with an email or login providers like Google, Apple, Github, and Amazon. If you didn't already have a Builder ID, one will be created for you as part of this process.

Once you're signed in you can create your first AWS project build the next awesome idea.

Have more ideas, make another project!

Give the new exp a try and let us what you think.

Try the new AWS experience

As always, happy coding 😎!

Follow AWS for more articles like this.

AWS Follow

Articles written by current and past AWS Developer Advocates to help people interested in building on AWS. Opinions are each author's own.

Follow me for all things tech.

Sean BoultFollow

Developer. Hacker. Creator.

What the new AWS means if you're just getting started

Ramses Mata — Thu, 01 Oct 2026 16:13:11 +0000

The first time I used AWS, it was because I had built something locally and wanted to deploy it so my friends could see what I was already seeing on localhost. But that whole journey, from the moment I first landed on the AWS login screen, created my account, all the way to finally watching my app run, took me weeks.

What do I need? What are Regions, and which one do I pick? What is IAM, and why is it asking me for so many permissions? How do I know how much one specific app is costing me? And why is everything so scattered?

AWS is rolling out a new experience built exactly for folks who are just getting started, because I wasn't the only one who ran into these questions and AWS listened. The new experience smooths out a lot of the friction that existed for people using AWS for the first time. In this post I'll walk you through what those changes are and what they mean if you're just starting out.

How do you create an AWS account?

To kick things off, you can now create your account with Google, GitHub, or an AWS Builder ID. That makes life easier, because you no longer have to waste time filling out a huge form, and you can start building in just a few clicks. And what excites me the most is that for most new users a credit card won't be required anymore, which I think is awesome for students.

Projects

Something that always bugged me was that if you didn't have much experience, or if you hadn't put in a good time studying governance, getting a clear picture of the resources you were using for one specific app turned into a real challenge.

Now in the new AWS experience, there's something called Projects. A project is a separate AWS account where you create resources. The difference is that you can create several projects, and the resources you create in one project won't show up in the others.

Inviting team members

This is something I would have loved back when I was in school, being able to invite my classmates into the same space to build together without fighting with IAM and explaining to them how to use credentials.

In the new experience you can invite team members to your projects just by sending them an email invite from AWS Settings. They create their own AWS Builder ID to get in and that's it, they're already collaborating with you, and there's no cost for inviting collaborators. They share the same project and only pay for the resources they use, just like if you were on your own. That makes it perfect for studying in a group, for a hackathon, or for your final university project. If you want the exact steps, they're in the official docs for inviting team members.

Start building without fighting the permissions

When I started, IAM was one of the most confusing things. Why do I have to create users, roles, and policies just to try something out? It felt like a giant wall standing between me and building anything.

To understand what changes, it helps me to think of permissions as three separate layers.

The first layer is who gets into your project, meaning which people can log in and work. Before, you set this up by hand, creating users, credentials, and policies for each person. In the new experience, AWS handles it. You don't create users anymore, you invite people by email and they get in with their AWS Builder ID as team members.

The second layer is the project's rules, the limits that apply to the whole project and define what can be done in general, like working in a single Region or which services are available. In the new experience AWS takes care of this one too, so you don't configure it. If you want to take a look at the details, it's in the docs on policies for projects.

The third layer is access between your resources and the outside world. Here's the nice surprise, inside your project your resources can already talk to each other by default, so your Lambda can read your DynamoDB without you wiring up any IAM policies. What stays in your hands is deciding what to expose publicly, because by default nothing in your project is reachable from the internet until you configure it, like a public S3 bucket, an API Gateway, or a Lambda function URL.

No surprise bills while you learn

When you're starting out, the scariest part usually isn't the code, it's the bill. The new experience handles that in a way that genuinely calmed me down.

It starts with the Free Tier. As a new user you get up to $200 in credits, $100 the moment you create your account and up to $100 more as you complete activities such as creating a lambda function or an EC2 instance which is great to start learning and building. You can use those credits over your first six months. On the Free plan you build with free services and those credits, and you don't get charged unless you choose to upgrade, so there are no surprise overages while you're learning.

On top of that, because your resources live inside projects, you can see exactly how much each project is spending instead of digging through one big pile. That clarity per project was something I really wished when I started.

And when your free credits run out and you move to the Paid plan to keep building, that's where spend limits come in. A spend limit is a monthly cap on a project, and if you reach it, AWS pauses the project so your bill never grows past what you set. Spend limits are a Paid plan feature, so think of them as your safety net for when you grow beyond the free credits. Here are the details on how to create a spend limit.

A single Region, and why that helps you at the start

Another question that kept nagging at me was the one about Regions. Which one do I pick? What if I get it wrong?

In the new experience each project works in a single Region, so that's one less decision to make when you're starting. All your regional resources live there and if you want to confirm which one is yours, you'll find it in AWS Settings, in your project's additional info.

Frequently asked questions

What happens if I hit my spend limit?

Your project pauses so you don't keep spending. To bring it back, the project owner raises the limit from AWS Settings.

Can I use any AWS service?

Not all of them are available right out of the gate. If a service doesn't show up, you can check the list of supported services and, if you need it, turn on advanced features, which is AWS the way we knew it before.

Where do I see what I'm spending?

In AWS Settings, under Billing. Your billing is shared across all your projects, so you pay in one place instead of juggling a separate bill for each. Even so, you can still see how much each project is spending on its own, so nothing feels scattered.

Wrapping up

What would have helped me most when I started wasn't another tutorial, it was clearing away the roadblocks that kept me from even getting going. And that's exactly what the new AWS experience solves.

You sign in with a social login and work inside a project, without so much upfront setup.
You invite your friends to collaborate at no extra cost for adding them.
You start with free credits and clear costs per project, and spend limits cap your bill once you move to the Paid plan.
AWS manages human access, so IAM stops being the first pebble in your shoe.
You work in a single Region, with fewer decisions to make at the start.

If any of this sparked your curiosity, the best next step is to create your project and build something small. Theory really clicks when you put it into practice, and now the path to doing that is a whole lot shorter.

If you like this kind of content and you're more of a video person, follow us on our YouTube channel AWS Developers, we'll be waiting for you there.

Switching Between Your Personal ChatGPT Account and Amazon Bedrock

Matheus Guimaraes — Thu, 01 Oct 2026 10:33:52 +0000

In the previous post in this series, I walked through how to configure the ChatGPT desktop app to use OpenAI models through Amazon Bedrock.

That works great if Bedrock is the only environment you want to use. But what if you want to use both your personal ChatGPT account and Amazon Bedrock?

That's when it gets awkward.

I found that out the hard way after setting up my Bedrock configuration, because my intention was always to keep using my personal ChatGPT account as well and switch between the two on demand to help me manage my token limits.

I also didn't want two completely separate Codex environments. I wanted to keep the same local conversations, files and working state, and simply change which provider was handling the model requests.

So I built a small account switcher to make that easier.

If you just want the solution, you can grab it here:

techwithmatheus/codex-account-switcher

It includes an installer, uninstaller and two simple commands:

codex-personal
codex-bedrock

If you'd rather understand what it's doing before installing it, keep reading. That's what the rest of this post is about.

The problem with simply switching accounts

When you're using the normal ChatGPT experience, switching accounts is something you generally think about at the application level.

Bedrock is different.

In the setup from the previous post, Codex is configured locally with something like:

model = "openai.gpt-6-astra"
model_provider = "amazon-bedrock"

[model_providers.amazon-bedrock.aws]
profile = "codex-bedrock"
region = "us-west-2"
wire_api = "responses"

That tells Codex to send model requests through Amazon Bedrock using the AWS profile and Region you've configured.

So Bedrock isn't another ChatGPT account that can simply appear in the normal account switcher. It's a different model-provider configuration.

My first thought was therefore to maintain two separate Codex environments: one for my personal account and another for Bedrock.

That would work, but there's a downside.

Why I decided not to separate the whole Codex environment

Codex stores its local state under:

~/.codex

And there's considerably more in there than config.toml.

On my machine, that directory contains authentication state, sessions, thread history, memories, plugins, skills, model caches, trusted-project settings and several local databases used by the desktop experience.

If I gave my personal and Bedrock setups completely separate Codex homes, I would also be separating much of that useful state.

That wasn't really what I wanted.

My use case was closer to this:

same Codex workspace
same conversations
same local state
different model provider

So I tried something simpler.

I completely quit the ChatGPT app, removed only the Bedrock-specific configuration from ~/.codex/config.toml, and launched it again.

The desktop app returned to my personal ChatGPT-backed Codex environment.

More importantly, a test conversation that I had originally created while using Bedrock was still there. It contained a small .NET console application, and I could still open the generated files in the desktop preview.

I then quit the app, restored the Bedrock configuration and launched it again.

The same conversation and files were still there.

So that's the model we'll use here: keep the Codex state shared and switch only the part of the configuration that selects Amazon Bedrock.

There was another nice surprise when I later tested the full uninstall flow. When I switched back to my personal ChatGPT environment, I expected to have to sign in again. I didn't.

My existing personal authentication was still part of the shared Codex state. Bedrock had changed which provider handled the model requests, but it hadn't logged me out of my personal ChatGPT account.

This is behaviour I've personally verified on macOS with the ChatGPT desktop app. I haven't tested every piece of desktop state, so I'm deliberately not claiming that every feature behaves identically across providers.

Back up your configuration first

Before changing anything, make a backup of your existing Codex configuration.

I like using the date and time in the filename so old backups remain meaningful:

cp ~/.codex/config.toml ~/.codex/config.toml.backup.$(date +%F-%H%M%S)

I'd also back up your .zshrc, since the installer will add a small block to it:

cp ~/.zshrc ~/.zshrc.backup.$(date +%F-%H%M%S)

You don't need to copy the whole ~/.codex directory for this. The switcher doesn't touch your sessions, memories, authentication databases or other Codex state.

We'll also make the switcher maintain a rolling safety backup before it modifies config.toml, but that's different from this manual checkpoint.

Install the switcher

I've put the maintained version of the switcher on GitHub:

techwithmatheus/codex-account-switcher

Clone the repository:

git clone https://github.com/techwithmatheus/codex-account-switcher.git
cd codex-account-switcher

Then run the installer:

bash install.sh

I'm deliberately using bash install.sh rather than ./install.sh. That means you don't have to change executable permissions on the downloaded script first.

The installer puts the switcher under:

~/.config/codex-switcher/
├── codex-switcher.zsh
└── config

and adds a small marked block to ~/.zshrc so zsh loads it whenever you open a shell.

The actual switching code lives in its own file rather than dumping a large shell function directly into your .zshrc. That makes it much easier to inspect, maintain or replace later.

After installation, reload your shell:

source ~/.zshrc

Configure your Bedrock settings

The switcher's Bedrock-specific settings live in:

~/.config/codex-switcher/config

The defaults used throughout this series are:

CODEX_BEDROCK_MODEL="openai.gpt-6-astra"
CODEX_BEDROCK_PROFILE="codex-bedrock"
CODEX_BEDROCK_REGION="us-west-2"

If you used different values when configuring Bedrock, update them there.

For example, if your AWS profile is called work-bedrock:

CODEX_BEDROCK_PROFILE="work-bedrock"

The model and Region should likewise match the Bedrock setup you've already verified.

What if Bedrock is already configured?

If you've just followed the first article, you may already have Amazon Bedrock active when you install the switcher.

The installer handles that case too.

If it finds the standard Bedrock configuration already active, it shows the values it discovered:

Existing Amazon Bedrock configuration found.

Model:       openai.gpt-6-astra
AWS profile: codex-bedrock
Region:      us-west-2

These provider settings will be adopted by the switcher and will not be replaced.

Continue? [Y/n]

It then adopts the existing settings rather than creating a duplicate Bedrock provider configuration.

If you're starting from your normal personal ChatGPT environment instead, your current Codex configuration is left alone and the switcher starts from there.

What the switcher actually changes

When Bedrock is active, the tool owns one clearly marked block inside ~/.codex/config.toml:

# >>> codex-bedrock-switcher >>>
model = "openai.gpt-6-astra"
model_provider = "amazon-bedrock"

[model_providers.amazon-bedrock.aws]
profile = "codex-bedrock"
region = "us-west-2"
wire_api = "responses"
# <<< codex-bedrock-switcher <<<

The values come from the separate switcher configuration file we just looked at.

Everything outside those markers belongs to Codex, or to you, and the switcher leaves it alone.

That's important because the desktop-generated config.toml can contain much more than provider configuration: desktop preferences, plugins, MCP servers, trusted projects and other settings may all live in the same file.

Replacing the entire file whenever you switch would be unnecessarily risky.

Before each automated change, the current configuration is also copied to:

~/.codex/config.toml.switcher-backup

That's a rolling safety backup. It contains the state immediately before the most recent switch and is intentionally overwritten on later switches.

Switch to Amazon Bedrock

Once everything is installed and your configuration looks right, run:

codex-bedrock

The switcher will:

make a safety backup of your current config.toml;
add the managed Bedrock block;
launch the ChatGPT desktop app.

The rest of your Codex state remains where it was.

Switch back to your personal ChatGPT account

To go back:

codex-personal

The switcher removes only the Bedrock block it owns.

It does not insert some handcrafted OpenAI provider configuration in its place.

That's deliberate.

During testing, removing the Bedrock override was enough for the desktop app to return naturally to my personal ChatGPT-backed environment using its existing authentication and defaults.

So rather than trying to reproduce configuration that Codex already knows how to manage, the switcher simply gets out of the way.

In my tests, I didn't need to authenticate again either. My personal ChatGPT login was still available because we had never replaced or deleted the shared Codex authentication state.

What if ChatGPT is still running?

I didn't want the switcher modifying config.toml underneath a running desktop application.

So if ChatGPT is still open when you run either command, you'll get:

Answer y and the switcher asks macOS to quit ChatGPT normally, waits until the application has exited, performs the switch and launches it again.

Anything else cancels the operation.

The important part here is that it uses the application's normal quit behaviour rather than abruptly killing the process.

Skip the question

If you already know you want it to close ChatGPT, use -f or --force:

codex-bedrock -f

or:

codex-personal --force

That closes the app automatically and continues with the switch.

Do the conversations actually carry across?

This was the part I cared about most.

I created a test conversation while Codex was configured through Amazon Bedrock. In that conversation I had it create a small .NET console application that displayed the date.

I then switched the desktop app back to my personal ChatGPT environment.

The conversation was still in the app. I could open it and inspect the generated files in the preview panel.

I switched back to Bedrock and it remained there as well.

So at least for the local conversation and generated-file workflow I tested, this gives me what I wanted:

Personal ChatGPT
        │
        ▼
same local Codex workspace
        ▲
        │
Amazon Bedrock

The conversations aren't being recreated each time you switch providers. We're keeping the same local Codex state and changing which provider handles model requests.

That doesn't mean the underlying services suddenly share billing, authentication or infrastructure. They don't.

What we're preserving is the local working environment around them.

What if I already use another custom provider?

Codex can contain definitions for multiple model providers in the same configuration, and the switcher leaves unrelated provider definitions alone.

However, this utility is not intended to be a universal provider manager.

It specifically manages:

Personal ChatGPT / OpenAI
            ⇅
       Amazon Bedrock

If you also use another custom provider, you can continue switching to it using whatever method you already use.

There is one important behaviour to understand.

Running:

codex-bedrock

deliberately makes Bedrock active.

Running:

codex-personal

removes the Bedrock override and returns Codex to its normal personal ChatGPT/OpenAI behaviour.

It does not remember that you previously happened to be using some third provider and restore that provider instead.

Because of that, if the automatic installer finds an unrelated custom provider currently active, it stops instead of trying to guess what your configuration means.

You can still install the switcher manually alongside a more complex provider setup. The repository README contains the manual installation steps.

And if there's another provider you'd like the switcher to support directly, feel free to open an issue. Pull requests are welcome too.

Uninstalling the switcher

Run:

bash uninstall.sh

The slightly interesting part of uninstalling isn't removing the shell files. It's deciding which provider should remain configured afterward.

The uninstaller therefore asks:

Removing the switcher means ChatGPT will be left configured for a single provider.

Which provider would you like to keep?

1) Personal ChatGPT / OpenAI
2) Amazon Bedrock
3) Cancel

If you choose Personal ChatGPT / OpenAI, the switcher-managed Bedrock block is removed.

If you choose Amazon Bedrock, the Bedrock settings stay in config.toml, but the switcher's marker comments are removed. What remains is simply a normal Codex Bedrock configuration like the one from the first article.

And if you choose Cancel, nothing changes.

One thing the uninstaller deliberately does not do is restore some snapshot of config.toml from the day you installed the switcher.

Your Codex configuration may have legitimately evolved since then with new desktop settings, project permissions, plugins or other configuration. Restoring an old snapshot could wipe changes that have nothing to do with this tool.

Why `~/.config`?

You'll notice the utility lives under:

~/.config/codex-switcher/

rather than inside the Codex directory itself.

~/.config is a common convention in Unix-style command-line environments for user-specific configuration. macOS doesn't guarantee that the directory already exists, so the installer creates it when necessary.

I also deliberately keep the utility outside ~/.codex.

The switcher isn't part of Codex. It's a small shell tool that modifies one well-defined part of Codex configuration, and keeping its own code and settings separate makes that boundary clearer.

A provider switch, not a second account system

There's one distinction worth finishing on.

This doesn't turn Amazon Bedrock into another ChatGPT account.

Your personal ChatGPT environment and your Bedrock environment are still separate in the ways that matter: authentication, billing and the infrastructure processing the model requests are different.

What we've done is take advantage of the fact that Codex's local workspace doesn't need to be discarded just because the active model provider changes.

For my workflow, that's considerably more useful than maintaining two completely isolated desktop environments.

I can keep working in the same Codex setup and choose whether the next part of that work should run through my personal ChatGPT environment or through Amazon Bedrock.

Until the desktop app has a first-class way to handle that scenario, two shell commands are doing the job nicely.

Source code

The switcher, installer and uninstaller used in this article are available here:

techwithmatheus/codex-account-switcher

The repository also contains manual installation instructions, configuration details and notes for people already using other custom providers.

If Codex changes in a way that affects the switching mechanism, I'll maintain the implementation there rather than expecting readers to keep copying an old shell snippet.