DEV Community: AWS

AI Game Mashups: Can AI Really Turn Two Games Into One?

Matheus Guimaraes — Thu, 29 Oct 2026 11:27:37 +0000

Mario shooting some baddies in Halo. Minecraft inside GTA V (see Appendix: a real-world example). A social media trend has people sharing videos of what’s being branded as “AI game mashups.” The claim is that people have used AI to reverse engineer different games and mash them together into one in unexpected or cool ways... but is that the whole story?

As usual, hype has a tendency to exaggerate things to create, well, more hype. So let's separate reality from fiction and explore what’s actually happening behind these demos.

The good news is that there is plenty on the reality side to be mind-blown about! However, there are also some disappointing truths. At least for the time being.

Let's Mash Candy Crush And Call of Duty!

Let's walk through a ridiculous combination as a practical example. Let's imagine that we want to combine Candy Crush and Call of Duty!

However, simply naming two games does not constitute a plan. Like anything else, first we need to work out our requirements and architectural concerns.

Here's my take: every time you reload your weapon, Candy Crush loads inside the Call of Duty gameplay and you have to complete a match-three puzzle before the reload can finish.

Hypothetical mashup: solve a match-three puzzle to finish reloading. AI-generated concept illustration, not a screenshot of a working mod.

I have no idea whether that would be fun. I suspect my teammates would have opinions. But at least we now have something concrete enough to discuss.

There are still decisions to make though. Does the shooter pause while you solve the puzzle? What happens if you fail? Can you cancel? Does a harder puzzle earn you more ammunition?

Neither original game contains the answers so it's up to us to introduce new rules.

And that is our first lesson: Connecting two game engines does not automatically create coherent new gameplay. Somebody, potentially with AI assistance, still has to decide what the connection means and implement it.

What Are We Actually Mashing Together?

When I watch these demos, I find it useful to separate four things.

What’s happening	What it establishes
Visual composition	Images or rendered objects from different sources appear together.
Event integration	Something happening in one game triggers something in another.
Gameplay orchestration	New rules coordinate actions and state across the games.
Hybrid game design	Those rules form a coherent experience with its own objectives, constraints and balance.

These can overlap. A project might combine graphics and translate a few events without sharing every part of either simulation.

For example, an explosion in one game could trigger an explosion in another. That is a meaningful integration, but it doesn’t, by itself, establish that every object in both worlds can collide, that both physics engines agree, or that every mission works across the boundary.

A clip can still demonstrate a specific interaction beautifully while leaving those broader questions unanswered.

The missing interfaces

Ok, so how can we go about implementing our Call of Duty and Candy Crush mash-up? Well, to begin with we need to discover each game's available integration points. Then we need to find a way to connect those before finally figuring out how to coordinate the result.

1. Find a way to control the relevant behaviour

A game with a supported modding API might already expose the events and controls we need. Otherwise, investigating its internal behaviour may be necessary.

For our shooter, we would need to identify a reload request and find a reliable way to defer it. For the puzzle, we need to start a challenge and detect its completion. Observing an animation on screen is different from having a dependable signal that the underlying action succeeded.

This is where reverse engineering can contribute: working out how software behaves when its original source code or a suitable interface isn’t available.

REA, or Reverse Engineer Anything, is one project in this area and the one behind the viral game mashups trend. Its documentation describes connecting agents to analysis tools, including Ghidra, Hopper and IDA, and returning findings that an agent can investigate further.

It is indeed a pretty cool tool that gives an agent ways to inspect software. However, it is NOT a magical command that enables agents to recover an entire game’s original source project or to understand every subsystem.

Moreover, it's important to remember that runtime modification of games predates AI tools.

Mod Engine 2, for example, documents runtime patching and injection for Souls games, including Elden Ring.[3] Existing tools and community knowledge are part of the foundation here.

2. Build interfaces between the games

Once we understand the relevant behaviour, we can build adapters: code that translates between what our mashup needs and what each game can actually do.

From the coordinating code’s perspective, the shooter adapter might offer operations such as “defer reload” or “resume gameplay.” The puzzle adapter might offer “start challenge” and a completion event.

Those are interfaces that we have to build unless the game itself provides out-of-the-box integration points, or in simpler language, hooks. This could be, for example, official support for mods. That means creating and maintaining your own adapter code, which, yes, you can also use AI to help you generate.

There is an added complication: If components run in separate processes, they need a way to exchange messages, such as sockets or named pipes. This is referred to as inter-process communication, often shortened to IPC.

A hook and a communication channel have different jobs. A hook can intercept behaviour inside a game whereas IPC lets separate processes exchange information. Having one doesn’t automatically give us the other.

Either way, we arrive at our second lesson: AI doesn't somehow make two incompatible executables magically understand each other. The real magic is that AI can help us build the missing interfaces between them.

3. Implement the new rules

Now we need the coordinator, or orchestrator, that implements our reload rule so we can load Candy Crush every time you need to reload your weapon on Call of Duty.

Here's the plan: it receives a reload request, defers the action, puts the shooter into an appropriate paused state, and opens the puzzle. On success, it allows the reload to proceed and returns control to the shooter.

The orchestrator coordinates the reload and puzzle, with a recovery path for failure, cancellation or timeout. This conceptual flow assumes the required integration points exist.

What if the puzzle crashes though? The player shouldn’t remain trapped forever with a frozen gun. And how about if a completion message arrives twice? We need to be careful not to grant ammunition twice. Like any piece of software we need to design for our error conditions.

This is why “pause the game” deserves scrutiny. Preventing player input is different from pausing the simulation. In a networked game, the server and other players may continue regardless. Our example depends on capabilities that may be unavailable or prohibited in a protected online title.

If you work with microservices, there’s a familiar architectural idea here. Connecting two services doesn’t automatically create an e-commerce application. You still need rules that define what placing an order means, what happens next, and how failure is handled.

Games add another difficulty, one that becomes our third lesson: we still need to design and build gameplay rules for the mashup much like building any other game.

Do the games become one program?

They don’t have to.

In one possible implementation of our example, the shooter and puzzle remain separate processes while our own coordinator manages their behaviour and presentation.

The simplest implementation may be, for example, switching back and forth between the Candy Crush puzzle’s window and the Call of Duty window. A more integrated version could display the puzzle within the shooter’s view as ensioned in our concept above. We'll have to work harder for it because it then adds rendering and input-routing work but it does look super cool. Either way, the objective is to have the player experience a single set of rules while multiple programs do the work.

Another consideration is whether we need to create our own launcher app. This could gives even more control over the runtime and coordination between the two processes running either game, however it does not automatically give control over either game's internals.

So lesson four is: the desired user experience dictates how much control you need to have over either game and determines the architectural choices as well as the amount of code that you need to write and maintain.

Where did the graphics come from?

This is perhaps the most intriguing question.

A newly written game might use original artwork, generated assets, placeholders or reused material. A mod might leave the original game’s engine and assets in place. A mashup might combine output from two running engines, each rendering its own content.

Those are different workflows. A familiar character on screen doesn’t tell you which one happened.

In our hypothetical example, if both original games were running, neither would need its graphics recreated merely to appear in the experience. Each game already knows how to render its own world. The integration challenge would concern control, communication, presentation and the new rules.

Conversely, reproducing familiar graphics in a newly written program doesn’t establish that the original physics, enemy behaviour, timing or levels have been reproduced.

But hang on. If we put Mario inside Halo, how does he know where the floor is? Doesn’t he come with his own bounding box? The important distinction is that a character’s appearance and its collision behaviour are separate things. A visible model doesn’t automatically bring a working physics system with it.

For a hypothetical model replacement, we could give an existing Halo character Mario’s appearance while keeping the host character’s movement and collision setup. Or, if we were adding a new character, we would need to create or convert the collision data into a form the host engine understands and configure its behaviour. Halo wouldn’t need to recognise “Mario”; it would need a correctly configured character in its own simulation. That could stop him falling through the floor without reproducing how he moves in a Mario game.

So lesson number five is: Looking like two worlds have merged does not mean that their physics have merged too. There's work to be done to make that happen.

Asset provenance and permission are also separate questions from whether an integration works. A clip alone cannot answer them. Before making claims about how a creator obtained the assets, we need their documentation.

Where does the AI fit?

We should distinguish AI helping build the mashup from AI running it.

During development, an agent can use tools to investigate behaviour, propose integration code and help iterate on failures. REA’s documented workflow, for example, lets an agent inspect findings, ask follow-up questions, and write and test an implementation.[2]

But once our reload rule works, it can run as ordinary deterministic code. Receive the event, start the puzzle, wait for a result, update the state. There is no inherent need to ask a language model what should happen every time the player reloads.

AI can be the engineer that builds the bridge without being the driver that crosses it.

That distinction also helps us evaluate claims about speed. A successful demo shows that someone achieved a result. Understanding how much AI accelerated it requires more evidence: the starting tools, existing mods, development history, human interventions and failed attempts. The finished clip doesn’t contain that history.

Appreciate the demo. Be precise about the claim.

I find this trend exciting because it opens up questions about what people might build when investigating and connecting unfamiliar software becomes more accessible. Not to mention that level of creativity which makes me smile or even laugh out loud every time I see one out there.

But, if we're gonna get down to the nitty and gritty and talk technical, I scrutinize them about what they're trying to prove. What is running? How much of it is custom integration and coordination code? Which information crosses the boundary? Which interactions actually work? Where does the AI contribute?

An overlay, an event bridge and a hybrid game can all be worthwhile achievements. Describing them accurately gives the people building them credit for the work they actually did, and gives everyone else a better understanding of what remains unsolved.

Reverse engineering exposes capabilities. Integration connects them. Orchestration gives them new meaning.

Whatever the path you take, ultimately it comes down to our final lesson number six: AI or no AI, REA or whatever comes next...game mashups are a project like any other and still take a lot of work!

As for whether solving Candy Crush puzzles before reloading a gun in Call of Duty is a good idea...that is up for debate!

Appendix: A real-world example

The Universal Modder repository documents a Minecraft and GTA V story-mode example. Its description identifies a Minecraft Fabric mod, a ScriptHookV component and a ReShade add-on, with camera, ground and event information exchanged over a local WebSocket connection. It also describes combining Minecraft’s colour and depth output with GTA’s frame, and translating selected Minecraft events into GTA effects.[1]

There are two useful ideas in that description.

First, the games have specific integration components. A communication channel carries information, but code still has to decide what to send and what the receiving game should do with it.

Second, presentation and interaction are separate problems. Depth information helps decide which rendered surfaces should appear in front of others. That can make the combined image convincing. Making an object affect the other game’s simulation requires additional behaviour.

That is a substantial achievement. It is also a much more precise claim than “any two games can now be merged.” The project’s documented approach is evidence about that example, not a universal explanation for every viral mashup.

Sources

Project documentation checked on 20 October 2026; collision reference added on 29 October 2026. Named implementations are described from their maintainers’ documentation; I have not independently run or benchmarked them.

Universal Modder: documented Minecraft × GTA V example.
REA: overview and how it works.
Mod Engine 2: runtime patching, launcher and extension documentation.
Godot documentation: collision shapes, physics bodies and collision response. General collision concepts; not evidence of a particular Halo mod implementation.

Ship a Lambda Web Function with CDK

Sean Boult — Wed, 28 Oct 2026 17:45:51 +0000

So, AWS Lambda Web Functions just came out, and I'm super excited about them.

What are they? Well, you can now ship Express, Hono, or React Router with no Lambda-specific adapters or wrappers.

Let me show you how I got this demo set up with CDK.

λ: https://cxrj1w1j65n0k7ss.p7v.lambda-web.us-east-2.on.aws (this may not live forever but the code should)

⚠️ DISCLAIMER: The code we are about to see is written with L1 CDK constructs. The L2 constructs are being tracked via this PR.

First, let's look at the server code I have in Express. I've omitted the bulk of its logic for brevity.

Here, you can see that it's an Express.js server binding to a port.

import express from "express";

const [hostname, rawPort] = (
  process.env.AWS_LAMBDA_HTTP_ENDPOINT ??
  `127.0.0.1:${process.env.PORT ?? "3000"}`
).split(":");
const port = Number(rawPort);

export const app = express();

export const server = app.listen(port, hostname, () => {
  console.log(`Spinning Lambda is listening on http://${hostname}:${port}`);
});

I can run the code locally with pnpm dev.

Now, let's look at the CDK stack used to deploy this function.

export class SpinningLambdaStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    // code bucket stuff omitted
    const webFunction = new CfnWebFunction(this, "WebFunction", {
      functionName: `${this.stackName}-web`,
      // many props omitted for brevity
    });

    const revision = new CfnWebFunctionRevision(this, "WebFunctionRevision", {
      functionName: webFunction.ref,
      // many props omitted for brevity
    });

    const endpoint = new CfnWebFunctionEndpoint(this, "WebFunctionEndpoint", {
      functionName: webFunction.ref,
      // many props omitted for brevity
    });

  }
}

Now for deployment. I'm using the new AWS experience, so I have a project dedicated to this demo.

I grab some credentials for my account with aws login. I need to do a one-time setup to bootstrap CDK with npx cdk bootstrap.

Once that's done, I can run pnpm deploy to ship it.

Then it's live 🚀!

Share this on X/Twitter, and it should render as an embed:

https://cxrj1w1j65n0k7ss.p7v.lambda-web.us-east-2.on.aws/embed

Full repo:
https://github.com/sboult/lwf-three-js

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.

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.