Forem: AWS

Estructuras de datos: ¿Qué son los Stacks (LIFO)?

Axel Espinosa — Fri, 08 May 2026 21:22:09 +0000

¿Alguna vez te has preguntado qué pasa cuando presionas el botón "atrás" en tu navegador? ¿O cómo Ctrl + Z sabe exactamente qué acción deshacer? Detrás de esas funciones hay una estructura de datos que llevas años usando sin darte cuenta: el stack.

En los artículos anteriores vimos los arrays y los strings. Hoy toca hablar de la siguiente pieza: los stacks. Si los arrays son el almacén general, el stack es una pila de platos. Ya lo vas a ver.

Lo que encontrarás en este artículo:

Qué es un stack y qué significa LIFO

Las operaciones básicas: push, pop, peek, size, isEmpty

Cómo implementar tu propio stack en JavaScript

La complejidad Big O de cada operación

Dónde se usan los stacks en la vida real

¿Qué es un stack?

Un stack (o pila) es una estructura de datos que sigue el principio LIFO: Last In, First Out. En español: el último que entra es el primero que sale.

Imagina una pila de libros sobre tu escritorio. Vas apilándolos uno sobre otro. Cuando quieres leer uno, ¿por cuál empiezas? Por el de arriba, no por el de abajo. El último libro que pusiste es el primero que vas a tomar.

Esa es la esencia de un stack. No puedes sacar un elemento del medio o del fondo. Solo trabajas con el que está hasta arriba.

Pero aquí viene el detalle interesante: aunque suene restrictivo, esta limitación es justo lo que hace al stack útil. Cuando solo te importa el último elemento agregado, un stack es la herramienta perfecta.

Operaciones básicas de un stack

Un stack tiene cinco operaciones fundamentales. Estas son las que aparecen en el ADT (Abstract Data Type) de un stack:

push(item): agrega un elemento a la parte superior
pop(): elimina el elemento de arriba y lo devuelve
peek(): mira el elemento de arriba sin eliminarlo
size(): devuelve cuántos elementos hay en el stack
isEmpty(): dice si el stack está vacío o no

Las dos estrellas son push y pop. Con ellas agregas y quitas elementos, siempre desde la misma puerta: la de arriba.

Fíjate en cómo pop() siempre saca el último que entró. En el paso 3 agregamos 🐱, y en el paso 4 pop() nos devuelve 🐱. Si hubiéramos hecho pop() otra vez, nos devolvería 🐶.

Cómo implementar un stack en JavaScript

Dato curioso antes de empezar: los arrays en JavaScript ya se comportan como un stack. Si haces miArray.push(x) y miArray.pop(), estás trabajando como si fuera un stack..

Pero un array te deja hacer cosas que un stack no debería permitir: acceder por cualquier índice, unshift, splice, lo que quieras. Y esa libertad de más es justo lo que queremos esconder.

Así que vamos a implementarlo desde cero. Sin usar .push() ni .pop() del array. Solo lo vamos a usar como almacenamiento indexado y el control lo lleva nosotros. Así se ve qué pasa por debajo.

class Stack {
  constructor() {
    this.items = [];
    this.count = 0; // posición donde iría el próximo elemento
  }

  push(item) {
    this.items[this.count] = item;
    this.count++;
  }

  pop() {
    if (this.isEmpty()) {
      throw new Error("El stack está vacío");
    }
    this.count--;
    const item = this.items[this.count];
    this.items.length = this.count; // recortamos el array
    return item;
  }

  peek() {
    if (this.isEmpty()) {
      throw new Error("El stack está vacío");
    }
    return this.items[this.count - 1];
  }

  size() {
    return this.count;
  }

  isEmpty() {
    return this.count === 0;
  }
}

Probemos cómo se usa:

const miStack = new Stack();

miStack.push("🐶");
miStack.push("🐱");
miStack.push("👻");

console.log(miStack.size()); // 3
console.log(miStack.peek()); // "👻" (solo mira, no elimina)
console.log(miStack.pop()); // "👻" (lo elimina y devuelve)
console.log(miStack.size()); // 2
console.log(miStack.isEmpty()); // false

Así se ve el stack en cada paso:

Puedes probar este código en RunJS o verlo paso a paso en PythonTutor, que también soporta JavaScript.

Vamos a desarmar lo que está pasando:

count lleva la cuenta de cuántos elementos hay. También indica la siguiente posición libre del array. Recuerda que los arrays empiezan en el índice 0, así que cuando el stack está vacío count vale 0 y ese es justo el lugar donde va a caer el primer elemento.
push() coloca el nuevo elemento en la posición count y luego incrementa el contador.
pop() hace lo contrario: decrementa count primero (ahora apunta al último elemento), lee ese valor y recorta el array.
peek() lee la posición count - 1 (el último elemento) sin mover nada.

Por ejemplo, si hacemos push("🐶"), push("🐱"), push("👻"), el array queda así:

Cuando hacemos pop(), el contador baja de 3 a 2 y leemos items[2] que es 👻. Luego hacemos this.items.length = 2 para recortar el array, y listo.

Un truco de los arrays en JavaScript

Fíjate en esta línea: this.items.length = this.count. Podría parecer que solo estamos "cambiando un número", pero en realidad estamos modificando el array. En JavaScript, asignarle un valor menor a .length recorta el array y elimina los elementos que sobran.

Míralo por fuera de la clase:

const numbers = [1, 2, 3, 4, 5];

console.log(numbers.length); // 5

// Definir la longitud
numbers.length = 3;

console.log(numbers); // [1, 2, 3]
console.log(numbers.length); // 3
console.log(numbers[3]); // undefined (los elementos extra se eliminan)

Este es un detalle que muchos desarrolladores desconocen y te abre posibilidades interesantes. En nuestra clase lo usamos para asegurarnos de que el array y el contador count siempre estén sincronizados.

Si te fijas, no usamos los métodos push y pop del array nativo de JavaScript. Solo lo usamos como almacenamiento indexado. Todo el control lo lleva nuestra variable count.

Complejidad Big O de las operaciones

Ya vimos qué hace cada operación. Ahora, ¿cuánto cuestan? Aquí es donde entra Big O, la notación que nos dice cómo crece el tiempo de una operación conforme crece el stack.

Operación	Complejidad en tiempo	Complejidad en espacio
`push()`	O(1)*	O(1)
`pop()`	O(1)	O(1)
`peek()`	O(1)	O(1)
`size()`	O(1)	O(1)
`isEmpty()`	O(1)	O(1)

* Amortizado. Ocasionalmente O(n) cuando el array dinámico necesita crecer por debajo.

Todas las operaciones de un stack son O(1). ¿Por qué? Porque siempre trabajamos con un solo elemento: el de arriba. No importa si el stack tiene 10 o 10 millones de elementos, push y pop tardan lo mismo.

Compara esto con un array, donde insertar al inicio es O(n) porque hay que mover todos los elementos. En un stack no tenemos ese problema porque solo tocamos la punta.

Esta es la razón principal por la que los stacks se usan tanto: son rápidos y predecibles. Si tu problema solo necesita trabajar con el último elemento agregado, un stack te da esa operación en tiempo constante.

Eso sí, rápido no quiere decir infinito. Un stack vive en memoria, así que si crece demasiado va a depender por completo de los recursos del dispositivo donde corra. En celulares, tablets y computadoras con poca RAM esto importa más de lo que crees: un stack que crece sin control puede tronar la app. Los lenguajes hasta tienen un límite específico para el call stack, y si lo rebasas te topas con el famoso stack overflow.

¿Dónde se usan los stacks en la vida real?

Antes de ver ejemplos, quédate con esto:

Regla de oro: cuando lo único que te importa es el último elemento, un stack es la respuesta.

Todo lo que viene a continuación es una variante del mismo patrón. Una vez que lo ves, empiezas a reconocer stacks en todos lados.

Navegador web: botón de "atrás"

Cada vez que visitas una página nueva, el navegador hace push() con la URL. Cuando presionas "atrás", hace pop() y te lleva a la página anterior.

Funciona perfecto porque siempre quieres volver a la última página que visitaste, no a una del medio.

Ctrl + Z: deshacer acciones

Cuando escribes en un editor de texto, cada acción (escribir una letra, borrar, pegar) se agrega a un stack. Cuando presionas Ctrl + Z, la última acción se hace pop() y se deshace. Presionas Ctrl + Z otra vez y la penúltima se deshace.

Mismo patrón: siempre deshaces la acción más reciente.

Call stack de tu programa

Cuando una función llama a otra, que a su vez llama a otra, tu programa va apilando cada llamada en un "call stack". Cuando una función termina, se hace pop() y el control vuelve a la función anterior.

Por eso cuando ves un error con "stack trace" en la consola, estás viendo exactamente eso: el estado del stack de llamadas en el momento del error.

Validación de paréntesis balanceados

Un problema clásico de entrevistas. ¿Cómo verificas que en ((a + b) * (c - d)) todos los paréntesis estén correctamente balanceados? Con un stack. Cada ( hace push, cada ) hace pop. Si al final el stack está vacío, los paréntesis están balanceados.

Cierre

Los stacks son simples: cinco métodos, todos O(1), un solo principio (LIFO). Y justo por eso los encuentras en tantos lugares, desde el botón de atrás hasta el call stack de tu lenguaje de programación.

Si te sirvió el artículo, dale ❤️ y sígueme para no perderte el siguiente. Nos leemos pronto. 🙌🏻

Estructuras de datos: ¿Qué son los Stacks (LIFO)?

Axel Espinosa — Fri, 08 May 2026 21:22:09 +0000

En los artículos anteriores vimos los arrays y los strings. Hoy toca hablar de la siguiente pieza: los stacks. Si los arrays son el almacén general, el stack es una pila de platos. Ya lo vas a ver.

Lo que encontrarás en este artículo:

Qué es un stack y qué significa LIFO

Las operaciones básicas: push, pop, peek, size, isEmpty

Cómo implementar tu propio stack en JavaScript

La complejidad Big O de cada operación

Dónde se usan los stacks en la vida real

¿Qué es un stack?

Un stack (o pila) es una estructura de datos que sigue el principio LIFO: Last In, First Out. En español: el último que entra es el primero que sale.

Esa es la esencia de un stack. No puedes sacar un elemento del medio o del fondo. Solo trabajas con el que está hasta arriba.

Operaciones básicas de un stack

Un stack tiene cinco operaciones fundamentales. Estas son las que aparecen en el ADT (Abstract Data Type) de un stack:

push(item): agrega un elemento a la parte superior
pop(): elimina el elemento de arriba y lo devuelve
peek(): mira el elemento de arriba sin eliminarlo
size(): devuelve cuántos elementos hay en el stack
isEmpty(): dice si el stack está vacío o no

Las dos estrellas son push y pop. Con ellas agregas y quitas elementos, siempre desde la misma puerta: la de arriba.

Fíjate en cómo pop() siempre saca el último que entró. En el paso 3 agregamos 🐱, y en el paso 4 pop() nos devuelve 🐱. Si hubiéramos hecho pop() otra vez, nos devolvería 🐶.

Cómo implementar un stack en JavaScript

Dato curioso antes de empezar: los arrays en JavaScript ya se comportan como un stack. Si haces miArray.push(x) y miArray.pop(), estás trabajando como si fuera un stack..

Pero un array te deja hacer cosas que un stack no debería permitir: acceder por cualquier índice, unshift, splice, lo que quieras. Y esa libertad de más es justo lo que queremos esconder.

Así que vamos a implementarlo desde cero. Sin usar .push() ni .pop() del array. Solo lo vamos a usar como almacenamiento indexado y el control lo lleva nosotros. Así se ve qué pasa por debajo.

class Stack {
  constructor() {
    this.items = [];
    this.count = 0; // posición donde iría el próximo elemento
  }

  push(item) {
    this.items[this.count] = item;
    this.count++;
  }

  pop() {
    if (this.isEmpty()) {
      throw new Error("El stack está vacío");
    }
    this.count--;
    const item = this.items[this.count];
    this.items.length = this.count; // recortamos el array
    return item;
  }

  peek() {
    if (this.isEmpty()) {
      throw new Error("El stack está vacío");
    }
    return this.items[this.count - 1];
  }

  size() {
    return this.count;
  }

  isEmpty() {
    return this.count === 0;
  }
}

Probemos cómo se usa:

const miStack = new Stack();

miStack.push("🐶");
miStack.push("🐱");
miStack.push("👻");

console.log(miStack.size()); // 3
console.log(miStack.peek()); // "👻" (solo mira, no elimina)
console.log(miStack.pop()); // "👻" (lo elimina y devuelve)
console.log(miStack.size()); // 2
console.log(miStack.isEmpty()); // false

Así se ve el stack en cada paso:

Puedes probar este código en RunJS o verlo paso a paso en PythonTutor, que también soporta JavaScript.

Vamos a desarmar lo que está pasando:

count lleva la cuenta de cuántos elementos hay. También indica la siguiente posición libre del array. Recuerda que los arrays empiezan en el índice 0, así que cuando el stack está vacío count vale 0 y ese es justo el lugar donde va a caer el primer elemento.
push() coloca el nuevo elemento en la posición count y luego incrementa el contador.
pop() hace lo contrario: decrementa count primero (ahora apunta al último elemento), lee ese valor y recorta el array.
peek() lee la posición count - 1 (el último elemento) sin mover nada.

Por ejemplo, si hacemos push("🐶"), push("🐱"), push("👻"), el array queda así:

Cuando hacemos pop(), el contador baja de 3 a 2 y leemos items[2] que es 👻. Luego hacemos this.items.length = 2 para recortar el array, y listo.

Un truco de los arrays en JavaScript

Míralo por fuera de la clase:

const numbers = [1, 2, 3, 4, 5];

console.log(numbers.length); // 5

// Definir la longitud
numbers.length = 3;

console.log(numbers); // [1, 2, 3]
console.log(numbers.length); // 3
console.log(numbers[3]); // undefined (los elementos extra se eliminan)

Si te fijas, no usamos los métodos push y pop del array nativo de JavaScript. Solo lo usamos como almacenamiento indexado. Todo el control lo lleva nuestra variable count.

Complejidad Big O de las operaciones

Ya vimos qué hace cada operación. Ahora, ¿cuánto cuestan? Aquí es donde entra Big O, la notación que nos dice cómo crece el tiempo de una operación conforme crece el stack.

Operación	Complejidad en tiempo	Complejidad en espacio
`push()`	O(1)*	O(1)
`pop()`	O(1)	O(1)
`peek()`	O(1)	O(1)
`size()`	O(1)	O(1)
`isEmpty()`	O(1)	O(1)

* Amortizado. Ocasionalmente O(n) cuando el array dinámico necesita crecer por debajo.

Compara esto con un array, donde insertar al inicio es O(n) porque hay que mover todos los elementos. En un stack no tenemos ese problema porque solo tocamos la punta.

¿Dónde se usan los stacks en la vida real?

Antes de ver ejemplos, quédate con esto:

Regla de oro: cuando lo único que te importa es el último elemento, un stack es la respuesta.

Todo lo que viene a continuación es una variante del mismo patrón. Una vez que lo ves, empiezas a reconocer stacks en todos lados.

Navegador web: botón de "atrás"

Cada vez que visitas una página nueva, el navegador hace push() con la URL. Cuando presionas "atrás", hace pop() y te lleva a la página anterior.

Funciona perfecto porque siempre quieres volver a la última página que visitaste, no a una del medio.

Ctrl + Z: deshacer acciones

Mismo patrón: siempre deshaces la acción más reciente.

Call stack de tu programa

Por eso cuando ves un error con "stack trace" en la consola, estás viendo exactamente eso: el estado del stack de llamadas en el momento del error.

Validación de paréntesis balanceados

Cierre

Si te sirvió el artículo, dale ❤️ y sígueme para no perderte el siguiente. Nos leemos pronto. 🙌🏻

Why does AI lie? Hallucinations explained simply

Rohini Gaonkar — Fri, 08 May 2026 16:37:02 +0000

In the previous post, I showed you an AI doing something genuinely useful, helping me adapt a recipe for a dinner party. We talked about the basic loop: send a prompt to a foundation model, get a response.

Today we're talking about why AI lies to you.

You know how AI sounds confident when it's completely wrong? It's called hallucination, and it's the thing that'll either make you trust AI long-term, or burn you badly.

The demo: same question, two models

I asked two different models the same question in Amazon Bedrock Playground:

"What happened at the recent Lyrids meteor shower?"

Model 1: Amazon Nova Micro 1.0

Nova Micro gave me details. Dates, locations, numbers, all delivered with complete confidence. It didn't hesitate. It didn't caveat. It just answered as if it knew.

But it doesn't know. Its training data ends in 2023. Anything after that is a gap it can't see. It didn't flag that. It just filled the gap with something plausible.

This is hallucination. The model invents something plausible to fill a gap it doesn't know how to admit. It's not lying on purpose. It's doing exactly what it's designed to do: predict what a useful-sounding answer looks like. It has no idea whether the answer is actually true.

Model 2: Claude Haiku 4.5

Same question, newer model, much more recent training.

Haiku told me straight: "I don't have access to current information. My knowledge was last updated in April 2024." Then it offered general facts about the Lyrids and suggested I check recent astronomy websites.

Progress. Newer models are better at recognising the edges of what they know.

I gave it a link to a Space.com article. It told me it can't browse the internet.

So I uploaded the PDF of that website article. There are limits to how big the file size can be so I provided it first few pages only. Then it answered accurately, pulling real details from the source.

So, in this case, we provided some context to the model and it gave me an answer based on that context.

The biography test

I asked Nova Micro:

"Tell me about Rohini Gaonkar."

It didn't hesitate. It told me I'm a "well-known Indian writer, scholar, and cultural critic." That I got my PhD in Comparative Literature from Duke. That I'm a professor at the University of Minnesota. That I've edited influential anthologies on postcolonial theory.

None of this is true. Not one detail.

The model doesn't know who I am. But it knows what an academic biography looks like. So it generated one. Complete with research interests, notable works, and recognition. All fabricated. All confident.

So Haiku knew when to stop. Nova Micro didn't.

But the underlying mechanism is the same in both models: prediction.

One has better guardrails. The other just fills every gap it finds.

Hallucination isn't just about training cutoffs. It's about the model filling gaps anywhere in what it knows. Names it hasn't seen. Niche topics. Combinations it was never taught. Better guardrails help. They don't make the problem disappear.

A note on the name test: I used my own name on purpose. If the model invents something weird about me, the only person affected is me. Be thoughtful if you try this with other people's names, especially private ones, or anyone who hasn't agreed to be part of your experiment. Whatever the model says about them, you've just generated and potentially broadcasted it. So, be cautious.

Why this happens: the architecture

Remember the loop from the last post:

Input (prompt) → Foundation Model → Output (response)

The model predicts what a useful answer looks like, based on everything it learned during training.

During training is the key phrase.

Training ends on a specific date, called the training cutoff. After that, the model is frozen. When you ask it about anything past that date, or anything it never quite learned, it has two options: say "I don't know", or do the thing it's designed to do i.e. predict.

And for a long time, these models weren't great at saying "I don't know". That's not what they were rewarded for in training. They were rewarded for producing fluent, useful-sounding answers. So that's what they produce. Even when the answer is made up.

Hallucination shows up in different flavors: fabricated facts (the biography), outdated information stated as current (the meteor shower), inconsistent reproduction even with the source right there (the quote test). There are others too, wrong attributions, sycophantic agreement (going along with something you said even when it's wrong), confident extrapolation (extending a pattern beyond where the data supports it).

The mechanism is always the same, prediction filling a gap, but knowing the flavor helps you design the right mitigation. We'll get into those mitigations in later posts when we talk about grounding, evaluation, and guardrails.

If you're a builder, this'll feel familiar. Think of a DNS cache. You move your app to a new server, update the DNS record, but for the next hour some users still get routed to the old IP. The cache doesn't know the record changed. It just serves what it has, confidently, because it was designed to always give you an answer fast.

Or autoscaling on the wrong metric. You scale on CPU. CPU is low, so the system thinks everything's fine. Meanwhile your queue is backed up with 10,000 unprocessed messages. The system is optimized to respond to one signal, so it confidently does nothing while things pile up.

An AI model works the same way. It was trained to always produce a helpful-sounding answer. So when it doesn't know something, it still produces a helpful-sounding answer. It doesn't have a "say nothing" instinct. It has a "say something useful-looking" instinct.

Modern models are much better at refusing. But the underlying shape of the problem doesn't go away. The model doesn't know what it knows. It just predicts.

"But ChatGPT can search the web?"

Yes, most chat tools today can look things up online. That's not the model itself doing the searching. It is a tool plugged into the model.

We'll get to how that works in a later post. For today, we're looking at the model on its own. No internet, no tools. Just what it learned.

The fix, and where the fix breaks

I gave Nova Lite the actual article as a PDF and asked it to quote the second paragraph.

It gave me a response. Then I asked the same thing again. Different answer. Same source, same conversation, two different versions of the same paragraph.

Even with the source right there, it didn't pull the paragraph verbatim. I asked the same question twice, same conversation, same document, and got two different versions. It's not retrieving. It's still predicting what that paragraph probably looks like. And prediction isn't deterministic.

This matters because a lot of people think "just give the AI the document and it'll be fine."

It's better but it's not perfect. Things can get complex and messy, especially for anything that depends on exact wording, like legal text, medical dosages, or contract clauses. You still need to verify the responses.

Context reduces hallucination. It doesn't eliminate it.

Three signs you should double-check

If you're using AI day-to-day, here are the tells:

1. Specific details you can't verify. Names, dates, numbers, URLs in an area you can't check. Assume 50/50.

2. Fluency on topics that should be fuzzy. Ask about something niche or recent, get a confident detailed answer, and be suspicious. Real expertise has hedges, hallucination doesn't.

3. Citations. Especially URLs. Models invent sources that look real. If you get a URL, open it. Nine times out of ten it's fine. The tenth time it's a made-up paper.

Try it yourself

If you're more on the builder side:
Remember, hallucinations aren't a bug you patch. They're a property of the system. You mitigate them with grounding (give the model real context), with instructions (tell the model to refuse when unsure), and later, with evaluation. Designing around them is the job.

If you're just getting started:
Remember, AI is NOT a search engine. It's a prediction engine that's really good at sounding right. Treat specific claims the way you'd treat a confident stranger at a party. Friendly, but verify before you repeat them.

Some examples I found on internet, for fun and educational purposes only: (Answers may change as models are catching up)

How many 'r's are in the word strawberry?
If I have to take my car to car wash, and the car wash is 100ft away. Should I drive or go walking?

What's next

Why are there so many of these things? Haiku, Sonnet, Opus. Mini, large, pro. And honestly, which one should you actually pick?

That's the next post. Ride along.

This post is part of the "Learning AI Out Loud" series, a cloud architect learning AI from first principles.

Follow along with the series

I Built My Mom an AI Recipe Helper for Mother's Day

Ifeanyi O. — Fri, 08 May 2026 07:53:25 +0000

A project about a fridge, Strands agents & trying to keep up with Mom's seasons.

My Mom's Problem

My mom has a drawer full of recipes. Yes! Not a folder.... an actual drawer. Torn pages from magazines, things written on the back of envelopes and binders that've been around longer than I have. Whenever she's looking for dinner ideas she pulls something out, sighs and puts it back.

The recipe is not the issue here, that's always fine. It's that she's missing one ingredient or four!

And even if she has everything, the recipe might not fit whatever season she's in at the moment because the other thing is, her eating is a moving target.

One month she's a vegetarian because a friend got her into it, a few months later she's watching her sugar because the doctor mentioned it during a checkup, then it's low sodium or she's "just trying to be a little better with dinners." You just never really know which version is going to be at the stove on a given Tuesday.
But the real question she's always asking, underneath the recipe hunt, is...

What could I make with what I already have, that fits how I'm eating right now, that I won't get bored with?

Now that sounds like problem for an agent! So for Mother's Day this year, I built her one and called it AskMom Recipes. You can try it out here.

What it does in 30 seconds

You open a pink website and tell it what's in your kitchen. You can type it, or you can just take a photo of your groceries on the counter and drop it in.

You also have the option to pick how you're eating this week, for eg. no restriction, vegetarian, low sodium, diabetic-friendly or gluten-free. Then hit the "Suggest recipes" button.
A couple seconds later, you'll get three recipes and each one tells you:

What you already have vs. what you'd need to grab
Simple, unfussy steps (the kind of thing my mom actually cooks)
Why it's good for you, with real nutrition numbers from the USDA
One sentence about where the dish possibly comes from

If you don't love the recipes, you can tap "make it healthier" or "something quicker" or "fewer ingredients" and it adjusts on the fly.

That's it! The rest of this blog is how I built it and the design decisions that made the difference between "okay, cool demo that kinda works" and "something my mom would actually use."

Why an agent and not a prompt

An easy version of this would just be to throw the ingredients into a single prompt, ask for three recipes, done. I tried it, it's fine but there's problems that show up the moment you try to use it for real.
First, the model will happily make up nutrition numbers. Ask it how much protein is in chicken and it'll give you a number, confidently and you'll have no idea if it's right.

Second, it'll cheerfully tell you that tomatoes come from Italy or that pasta is a Chinese invention. Third, if you want to say "actually, make that healthier" the prompt has to start over from scratch because there's no memory.

An agent solves two of those three. As for the made up facts we needed something else which we'll get.

I used Strands Agents, which is a refreshingly simple Python SDK for building agents on Amazon Bedrock. You define your tools as functions, write a system prompt and Strands handles the loop of "model decides what tool to call, tool runs, result goes back to model, repeat."

It's the first agent framework I've used that didn't make me want to throw my laptop.

def build_agent(model_id: Optional[str] = None) -> Agent:

    model_id = model_id or os.environ.get(
        "BEDROCK_MODEL_ID", "anthropic.claude-3-haiku-20240307-v1:0"
    )
    region = os.environ.get("AWS_REGION", "us-east-1")

    model = BedrockModel(
        model_id=model_id,
        region_name=region,
        temperature=0.4,
    )

    return Agent(
        model=model,
        system_prompt=SYSTEM_PROMPT,
        tools=[
            extract_ingredients_from_image,
            extract_ingredients_from_text,
            suggest_recipes,
        ],
    )

With Strands, setting up the agent is almost anticlimactic. There's a model, a prompt and a list of tools. That's the whole thing.

I wanted to flag this, because it took me a few iterations to get right, the tools I gave the agent are not "one tool for everything." They're small, single-purpose and named like verbs.

The tools and why there aren't very many

Everyone always goes tool crazy, when they first build an agent. Each tool feels free so why not just add them all, right? Wrong!

The problem is every tool call is another round trip through the model. The model says "I'd like to call X," you run X, hand the result back, it thinks for a second and says "now I'd like to call Y." Each hop is a few seconds but when you add six tool calls, then your recipe helper takes forty seconds and your API times out.

So I decided to split the work in two:

Things the agent handles (because they genuinely need a model's judgment):

Reading a photo and identifying what's in it
Normalizing messy text like "some chicken, rice, maybe garlic" into a clean list
Generating three healthy recipes that fit the user's preferences

Things Python handles (because they just need a lookup):

Looking up real nutrition numbers
Formatting a recipe card for the frontend

Since Python can fetch faster than the model can ask, why would I let a language model guess when there's a real source? USDA has an API with the actual nutrition numbers.

This one design decision cut request latency from ~34 seconds to ~17 seconds. You get the same quality in half the time with way less money spent on Bedrock tokens and it made the agent more reliable with fewer retries and self corrections that eat tokens for no reason.

The lesson is to use the LLM for the things that need reasoning and use code for the things that need answers.

Preference handling

Alright, back to my mom for a second. The seasons thing, vegetarian one month and low sodium the next taught me more about preference handling that I didn't expect.

The naive approach is a freeform text field that ask you to type your dietary preferences. The problem is the model has to figure out what "watching my sugar a bit" means versus "diabetic-friendly" versus "low-carb." Sometimes it guesses wrong and sometimes the recipes it produces have way too much added.

So I made it a dropdown. Five options:

No restriction
Vegetarian
Low sodium
Diabetic-friendly
Gluten-free

Each one maps to a crisp, one sentence guidance block that gets injected into the recipe prompt:

_PREFERENCE_GUIDANCE = {
    "none": "No dietary restrictions. Focus on healthy, balanced meals.",
    "vegetarian": "Strictly vegetarian: no meat, poultry, or fish.",
    "low_sodium": "Low sodium: minimize salt and high-sodium ingredients like soy sauce or canned broths.",
    "diabetic_friendly": "Diabetic-friendly: low glycemic index, limit added sugars and refined carbs.",
    "gluten_free": "Strictly gluten-free: no wheat, barley, rye, or standard soy sauce.",
}

It's five lines of Python.

A dropdown sounds less impressive than "the AI understands your preferences," but the dropdown is more reliable and trust me, reliable is what my mom needs.

When it comes to agent patterns, the more you can constrain the inputs, the better the outputs. Freeform is cool in demos but more structure is better in real life.

The "send a photo of your groceries" part

I wanted to keep the typed-ingredients path simple, but the photo path is where it gets fun. You take a picture of whatever's on your counter and the agent reads the photo, identifies the food and treats it the same as if you'd typed it in.

Under the hood this is one of Strands' best party tricks. Claude 3 Haiku on Bedrock handles vision natively, so the whole thing is one tool call:

@tool
def extract_ingredients_from_image(s3_key: str) -> List[str]:
    """Look at a photo of groceries and return the ingredients visible in it."""
    bucket = os.environ["UPLOADS_BUCKET_NAME"]
    region = os.environ.get("AWS_REGION", "us-east-1")

    # 1. Fetch image bytes from S3
    s3 = boto3.client("s3", region_name=region)
    obj = s3.get_object(Bucket=bucket, Key=s3_key)
    image_bytes = obj["Body"].read()
    media_type = obj.get("ContentType", "image/jpeg")

    # 2. Ask Bedrock Claude Haiku what's in the photo
    prompt = (
        "List only the food ingredients you can clearly see in this photo. "
        "Return a JSON array of short lowercase names, nothing else. "
        'Example: ["tomato", "onion", "chicken breast"]. '
        "If you can't identify any food, return []."
    )
    bedrock = boto3.client("bedrock-runtime", region_name=region)
    response = bedrock.invoke_model(
        modelId=os.environ["BEDROCK_MODEL_ID"],
        body=json.dumps({
            "anthropic_version": "bedrock-2023-05-31",
            "max_tokens": 400,
            "messages": [{
                "role": "user",
                "content": [
                    {"type": "image", "source": {
                        "type": "base64",
                        "media_type": media_type,
                        "data": base64.standard_b64encode(image_bytes).decode(),
                    }},
                    {"type": "text", "text": prompt},
                ],
            }],
        }),
    )

    # 3. Pull the JSON array back out (defensively)
    text = json.loads(response["body"].read())["content"][0]["text"]
    match = re.search(r"\[.*?\]", text, re.DOTALL)
    if not match:
        return []
    try:
        items = json.loads(match.group(0))
    except json.JSONDecodeError:
        return []
    return [str(x).strip().lower() for x in items if str(x).strip()]

The prompt is boring on purpose. All is says is "List only the food ingredients you can clearly see in this photo. Return a JSON array of short lowercase names, nothing else." I did not give it a personality or tell it to "please think carefully". I also didn't give it examples of how the model should "reason." I just told it what I want and what format I want it in.

The model is very good at ambitious prompts and very good at literal ones. Ambitious prompts return ambitious, chatty and often wrong answers but literal prompts more closely return what you asked for. For this tool, where the output feeds directly into the next step, literal wins every time.

Also, note that the photo gets uploaded straight from the browser to S3 via a pre-signed URL, so my Lambda never has to deal with multipart file uploads. The agent just gets an S3 key and fetches it.

The Architecture

Here's the whole thing, in the order a request flows:

Browser loads static pink site from S3, served through CloudFront.
User submits text and/or photo. If photo, goes straight to S3 as pre-signed URL.
Browser calls POST /ingredients on API Gateway, which hits a Lambda.
Lambda builds a Strands agent with three tools, runs the agent loop.
Agent extracts ingredients (text + vision), then calls suggest_recipes once.
Lambda enriches each recipe in Python, origin lookup, USDA lookup and format.
Session is saved to DynamoDB with a 24-hour TTL for the "refine" follow up.
Recipes come back to the browser.

The whole thing is deployed with AWS CDK in Python, one stack, one make deploy. No Docker needed, no hand-wiring and definitely no clicking around in the console.

What it costs me to keep it running

For my mom's personal deployment, answering a few requests a week:

Bedrock: Tenth of a penny per recipe request.
Lambda: Free.
DynamoDB: Free.
S3 + CloudFront: Couple cents a month for the static site.
USDA API: Free.

I pay less for AskMom per month than for a single coffee. If I published it and a hundred people used it regularly, I'd still be under a few dollars a month!

Try it yourself

If you want to build one for your mom (or your dad, or anyone whose fridge is a mystery), the whole thing is open source.

Repo: github.com/rextheking/askmom-recipes-sample-for-aws-strands

The README walks through the deploy in six steps. You need:

An AWS account with Bedrock access enabled for Claude 3 Haiku in us-east-1
Python 3.12, Node 20/22/24, AWS CDK CLI and the AWS CLI
A free USDA FoodData Central API key (takes 30 seconds to get)

Then it's:

cd infra
make install
make bootstrap     # one time per AWS account
make deploy        # ~5-7 minutes, most of it CloudFront
# paste the ApiUrl into web/config.js
cd ../web
make deploy
# open the CloudFront URL

Note, the first deploy takes a few minutes because CloudFront is slow to propagate. If you're just kicking the tires, there's a -c with_cloudfront=false flag that skips CloudFront and gets you a working API in about 90 seconds.

The Hug

If you build something for your mom this year, I'd love to see it. Tag me or share the repo of whatever weird thing you shipped.

Happy Mother's Day 💖

Credits

Strands Agents for making agent code actually pleasant to write
Amazon Bedrock + Claude 3 Haiku for the model
USDA FoodData Central for free, honest nutrition data
My mom, for the original problem

Build your own daily notification bot on AWS Free Tier

Esin Saribudak — Fri, 08 May 2026 02:04:13 +0000

A Lambda function checks the forecast, Bedrock tells you what to wear, and ntfy.sh pushes it to your phone before you get ready for the day, and it's all Free Tier eligible.

Last updated: May 7, 2026

Every morning before work, you open your weather app. It takes a few seconds to refresh. Then you scroll past the hourly breakdown, the radar map, the air quality index, the pollen count. All you need to know is: what's the high, what's the low, is it going to rain, and what should you wear?

If you're leaving your home for the office every day like I am, this time spent scrolling and thinking every morning adds up. Especially where I live, where it might be 55°F when I leave the house and 88°F by lunch. You need a jacket at 7 AM and regret wearing it by noon. The weather app gives you all the data but none of the interpretation.

This tutorial walks you through building a service that sends you a push notification every morning with the forecast and a clothing recommendation. You deploy it once, and it runs on a schedule. Instead of opening an app and parsing data yourself, the notification just shows up with what you need. It looks like this on your phone:

Austin, TX — Tuesday, May 6
Today: 88°F, Partly Sunny
Tonight: 73°F, Mostly Cloudy
Wind: 10 mph S | Rain: 20%

Light layers today. Short sleeves with a light
jacket for the morning, ditch it by lunch.
No umbrella needed.

Along the way, you'll wire together EventBridge, Lambda, and Bedrock into an app that streamlines a daily task. By the end, you'll have a working notification on your phone and hands-on experience with the same infrastructure that powers production applications. All the AWS services it uses are eligible for the AWS Free Tier.

If you followed the blog post view counter tutorial, this is a good next project. Same tools, different services, and you end up with something you'll use every day. If you haven't built that one, that's fine too — the prerequisites section covers what you need.

What you're building

Here's the application flow:

EventBridge triggers a Lambda function every morning on a cron schedule
Lambda calls the National Weather Service API with your coordinates to get the local forecast
Lambda sends that weather data to Amazon Bedrock (Nova Lite) and asks for a clothing recommendation
Lambda formats the forecast + recommendation into a short message
Lambda sends the message as a push notification to your phone via ntfy.sh, an open source pub/sub service

Three AWS services, two free external APIs, about 230 lines of TypeScript.

Outside the US? The NWS API only covers US locations. If you're elsewhere, swap in Open-Meteo as a drop-in replacement. It's free for non-commercial use, requires no API key, and covers the entire world.

Prerequisites

An AWS account. If you don't have one yet, the Creating an AWS account guide walks you through it. You'll need a credit card on file, but this project stays within Free Tier limits.
Node.js 24 or later
AWS CLI installed and configured
AWS CDK bootstrapped in your account. If you haven't used CDK before, it's an infrastructure-as-code tool. You write TypeScript that describes your AWS resources, and CDK turns it into CloudFormation and deploys it. The bootstrap command creates a staging bucket CDK needs to upload your code, and needs to be run the first time you use it.

npx cdk bootstrap aws://YOUR_ACCOUNT_ID/us-east-1

ntfy app installed on your phone. Download ntfy from the App Store or Google Play. Open it and add a topic name you'll remember (this acts as your private channel, so pick something not easily guessable, like weather-forecast-abc123).

What is ntfy.sh and why use it for notifications

ntfy.sh (pronounced "notify") is an open-source push notification service built on a simple pub/sub model. You subscribe to a topic in the app, and any HTTP POST to that topic's URL shows up as a push notification on your phone. No account required, no API key, no app store approval process.

Project setup

Create a new directory and initialize the project:

mkdir daily-notification-bot && cd daily-notification-bot
npm init -y
npm install aws-cdk-lib constructs @aws-sdk/client-bedrock-runtime
npm install -D aws-cdk tsx typescript @types/node

Create a cdk.json file in the project root:

{
  "app": "npx tsx cdk/app.ts"
}

And a tsconfig.json:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "lib": ["ES2022"],
    "outDir": "dist",
    "rootDir": ".",
    "strict": true,
    "types": ["node"],
    "esModuleInterop": true,
    "skipLibCheck": true,
    "declaration": true
  },
  "include": ["lambda/**/*", "cdk/**/*"]
}

Your project structure:

daily-notification-bot/
├── cdk/
│   ├── app.ts          # CDK entry point
│   └── stack.ts        # Infrastructure definition
├── lambda/
│   └── index.ts        # Lambda function code
├── cdk.json
├── package.json
└── tsconfig.json

Step 1: Define the infrastructure with CDK

Create cdk/stack.ts. This defines all the infrastructure:

import * as cdk from 'aws-cdk-lib';
import * as events from 'aws-cdk-lib/aws-events';
import * as targets from 'aws-cdk-lib/aws-events-targets';
import * as iam from 'aws-cdk-lib/aws-iam';
import { NodejsFunction } from 'aws-cdk-lib/aws-lambda-nodejs';
import { Runtime } from 'aws-cdk-lib/aws-lambda';
import * as path from 'path';
import { fileURLToPath } from 'url';
import { Construct } from 'constructs';

const __dirname = path.dirname(fileURLToPath(import.meta.url));

export class MorningForecastStack extends cdk.Stack {
  constructor(scope: Construct, id: string) {
    super(scope, id);

    // Configuration — pass these at deploy time:
    //   npx cdk deploy -c latitude=30.27 -c longitude=-97.74 -c ntfyTopic=my-secret-weather-topic
    const latitude = this.node.tryGetContext('latitude');
    const longitude = this.node.tryGetContext('longitude');
    const ntfyTopic = this.node.tryGetContext('ntfyTopic');

    if (!latitude || !longitude || !ntfyTopic) {
      throw new Error(
        'Missing required context. Deploy with: npx cdk deploy ' +
        '-c latitude=30.27 -c longitude=-97.74 -c ntfyTopic=my-secret-weather-topic'
      );
    }

    // Lambda function — fetches weather, calls Bedrock, sends notification via ntfy
    const fn = new NodejsFunction(this, 'ForecastFunction', {
      runtime: Runtime.NODEJS_24_X,
      entry: path.join(__dirname, '../lambda/index.ts'),
      handler: 'handler',
      environment: {
        LATITUDE: latitude,
        LONGITUDE: longitude,
        NTFY_TOPIC: ntfyTopic,
      },
      timeout: cdk.Duration.seconds(30),
      memorySize: 256,
    });

    // Grant Lambda permission to invoke Bedrock
    fn.addToRolePolicy(new iam.PolicyStatement({
      actions: ['bedrock:InvokeModel'],
      resources: ['arn:aws:bedrock:*::foundation-model/amazon.nova-lite-v1:0'],
    }));

    // EventBridge rule — triggers every morning at 6:30 AM CT (11:30 UTC)
    // Adjust the cron to match your timezone and preferred time
    new events.Rule(this, 'MorningSchedule', {
      schedule: events.Schedule.cron({
        minute: '30',
        hour: '11',    // 11:30 UTC = 6:30 AM CT
        weekDay: 'MON-FRI',
      }),
      targets: [new targets.LambdaFunction(fn)],
    });

    // Output the function name for manual testing
    new cdk.CfnOutput(this, 'FunctionName', {
      value: fn.functionName,
      description: 'Lambda function name (for manual invocation)',
    });
  }
}

How to schedule a Lambda function with EventBridge

The EventBridge rule above is what makes this run every morning. A few things to notice:

Configuration via context. Your coordinates and ntfy topic are passed at deploy time with -c flags. This keeps configuration out of your source code and makes the project easy to share. To find your coordinates, right-click any location in Google Maps and the lat/long will appear at the top of the context menu.
Notifications go through ntfy.sh, which is just an HTTP POST from Lambda. There are no AWS messaging services to configure, no phone number verification steps, and no sandbox restrictions to deal with.
Weekdays only. The cron schedule runs Monday through Friday. If you want weekends too, change weekDay: 'MON-FRI' to remove that constraint, or set it to '*'.
UTC time. EventBridge cron expressions use UTC. Central Time is UTC-5 (or UTC-6 during standard time), so 6:30 AM CT is 11:30 UTC during CDT. You'll need to adjust this for your timezone.
30-second timeout. The Lambda makes three external calls (NWS points, NWS forecast, and Bedrock), so we give it more time than the default 3 seconds. In practice it finishes in 2-4 seconds.

Now create the entry point at cdk/app.ts:

#!/usr/bin/env node
import * as cdk from 'aws-cdk-lib';
import { MorningForecastStack } from './stack.js';

const app = new cdk.App();
new MorningForecastStack(app, 'MorningForecastNotificationApp');

Step 2: Fetch the forecast and generate a notification

Create lambda/index.ts. This is the code that runs every morning:

import { BedrockRuntimeClient, InvokeModelCommand } from '@aws-sdk/client-bedrock-runtime';

const bedrock = new BedrockRuntimeClient({});

const LATITUDE = process.env.LATITUDE!;
const LONGITUDE = process.env.LONGITUDE!;
const NTFY_TOPIC = process.env.NTFY_TOPIC!;

const NWS_USER_AGENT = 'daily-notification-bot (github.com/your-repo)';

// Type definitions
interface NwsPoint {
  forecastUrl: string;
  city: string;
  state: string;
}

interface ForecastPeriod {
  name: string;
  temperature: number;
  temperatureUnit: string;
  windSpeed: string;
  windDirection: string;
  shortForecast: string;
  probabilityOfPrecipitation: number;
  isDaytime: boolean;
}

interface WeatherData {
  city: string;
  state: string;
  daytime: ForecastPeriod;
  nighttime: ForecastPeriod;
}

// Step 1: Get the NWS grid point for our coordinates
async function getNwsPoint(): Promise<NwsPoint> {
  const url = `https://api.weather.gov/points/${LATITUDE},${LONGITUDE}`;
  const response = await fetch(url, {
    headers: { 'User-Agent': NWS_USER_AGENT },
  });

  if (!response.ok) {
    throw new Error(`NWS points API error: ${response.status}`);
  }

  const data: any = await response.json();
  return {
    forecastUrl: data.properties.forecast,
    city: data.properties.relativeLocation.properties.city,
    state: data.properties.relativeLocation.properties.state,
  };
}

// Step 2: Get the forecast from the NWS grid point
async function getForecast(point: NwsPoint): Promise<WeatherData> {
  const response = await fetch(point.forecastUrl, {
    headers: { 'User-Agent': NWS_USER_AGENT },
  });

  if (!response.ok) {
    throw new Error(`NWS forecast API error: ${response.status}`);
  }

  const data: any = await response.json();
  const periods = data.properties.periods;

  const daytime = periods.find((p: any) => p.isDaytime);
  const nighttime = periods.find((p: any) => !p.isDaytime);

  const toPeriod = (p: any): ForecastPeriod => ({
    name: p.name,
    temperature: p.temperature,
    temperatureUnit: p.temperatureUnit,
    windSpeed: p.windSpeed,
    windDirection: p.windDirection,
    shortForecast: p.shortForecast,
    probabilityOfPrecipitation: p.probabilityOfPrecipitation?.value ?? 0,
    isDaytime: p.isDaytime,
  });

  return {
    city: point.city,
    state: point.state,
    daytime: toPeriod(daytime),
    nighttime: toPeriod(nighttime),
  };
}

// Step 3: Ask Bedrock for a clothing recommendation
async function getClothingAdvice(weather: WeatherData): Promise<string> {
  const prompt = `Today's forecast for ${weather.city}, ${weather.state}:
- Daytime (${weather.daytime.name}): ${weather.daytime.temperature}°${weather.daytime.temperatureUnit}, ${weather.daytime.shortForecast}
- Wind: ${weather.daytime.windSpeed} ${weather.daytime.windDirection}
- Rain chance: ${weather.daytime.probabilityOfPrecipitation}%
- Tonight: ${weather.nighttime.temperature}°${weather.nighttime.temperatureUnit}, ${weather.nighttime.shortForecast}

What should I wear today? Give me a practical recommendation in one to two sentences. Be direct and specific. No preamble.`;

  const body = JSON.stringify({
    messages: [
      {
        role: 'user',
        content: [{ text: prompt }],
      },
    ],
    inferenceConfig: {
      maxTokens: 80,
    },
  });

  const command = new InvokeModelCommand({
    modelId: 'amazon.nova-lite-v1:0',
    contentType: 'application/json',
    accept: 'application/json',
    body: new TextEncoder().encode(body),
  });

  const response = await bedrock.send(command);
  const result = JSON.parse(new TextDecoder().decode(response.body));
  return result.output.message.content[0].text;
}

// Step 4: Format the notification message
function formatMessage(weather: WeatherData, advice: string): string {
  const today = new Date().toLocaleDateString('en-US', {
    weekday: 'long',
    month: 'short',
    day: 'numeric',
    timeZone: 'America/Chicago', // Adjust to your timezone
  });

  return [
    `${weather.city}, ${weather.state} — ${today}`,
    `${weather.daytime.name}: ${weather.daytime.temperature}°${weather.daytime.temperatureUnit}, ${weather.daytime.shortForecast}`,
    `Tonight: ${weather.nighttime.temperature}°${weather.nighttime.temperatureUnit}, ${weather.nighttime.shortForecast}`,
    `Wind: ${weather.daytime.windSpeed} ${weather.daytime.windDirection} | Rain: ${weather.daytime.probabilityOfPrecipitation}%`,
    '',
    advice,
  ].join('\n');
}

// Step 5: Send push notification via ntfy.sh
async function sendNotification(message: string): Promise<void> {
  const response = await fetch(`https://ntfy.sh/${NTFY_TOPIC}`, {
    method: 'POST',
    headers: {
      'Title': 'Morning Forecast',
    },
    body: message,
  });

  if (!response.ok) {
    throw new Error(`ntfy.sh error: ${response.status}`);
  }
}

// Main handler — EventBridge triggers this every morning
export const handler = async (): Promise<void> => {
  const point = await getNwsPoint();
  const weather = await getForecast(point);
  const advice = await getClothingAdvice(weather);
  const message = formatMessage(weather, advice);

  await sendNotification(message);

  console.log('Forecast sent:', message);
};

The function does four things in sequence:

Calling the NWS weather API from Lambda

The NWS API works in two steps. First you send your coordinates to /points/{lat},{lon}, which returns metadata about your location including the forecast URL and your city/state name. The NWS requires a User-Agent header for identification, but no API key.

The second call hits the forecast URL from step one. It returns forecast periods (today, tonight, tomorrow, etc.) with temperature, wind, precipitation probability, and a plain-English summary like "Partly Cloudy" or "Chance Showers."

Using Bedrock to generate clothing advice

We send the weather data to Amazon Nova Lite with a prompt that asks for practical clothing advice. The maxTokens: 80 keeps the response tight — one to two sentences, no filler. Nova Lite is Amazon's cheapest model and responds in under a second.

Sending push notifications with ntfy.sh

The city name, forecast summary, and clothing advice get combined into a notification message and sent to ntfy.sh with a single HTTP POST. The ntfy app on your phone picks it up instantly.

Step 3: Deploy and test your notification

Deploy with your coordinates and ntfy topic:

npx cdk deploy \
  -c latitude=YOUR_LATITUDE \
  -c longitude=YOUR_LONGITUDE \
  -c ntfyTopic=YOUR_NTFY_TOPIC

Replace the values with your own:

Latitude and longitude of your location. Right-click any spot in Google Maps and the coordinates appear at the top of the menu. For example, Austin, TX is 30.27,-97.74.
ntfy topic — the same topic name you subscribed to in the ntfy app. This is like a private channel, so pick something not easily guessable.

CDK will show you the resources it's creating and ask for confirmation. Type y.

CDK asks because the stack creates IAM permissions (Lambda's execution role, Bedrock invoke access). This is standard for any stack that includes a Lambda function. Review the permissions if you want, then approve.

After about two minutes, you'll see output like this:

✅  MorningForecastNotificationApp

✨  Deployment time: 107.44s

Outputs:
MorningForecastNotificationApp.FunctionName = MorningForecastNotificationApp-ForecastFunctionBE622553-a1B2c3D4e5Fg

Stack ARN:
arn:aws:cloudformation:us-east-1:123456789012:stack/MorningForecastNotificationApp/67f1ff60-1234-5678-abcd-0affd8af3937

✨  Total time: 110s

Don't wait until tomorrow morning to test it. Invoke the function manually using the function name from the deploy output:

aws lambda invoke \
  --function-name MorningForecastNotificationApp-ForecastFunctionBE622553-a1B2c3D4e5Fg \
  --payload '{}' \
  output.json

Check your phone. You should have a push notification from the ntfy app with today's forecast and a clothing recommendation. 😎

Step 4: Customize the schedule, location, and AI prompt

Change your location

Update the coordinates in your deploy command. Right-click any location in Google Maps to get the
lat/long:

npx cdk deploy \
  -c latitude=YOUR_LATITUDE \
  -c longitude=YOUR_LONGITUDE \
  -c ntfyTopic=YOUR_NTFY_TOPIC

How to change the EventBridge cron schedule

The cron expression in stack.ts controls when you get your notification. A few examples:

// Every day at 7:00 AM ET (12:00 UTC during EDT)
schedule: events.Schedule.cron({ minute: '0', hour: '12' })

// Weekdays at 6:00 AM CT (11:00 UTC during CDT)
schedule: events.Schedule.cron({ minute: '0', hour: '11', weekDay: 'MON-FRI' })

// Every day at 6:30 AM PT (13:30 UTC during PDT)
schedule: events.Schedule.cron({ minute: '30', hour: '13' })

Remember: EventBridge uses UTC. Convert your local time accordingly.

Tweak the AI prompt

The Bedrock prompt in getClothingAdvice() is where you make this yours. The default asks for one to two direct sentences. Some ways to customize:

// If you bike to work:
"Assume I'm biking 3 miles to the office."

// If you run hot:
"I tend to run warm, so err on the side of lighter clothing."

// If you want outfit specifics:
"Suggest specific items: jacket type, shirt type, pants vs shorts, shoe type."

// If you want even less:
"Answer in one sentence only."

The prompt is just a string. Change it, redeploy, and your morning notification changes with it.

How the full flow works

Now that you've seen all the code, here's the complete flow, complete with approximate timestamps:

6:30 AM — EventBridge fires a scheduled event
6:30:01 — Lambda calls the NWS API with your coordinates, gets the forecast
6:30:02 — Lambda sends the weather data to Bedrock, gets back clothing advice
6:30:03 — Lambda formats the message and POSTs it to ntfy.sh
6:30:04 — Your phone buzzes with a push notification

Total execution time: 2-4 seconds. Total cost: covered by Free Tier.

How much this costs on AWS Free Tier

This project uses services eligible for the AWS Free Tier. Here's what each one costs:

Service	Free Tier allowance	Your usage
EventBridge	14M scheduled invocations/month	~30/month
Lambda	1M requests/month, 400K GB-seconds	~30 invocations/month
Bedrock (Nova Lite)	Free Tier credits	~$0.001/month
ntfy.sh	Free (open source)	~30 notifications/month
NWS API	Free (US government data)	~60 calls/month

EventBridge — 14 million scheduled invocations per month free. You're using around 30.

Lambda — You'll probably use around 30 invocations per month, each running for 2-4 seconds at 256 MB. That's well under the 1 million requests and 400,000 GB-seconds you get free.

Bedrock — Nova Lite costs fractions of a cent per invocation at this token volume. At 30 calls per month, it comes out of your Free Tier credits.

ntfy.sh — free, and doesn't require an account or API key for personal use.

NWS API — free US government public data, no key required.

I'd still recommend setting up a billing alarm at $5 as a safety net.

What you just learned

If you followed along, you now have hands-on experience with:

EventBridge: cron scheduling in UTC, weekday-only rules
Lambda: calling external APIs, environment variables, working with the Bedrock SDK
Bedrock: invoking a foundation model, prompt design, controlling output length
CDK: defining infrastructure in TypeScript, passing configuration via context, deploying with a single command
NWS API: the two-step points → forecast pattern for US weather data
ntfy.sh: push notifications via a simple HTTP POST

And you have something running that you'll actually use every morning.

A note on security

This project has a small attack surface. The Lambda has no public URL and can only be triggered by EventBridge within your account. There's no user input, no stored data, and the IAM permissions are scoped to a single Bedrock model.

The one thing to be aware of: your ntfy topic name is the only access control on your notifications. Anyone who knows the topic name can subscribe and read your messages. Since the content is just weather data, the risk is low, but pick a topic name that isn't easily guessable. If you want tighter control, ntfy supports token-based auth on their paid plan, or you can self-host.

Cleanup

If you want to tear everything down:

npx cdk destroy \
  -c latitude=YOUR_LATITUDE \
  -c longitude=YOUR_LONGITUDE \
  -c ntfyTopic=YOUR_NTFY_TOPIC

This deletes the Lambda, the EventBridge rule, and the IAM role. Your morning notifications will stop. Unsubscribe from the topic in the ntfy app if you want to clean that up too.

What to try next

Add a weekend mode with a later send time and more casual tone
Send a mid-day alert if rain probability spikes above 70%
Share the topic with your household so everyone gets the notification
Add a weekly summary on Sunday evenings for the week ahead
Swap the NWS API for Open-Meteo if you're outside the US (free for non-commercial use, covers the entire world)
Replace the weather API with something else you care about: stock prices, package tracking, your team's on-call schedule, a daily quote. The architecture will likely be similar regardless of what data you're fetching.

If you built the blog post view counter, you now have two working projects on AWS Free Tier: one that reacts to events (page views) and one that runs on a schedule (morning forecast). Between the two, you've used Lambda, DynamoDB, API Gateway, EventBridge, and Bedrock.

The source code for this project is on GitHub if you want to fork it and make it your own.

Embed These Websites In Your Blog Today

Sean Boult — Thu, 07 May 2026 18:34:41 +0000

I stumbled onto the DEV supported URL embeds list, which revealed some interesting supported platforms.

You'll want to refer to the link above to figure out the syntax for the DEV specific ones but most are just:

{% embed <url> %}

If you would like to jump around.

asciinema
StackBlitz
GitHub
X/Twitter
YouTube
DEV specific

asciinema

A video-like player which is so cool because you can actually pause it and copy the text from it.

StackBlitz

Interactive code editor right in a blog post 😍. Seems like the embedded terminal and preview will fail due to some postMessage shenanigans, but perhaps it can be fixed.

GitHub

It supports rendering the README to give some brief context with a CTA to open the repo.

strands-agents / sdk-typescript

A model-driven approach to building AI agents in just a few lines of code.

Strands Agents - TypeScript SDK

A model-driven approach to building AI agents in TypeScript/JavaScript

Documentation ◆ Samples ◆ Python SDK ◆ Tools ◆ Agent Builder ◆ MCP Server

Overview

Strands Agents is a simple yet powerful SDK that takes a model-driven approach to building and running AI agents. The TypeScript SDK brings key features from the Python Strands framework to Node.js environments, enabling type-safe agent development for everything from simple assistants to complex workflows.

Key Features

🪶 Lightweight & Flexible: Simple agent loop that works seamlessly in Node.js and browser environments
🔒 Type-Safe Tools: Define tools easily using Zod schemas for robust input validation and type inference
📋 Structured Output: Get type-safe, validated responses from LLMs using Zod schemas with automatic retry on validation errors
🔌 Model Agnostic: First-class support for Amazon Bedrock and OpenAI, with extensible architecture for custom providers
🔗 Built-in MCP: Native…

View on GitHub

X/Twitter

Useful when a tweet has some context you want to reference.

// Detect dark theme var iframe = document.getElementById('tweet-2052162536301072643-10'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2052162536301072643&theme=dark" }

YouTube

Video is king 👑. However, I'd probably reach for the "Cover Video Link" feature, where you can have the video be your banner instead of an image.

DEV specific

These are some of the custom things that DEV supports outside of third party site embeds.

Article Link:

Erik Hanchett for AWS

May 4

Stop Reaching for Python: Strands Agents TypeScript SDK Just Hit 1.0

#typescript #ai #aws #agents

Comments 1

8 min read

User Profile:

Brooke JamiesonFollow

🌥️ I’ll teach you tech tips in bite sized videos 📣 Keynote Speaker 👩🏻‍💻 AI/ML Specialist 💼 AWS Sr Developer Advocate (views are my own) 🇦🇺AU ➡️ NYC🗽

Tag Profile:

#aws Follow

Amazon Web Services (AWS) is a collection of web services for computing, storage, machine learning, security, and more There are over 200+ AWS services as of 2023.

Comment:

Comment on What Even Is AI? (I Took a Break & Had to Relearn Everything)

Jess Lee May 5

I just came back from maternity leave. And honestly? I felt like I'd missed a decade in six months.

I feel this so hard.

Looking forward to your series!

Podcast Episode:

120. Lambda Best Practices

AWS Bites

Your browser does not support the audio element.

1x initializing... ×

Organization:

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.

Well, this one is not a website, but it's useful when you want to add some CTA at the end of a blog.

Buttons:
View @AWSDevelopers on X/Twitter 💻
—
Visit AWS Builder Center

Let me know what your favorite embed is or if I'm missing any amazing ones in the comments.

Happy coding 👨‍💻!

¿Qué es un Agente de IA? Explicado para devs

Ramses Mata — Wed, 06 May 2026 20:51:06 +0000

Si has usado un chat de IA, ya interactuaste con un modelo. Le haces una pregunta, te responde, y ahí termina la historia. Pero, ¿qué pasa cuando necesitas que la IA no solo responda, sino que haga cosas? Que busque información, ejecute código, llame APIs, y tome decisiones sobre qué hacer a continuación. Ahí es donde entran los agentes de IA.

En mi artículo anterior exploramos qué es un modelo de IA, y descubrimos que es un programa que predice texto basándose en patrones. Hoy vamos a ver qué pasa cuando le das a ese modelo la capacidad de actuar en el mundo real.

1. ¿Qué es un agente de IA?

Un agente de IA es un sistema que usa un modelo de lenguaje como cerebro para razonar, tomar decisiones y ejecutar acciones de forma autónoma hasta completar una tarea.

El modelo genera texto, el agente hace cosas. Un modelo es como un cerebro en un frasco. Muy inteligente, puede razonar, analizar y generar ideas, pero no tiene manos, no tiene ojos, no puede interactuar con nada fuera de sí mismo. Un agente es ese mismo cerebro conectado a manos, ojos y memoria. Puede buscar información, ejecutar código, leer archivos, llamar APIs, y decidir qué hacer a continuación basándose en lo que observa.

2. Modelo vs Agente: ¿cuál es la diferencia?

Veamos un ejemplo concreto para que la diferencia quede clara.

Tú preguntas: "¿Qué clima hace en Ciudad de México?"

Un modelo:

Recibe tu pregunta
Genera texto basándose en sus datos de entrenamiento
Responde: "No tengo acceso a información en tiempo real, pero el clima en CDMX suele ser templado..."
Fin. No puede hacer más.

Un agente:

Recibe tu pregunta
Piensa: "Necesito datos del clima actual. Tengo una herramienta que consulta APIs de clima."
Actúa: Llama a la API del clima con la ubicación "Ciudad de México"
Observa: Recibe los datos: 22°C, soleado, humedad 45%
Responde: "Ahora mismo en Ciudad de México hay 22°C, está soleado con 45% de humedad."

El modelo está limitado a lo que sabe de su entrenamiento. El agente puede ir a buscar lo que no sabe.

	Modelo	Agente
Genera texto	Si	Si
Usa herramientas	No	Si
Toma decisiones	No	Si
Ejecuta acciones	No	Si
Recuerda contexto entre pasos	No	Si
Trabaja de forma autónoma	No	Si

3. ¿Qué NO es un agente?

Antes de seguir, limpiemos confusiones comunes:

Un chatbot con respuestas predefinidas no es un agente. Si solo sigue un árbol de decisiones fijo, no hay razonamiento ni autonomía.
Un modelo con un prompt muy largo no es un agente. Por más contexto que le des, si no puede ejecutar acciones ni tomar decisiones sobre qué hacer, sigue siendo solo un modelo.
Una automatización con if/else no es un agente. Si el flujo está completamente predefinido por un humano, no hay autonomía.

Un agente combina razonamiento + decisión + acción + observación en un loop que él mismo controla.

4. Los componentes de un agente

Un agente no es una sola cosa mágica. Es una combinación de componentes trabajando juntos.

Modelo (el cerebro)

Es el componente que razona y decide. El modelo de lenguaje analiza la situación, decide qué hacer a continuación y genera las instrucciones para actuar. Sin el modelo, no hay razonamiento.

En el artículo anterior vimos cómo elegir un modelo según sus capacidades. Para agentes, necesitas un modelo que soporte tool use (uso de herramientas), que es la capacidad de describir cuándo necesita llamar a una función externa y con qué parámetros.

Herramientas (las manos)

Las herramientas son funciones que el agente puede ejecutar para interactuar con el mundo exterior. Pueden ser:

APIs externas: clima, bases de datos, servicios web
Ejecución de código: correr scripts, hacer cálculos
Búsqueda: buscar en internet, en documentos, en bases de conocimiento
Acciones en sistemas: crear archivos, enviar emails, desplegar código

Sin herramientas, el agente sería solo un modelo con pasos extra. Las herramientas son lo que le dan la capacidad de actuar.

Memoria (el contexto)

La memoria permite al agente recordar qué ha hecho, qué ha observado y qué ha decidido. Hay dos tipos:

Memoria a corto plazo: la conversación actual, los pasos que ha dado, los resultados que ha obtenido. Esto vive en la ventana de contexto del modelo.
Memoria a largo plazo: información que persiste entre conversaciones. Puede ser una base de datos, un archivo, o cualquier sistema de almacenamiento externo.

Sin memoria, el agente repetiría los mismos errores y no podría construir sobre sus observaciones anteriores.

Instrucciones (el propósito)

Las instrucciones le dicen al agente qué debe hacer y cómo debe comportarse. Esto incluye:

El prompt del sistema que define su rol y restricciones
Los objetivos que debe cumplir
Las reglas que debe seguir

Sin instrucciones claras, el agente no sabría hacia dónde dirigir su razonamiento.

5. El loop: cómo funciona un agente

Ahora que conoces los componentes, veamos cómo interactúan. Un agente funciona en un loop (ciclo) que se repite hasta completar la tarea:

Pensar

El modelo analiza la situación actual: ¿qué me pidieron? ¿qué sé hasta ahora? ¿qué me falta? Decide cuál es el siguiente paso.

Actuar

Basándose en su razonamiento, el agente ejecuta una acción. Puede ser llamar una herramienta, hacer una búsqueda, o ejecutar código.

Observar

El agente recibe el resultado de su acción y lo incorpora a su contexto. ¿Funcionó? ¿Obtuvo lo que necesitaba? ¿Necesita hacer algo más?

Repetir o responder

Si la tarea está completa, el agente genera su respuesta final. Si no, vuelve a Pensar con la nueva información y repite el ciclo.

El modelo responde una vez. El agente itera hasta resolver el problema.

💡 Tip importante: El número de iteraciones del loop depende de la complejidad de la tarea. Una pregunta simple puede resolverse en 1-2 ciclos. Una tarea compleja como "investiga este bug y propón una solución" puede tomar 5-10 ciclos donde el agente lee código, ejecuta tests, analiza errores y propone cambios.

6. ¿Cómo se construye un agente?

Si estás pensando "esto suena complejo de implementar", tienes razón. Conectar un modelo con herramientas, manejar memoria, implementar el loop, manejar errores... son muchas piezas.

Por eso existen SDKs y frameworks que se encargan de la infraestructura para que tú te enfoques en definir qué debe hacer tu agente:

Strands Agents: Un SDK open source de AWS que simplifica la creación de agentes con un enfoque en model-driven development
LangGraph: Framework para construir agentes como grafos de estados
Amazon Bedrock Agents: Servicio administrado de AWS para crear agentes sin manejar infraestructura

Estos frameworks se encargan de:

Implementar el loop (Pensar → Actuar → Observar)
Conectar el modelo con las herramientas
Manejar la memoria y el contexto
Gestionar errores y reintentos

Tu trabajo como desarrollador es definir: ¿qué herramientas tiene disponibles mi agente? ¿qué instrucciones le doy? ¿qué modelo uso?

En el próximo artículo de esta serie vamos a construir tu primer agente de IA paso a paso usando uno de estos frameworks. Vas a ver que con pocas líneas de código puedes tener un agente funcional que resuelve problemas reales.

Preguntas frecuentes

¿Todos los chatbots de IA son agentes?

No. La mayoría de chatbots que usas día a día (como ChatGPT en modo básico) son modelos con una interfaz de conversación. Se convierten en agentes cuando tienen acceso a herramientas y pueden ejecutar acciones, como cuando ChatGPT busca en internet o ejecuta código con Code Interpreter.

¿Un agente puede equivocarse?

Si. Los agentes heredan las limitaciones del modelo que usan como cerebro. Pueden tomar decisiones incorrectas, usar herramientas de forma equivocada, o entrar en loops infinitos. Por eso las instrucciones claras y las restricciones son importantes.

¿Necesito un modelo específico para construir agentes?

Necesitas un modelo que soporte tool use (también llamado function calling). La mayoría de modelos modernos lo soportan: Claude, GPT-4, Llama 3, Nova, entre otros. Puedes acceder a varios de estos a través de Amazon Bedrock.

¿Los agentes son seguros?

Depende de cómo los construyas. Un agente con acceso a herramientas poderosas (como ejecutar código o modificar bases de datos) necesita restricciones claras. Es tu responsabilidad como desarrollador definir qué puede y qué no puede hacer.

Conclusión

Recapitulemos lo que aprendimos:

Un agente de IA es un sistema que usa un modelo como cerebro para razonar, decidir y ejecutar acciones de forma autónoma
La diferencia con un modelo solo: el modelo genera texto, el agente hace cosas
Un agente tiene 4 componentes: modelo (cerebro), herramientas (manos), memoria (contexto) e instrucciones (propósito)
Funciona en un loop: Pensar → Actuar → Observar → Repetir hasta completar la tarea
Existen frameworks y SDKs que simplifican la construcción de agentes para que no tengas que implementar todo desde cero

En el próximo artículo vamos a pasar de la teoría a la práctica: vas a construir tu primer agente de IA funcional, con herramientas reales, en pocas líneas de código.

Build Your Own AI Butler - A Scheduled Agent That Runs Itself!

Erik Hanchett — Wed, 06 May 2026 16:00:47 +0000

I want an AI agent that works for me. I want it to search up the latest news, and I want it to deliver it to me in a daily message. I want to chat with it, and get advice. I want to expand its capabilities in the future. And most importantly I want to control it. Basically, I want Jarvis.

Yes Jarvis, the fictional AI character in the Marvel Cinematic Universe (MCU), serving as Tony Stark's butler. I've never had my own agentic butler, and now that I think about it who wouldn't? 😆 A few years ago I would have told you this would have never happened. But today with the rise of agents the future is here.

Well sort of... we are getting closer than ever though!

To take on this task one of the most obvious routes was to use something like OpenClaw. Except, OpenClaw is too new, and a little too much for what I needed, so like any good engineer I decided to roll my own. OpenClaw is an open-source, autonomous AI agent that runs locally on a your machine or VPS to automate tasks.

Recently Amazon Bedrock AgentCore released its managed harness in preview. You define the agent in a config file and a system prompt, and then deploy it. That was it! From my research it looked very straightforward to get up and running, and it could save me a lot of time in the long run. So I decided to take the journey to create my very own Jarvis.

If you want the conceptual breakdown of what a harness actually is in more detail, my friend Morgan's post on dev.to covers that well. This post is the hands-on build.

After several hours of tinkering and research I created "The Pulse." It opens Hacker News in a real browser, grabs Reddit posts via RSS, saves everything to persistent storage, and every 6 hours writes a trending stories digest. It messages me every day, or I can message it anytime and ask what's happening in AI. It reads from the data it's been collecting all day.

If you're more like me and love videos, check out the full video below on how to get started. I'm also including the source code so you can try it yourself. Otherwise continue on and learn all about how to get started! Feel free to let me know how it goes.

Full code:

aws-samples / sample-AgentCore-Managed-Harness-News

AgentCore Managed Harness News Sample — The Pulse

A sample AgentCore managed harness project that runs a scheduled news digest agent ("The Pulse") on Amazon Bedrock AgentCore and posts the results to Telegram.

The agent is scheduled with EventBridge Scheduler, invoked via a Lambda trigger, and uses AgentCore Memory to retain context across runs. It's a realistic end-to-end example of building a recurring, long-running agent on AWS.

What's in here

AgentCore-News-Sample/
├── agentcore/
│   ├── agentcore.json          # Project config (runtimes, memories, etc.)
│   ├── aws-targets.json        # AWS account + region to deploy into
│   ├── cdk/                    # CDK infrastructure (@aws/agentcore-cdk)
│   │   ├── bin/cdk.ts          # CDK entry — synthesizes both stacks
│   │   ├── lib/cdk-stack.ts    # AgentCore stack (agent, memory, roles)
│   │   ├── lib/scheduler-stack.ts  # Scheduler + Lambda trigger
│   │   └── lambda/pulse-trigger/   # Lambda that invokes the harness
│   └── .llm-context/           # Type definitions for AI coding assistants

…

View on GitHub

AgentCore Harness is in preview. The CLI, pricing, and some APIs may change. Check the AgentCore docs for the latest.

Table of Contents

What We're Building
Why Not Just Use Lambda?
Prerequisites
Create the Harness Project
Configure the Agent
Deploy
Test the Hourly Collection
Test the Summary Digest
Ask It Questions
Pull Data Out Without Burning Tokens
Schedule It With EventBridge and Lambda
Troubleshooting
Cost Estimate
Cleanup
What's Next

What We're Building

Don't worry if this diagram looks intimidating! The most complicated part is just getting the EventBridge connected with the correct IAM roles to the harness and dealing with the infrastructure code if you're new to that. Let's break down the flow here.

EventBridge fires every hour and triggers a Lambda. EventBridge is AWS's scheduler service, think of it like a cron job in the cloud. The Lambda makes one API call to the harness. Inside the harness, the agent runs in its own microVM, which is basically a lightweight virtual machine that spins up just for your session with its own CPU, memory, and filesystem. The agent opens a browser, scrapes HN, fetches Reddit RSS, and saves a snapshot. Every 6th run it reads all the snapshots, finds trends, and writes a digest. And because the session ID stays the same across runs, all that data accumulates on /mnt/data. You can also just talk to it anytime through the CLI and ask what's trending.

Why Not Just Use Lambda?

Before we get into the details, one question you may be thinking is couldn't we do all this with just a Lambda, some Strands Agents code, an LLM, and a dream? For a simple one-shot task, you are probably right. But this agent needs a few things Lambda can't give you, which makes this approach well worth it.

First, the agent opens a real browser to scrape Hacker News. Lambda can't spin up a managed browser session. You'd need Fargate plus Playwright, and now you're managing containers. I love containers, but let's skip it for this scenario.

Second, it saves hourly snapshots to /mnt/data/runs/ and reads them back 6 hours later. Lambda's /tmp gets wiped after every invocation. You'd need S3 plus custom read/write logic for every file operation. That's a lot of work for what should be "save a file."

Third, the 6-hour summary run reads all the accumulated data, compares scores across snapshots, identifies trends, and writes a digest. That can take a while. Lambda maxes out at 15 minutes. The harness defaults to a 1-hour timeout per invocation (I set mine to 30 minutes since that's plenty), and the microVM itself can stay alive for up to 8 hours across multiple invocations.

And then there's memory. AgentCore Memory is a built-in service that stores facts, preferences, and conversation summaries across sessions. So "What did I ask about yesterday?" works because the memory carries context forward. In Lambda, you'd need DynamoDB plus a custom integration.

Could you build all of this with Lambda plus S3 plus Fargate plus DynamoDB plus Step Functions? Sure. That's five services instead of one. That's four too many for this tutorial.

Prerequisites

Node.js 20+
AWS credentials configured in a preview region (us-west-2, us-east-1, eu-central-1, or ap-southeast-2)
CDK bootstrapped in your account (cdk bootstrap). CDK is the AWS Cloud Development Kit. It lets you define infrastructure in TypeScript instead of clicking through the console. If you haven't used it before, npm install -g aws-cdk and then cdk bootstrap in your account.
The AgentCore CLI:

npm install -g @aws/agentcore@preview

Bedrock model access for Claude Sonnet 4.6 in your region. As of late 2025, Bedrock gives you automatic access to all serverless models in your region without needing to enable them individually. If your organization uses IAM policies or SCPs to restrict model access, make sure Sonnet isn't blocked. You can verify by opening the Bedrock console and trying the model in the playground.

Create the Harness Project

This is where the fun begins. We'll create our very first managed harness.

agentcore create \
  --name thepulse \
  --model-provider bedrock \
  --session-storage-mount-path /mnt/data

cd thepulse

That one command scaffolds the whole project. Harness config, memory, session storage, CDK app, IAM role. The --session-storage-mount-path flag wires up persistent storage so the platform creates a /mnt/data mount point for you. You don't have to worry about a Dockerfile, or container to manage.

Now add the browser tool. AgentCore Browser is a managed headless Chrome instance that the harness can spin up on demand. Your agent can navigate pages, click elements, extract content, basically anything you'd do with Playwright but without managing the browser infrastructure yourself.

agentcore add tool --harness thepulse --type agentcore_browser --name browser

Here's what you end up with:

thepulse/
├── agentcore/
│   ├── agentcore.json          # Project-level resource config
│   ├── aws-targets.json        # Deployment targets (account, region)
│   ├── .env.local              # Local dev config (gitignored)
│   └── cdk/                    # CDK TypeScript app
├── app/
│   └── thepulse/
│       ├── harness.json        # Agent config
│       └── system-prompt.md    # Agent instructions

Configure the Agent

Our AgentCore CLI already set up the model, memory, and session storage. You just need to tweak the execution limits and write the system prompt.

Edit app/thepulse/harness.json:

{
  "name": "thepulse",
  "model": {
    "provider": "bedrock",
    "modelId": "global.anthropic.claude-sonnet-4-6"
  },
  "tools": [
    {
      "type": "agentcore_browser",
      "name": "browser"
    }
  ],
  "skills": [],
  "memory": { "name": "thepulseMemory" },
  "sessionStoragePath": "/mnt/data",
  "maxIterations": 75,
  "timeoutSeconds": 1800
}

A few things worth mentioning here.

I set maxIterations to 75 because browser interactions are chatty. That eats through iterations fast, and 75 gives room for the full HN browser scrape plus Reddit RSS plus file operations without the agent hitting the ceiling.

timeoutSeconds is 1800 (30 minutes). Browser sessions take time, and the summary run reads a lot of data. I didn't hit too many timeouts when testing, but this was a just-in-case update.

This next setting is really useful. The platform creates the /mnt/data mount point automatically when you set sessionStoragePath. This mount point will be shared per session, no matter if the session times out.

Now edit app/thepulse/system-prompt.md. The CLI created this file with a default prompt. Replace it:

You are The Pulse, an AI research agent that monitors Hacker News
and Reddit for AI/ML stories.

You have two modes:

### HOURLY COLLECTION
When the prompt says "hourly run":

**Hacker News (browser):**
1. Use the browser tool to open https://news.ycombinator.com
2. Extract the top 30 stories: title, score, comment count, URL
3. Close the browser session when done

**Reddit (RSS — do NOT use the browser):**
Reddit blocks automated browser access (403). Use the RSS feed instead:
1. Shell: `curl -s -A 'ThePulse/1.0'
   'https://www.reddit.com/r/MachineLearning/.rss'`
2. Parse the XML to extract post titles, URLs, authors, and dates
3. Note: RSS does not include upvote scores. That's expected.
4. Also try r/artificial: `curl -s -A 'ThePulse/1.0'
   'https://www.reddit.com/r/artificial/.rss'`

**Save the snapshot:**
1. Combine HN and Reddit data into a single JSON file
2. Save to /mnt/data/runs/YYYY-MM-DD-HH.json
3. If a previous hour's snapshot exists (check /mnt/data/runs/),
   compare and flag:
   - Stories that appeared in both snapshots (persistent)
   - HN stories with rising scores

### SUMMARY DIGEST
When the prompt says "generate summary":
1. Read all snapshots from /mnt/data/runs/ for the last 6 hours
2. Identify stories that appeared in multiple snapshots
   (persistent presence = trending)
3. Identify stories with rising scores across snapshots
4. Deduplicate and rank by persistence, score growth, and
   comment activity
5. Write a markdown digest to
   /mnt/data/digests/YYYY-MM-DD-{morning|afternoon|evening|night}.md
6. Include the top 10 trending stories with: title, source
   (HN/Reddit), peak score, trend direction, URL

### INTERACTIVE
When a user asks a question:
- Read from /mnt/data/runs/ and /mnt/data/digests/ to answer
- Use memory for conversational context

## Important
- /mnt/data is persistent session storage. Use the same session ID
  across runs so data accumulates.
- Always create directories before writing:
  `mkdir -p /mnt/data/runs /mnt/data/digests`

I put the collection to be hourly and the snapshots to run every six hours. Retrospectively, this is a lot of data, and I could certainly have expanded that. I'd say collecting twice a day and having a snapshot created once a day would be fine as well. Feel free to tweak this prompt to your liking.

One gotcha I'd like to pass on is that Reddit doesn't like agents scraping its data. The agent kept trying to open Reddit in the browser, getting 403'd, and burning 5-6 iterations before giving up. I sat there watching it retry over and over thinking "please just stop." The RSS feed at reddit.com/r/MachineLearning/.rss works every time. Putting it explicitly in the system prompt saves you from that pain.

Deploy

agentcore deploy

One command. It provisions the harness, memory, IAM role, session storage, and the underlying microVM infrastructure. This takes about 3-5 minutes because it's also spinning up AgentCore Memory and running CDK for the IAM roles.

You can verify what got created:

agentcore status --json

Test the Hourly Collection

To test this out you'll need a stable session ID so /mnt/data accumulates across runs, as I mentioned earlier. The session ID needs to be at least 33 characters (a UUID is 36, so that works). This is important because the same session ID means the same filesystem. That's how data builds up over time.

SESSION_ID="thepulse-$(uuidgen)"
echo $SESSION_ID  # Save this. You'll reuse it for every run.

agentcore invoke --harness thepulse \
  --session-id "$SESSION_ID" \
  --actor-id scheduler \
  "Hourly run. Collect AI/ML stories from Hacker News and Reddit. Save the snapshot."

The agent will open a managed Chrome browser, navigate to news.ycombinator.com, extract stories, fetch Reddit via RSS, and save everything to /mnt/data/runs/.

Verify it worked:

agentcore invoke --exec --harness thepulse \
  --session-id "$SESSION_ID" \
  "ls -la /mnt/data/runs/"

That --exec flag is one of my favorite things about the harness. It runs a shell command directly on the microVM. It's not connecting to any LLM so no tokens are used. You can use it to poke around the filesystem anytime without spending money.

Test the Summary Digest

Run the collection a couple times (or wait a few hours), then:

agentcore invoke --harness thepulse \
  --session-id "$SESSION_ID" \
  --actor-id scheduler \
  "Generate summary. Read all snapshots from the last 6 hours and write a trending stories digest."

The agent reads all the hourly snapshots, identifies stories that appeared multiple times (trending), flags rising scores, and writes a markdown digest.

Ask It Questions

agentcore invoke --harness thepulse \
  --session-id "$SESSION_ID" \
  --actor-id demo-user \
  "What's trending in AI right now?"

The agent reads from /mnt/data/runs/ and /mnt/data/digests/ to answer with real data. Not hallucinated summaries, actual scores and URLs from the snapshots it collected. I really liked this part. The agent isn't guessing. It's reading files it wrote earlier that day.

Schedule It With EventBridge and Lambda

The agentcore create command already scaffolded a CDK app at agentcore/cdk/. We'll add a Lambda trigger and an EventBridge schedule to that existing project. EventBridge Scheduler is the AWS service that fires events on a cron schedule. We'll have it invoke a Lambda every hour, and that Lambda calls the harness. One agentcore deploy handles the harness, one cdk deploy handles the scheduler. I like keeping these separate because you iterate on the agent config way more often than the scheduling infrastructure.

Set Up the Lambda

mkdir -p agentcore/cdk/lambda/pulse-trigger
cd agentcore/cdk/lambda/pulse-trigger
npm init -y
npm install @aws-sdk/client-bedrock-agentcore @aws-sdk/client-secrets-manager
npm install -D typescript @types/node esbuild
cd ../../../..

Create agentcore/cdk/lambda/pulse-trigger/index.ts:

import {
  BedrockAgentCoreClient,
  InvokeHarnessCommand,
} from "@aws-sdk/client-bedrock-agentcore";
import {
  SecretsManagerClient,
  GetSecretValueCommand,
} from "@aws-sdk/client-secrets-manager";

interface TelegramSecret {
  botToken: string;
  defaultChatId: string;
}

const agentCore = new BedrockAgentCoreClient({ region: process.env.AWS_REGION });
const secrets = new SecretsManagerClient({ region: process.env.AWS_REGION });

// Cache the secret across warm invocations
let cachedSecret: { value: TelegramSecret; expiry: number } | null = null;
const SECRET_TTL_MS = 5 * 60 * 1000; // 5 minutes

async function getSecret(): Promise<TelegramSecret> {
  if (cachedSecret && Date.now() < cachedSecret.expiry) {
    return cachedSecret.value;
  }
  const secretArn = process.env.TELEGRAM_SECRET_ARN;
  if (!secretArn) throw new Error("Missing TELEGRAM_SECRET_ARN env var");

  const res = await secrets.send(
    new GetSecretValueCommand({ SecretId: secretArn })
  );
  const value: TelegramSecret = JSON.parse(res.SecretString!);
  cachedSecret = { value, expiry: Date.now() + SECRET_TTL_MS };
  return value;
}

async function sendToTelegram(
  botToken: string, chatId: string, text: string
) {
  // Telegram's message limit is 4096 chars. Split if needed.
  const chunks = text.match(/[\s\S]{1,4000}/g) || [];
  for (const chunk of chunks) {
    const res = await fetch(
      `https://api.telegram.org/bot${botToken}/sendMessage`,
      {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({
          chat_id: chatId,
          text: chunk,
          parse_mode: "Markdown",
        }),
      }
    );
    if (!res.ok) {
      console.error("Telegram send failed:", await res.text());
    }
  }
}

export const handler = async () => {
  const hour = new Date().getUTCHours();
  const sessionId = process.env.STABLE_SESSION_ID!;
  const harnessArn = process.env.HARNESS_ARN!;

  const isSummaryRun = hour % 6 === 0;

  const prompt = isSummaryRun
    ? "Generate summary. Read all snapshots from the last 6 hours and write a trending stories digest."
    : "Hourly run. Collect AI/ML stories from Hacker News and Reddit. Save the snapshot.";

  const command = new InvokeHarnessCommand({
    harnessArn,
    runtimeSessionId: sessionId,
    actorId: "scheduler",
    messages: [{ role: "user", content: [{ text: prompt }] }],
  });

  const response = await agentCore.send(command);

  // Collect the full response text from the stream
  let responseText = "";
  let chunkCount = 0;
  if (response.stream) {
    for await (const event of response.stream) {
      chunkCount++;
      if ("contentBlockDelta" in event) {
        const delta = (event as any).contentBlockDelta?.delta;
        if (delta && "text" in delta) {
          responseText += delta.text;
          process.stdout.write(delta.text);
        }
      }
    }
  }

  console.log(
    `\n[pulse-trigger] Stream complete — ${chunkCount} chunks`
  );

  // On summary runs, send the digest to Telegram
  if (isSummaryRun && responseText) {
    const { botToken, defaultChatId } = await getSecret();
    await sendToTelegram(botToken, defaultChatId, responseText);
  }

  return {
    statusCode: 200,
    hour,
    type: isSummaryRun ? "summary" : "collection",
    digestSent: isSummaryRun,
  };
};

Let's break down what's happening here.

The Lambda passes a stable session ID (from an environment variable) so every hourly run writes to the same /mnt/data. It collects the full response text from the stream and logs it to CloudWatch. On summary runs, it sends the digest to Telegram using a bot token stored in Secrets Manager. Secrets Manager is the AWS service for storing sensitive values like API keys and tokens. You don't want a bot token sitting in an environment variable where anyone with console access can see it. The sendToTelegram function handles Telegram's 4096 character limit by chunking the text. I found the CloudWatch logging really helpful for debugging early on when the agent would occasionally get stuck in a browser loop.

Add the Scheduler Stack

Create agentcore/cdk/lib/scheduler-stack.ts. This is a CDK stack, which is basically a unit of deployment. Everything in this file gets deployed together as one CloudFormation stack.

import {
  Stack, StackProps, Duration, TimeZone, CfnOutput,
} from "aws-cdk-lib";
import { NodejsFunction } from "aws-cdk-lib/aws-lambda-nodejs";
import { Runtime } from "aws-cdk-lib/aws-lambda";
import { Secret } from "aws-cdk-lib/aws-secretsmanager";
import * as iam from "aws-cdk-lib/aws-iam";
import * as scheduler from "aws-cdk-lib/aws-scheduler";
import * as targets from "aws-cdk-lib/aws-scheduler-targets";
import { Construct } from "constructs";
import * as path from "path";

export interface PulseSchedulerStackProps extends StackProps {
  agentRuntimeArn: string;
  harnessArn: string;
  stableSessionId: string;
  telegramSecretArn: string;
}

export class PulseSchedulerStack extends Stack {
  constructor(
    scope: Construct, id: string, props: PulseSchedulerStackProps
  ) {
    super(scope, id, props);

    const telegramSecret = Secret.fromSecretCompleteArn(
      this, "TelegramSecret", props.telegramSecretArn
    );

    const triggerFn = new NodejsFunction(this, "PulseTrigger", {
      runtime: Runtime.NODEJS_22_X,
      entry: path.join(
        __dirname, "../../lambda/pulse-trigger/index.ts"
      ),
      handler: "handler",
      timeout: Duration.minutes(15),
      memorySize: 256,
      environment: {
        HARNESS_ARN: props.harnessArn,
        STABLE_SESSION_ID: props.stableSessionId,
        TELEGRAM_SECRET_ARN: props.telegramSecretArn,
      },
      bundling: {
        externalModules: [],
      },
    });

    triggerFn.addToRolePolicy(
      new iam.PolicyStatement({
        actions: [
          "bedrock-agentcore:InvokeHarness",
          "bedrock-agentcore:InvokeAgentRuntime",
        ],
        resources: [
          props.harnessArn,
          props.agentRuntimeArn,
        ],
      })
    );

    // Read access to the Telegram bot token secret
    telegramSecret.grantRead(triggerFn);

    new scheduler.Schedule(this, "HourlySchedule", {
      schedule: scheduler.ScheduleExpression.cron({
        minute: "0",
        hour: "*",
        timeZone: TimeZone.of("UTC"),
      }),
      target: new targets.LambdaInvoke(triggerFn, {}),
      description: "The Pulse — hourly AI/ML news collection",
    });

    new CfnOutput(this, "TriggerFunctionName", {
      value: triggerFn.functionName,
    });
  }
}

The telegramSecret.grantRead(triggerFn) line gives the Lambda permission to read the bot token from Secrets Manager. The bot token lives there instead of in environment variables so it doesn't show up in CloudFormation outputs or the Lambda console.

Wire it into agentcore/cdk/bin/cdk.ts:

import { PulseSchedulerStack } from "../lib/scheduler-stack";

// ... existing AgentCore stack code ...

new PulseSchedulerStack(app, "ThePulseScheduler", {
  harnessArn: "REPLACE_WITH_YOUR_HARNESS_ARN",
  agentRuntimeArn: "REPLACE_WITH_YOUR_RUNTIME_ARN",
  stableSessionId: "REPLACE_WITH_YOUR_SESSION_ID",
  telegramSecretArn: "REPLACE_WITH_YOUR_SECRET_ARN",
  env: {
    account: targets[0].account,
    region: targets[0].region,
  },
});

I'm showing placeholders here to make it clear what goes where. You can get your harness ARN and runtime ARN with agentcore status --json, and use the same session ID you've been testing with. The Telegram secret ARN comes from Secrets Manager (store your bot token and chat ID as a JSON object with botToken and defaultChatId keys).

That said, you shouldn't hardcode ARNs and secrets into source files you commit to git. The actual repo resolves the harness ARN and runtime ARN automatically from the deployed state file that agentcore deploy creates, and reads the Telegram secret ARN and session ID from environment variables. That way nothing sensitive ends up in version control. Check the cdk.ts in the repo for the full implementation.

Deploy and Test

# Install esbuild in the CDK project (needed for NodejsFunction)
cd agentcore/cdk && npm install esbuild --save-dev && cd ../..

# Deploy the harness
agentcore deploy

# Deploy the scheduler stack
cd agentcore/cdk && npm run build && npx cdk deploy ThePulseScheduler && cd ../..

Test the Lambda directly:

aws lambda invoke \
  --function-name $(aws cloudformation describe-stacks \
    --stack-name ThePulseScheduler \
    --query 'Stacks[0].Outputs[?OutputKey==`TriggerFunctionName`].OutputValue' \
    --output text) \
  --region us-west-2 \
  --cli-read-timeout 900 \
  /tmp/lambda-response.json

cat /tmp/lambda-response.json

The --cli-read-timeout 900 is important. The harness invocation takes a few minutes (the agent is browsing HN, fetching RSS, saving data), and the AWS CLI's default timeout is 60 seconds. Without it, you'll get a Read timeout error even though the Lambda is still running fine. Don't make this mistake like I did.

You should see {"statusCode":200,"hour":...,"type":"collection"}.

Troubleshooting

A few things I hit while building this. Hopefully they save you some time.

npm ci fails during CDK synth. If you use nodeModules in the bundling config instead of externalModules: [], CDK copies your package-lock.json into a temp directory and runs npm ci. If the lock file is even slightly out of sync with package.json, it fails. I went back and forth on this for a while before landing on the externalModules: [] approach that bundles everything with esbuild and skips npm ci entirely.

AccessDeniedException on ConverseStream. This one got me. Bedrock now gives automatic access to all models in your region, so the old "Model Access" page is gone. But if your organization uses IAM (Identity and Access Management) policies or SCPs (Service Control Policies) to restrict which models can be invoked, you'll get this error. Check with your admin to make sure the model isn't blocked by a deny policy. I hit this when I tried to use Haiku for cheaper collection runs in an account that had an SCP limiting models to Sonnet only. The error message doesn't make it obvious that it's a permissions issue.

Lambda times out but the agent is still running. The Lambda timeout (15 min max) and the harness timeout (30 min) are separate. If the agent takes longer than the Lambda allows, the Lambda dies but the harness session keeps running in the background. Check CloudWatch logs for the Lambda, and use agentcore logs --harness thepulse --since 1h for the harness side.

Reddit returns 403 in the browser. Reddit blocks automated browser access. The system prompt tells the agent to use RSS instead, but if you're iterating on the prompt and forget to include that instruction, the agent will waste iterations trying to open Reddit in the browser. Ask me how I know.

Cost Estimate

The main cost here is Bedrock model usage. Each hourly collection run uses around 10-15K tokens (browser interactions are chatty), and summary runs use more since they read all the accumulated data. Lambda and EventBridge are basically free at this scale.

You can cut costs by enabling a cheaper model like Haiku in the Bedrock console and passing a model override for collection runs. Keep Sonnet for the summary runs that need more reasoning. The harness supports per-invocation model overrides so you don't need to redeploy. You can also just reduce the number of times it collects data.

AgentCore Runtime and Browser have no separate charge during preview.

Check the Bedrock pricing page for current model token costs and the AgentCore pricing page for runtime and browser session rates.

Cleanup

Make sure you always clean up your stacks after trying out tutorials!

# Delete the scheduler stack
cd agentcore/cdk && npx cdk destroy ThePulseScheduler && cd ../..

# Delete the harness and all AgentCore resources
agentcore destroy

The agentcore destroy command removes the harness, memory, IAM role, and session storage. The CDK destroy removes the Lambda, EventBridge schedule, and any IAM roles CDK created.

What's Next

This is a starting point. I have thoughts on a few directions I could take my very own Jarvis 😊.

Right now the Telegram integration is outbound only. I want to add two-way chat so I can message the bot and ask questions (without just using the command line). That means an API Gateway webhook and a second Lambda that invokes the harness in interactive mode. The agent reads from /mnt/data to answer with real data.

More sources would be easy to add. The system prompt is just markdown. Add instructions for other news sources that a browser can reach. The nice thing is it would just take a prompt update and a new run of agentcore deploy.

I also want to try switching models per run. Enable Haiku in the Bedrock console and pass --model-id on collection runs for cheaper hourly scrapes. Keep Sonnet for the summary runs that need more reasoning. The harness supports this per-invocation without a redeploy.

And eventually, a dashboard. Have the agent generate an HTML page from the accumulated data and sync it to S3. Use --exec to run aws s3 sync from the microVM.

After building this, I'm convinced the harness approach works really well for simpler use cases like my personal news Jarvis. If your agent needs persistent state, scheduled runs, and a browser, this is way less infrastructure than stitching it together yourself. If you just need a one-shot agent that answers a question, stick with Lambda. And of course if you need maximum flexibility, using AgentCore runtime is your best bet!

Let me know in the comments what you think! Thanks!

Resources

What Even Is AI? (I Took a Break & Had to Relearn Everything)

Rohini Gaonkar — Tue, 05 May 2026 18:38:06 +0000

I just came back from maternity leave. And honestly? I felt like I'd missed a decade in six months. I talked about starting small in my other blog Lost in the AI Hype, I Started Small

I've spent the last fifteen years designing cloud systems. And even I felt behind. AI went from a thing people were experimenting with to a thing everyone's apparently building with, and I had no idea where to start.

So I did what any architect would do. I went back to first principles.

I'm rebuilding my AI mental model from scratch in public. No math. No expert-level coding. Just real problems, the architecture underneath, and honest notes on where things might break.

If you prefer video, please watch Episode 1 of my video series . If you prefer reading, you're in the right place.

The demo: AI adapts a recipe in under a minute

Before any theory, let me show you what these models can actually do.

I opened Amazon Bedrock Playground, pasted a real recipe, and asked three questions with each one pushing the model a little further:

1. Extract and summarise

"What are the core techniques in this recipe, strip off the fluff?"

Clean, fast, useful. You might think: that's a fancy Ctrl+F (search).

2. Interpret and advise

"Looking at this recipe, what's the thing that's most likely to go wrong for someone cooking it for the first time?"

Now we're somewhere a search tool genuinely can't go. The model is reasoning about the recipe like spotting the bit where people actually mess up.

3. Personalise

"I'm cooking this for six people on Saturday. One is vegan, one is gluten-free. Adapt the recipe, give me a shopping list, and a timeline starting from 4pm."

This is the moment. I asked it something I'd normally spend twenty minutes thinking through. It gave me a starting point in ten seconds.

If you're curious but not technical, that's already useful.

If you're a builder, you're probably already thinking so what happened here.

So what actually happened?

Here's the architecture, as simply as I can put it.

I sent text called a prompt to a foundation model.

People throw around terms like AI, LLMs, and foundation models like they all mean the same thing but they don’t.

AI is the broad umbrella. It includes everything from recommendation engines and fraud detection systems to generative AI tools like ChatGPT.

Foundation models are a subset of AI, they are large models trained on massive datasets that can be adapted for different tasks. These aren’t just text models; they can generate images, video, speech, code, and more. Platforms like Amazon Bedrock give access to many of these models.

LLMs (Large Language Models) are a specific type of foundation model built for language tasks like answering questions, summarizing text, writing, or coding. So in my recipe demo, I was technically interacting with an LLM.

The simplest way to think about it:

AI → Foundation Models → LLMs

So, in our case it means its a big model trained on a huge mix of data for your day to day general purpose.

The model is a piece of software trained on an enormous amount of text: books, articles, code, conversations. It is not searching the internet. It learned patterns from all that text beforehand.

When I give it my prompt, it predicts the most useful response based on everything it learned.

Input (prompt) → Foundation Model → Output (response)

I've been building distributed systems for years, and a foundation model call is simpler than most of the APIs I'm used to. It's an HTTP request with text in, text out.

The complexity isn't in the call itself, it is in what the model learned before you or I ever showed up.

And this exact loop is what the entire current wave of AI is built on.

Every time you see a new Claude, or GPT, or Llama land, what's actually happening is someone trained a bigger or smarter version of this same idea.

Same loop. More data. Better prediction.

Where it breaks

The model doesn't know if it's right. It's predicting what a useful answer looks like. Sometimes that prediction is brilliant. Sometimes it invents something that sounds plausible and is completely wrong.

Every time you use one of these tools, ask yourself: what would I need to double-check before I trusted this?

That question is the single most useful habit you can build right now. We'll dig into why this happens in the next post.

Where the models live: Amazon Bedrock

You might've noticed I wasn't using ChatGPT or Claude's own website. I was using Amazon Bedrock.

Bedrock is where a bunch of foundation models live on AWS. Anthropic's Claude, Meta's Llama, Mistral, Amazon's own models, they are all callable through Bedrock, no need to run or train anything yourself.

The Playground is the easy door in, just type and go. Later in this series, when we start building, we'll call these same models from code. Same models, different door.

A note on my stack

I work at AWS. So the tools I use in this series are AWS tools like Bedrock for the models, and later, an AI-powered IDE called Kiro for building.

The concepts, though, aren't AWS specific. Foundation models, tokens, context windows, RAG, agents, these work the same way on any cloud. I'm showing you my stack. And honestly, I'm still figuring out which parts of it are great and which parts are a pain. You'll know which is which.

Try it yourself

If you're just getting started: open any AI chat tool (Bedrock Playground, Claude, ChatGPT, whatever you have access to), paste a recipe, a contract, a long email and ask it three questions:

One to summarise.
One to interpret.
One that's personal to you.

See what happens. That's your homework.

If you're more on the builder side: the mental model is simple: text in, model, text out. Everything we build in this series is a variation on that loop.

What's next

Next up: when AI sounds confident and is completely wrong. Why it happens, how to spot it, how to stop it.

This is a series. I'm learning this in public, building as I go, and being honest when things don't work. If that sounds useful, please follow along.

This post is part of the "Learning AI Out Loud" series, a cloud architect learning AI from first principles. Watch the video version or follow the series on dev.to.

Modern Container Builds and WebSocket APIs Come to AWS SAM

Eric D Johnson — Tue, 05 May 2026 18:09:06 +0000

SAM CLI has always been good at taking the grunt work out of serverless deployments. You define your functions and APIs in a template, and SAM handles the CloudFormation, the packaging, the deployment. It works.

Until recently, two things were missing. BuildKit support for container image builds. And a SAM resource type for WebSocket APIs.

Both are now shipped. Neither breaks existing templates.

Let's walk through it.

BuildKit Support for Image-Based Lambda Functions
The problem
When you run sam build for an image-based Lambda function, SAM uses the docker-py Python SDK under the hood. That SDK talks to the Docker daemon directly, but it doesn't support BuildKit. At all.

That means every sam build invocation uses the legacy Docker builder. You lose parallelized build stages. You lose efficient layer caching. You lose multi-stage build optimizations. You lose cross-architecture improvements that BuildKit has shipped over the past several years.

For simple single-stage Dockerfiles, this probably doesn't matter. For anything with multiple stages, private dependencies, or cross-compilation targets, it's a real bottleneck.

What shipped
SAM CLI v1.156.0 introduced the --use-buildkit flag on sam build. When you pass this flag, SAM bypasses docker-py entirely and shells out to the Docker CLI (or Finch CLI) directly. That gives you access to everything BuildKit offers.

sam build --use-buildkit
That's it. One flag.

SAM auto-detects which container runtime you have. It defaults to Docker, falls back to Finch if Docker isn't running, and respects any admin-configured preference. Finch supports BuildKit too, so either runtime works.

What you get
BuildKit brings real improvements over the legacy builder:

Parallel stage execution. Multi-stage Dockerfiles build independent stages concurrently instead of sequentially.
Better layer caching. BuildKit tracks dependencies at the file level, not just the layer level. Change one file, rebuild one layer.
Multi-stage build optimizations. BuildKit skips stages that don't contribute to the final output. The legacy builder runs every stage regardless.
Improved cross-architecture support. Building arm64 (Graviton2) images on an x86 machine is more reliable with BuildKit's QEMU integration. Lambda currently supports Graviton2 for arm64 workloads.
Build secrets
SAM CLI v1.159.0 added support for passing BuildKit parameters, including build-time secrets. This lets you pass credentials into a build stage without baking them into a layer. Useful when your Lambda function pulls packages from a private registry during the build.

syntax=docker/dockerfile:1

FROM public.ecr.aws/lambda/python:3.12

RUN --mount=type=secret,id=pip_conf,target=/etc/pip.conf \
pip install -r requirements.txt

COPY app.py ${LAMBDA_TASK_ROOT}
CMD ["app.handler"]
You configure secrets through the Metadata section of your function resource, using DockerBuildExtraParams. SAM passes these parameters straight to docker buildx under the hood.

Resources:
MyFunction:
Type: AWS::Serverless::Function
Properties:
PackageType: Image
Architectures: [x86_64]
Timeout: 10
Metadata:
Dockerfile: Dockerfile
DockerContext: ./src
DockerTag: latest
DockerBuildExtraParams:
- "--secret"
- "id=pip_conf,src=$HOME/.pip/pip.conf"
The secret mounts into the build stage at the path you specify in the Dockerfile, gets used during pip install, and never appears in the final image layers. Different functions can have different build secrets, since the configuration lives in each function's Metadata block.

Tradeoffs and limitations
A few things to keep in mind.

Opt-in only. This doesn't change existing build behavior. If you don't pass --use-buildkit, nothing changes. That's intentional. SAM doesn't break working builds.

Requires Docker or Finch CLI. BuildKit support works by calling the Docker or Finch CLI directly. If your CI environment only has the Docker daemon (no CLI), this won't work. Most environments have both, but check yours.

Dockerfile syntax matters. Some BuildKit features, like secret mounts, require the # syntax=docker/dockerfile:1 parser directive at the top of your Dockerfile. Without it, the build falls back to legacy parsing and you get confusing errors.

Not for ZIP-based functions. This flag only applies to image-based Lambda functions (PackageType: Image). ZIP-based functions don't use Docker at all.

The rule of thumb I like is this: if your Dockerfile is more than a few lines, or you're building for a different architecture, turn on BuildKit. The caching alone will save you time.

WebSocket API Support
The problem
Before this release, SAM had no native resource type for WebSocket APIs. You had two options: write raw CloudFormation, or don't use SAM for that part of your stack.

Here's what a minimal WebSocket API looks like in plain CloudFormation. Three routes ($connect, $disconnect, sendMessage), each backed by a Lambda function:

Resources:
WebSocketApi:
Type: AWS::ApiGatewayV2::Api
Properties:
Name: MyWebSocketApi
ProtocolType: WEBSOCKET
RouteSelectionExpression: $request.body.action

ConnectRoute:
Type: AWS::ApiGatewayV2::Route
Properties:
ApiId: !Ref WebSocketApi
RouteKey: $connect
Target: !Sub integrations/${ConnectIntegration}

ConnectIntegration:
Type: AWS::ApiGatewayV2::Integration
Properties:
ApiId: !Ref WebSocketApi
IntegrationType: AWS_PROXY
IntegrationUri: !Sub arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${ConnectFunction.Arn}/invocations

ConnectPermission:
Type: AWS::Lambda::Permission
Properties:
FunctionName: !Ref ConnectFunction
Action: lambda:InvokeFunction
Principal: apigateway.amazonaws.com
SourceArn: !Sub arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${WebSocketApi}/*/$connect

DisconnectRoute:
Type: AWS::ApiGatewayV2::Route
Properties:
ApiId: !Ref WebSocketApi
RouteKey: $disconnect
Target: !Sub integrations/${DisconnectIntegration}

DisconnectIntegration:
Type: AWS::ApiGatewayV2::Integration
Properties:
ApiId: !Ref WebSocketApi
IntegrationType: AWS_PROXY
IntegrationUri: !Sub arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${DisconnectFunction.Arn}/invocations

DisconnectPermission:
Type: AWS::Lambda::Permission
Properties:
FunctionName: !Ref DisconnectFunction
Action: lambda:InvokeFunction
Principal: apigateway.amazonaws.com
SourceArn: !Sub arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${WebSocketApi}/*/$disconnect

SendMessageRoute:
Type: AWS::ApiGatewayV2::Route
Properties:
ApiId: !Ref WebSocketApi
RouteKey: sendMessage
Target: !Sub integrations/${SendMessageIntegration}

SendMessageIntegration:
Type: AWS::ApiGatewayV2::Integration
Properties:
ApiId: !Ref WebSocketApi
IntegrationType: AWS_PROXY
IntegrationUri: !Sub arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${SendMessageFunction.Arn}/invocations

SendMessagePermission:
Type: AWS::Lambda::Permission
Properties:
FunctionName: !Ref SendMessageFunction
Action: lambda:InvokeFunction
Principal: apigateway.amazonaws.com
SourceArn: !Sub arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${WebSocketApi}/*/sendMessage

Deployment:
Type: AWS::ApiGatewayV2::Deployment
DependsOn:
- ConnectRoute
- DisconnectRoute
- SendMessageRoute
Properties:
ApiId: !Ref WebSocketApi

Stage:
Type: AWS::ApiGatewayV2::Stage
Properties:
ApiId: !Ref WebSocketApi
StageName: prod
DeploymentId: !Ref Deployment
That's twelve resources for three routes. Around 90 lines of YAML. And I left out the Lambda function definitions.

Notice the DependsOn on the Deployment resource. If you forget that, CloudFormation tries to create the deployment before the routes exist, and the stack fails. You have to manage that dependency graph yourself.

That's a lot of ceremony for "connect a WebSocket to some Lambda functions."

What shipped
The new AWS::Serverless::WebSocketApi resource type collapses all of that into this:

Resources:
MyWebSocketApi:
Type: AWS::Serverless::WebSocketApi
Properties:
RouteSelectionExpression: $request.body.action
StageName: prod
Routes:
$connect:
FunctionArn: !GetAtt ConnectFunction.Arn
$disconnect:
FunctionArn: !GetAtt DisconnectFunction.Arn
sendMessage:
FunctionArn: !GetAtt SendMessageFunction.Arn
Compare that to the CloudFormation version. Twelve resources become one. Ninety lines become twelve. The routes, integrations, Lambda permissions, deployment, stage, and resource ordering are all handled by SAM's transform.

You define the routes. SAM generates the rest.

What SAM handles automatically
For each route you declare, SAM creates:

The AWS::ApiGatewayV2::Route resource
The AWS::ApiGatewayV2::Integration wiring the route to your Lambda function
The AWS::Lambda::Permission granting API Gateway invoke access
If you add a Lambda authorizer, the authorizer permission too
SAM also creates the deployment and stage resources, with the correct dependency ordering. No DependsOn blocks to manage.

Full feature parity
This isn't a simplified subset. The new resource type supports everything API Gateway V2 WebSocket offers:

Auth: IAM authorization and Lambda authorizers, per-route or API-wide
Custom domains: Map your WebSocket API to your own domain
Route settings: Configure throttling and logging per route via RouteSettings
Models: Attach request/response models for validation
Stage variables: Pass configuration to your integration through stage variables
Globals: Share configuration across multiple WebSocket APIs using the SAM Globals section
Use cases
WebSocket APIs are the right tool when you need a persistent, bidirectional connection. Common patterns:

Chat applications. Users send and receive messages in real time.
Live dashboards. Push metric updates to connected browsers without polling.
AI/LLM streaming. Stream token-by-token responses from a model back to the client. This one is increasingly common.
IoT command channels. Send commands to devices and receive status updates on the same connection.
If your current approach is a REST API that the client polls every few seconds, a WebSocket API will give you lower latency and lower cost. Fewer requests, fewer Lambda invocations, faster updates.

Tradeoffs and limitations
No local emulation. SAM CLI doesn't support sam local start-api for WebSocket APIs. You can test individual Lambda handlers with sam local invoke, but end-to-end local WebSocket testing isn't available yet. Deploy to a dev stage for integration testing.

No sam local start-websocket. Related to the above, there's no dedicated local command for WebSocket APIs like there is for HTTP APIs with sam local start-api.

For the Agents
If you're using an AI coding agent to build SAM applications, both of these features work out of the box with agent-driven workflows. Your agent can scaffold a WebSocket API or add BuildKit to an existing image-based function without any special setup.

For Kiro, there's an official AWS SAM Power that gives your agent SAM-aware tooling. Install it and your agent gets access to sam_init, sam_build, sam_deploy, sam_logs, and sam_local_invoke as callable tools, plus opinionated project structure guidance.

Here's what a Kiro-assisted WebSocket API scaffold looks like in practice:

You: Create a WebSocket API with connect, disconnect, and sendMessage routes.
Use the SAM Power.

Kiro: [runs sam_init] → creates project structure
[updates template.yaml] → adds AWS::Serverless::WebSocketApi
[creates Lambda handlers] → connect.py, disconnect.py, send_message.py
[runs sam_build] → builds the project
[runs sam_local_invoke] → tests the connect handler locally
The SAM Power also enforces good project structure: separate Lambda handlers in infrastructure/lambda/, proper CodeUri paths, and .aws-sam in your .gitignore. It gets you from idea to deployed WebSocket API without hand-writing boilerplate.

You can install the SAM Power from the Kiro Powers marketplace or add it directly to your project's .kiro/powers/ directory.

Getting Started
Upgrade SAM CLI to get both features:

sam --version

Need v1.156.0 or later for BuildKit, latest for WebSocket APIs

Upgrade via pip

pip install --upgrade aws-sam-cli

Or via Homebrew

brew upgrade aws-sam-cli
For BuildKit, add --use-buildkit to your sam build command. No template changes needed.

For WebSocket APIs, replace your CloudFormation resources with the new AWS::Serverless::WebSocketApi type. If you're starting fresh, the SAM template above is a working starting point.

BuildKit works with sam local for local testing. WebSocket APIs currently support sam deploy for deployment and sam local invoke for testing individual handlers, but full local WebSocket emulation isn't available yet.

Two Features, Zero Breaking Changes
These two features fill gaps that have been open for a while. BuildKit support means sam build finally uses the same build engine as the rest of the container ecosystem. WebSocket API support means you can define a real-time API in SAM the same way you define a REST API. A few lines instead of a hundred.

Neither feature changes existing behavior. Both are additive. Upgrade, try them, and keep building.

The Next Casualty of the GenAI Revolution

Maish Saidel-Keesing — Tue, 05 May 2026 13:25:34 +0000

I was at an event this morning where someone said something that really resonated with me. "The new programming language is English." And you know what? They're right. Jensen Huang said the same thing. Andrej Karpathy has been saying it since 2023. And Marc Andreessen did a whole podcast about it. But while I was sitting there nodding along, something else clicked in my head. Something bigger. Something that I think we're not talking about enough.

We talk a lot about the 'casualties' of GenAI. Students who are terrified they won't have jobs waiting for them after university. Junior developers who are finding it brutally hard to land a position in today's market. The whole "should I even study Computer Science?" existential crisis. These are real, painful, happening-right-now problems.

But here is where it gets interesting. I think there's another casualty coming. One that's a few years out maybe, but it dawned on me this week, and I can't shake it. And it's a big one.

The personal computer.

Your agent doesn't need a MacBook Pro

Let me explain what I mean. We're seeing more and more systems where you provide a prompt to an AI tool and it goes out and does stuff for you. A very good example of this is all these MCP connections, A2A protocols that hook into every system you use and do things on your behalf. They're becoming your personal assistant. Your digital butler. Your "I'll handle it" person.

And the way we interact with these assistants? Usually through some kind of voice interface or through instant messaging. WhatsApp, Telegram, whatever works for you. And these are the tools which I think, once upon a time, we hoped would be the way we'd interact with our computers and phones. Siri. Alexa. Google Assistant. Gemini. God forbid, Cortana. You speak to an entity and that entity does stuff for you.

But they were never really able to deliver on what they were supposed to. I use my Alexa device to pretty much only turn on a timer for when I am cooking, or ask questions about how much 350 degrees Fahrenheit is in Celsius? Until now.

By hooking up multiple tools to some kind of orchestrator that can do everything for you and actually become your personal assistant, you are now able to control pretty much your entire life by talking into your phone or writing a message. Think about that for a second. Projects like OpenClaw and its growing list of alternatives are doing exactly this. They connect to your email, your calendar, your messaging apps, your code repos, your design tools, sometimes securely, sometimes... let's just say it's a work in progress. But the point is, they're turning a simple chat interface into a full-blown command center for your digital life. And they're running on a server somewhere, not on your laptop.

Do I really need a powerful laptop?

I'll give you a personal example. Last week I needed to put together a presentation for an upcoming talk. In the past, I would have fired up PowerPoint on my laptop, spent an hour fiddling with layouts and formatting, maybe opened Photoshop to tweak an image or two. Instead, I described what I wanted to an AI assistant, and it generated the whole deck for me. Slides, structure, speaker notes, the lot. My laptop was barely breaking a sweat because it wasn't doing the work. The agent was.

What I think is going to happen in the not-too-distant future is, we're not going to need all these powerful laptops and desktops anymore. All you'll need is some kind of personal agent running somewhere. It could be a VPS. Could be for example, in the cloud running on Lightsail. Could be on a Mac Mini humming away in a cupboard at home. And that agent will be able to do everything for you.

And a way to interact with it, and we all have that, it's your phone.

I can ask it to design something in a graphic design tool. Actually, scratch that. I don't even need Photoshop or Figma anymore because I can generate those things directly with an AI prompt. I can ask it to build me a website. I can ask it to write code, test it, deploy it. I can ask it to go into Canva and create a presentation. Or just skip Canva entirely and have it generate the slides from scratch.

You see where this is going?

I don't need a powerful computer at my fingertips anymore. In the background, running all my workloads, executing my commands and requests, my agent doing it for me and that machine is running somewhere else. All I need is a simple, almost dumb, interface into something that can listen to me and relay my intent.

Here's another one. I'm writing this very blog post while sitting in the car. I'm not typing. I'm talking. A voice note, dictated into my phone, transcribed into text, and then polished by an AI into something readable. My phone is doing the absolute bare minimum here. Recording audio and sending it somewhere smarter than itself.

English is the new programming language

And let me tell you, it's a hell of a lot quicker than typing it out by hand. The same way it's a hell of a lot quicker to ask an LLM to generate code for me instead of me actually writing and typing that code character by character. I can speak a lot faster than I can type. I can talk without having to put my fingers to use. And usually, I can do it while doing something else entirely. Multi-tasking for the win.

And this is precisely the point. We don't really need to know programming languages anymore (well, not all of us, not for everything) because we delegate our tasks and intent into spoken language, which is exactly what an LLM is amazing at doing. Taking that natural language and transferring it into something else. A command. A JSON payload. An API call. A full-blown application. Karpathy calls it Software 3.0. I think he's onto something.

The numbers are already moving

And here's the thing. The numbers are already starting to tell the story, even if the reasons are different today.

Gartner is projecting PC shipments to decline 10.4% in 2026. IDC is calling it 11.3%. Goldman Sachs says 10%. Right now, the analysts are blaming memory costs and pricing pressures. Fair enough. But I think there's a deeper, more structural shift happening underneath, and coupled with the rising prices in memory, this could actually be a perfect storm.

If my agent can do the heavy lifting running on a remote machine, why do I need a physical computer? A MacBook Pro costs around USD 1,600 today. A VPS with 4 GB memory, 2 vCPUs, 80 GB SSD and 4 TB transfer will run you about USD 24 /month. Over 4 years that's USD 1,152.
That's USD 450 less than the MacBook. And I know the specs are not at all the same, but that's kind of the whole point. Your agent doesn't need a Retina display or a force-touch trackpad. It needs compute, memory, and an internet connection. Oh, and it runs 24/7 in an enterprise datacenter with faaster connectivity than you could dream of, where no one can spill a cup of coffee on it.

And if you need more proof that the industry sees where this is heading, look no further than Apple. They just launched the MacBook Neo at $599. Apple. The company that has historically refused to compete on price. The company whose cheapest laptop was $1,099 just a year ago. They're now selling what is essentially a glorified Chromebook with a fruit logo on it. Why? Because even Apple can see that for most people, a lightweight, always-connected, thin-client device is going to be enough. You don't need an M4 chip to talk to your agent.

But Maish, what about...?

Look, I'm not saying the PC is going to disappear overnight. Gamers will still need their rigs (for now). Video editors, 3D artists, and data scientists will still need local horsepower (for now). Developers who run local Kubernetes clusters will still need their 64GB RAM machines (don't worry, I am not one of K8s groupie).

But for the vast majority of knowledge workers? The person who writes emails, creates presentations, manages spreadsheets, edits documents, and hops between 47 browser tabs? That person doesn't need a $2,000 laptop. That person needs a screen, a microphone, and a connection to their agent.

Some food for thought. We went from mainframes to personal computers because we wanted computing power at our desks. Then we went from desktops to laptops because we wanted that power to be portable. Then from laptops to smartphones because we wanted it in our pockets. And now? Now we might be going from all of that back to... something that looks a lot like a dumb terminal connected to a really smart backend.

History might not repeat itself. But it sure does rhyme.

The question we should be asking

So while the world is debating one set of consequences from AI, I think we're missing a completely different one.

Are we going to see a significant, sustained decline in personal computer sales? Not because of memory prices or economic cycles, but because we fundamentally won't need them anymore?

I think the answer is yes. Maybe not this year. Maybe not next year. But it's coming. And when it does, it won't be a blip on a quarterly earnings report. It'll be a structural shift in how we think about personal computing.

The PC had a good run. But the dumb terminal is making a comeback. And this time, it's got a really smart backend.

How to Prevent AI Agent Reasoning Loops from Wasting Tokens

Elizabeth Fuentes L — Mon, 04 May 2026 23:00:00 +0000

AI agent reasoning loops occur when an agent calls the same tool repeatedly without making progress, convinced that one more attempt will produce the perfect answer. The agent wastes tokens, time, and money without delivering a result. This post shows how to detect and block repeated calls, validated with a demo where ambiguous tools caused 14 calls vs clear SUCCESS states that stopped in 2.

This demo uses Strands Agents. The patterns — debounce hooks, clear tool states, and call limits — are framework-agnostic and apply to any agent that supports lifecycle hooks, including LangGraph, AutoGen, and CrewAI.

Working code: github.com/aws-samples/sample-why-agents-fail

Series: Why AI Agents Fail

Context Window Overflow — Memory Pointer Pattern for large data
MCP Tools That Never Respond — Async pattern for slow external APIs
AI Agent Reasoning Loops (this post) — Detect and block repeated tool calls

The Problem: Agents That Overthink

AI agent reasoning loops occur when an agent calls the same tool repeatedly without making progress, wasting tokens and time without delivering a result. AI agents don't just fail by giving wrong answers; they fail by never finishing. Research shows agents get trapped in reasoning loops where they call the same tool repeatedly, convinced that "one more step" will produce the perfect answer.

The Decoder (Jan 2025) found that even with unlimited computing power, overthinking leads to poor decisions. Incomplete understanding of the world causes compounding errors. Each additional reasoning step makes things worse, not better.

Particula (Jul 2025) (community observation) documented an extreme case: an agent executed 847 reasoning steps at $47 per minute and never delivered a final answer. It kept refining logic, questioning conclusions, and requesting more data in an endless cycle.

CodiesHub (Dec 2025) (community observation) identifies the root causes:

Unclear goals — agent doesn't know when the task is complete
Ambiguous tool feedback — tools don't return clear success/failure states
No stopping criteria — no hard limits on iterations or time

Why Loops Happen: Ambiguous Tool Feedback

Ambiguous tool feedback occurs when tools return partial results or suggest "more data may be available" without clear terminal states, causing agents to retry the same call. Tools that return partial results or suggest "more data may be available" cause agents to retry:

@tool
def search_flights(origin: str, destination: str, max_price: float) -> str:
    """Search for flights under a max price."""
    prices = [random.randint(200, 800) for _ in range(3)]
    matching = [p for p in prices if p <= max_price]
    # The problem: "More results may be available" signals the LLM to retry
    # The agent interprets this as "I should search again to find a better deal"
    return (
        f"Found {len(matching)} flights under ${max_price} "
        f"(out of {len(prices)} checked). "
        "Note: More results may be available. Prices change frequently."
    )

That "Note: More results may be available" triggers the loop. The agent sees it and thinks: "Maybe if I search again, I'll find a better deal." It retries with the same parameters, gets similar results, and the cycle continues.

Solution 1: Debounce Hook with Strands

Strands Hooks intercept the agent lifecycle at any point. A Debounce Hook uses BeforeToolCallEvent to detect duplicate calls before they execute:

from strands.hooks import HookProvider, BeforeToolCallEvent, BeforeInvocationEvent

class DebounceHook(HookProvider):
    def __init__(self, window_size=3):
        self.call_history = []       # Tracks (tool_name, input) pairs
        self.window_size = window_size  # Sliding window size for duplicate detection
        self.blocked_count = 0

    def register_hooks(self, registry):
        # BeforeInvocationEvent fires once at the start of each agent.invoke() call
        registry.add_callback(BeforeInvocationEvent, self.reset)
        # BeforeToolCallEvent fires before every tool execution — this is where we intercept
        registry.add_callback(BeforeToolCallEvent, self.check_duplicate)

    def reset(self, event):
        # Clear history at the start of each invocation so limits don't bleed across calls
        self.call_history = []

    def check_duplicate(self, event):
        # Build a fingerprint from tool name + exact inputs
        key = (event.tool_use["name"], str(event.tool_use["input"]))
        recent = self.call_history[-self.window_size:]

        if recent.count(key) >= 2:
            # cancel_tool is a native Strands API: blocks execution and returns this message to the LLM
            event.cancel_tool = "BLOCKED: Duplicate call detected"
            self.blocked_count += 1
            return

        self.call_history.append(key)

agent = Agent(tools=[search_flights], hooks=[DebounceHook()])

The hook tracks the last 3 tool calls. If the same tool with the same parameters appears twice, the third attempt is blocked via event.cancel_tool, a native Strands API that prevents tool execution and returns an error message to the LLM.

Solution 2: Clear SUCCESS/FAILED States

Tools that return explicit terminal states help agents know when to stop:

@tool
def book_hotel(hotel: str, guest: str, nights: int) -> str:
    """Book a hotel room. Returns clear SUCCESS or FAILED.

    Returns:
        SUCCESS: Booking confirmed with ID
        FAILED: Booking failed with reason
    """
    if random.random() > 0.15:
        conf = f"HT{random.randint(10000, 99999)}"
        price = random.randint(150, 350)
        return f"SUCCESS: Booking {conf} confirmed — {guest} at {hotel}, {nights} nights, ${price * nights} total"
    return f"FAILED: {hotel} fully booked"

When the agent receives "SUCCESS: Booking HT79265 confirmed", it knows the task is done. No ambiguity, no extra calls.

Solution 3: Hard Limits with LimitToolCounts

CodiesHub recommends: "Iterations, tokens, time, spend are non-negotiable." Strands provides LimitToolCounts in the Hooks Cookbook — a hook that caps tool calls per invocation:

from strands.hooks import HookProvider, BeforeToolCallEvent, BeforeInvocationEvent
from threading import Lock

class LimitToolCounts(HookProvider):
    """Limits tool calls per invocation. From Strands Hooks Cookbook."""

    def __init__(self, max_tool_counts: dict[str, int]):
        # Per-tool call budgets: {"search_flights": 2} means max 2 searches per invocation
        self.max_tool_counts = max_tool_counts
        self.tool_counts = {}
        self._lock = Lock()  # Thread-safe for concurrent tool calls in Swarm scenarios

    def register_hooks(self, registry):
        registry.add_callback(BeforeInvocationEvent, self.reset_counts)
        registry.add_callback(BeforeToolCallEvent, self.intercept_tool)

    def reset_counts(self, event):
        # Reset per invocation so limits apply per task, not per agent lifetime
        with self._lock:
            self.tool_counts = {}

    def intercept_tool(self, event):
        tool_name = event.tool_use["name"]
        with self._lock:
            max_count = self.max_tool_counts.get(tool_name)
            count = self.tool_counts.get(tool_name, 0) + 1
            self.tool_counts[tool_name] = count

            if max_count and count > max_count:
                # Hard ceiling: block the call and tell the LLM explicitly to stop
                event.cancel_tool = f"Tool '{tool_name}' limit reached. DO NOT CALL ANYMORE."

# Enforce a hard limit of 2 flight searches per booking task — prevents runaway costs
limit_hook = LimitToolCounts(max_tool_counts={"search_flights": 2})
agent = Agent(tools=[search_flights], hooks=[limit_hook])

Even if the agent wants to search 10 times, it's capped at 2. Hard ceiling, predictable costs.

Demo Results

We tested with a travel booking agent that searches for flights and hotels:

Scenario	Tool Calls	Time	Result
Ambiguous Feedback	14	21s	Agent retried organically — "prices may change" caused loops
DebounceHook	12	15s	Reduced retries but some variation in parameters
Clear SUCCESS States	2	4s	Agent stopped immediately after SUCCESS
LimitToolCounts	6 (2 blocked)	6s	Hard ceiling enforced — no runaway

The contrast is dramatic: 14 calls with ambiguous tools vs 2 calls with clear SUCCESS states. That is a 7x difference caused purely by tool feedback design.

When to Use Each Solution

DebounceHook — prevents duplicate calls with identical parameters. Use when tools are idempotent and retrying with the same input is wasteful.

Clear SUCCESS/FAILED states — the simplest solution. Design tools to return explicit terminal states. The agent knows when to stop.

LimitToolCounts — hard ceiling on tool calls per invocation. Use in production to prevent runaway costs regardless of tool design. From the Strands Hooks Cookbook.

All three together — defense in depth. Clear states prevent most loops, debounce catches duplicates, and hard limits guarantee bounded execution.

Try It Yourself

You need Python 3.9+, uv, and an OpenAI API key.

git clone https://github.com/aws-samples/sample-why-agents-fail
cd sample-why-agents-fail/stop-ai-agents-wasting-tokens/03-reasoning-loops-demo
uv venv && uv pip install -r requirements.txt
export OPENAI_API_KEY="your-key-here"

uv run python test_reasoning_loops.py   # Runs all 4 scenarios

Or open test_reasoning_loops.ipynb in Jupyter, JupyterLab, VS Code, or your preferred notebook environment.

Key Takeaways

Ambiguous tool feedback causes organic loops — "more results may be available" makes agents retry
14 calls vs 2 calls — clear SUCCESS states reduce calls by 7x in our demo
Hooks intercept before execution — BeforeToolCallEvent.cancel_tool blocks the call before the tool runs. The DebounceHook is ~30 lines of code
Hard limits are mandatory — every agent needs caps on iterations, time, and spend
847 steps at $47/min was documented (Particula, community observation) — unbounded agents burn money without delivering answers

Frequently Asked Questions

Why do AI agents repeat the same tool call?

Agents repeat tool calls when tool responses contain ambiguous feedback such as "more results may be available" or "prices change frequently." The LLM interprets these signals as a reason to retry, expecting different or better results. Without clear terminal states (SUCCESS/FAILED), the agent has no way to know the task is complete.

What is a DebounceHook and how does it prevent reasoning loops?

A DebounceHook tracks recent tool calls in a sliding window. When the same tool is called with identical parameters more than a set threshold (typically 2 times within a window of 3), the hook blocks the call using event.cancel_tool before the tool executes. The LLM receives a "BLOCKED: Duplicate call" message and must try a different approach. In Strands Agents, this is about 30 lines of code using the HookProvider API.

How do clear SUCCESS/FAILED states reduce tool calls?

When a tool returns "SUCCESS: Booking HT79265 confirmed," the LLM recognizes the task is complete and stops calling that tool. Ambiguous responses such as "Found 2 flights, more may be available" lack this signal, causing the agent to retry. In our demo, clear states reduced tool calls from 14 to 2, a 7x improvement.

References

Research

Language models can overthink — The Decoder, Jan 2025
How many reasoning steps do AI agents need — Particula (community observation), Jul 2025
How to Prevent Infinite Loops and Spiraling Costs — CodiesHub (community observation), Dec 2025

Implementation

Strands Hooks — Lifecycle event interception and tool cancellation

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.