Forem: Elizabeth Fuentes L

Context window overflow occurs when an AI agent's tool outputs exceed the token limit the large language model (LLM) can process at once. The agent doesn't crash; it silently truncates data, loses earlier context, or produces incomplete results. This post shows how the Memory Pointer Pattern fixes it: from single-agent to multi-agent coordination where 145KB of data never enters any LLM context.

This demo uses Strands Agents. The Memory Pointer Pattern is framework-agnostic and can be applied with LangGraph, AutoGen, or other agent frameworks that support tool context.

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

Series: Why AI Agents Fail

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

The Problem: Agents Can't Handle Large Tool Outputs

When an AI agent calls a tool that returns large data (server logs, database results, file contents), the response can overflow the LLM's context window. The agent doesn't crash with a clear error. It silently degrades: truncating data, losing context, or failing to complete the task.

Research from IBM (Solving Context Window Overflow in AI Agents, 2025) quantifies this:

In Materials Science workflows, tool outputs can reach 2M+ elements
Traditional approach consumed 20,822,181 tokens and failed
The same workflow with memory pointers used 1,234 tokens and succeeded
That's a reduction of over 16,000x in this workflow

Community observation (Context Window Limits Explained, Airbyte 2025) confirms teams discover these limits "the hard way" through silent errors. The agent appears to work but produces incomplete or wrong results.

The concept of passing references instead of raw data has also been validated in multi-agent settings. Research from Amazon (Towards Effective GenAI Multi-Agent Collaboration, 2024) introduces "payload referencing," where agents exchange pointers to shared data instead of embedding large payloads in messages. This improved performance on code-intensive tasks by 23% and achieved 90% end-to-end goal success rates in enterprise benchmarks. This is exactly what we implement below with Strands Swarm.

Why This Happens

When the tool output is small (a few KB), this works fine. But when a tool returns 200KB of server logs:

The full output gets injected into the conversation
The LLM's context window fills up
Older context (including the original question) gets pushed out
The LLM can't reason about the data because it can't see it all
The agent either fails or produces incomplete answers

Solution 1: Single Agent with Strands ToolContext

The first approach uses agent.state, a native key-value store scoped to each agent instance. Tools write large data there via ToolContext and return a short pointer string to the context:

from strands import Agent, tool, ToolContext

# context=True injects ToolContext as the last parameter — required to access agent.state
@tool(context=True)
def fetch_application_logs(app_name: str, tool_context: ToolContext, hours: int = 24) -> str:
    """Fetch application logs. Returns a memory pointer for large datasets."""
    logs = generate_logs(app_name, hours)  # Could be 200KB+

    if len(str(logs)) > 20_000:  # Threshold: store externally above 20KB
        pointer = f"logs-{app_name}"
        # Store the full payload in agent.state — it never enters the LLM context
        tool_context.agent.state.set(pointer, logs)
        # Return only the pointer key (52 bytes) — this is all the LLM sees
        return f"Data stored as pointer '{pointer}'. Use analyze tools to query it."
    return str(logs)  # Small enough to return directly

@tool(context=True)
def analyze_error_patterns(data_pointer: str, tool_context: ToolContext) -> str:
    """Analyze errors — resolves pointer from agent.state."""
    # Retrieve the full dataset from agent.state using the pointer key
    data = tool_context.agent.state.get(data_pointer)
    errors = [e for e in data if e["level"] == "ERROR"]
    # Return a summary (not raw data) — keeps the response small
    return f"Found {len(errors)} errors across {len(set(e['service'] for e in errors))} services"

The LLM never sees the 200KB. It only sees "Data stored as pointer 'logs-payment-service'" (52 bytes). The next tool reads the full data from agent.state and returns a summary. Strands handles this natively, with no global dicts, no hashlib, no external infrastructure.

Single Agent Results

Metric	Without Pointers	With Memory Pointers
Data in context	214KB (full logs)	52 bytes (pointer)
Agent behavior	Truncates/fails	Processes all data
Errors detected	Partial	Complete (all services)

Solution 2: Multi-Agent with Strands Swarm

A single agent works for linear pipelines. But real-world incident response involves specialized roles: someone fetches data, someone analyzes it, someone writes the report. Strands Swarm coordinates multiple agents autonomously: define agents with different tools, and the Swarm handles handoffs.

This is the same "payload referencing" pattern from the Amazon multi-agent collaboration paper. Agents exchange pointers to shared data instead of passing raw payloads. The difference is that Strands Swarm handles the coordination automatically, and provides invocation_state as the official API for sharing data across agents.

from strands import Agent, tool, ToolContext
from strands.multiagent import Swarm

# invocation_state is a dict shared across all agents in the Swarm — the cross-agent store
@tool(context=True)
def fetch_application_logs(app_name: str, tool_context: ToolContext, hours: int = 6) -> str:
    logs = generate_logs(hours)  # 145KB+
    pointer = f"logs-{app_name}"
    # Store in invocation_state so all downstream agents can access it without re-fetching
    tool_context.invocation_state[pointer] = logs
    # Only the pointer string travels through the LLM context to the next agent
    return f"Stored as '{pointer}'. Hand off to analyzer."

@tool(context=True)
def analyze_error_patterns(logs_pointer: str, tool_context: ToolContext) -> str:
    # Resolve the pointer to the full dataset — no LLM context consumed
    logs = tool_context.invocation_state.get(logs_pointer)
    errors = [l for l in logs if l["level"] == "ERROR"]
    result = {"total_errors": len(errors)}  # additional fields omitted for brevity
    # Store analysis results as another pointer for the reporter agent
    tool_context.invocation_state["error_analysis"] = result
    return json.dumps(result)

# Each agent has a focused role; the Swarm decides the handoff order autonomously
collector = Agent(name="collector", tools=[fetch_application_logs], model=MODEL)
analyzer = Agent(name="analyzer", tools=[analyze_error_patterns, detect_latency_anomalies], model=MODEL)
reporter = Agent(name="reporter", tools=[generate_incident_report], model=MODEL)

swarm = Swarm([collector, analyzer, reporter], entry_point=collector)
result = swarm("Fetch logs, analyze, and generate incident report.")

The Swarm automatically:

Starts with the collector, which fetches 145KB of logs and stores them in invocation_state
The collector hands off to the analyzer with the pointer "logs-payment-service"
The analyzer runs error and latency analysis, stores results in invocation_state, hands off to the reporter
The reporter generates the final incident report

No orchestration code or manual handoff logic is needed. Each agent has its own tools and the Swarm figures out the flow from the agent descriptions and the task. All data sharing happens via tool_context.invocation_state, the same ToolContext API used in single-agent, with a different store.

Swarm Results

Status: COMPLETED
Agents: collector → analyzer → reporter
Time: ~14s
Shared store:
  logs-payment-service: 145,310 bytes
  error_analysis: 135 bytes
  latency_analysis: 70 bytes

145KB of logs processed by three agents. None of it ever entered any LLM context window.

Follow-up Investigation

After the swarm completes, the data stays in the shared store. A separate investigator agent can drill into specific services without re-fetching:

# The investigator reuses invocation_state populated by the swarm — no data re-fetch needed
investigator = Agent(
    name="investigator",
    tools=[get_error_details, analyze_error_patterns],
    model=MODEL,
)

# Each question resolves the pointer from invocation_state and runs analysis in-memory
investigator("Which service had the most errors?")
investigator("Show me the error logs for cache-layer")
investigator("What status codes are those errors returning?")
# All queries read from the same 145KB already in invocation_state — no re-fetch, no context overflow

When to Use Each Approach

Single agent + agent.state — linear pipelines where one agent handles fetch + analyze + report. Use ToolContext to access tool_context.agent.state from tools.

Swarm + invocation_state — specialized roles, complex workflows, or when you want autonomous coordination. Use ToolContext to access tool_context.invocation_state — the official Strands API for multi-agent data sharing. The Swarm handles handoffs, timeouts, and repetitive handoff detection.

Both — use SlidingWindowConversationManager as additional protection. It automatically trims conversation history and handles ContextWindowOverflowException with retry.

These approaches are part of context engineering for AI agents: the practice of deciding what information enters the LLM's context window and when.

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/01-context-overflow-demo
uv venv && uv pip install -r requirements.txt
export OPENAI_API_KEY="your-key-here"

uv run python test_context_overflow.py   # Single-agent: 4 scenarios
uv run python swarm_demo.py              # Multi-agent: Collector → Analyzer → Reporter

Or open test_context_overflow.ipynb in Kiro, VS Code, or your preferred notebook environment.

Key Takeaways

Context overflow is silent — agents don't crash, they produce wrong results
Memory pointers solve it — store large data externally, pass references
>16,000x token reduction — validated by IBM Research on the Materials Science benchmark
Single-agent uses agent.state — @tool(context=True) + ToolContext to store and retrieve data outside context
Multi-agent uses invocation_state — same ToolContext API, shared across all agents in the Swarm. No orchestration code needed
Data persists for follow-up — after the pipeline completes, stored data is available for investigation without re-fetching

Frequently Asked Questions

Why do AI agents run out of context?

AI agents run out of context when tool responses are injected directly into the LLM conversation history. Each response consumes tokens. When cumulative tool outputs exceed the model's context window limit, the LLM loses earlier context, truncates data, or fails entirely. This happens silently: the agent appears to work but produces incomplete or wrong results.

What is the Memory Pointer Pattern for AI agents?

The Memory Pointer Pattern stores large tool outputs (logs, datasets, query results) in external state instead of the LLM context window. Tools return a short reference key (the "pointer") that subsequent tools use to retrieve the full data. IBM Research validated this pattern with a reduction of over 16,000x on the Materials Science benchmark.

How does agent.state differ from invocation_state in Strands Agents?

agent.state is scoped to a single agent instance. Use it for linear pipelines where one agent handles all steps. invocation_state is shared across all agents in a Strands Swarm. Use it when multiple specialized agents need to exchange data without passing large payloads through the LLM context.

Can I use the Memory Pointer Pattern with LangGraph or other frameworks?

Yes. The pattern requires two capabilities: a shared key-value store accessible from tools, and the ability to pass short reference strings through the LLM context. LangGraph provides this through its state management, AutoGen through shared memory, and CrewAI through task context. The Strands implementation uses ToolContext as the native API.

References

Research

Solving Context Window Overflow in AI Agents — IBM Research, Nov 2025
Towards Effective GenAI Multi-Agent Collaboration — Amazon, Dec 2024
Context Window Limits Explained — Airbyte blog (community observation), Dec 2025
Efficient On-Device Agents via Adaptive Context Management — Nov 2025

Implementation

Strands Agent State — ToolContext and agent.state
Strands Swarm — Multi-agent orchestration
Strands Conversation Management — Sliding window and context overflow

Have you hit context window limits in your agents? What strategies worked for you? Share in the comments.

Next in this series: MCP Tools That Never Respond — async patterns for slow external APIs.

All code in this series is open source under the MIT-0 License. Star the repository to follow updates.

Gracias!

🇻🇪Dev.to - Linkedin - GitHub - Twitter - Instagram - Youtube

[Boost]

Elizabeth Fuentes L — Thu, 09 Apr 2026 13:07:05 +0000

Memory-Aware Shopping Agents with Strands Agents and Mem0 - DEV Community

A research paper from Alibaba proposes a two-stage e-commerce agent that remembers customer...

dev.to

[Boost]

Elizabeth Fuentes L — Tue, 07 Apr 2026 22:41:12 +0000

Vinicius Senger

Apr 7

Goodbye localhost: why Quarkus + Vanilla JS + AWS Lambda + DynamoDB Is the Fastest Path from Idea to Production

#java #aws #quarkus #serverless

Comments 2

8 min read

Guardrails para Agentes de IA que se Autocorrigen en Lugar de Bloquear

Elizabeth Fuentes L — Tue, 07 Apr 2026 20:31:25 +0000

La mayoría de los guardrails para agentes hacen una sola cosa: bloquear. El agent choca con una regla, el flujo se detiene y el usuario tiene que intervenir. Agent Control añade una segunda opción: steer — el agent recibe instrucciones correctivas, se autocorrige y completa la tarea sin intervención humana.

Los guardrails para agentes hoy son binarios: permitir o denegar. Cuando un agent viola una política, la respuesta típica es bloquear la acción y mostrar un error. Esto funciona para restricciones estrictas (cumplimiento PCI, bloqueos regulatorios), pero genera fricción en reglas donde el agent podría resolver el problema por sí mismo: ajustar un parámetro, redactar datos sensibles o reformatear una salida.

Agent Control es un plano de control en tiempo de ejecución de código abierto que introduce steer controls junto con los bloqueos tradicionales. Los steer controls devuelven instrucciones correctivas mediante Guide() — el agent reintenta con la corrección aplicada y completa la tarea. Las reglas residen en un servidor, no en el código — se actualizan vía API o dashboard sin necesidad de redesplegar el agent.

Este artículo muestra cómo funciona Agent Control usando una demo de reservas construida con Strands Agents. Comparamos dos enfoques sobre el mismo escenario: hooks que bloquean vs Agent Control que corrige. Hooks y Agent Control son complementarios — usa hooks para bloqueos estrictos, steer para correcciones.

Resumen de la Serie

Este es un artículo adicional en la serie sobre cómo detener las alucinaciones de agentes de IA — añadido tras el lanzamiento de Agent Control:

RAG vs Graph-RAG — Los grafos de conocimiento previenen agregaciones alucinadas
Semantic Tool Selection — El filtrado vectorial reduce las elecciones incorrectas de herramientas
AI Agent Guardrails — Reglas simbólicas que el LLM no puede eludir
Bonus: Agent Control (este artículo) — Steer en lugar de block

El Problema: Bloquear Detiene el Flujo

Los Strands Hooks aplican reglas a nivel de tool. Cuando el agent llama a book_hotel(guests=15) y el máximo es 10, el hook establece cancel_tool y el agent recibe un mensaje de bloqueo:

class MaxGuestsHook(HookProvider):
    def check(self, event: BeforeToolCallEvent) -> None:
        guests = event.tool_use["input"].get("guests", 1)
        if guests > 10:
            event.cancel_tool = f"BLOCKED: {guests} guests exceeds maximum of 10"

El agent entonces le dice al usuario:

"El Grand Hotel tiene una capacidad máxima de 10 huéspedes. ¿Le gustaría ajustar el número de huéspedes?"

El flujo se detiene. El usuario debe responder. Para un asistente de reservas que maneja cientos de solicitudes, cada operación bloqueada es un punto de fricción.

La Solución: Steer en Lugar de Block

Agent Control es un plano de control en tiempo de ejecución de código abierto que evalúa las entradas y salidas del agent contra políticas gestionadas en el servidor. Se integra con Strands como un Plugin — el mismo punto de extensión que los Hooks, pero con dos diferencias clave:

Las reglas residen en un servidor — se modifican vía API o dashboard sin tocar el código del agent
Los steer controls devuelven Guide() en lugar de bloquear — el agent reintenta con instrucciones correctivas

Cómo Funciona Steer

Cuando el LLM genera una salida que menciona "15 guests", el AgentControlSteeringHandler la evalúa contra los controls definidos en el servidor:

El LLM genera: "I will book Grand Hotel for 15 guests from May 1 to May 3"
Agent Control evalúa la salida del LLM → el regex coincide con "15 guest"
El steer control se activa → devuelve Guide("reduce to 10, inform the user")
El LLM reintenta con la guía → llama a book_hotel(guests=10)
La reserva se completa → se informa al usuario sobre el ajuste

El agent responde:

"La capacidad máxima del Grand Hotel es de 10 huéspedes, así que he ajustado la reserva en consecuencia. ID de reserva: BK002."

Sin intervención del usuario. Sin reintentos manuales. El flujo se completó.

Implementación: Misma Consulta, Dos Enfoques

Las tools son idénticas — funciones de reserva limpias sin lógica de validación:

from strands import tool

@tool
def book_hotel(hotel: str, check_in: str, check_out: str, guests: int = 1) -> str:
    """Book a hotel room."""
    return f"SUCCESS: Booking {booking_id} — {hotel}, {guests} guests, {check_in} to {check_out}"

@tool
def process_payment(amount: float, booking_id: str) -> str:
    """Process payment for a booking."""
    return f"SUCCESS: Processed ${amount:.2f} for {booking_id}"

@tool
def confirm_booking(booking_id: str) -> str:
    """Confirm a booking."""
    return f"SUCCESS: Confirmed {booking_id}"

Las tools NO aplican la regla de máximo de huéspedes. Eso es responsabilidad de la capa de guardrails.

Test 1 — Hooks (Block)

from strands import Agent
from strands.hooks import HookProvider, HookRegistry, BeforeToolCallEvent

class MaxGuestsHook(HookProvider):
    def __init__(self):
        self.blocked = 0
    def register_hooks(self, registry: HookRegistry) -> None:
        registry.add_callback(BeforeToolCallEvent, self.check)
    def check(self, event: BeforeToolCallEvent) -> None:
        if event.tool_use["name"] != "book_hotel":
            return
        guests = event.tool_use["input"].get("guests", 1)
        if guests > 10:
            self.blocked += 1
            event.cancel_tool = f"BLOCKED: {guests} guests exceeds maximum of 10"

agent = Agent(model=MODEL, tools=[book_hotel, process_payment, confirm_booking],
              hooks=[MaxGuestsHook()])
agent("Book Grand Hotel for 15 guests from 2026-05-01 to 2026-05-03")

Resultado:

Hook blocked: 1 call(s)
Agent: "The Grand Hotel has a maximum capacity of 10 guests.
        Would you like to adjust?"
Outcome: BLOCKED — user must intervene

Test 2 — Agent Control (Steer)

Los controls se definen en el servidor de Agent Control — no en el código:

# setup_controls.py — run once
control = {
    "name": "steer-max-guests",
    "definition": {
        "scope": {"step_types": ["llm"], "stages": ["post"]},
        "selector": {"path": "output"},
        "evaluator": {"name": "regex", "config": {"pattern": r"(1[1-9]|[2-9]\d)\s*guest"}},
        "action": {
            "decision": "steer",
            "message": "Guest count exceeds maximum of 10",
            "steering_context": {
                "message": "Reduce the guest count to 10, retry the booking, "
                           "and inform the user that the maximum capacity is 10."
            }
        }
    }
}

El agent usa AgentControlPlugin + AgentControlSteeringHandler — ambos como Plugins de Strands:

from agent_control.integrations.strands import AgentControlPlugin, AgentControlSteeringHandler
import agent_control

agent_control.init(agent_name="booking-guardrails-demo")

plugin = AgentControlPlugin(agent_name="booking-guardrails-demo",
                            event_control_list=[BeforeToolCallEvent, AfterToolCallEvent])
steering = AgentControlSteeringHandler(agent_name="booking-guardrails-demo")

agent = Agent(model=MODEL, tools=[book_hotel, process_payment, confirm_booking],
              plugins=[plugin, steering])
agent("Book Grand Hotel for 15 guests from 2026-05-01 to 2026-05-03")

Resultado:

Steered: 1 time(s)
Agent: "The maximum capacity for the Grand Hotel is 10 guests,
        so I have adjusted the booking accordingly. Booking ID: BK002."
Outcome: SELF-CORRECTED — booking completed

Resultados

Misma consulta. Mismas tools. Mismo modelo. Solo cambia el guardrail.

Enfoque	Tiempo	Resultado
Test 1 — Hooks (`cancel_tool`)	~4s	BLOCKED — el agent pide al usuario que ajuste
Test 2 — Agent Control (steer)	~6s	Autocorregido — reserva completada con 10 huéspedes

Ambos aplican la misma regla. La diferencia es lo que ocurre cuando la regla se viola — no qué enfoque es "mejor". Los hooks son más rápidos y sencillos (Python puro, sin servidor). Agent Control añade latencia (steer → reintento) pero completa el flujo sin intervención del usuario. Elige según la regla, no según la tecnología.

Cuándo Usar Cada Enfoque

Enfoque	Mejor para
Hooks (block)	Reglas que DEBEN bloquear estrictamente — sin alternativa posible (p. ej., pago antes de confirmación, cumplimiento PCI)
Agent Control (steer)	Reglas donde el agent PUEDE autocorregirse — ajustar parámetros, redactar PII, corregir formato
Agent Control (deny)	Igual que hooks pero gestionado en un servidor — cambiar reglas sin redesplegar código

Son complementarios, no competidores. Los hooks son más sencillos (Python puro, sin servidor, sin sobrecarga de latencia). Agent Control es más flexible (gestionado en servidor, steer + deny, actualizaciones en tiempo de ejecución sin redespliegue). Muchos sistemas en producción usan ambos:

Hooks para reglas de cumplimiento que nunca deben eludirse — verificación de pagos, bloqueos regulatorios, PII en parámetros de tools
Agent Control (deny) para los mismos bloqueos estrictos pero gestionados centralmente en múltiples agents — actualización vía dashboard, sin redespliegue
Agent Control (steer) para reglas flexibles donde la autocorrección es preferible — ajustes de capacidad, redacción de PII en salidas, formato de fechas

Dos Formas de Definir Controls

Modo	Mejor para
Server (esta demo)	Equipos, producción, gestión vía dashboard — los controls residen en el servidor de Agent Control
Local YAML	Prototipado rápido — controls definidos en `controls.yaml`, sin necesidad de servidor

Consulta la documentación de Agent Control para más detalles sobre ambos modos.

Por Qué Strands lo Hace Sencillo

Tanto Hooks como Agent Control se integran con un solo cambio de línea:

# Hooks — block violations (existing Strands API):
agent = Agent(tools=[...], hooks=[MaxGuestsHook()])

# Agent Control — steer violations (plugin API):
agent = Agent(tools=[...], plugins=[AgentControlPlugin(...), AgentControlSteeringHandler(...)])

Sin orquestación personalizada. Sin lógica de reintentos. Strands gestiona el ciclo de vida — los hooks interceptan antes de las llamadas a tools, el steering evalúa después de la salida del modelo, y Guide() activa el reintento automático con instrucciones correctivas.

Strands Hooks Documentation
Strands Steering Documentation
Agent Control Plugin for Strands

Puntos Clave

Los hooks bloquean violaciones — efectivo pero detiene el flujo y requiere intervención del usuario
Agent Control redirige las violaciones — el agent se autocorrige y completa la tarea
Los steer controls devuelven Guide() con instrucciones correctivas — el LLM reintenta con la corrección aplicada
Los controls residen en un servidor — se actualizan las reglas vía API o dashboard sin tocar el código del agent
Ambos enfoques aplican la misma regla (máximo 10 huéspedes) — la diferencia es lo que ocurre cuando la regla se viola
Hooks para bloqueos estrictos, Agent Control para autocorrección — usa ambos cuando sea necesario

Ejecútalo Tú Mismo

git clone https://github.com/aws-samples/sample-why-agents-fail
cd stop-ai-agent-hallucinations/05-agent-control-demo

# Start Agent Control server (see setup instructions)
# https://github.com/agentcontrol/agent-control

# Install and run
uv venv && uv pip install -r requirements.txt
uv run setup_controls.py
uv run test_hooks_vs_control.py

Puedes cambiar a cualquier proveedor compatible con Strands — consulta Strands Model Providers para la configuración.

Referencias

Investigación

ATA: Autonomous Trustworthy Agents (2024) — Patrones de fallo en guardrails
Enhancing LLMs through Neuro-Symbolic Integration — Razonamiento neural + simbólico

Strands Agents

Strands Agents with Agent Control — Anuncio en blog
Agent Control Plugin — Documentación de integración
Strands Hooks — BeforeToolCallEvent, cancel_tool
Strands Steering — Guide, Proceed, SteeringHandler
Strands Model Providers — Cambiar a Amazon Bedrock, Anthropic, Ollama

Agent Control

Agent Control GitHub — Código abierto, Apache 2.0
Agent Control Docs — Configuración del servidor y referencia de API

Código

Code Repository

Multichannel AI Agent: Shared Memory Across Messaging Platforms

Elizabeth Fuentes L — Mon, 06 Apr 2026 07:00:00 +0000

Build an AI chatbot that remembers users across WhatsApp and Instagram using Amazon Bedrock AgentCore, unified identity, and DynamoDB message buffering

You send a video on WhatsApp. You switch to Instagram. You ask about the video. The chatbot has no idea what you are talking about. Most AI chatbots treat every channel as a separate conversation with no shared context, no shared memory, and no continuity. I built a multichannel AI agent that solves this problem using Amazon Bedrock AgentCore.

One deployment serves both WhatsApp and Instagram with shared memory. The agent remembers your name, your photos, your videos, and your preferences regardless of which channel you write from.

Assumes familiarity with AWS CDK, AWS Lambda, and WhatsApp/Instagram API concepts. Deployment takes approximately 15 minutes per stack.

What does a multichannel AI agent with shared memory look like?

Here is the agent processing different media types on WhatsApp and responding on Instagram with full context.

How does the AI agent process voice notes on WhatsApp?

The agent transcribes voice messages automatically using Amazon Transcribe and responds based on the spoken content. The transcription is stored in memory so the agent can reference it in future conversations.

How does the AI agent analyze videos on WhatsApp?

Send a video and the agent uploads it to TwelveLabs for visual and audio analysis. It describes the content in detail and stores a reference ID so you can ask follow-up questions about the same video later.

How does the AI agent analyze images on WhatsApp?

Send a photo and the agent describes the visual content, answers questions about it, and stores the description in long-term memory. You can ask about the same image days later and the agent recalls the details.

How does cross-channel memory work between WhatsApp and Instagram?

Switch to Instagram. The agent recognizes you by name, knows your preferences, and remembers what you shared on WhatsApp. This works because both channels share the same actor_id in AgentCore Memory.

How does the architecture work?

The project uses three independent AWS CDK stacks that share configuration through AWS Systems Manager Parameter Store:

Stack	Purpose	Integration path
Stack 00	AI agent with persistent memory	Amazon Bedrock AgentCore Runtime + Memory
Stack 01	WhatsApp only	AWS End User Messaging Social (SNS-based)
Stack 02	WhatsApp + Instagram	Amazon API Gateway webhook, single endpoint for both platforms

The agent uses AgentCore Memory with two layers of persistence:

Short-term memory: Conversation turns within a session. Expires after a configurable TTL (Time To Live).
Long-term memory: Extracted facts, preferences, and summaries. Persists indefinitely across all sessions and channels. The extraction happens asynchronously in the background.

How does unified identity work across WhatsApp and Instagram?

When you write from WhatsApp, the system creates a deterministic user ID based on your phone number (wa-user-{phone}). When you link your Instagram account, both channels resolve to the same ID. The actor_id sent to AgentCore Memory is identical regardless of channel.

The linking happens through conversation. The agent asks new users if they also write from another channel. If you share your Instagram username or WhatsApp number, a link_account tool merges both identities in a unified users DynamoDB table.

Channel	User ID format	Lookup method
WhatsApp first	`wa-user-{phone}`	GSI on `wa_phone`
Instagram first	`ig-user-{sender_id}`	GSI on `ig_id`, fallback scan on `ig_username`
Linked	Whichever was created first	Both GSIs resolve to the same record

How does message buffering reduce AI invocation costs?

WhatsApp users tend to send 3-5 rapid messages instead of one long text. Without buffering, each message triggers a separate AI invocation, multiplying cost and token usage.

A DynamoDB Streams tumbling window accumulates messages from the same user for 10 seconds, then sends them as a single concatenated prompt to the agent.

User sends 3 messages in 2 seconds:
  "hello"             -> DDB INSERT (t=0s)
  "I have a question"  -> DDB INSERT (t=1s)
  "about my video"     -> DDB INSERT (t=2s)

Tumbling window fires at t=10s:
  -> Processor receives all 3 records in one batch
  -> Aggregates: "hello\nI have a question\nabout my video"
  -> Single AgentCore invocation

This pattern is based on Enrique Rodriguez's sample-whatsapp-end-user-messaging-connect-chat, which reported a 4:1 aggregation ratio in real-world WhatsApp usage.

What media types does the AI agent support?

Media	Processing method	Memory storage
Text	Direct prompt to the agent	Stored as conversation event
Image	Anthropic Claude vision describes the content	Text description stored in long-term memory
Audio and voice notes	Amazon Transcribe converts speech to text	Transcription stored as text prompt
Video	TwelveLabs Pegasus analyzes visual and audio content	Description and reference ID stored in long-term memory
Documents (PDF, DOCX, XLSX)	Claude reads inline and summarizes	Summary stored in long-term memory

All multimedia is converted to text understanding before entering memory. This is how the agent recalls what was in a photo or video days later, even across channels.

Frequently asked questions

Can the same agent serve WhatsApp and Instagram at the same time?
Yes. Stack 02 uses a single API Gateway webhook that receives both WhatsApp and Instagram messages. The receiver Lambda detects the channel from the payload and normalizes both into a common format.

Does the agent remember conversations when switching channels?
Yes. A unified users table maps WhatsApp phone numbers and Instagram IDs to a single user. When both accounts are linked, the agent uses the same actor_id in AgentCore Memory. Long-term facts and preferences persist across both channels.

What happens if I only want WhatsApp without Instagram?
Deploy Stack 01 for WhatsApp via AWS End User Messaging, or deploy Stack 02 and configure only the WhatsApp secret. The agent works without Instagram when no Instagram credentials are configured.

How can I add more channels like Telegram or a web chat?
The AgentCore Runtime and Memory layer is channel-agnostic. To add a new channel, create a receiver that normalizes messages into the same DynamoDB format and add a reply dispatch function. The agent and memory work without changes.

Get started

The full project with deployment instructions, Instagram setup guide, and architecture documentation:

github.com/elizabethfuentes12/whatsapp-ai-agent-sample-for-aws-agentcore

This is a demo project for learning and experimentation. If you plan to use these patterns in production, add proper security hardening, error handling, and monitoring.

Built with Amazon Bedrock AgentCore, AWS CDK, and Strands Agents. Similar patterns can be applied using LangGraph, AutoGen, or the Amazon Bedrock Agents SDK.

Gracias!

🇻🇪🇨🇱 Dev.to Linkedin GitHub Twitter Instagram Youtube
Linktr

Elizabeth Fuentes LFollow

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

[Boost]

Elizabeth Fuentes L — Wed, 01 Apr 2026 19:54:27 +0000

ensamblador

Apr 1

Facebook Messenger to Amazon Connect Chat

#meta #amazonconnect #python #cdk

Comments

11 min read

[Boost]

Elizabeth Fuentes L — Wed, 01 Apr 2026 15:21:03 +0000

ensamblador

Apr 1

Respondiendo DMs de Instagram con Amazon Connect Chat

#amazonconnect #instagram #python #chat

Comments

12 min read

[Boost]

Elizabeth Fuentes L — Wed, 01 Apr 2026 05:22:55 +0000

Elizabeth Fuentes L for AWS

Mar 30

5 Techniques to Stop AI Agent Hallucinations in Production

#ai #aws #python #machinelearning

Comments 2

14 min read

Guardrails para Agentes de IA: Reglas Que los LLM No Pueden Evadir

Elizabeth Fuentes L — Tue, 31 Mar 2026 18:49:56 +0000

Los agentes de IA pueden alucinar el éxito de una operación incluso cuando violan reglas de negocio. Confirman reservas sin verificación de pago, aceptan parámetros inválidos como 15 huéspedes cuando el máximo es 10, o ignoran prerrequisitos obligatorios.

El problema central: los agentes pueden confirmar reservas de hotel a pesar de que el pago nunca fue verificado, violar restricciones de capacidad, o saltarse pasos de validación obligatorios. El prompt engineering por sí solo no puede prevenir estos errores.

Este post demuestra cómo la validación neurosimbólica — combinando razonamiento del LLM con reglas simbólicas deterministas aplicadas a nivel de framework — bloquea operaciones inválidas antes de que se ejecuten.

Esta demo utiliza Strands Agents. Patrones similares pueden aplicarse en LangGraph, AutoGen u otros frameworks de agentes.

Resumen de la Serie

Esta es la Parte 3 de una serie sobre cómo detener las hallucinations en agentes de IA:

RAG vs Graph-RAG — Knowledge graphs para prevenir hallucinations
Semantic Tool Selection — Filtrado de tools basado en vectores
AI Agent Guardrails (este post) — Reglas simbólicas que los LLM no pueden evadir
Runtime Guardrails — Redirigir en lugar de bloquear
Multi-Agent Validation — Detección de hallucinations basada en equipos

El Problema: Los Prompts Son Sugerencias, No Restricciones

La investigación de ATA: Autonomous Trustworthy Agents (2024) identifica tres patrones de hallucination:

Errores de parámetros: El agent llama a book_hotel(guests=15) a pesar de que el docstring indica un máximo de 10
Errores de completitud: El agent ejecuta reservas sin la verificación de pago requerida
Comportamiento de evasión de tools: El agent confirma éxito sin llamar a los tools de validación obligatorios

Causa raíz: Los prompts son texto que el LLM interpreta. Las reglas de negocio embebidas en docstrings se convierten en sugerencias — el modelo decide si las sigue en cada llamada.

La Solución: Validación Neurosimbólica con Strands Hooks

Los hooks a nivel de framework interceptan las llamadas a tools antes de la ejecución. Usando BeforeToolCallEvent en Strands Agents, puedes:

Validar reglas simbólicas de forma determinista
Cancelar la ejecución del tool si alguna regla falla
Enviar un mensaje de cancelación directamente al LLM (no puede ser anulado)

Diferencia arquitectónica clave:

Prompts: Entrada del LLM (interpretable, anulable)
Hooks: Interceptores del framework (deterministas, obligatorios)

Prerrequisitos

Experiencia con Python y uso de tools en agentes LLM
Familiaridad con Strands Agents

git clone https://github.com/aws-samples/sample-why-agents-fail
cd stop-ai-agent-hallucinations/04-neurosymbolic-demo
uv venv && uv pip install -r requirements.txt

Implementación: Reglas, Hook y Dos Agentes

Paso 1: Definir Reglas Simbólicas

from dataclasses import dataclass
from typing import Callable

@dataclass
class Rule:
    name: str
    condition: Callable[[dict], bool]
    message: str

BOOKING_RULES = [
    Rule("max_guests",   lambda ctx: ctx.get("guests", 1) <= 10,     "Maximum 10 guests per booking"),
    Rule("valid_dates",  lambda ctx: ctx["check_in"] < ctx["check_out"], "Check-in must be before check-out"),
]

CONFIRMATION_RULES = [
    Rule("payment_before_confirm", lambda ctx: ctx.get("payment_verified", False),
         "Payment must be verified before confirmation"),
]

Las reglas son funciones Python simples — deterministas, testeables y auditables de forma independiente a cualquier agent.

Paso 2: Crear el Hook de Validación

from strands.hooks import HookProvider, HookRegistry, BeforeToolCallEvent

class NeurosymbolicHook(HookProvider):

    def register_hooks(self, registry: HookRegistry) -> None:
        registry.add_callback(BeforeToolCallEvent, self.validate)

    def validate(self, event: BeforeToolCallEvent) -> None:
        tool_name = event.tool_use["name"]
        if tool_name not in self.rules:
            return
        context = self._build_context(tool_name, event.tool_use["input"])
        passed, violations = validate(self.rules[tool_name], context)
        if not passed:
            event.cancel_tool = f"BLOCKED: {', '.join(violations)}"

Cuando se establece event.cancel_tool, Strands reemplaza el resultado del tool con ese mensaje antes de que el LLM lo vea. El tool nunca se ejecuta.

Paso 3: Definir Tools Limpios

from strands import tool

@tool
def book_hotel(hotel: str, check_in: str, check_out: str, guests: int = 1) -> str:
    """Book a hotel room."""
    return f"SUCCESS: Booked {hotel} for {guests} guests, {check_in} to {check_out}"

@tool
def process_payment(amount: float, booking_id: str) -> str:
    """Process payment for a booking."""
    return f"SUCCESS: Processed ${amount:.2f} for {booking_id}"

@tool
def confirm_booking(booking_id: str) -> str:
    """Confirm a booking."""
    return f"SUCCESS: Confirmed {booking_id}"

Los tools contienen solo lógica de negocio — sin validación mezclada.

Paso 4: Crear Ambos Agentes

from strands import Agent
# Using OpenAI-compatible interface via Strands SDK (not direct OpenAI usage)
from strands.models.openai import OpenAIModel

MODEL = OpenAIModel(model_id="gpt-4o-mini")

# Baseline: no hook, no validation
baseline_agent = Agent(tools=[book_hotel, process_payment, confirm_booking], model=MODEL)

# Guarded: hook intercepts every tool call
hook = NeurosymbolicHook(STATE)
guarded_agent = Agent(tools=[book_hotel, process_payment, confirm_booking], hooks=[hook], model=MODEL)

Mismos tools, mismo modelo, mismos prompts. La única diferencia: hooks=[hook]

Resultados de las Pruebas

Prueba 1: Confirmar Reserva Sin Pago

Consulta: "Confirm booking BK001"

Agent	Resultado
Baseline	❌ Ejecuta — pago nunca verificado, docstring ignorado
Guarded	✅ Bloqueado — el hook evalúa `CONFIRMATION_RULES`, encuentra `payment_verified=False`, cancela

El LLM recibe: BLOCKED: Payment must be verified before confirmation

Prueba 2: Reservar Hotel Excediendo el Límite de Huéspedes

Consulta: "Book Grand Hotel for 15 people from 2026-03-20 to 2026-03-25"

Agent	Resultado
Baseline	❌ Ejecuta con 15 huéspedes — máximo en docstring ignorado
Guarded	✅ Bloqueado — `max_guests_check(15 <= 10)` falla, ejecución cancelada

La validación ocurre antes de la ejecución — no hay reserva que revertir.

Prueba 3: Reserva Válida

Consulta: "Book Grand Hotel for 5 guests from 2026-03-20 to 2026-03-25"

Agent	Resultado
Baseline	✅ Ejecuta
Guarded	✅ Ejecuta — todas las reglas pasan, el hook no agrega fricción

Resumen de Escenarios

Escenario	Baseline	Guarded
Confirmar sin pago	❌ Ejecuta — hallucination	✅ Bloqueado antes de la ejecución
Reservar 15 huéspedes (máx. 10)	❌ Ejecuta — regla violada	✅ Bloqueado antes de la ejecución
Reserva válida (5 huéspedes)	✅ Ejecuta	✅ Ejecuta

Punto Clave: Dónde Se Aplica la Validación

Prompt Engineering (Insuficiente)

system_prompt = """
IMPORTANT: Never confirm bookings without payment verification.
CRITICAL: Maximum 10 guests per booking.
"""
# The LLM reads this as context. It can hallucinate compliance.

❌ El LLM decide si sigue estas instrucciones en cada llamada.

Aplicación Basada en Hooks (Suficiente)

def validate(self, event: BeforeToolCallEvent) -> None:
    passed, violations = validate(self.rules[tool_name], context)
    if not passed:
        event.cancel_tool = f"BLOCKED: {', '.join(violations)}"
        # Tool never executes. LLM receives the cancellation.
        # There is no path to override this.

✅ El hook se ejecuta fuera del LLM. La decisión no depende del LLM.

Diferencia arquitectónica: Los prompts son entrada del LLM (interpretable). Los hooks son interceptores del framework (deterministas).

Consideraciones para Producción

Ventajas

Restricciones verificables: Las reglas son código, no instrucciones
Centralizadas: Un solo hook valida todos los tools
Testeables de forma independiente: Las reglas funcionan fuera de cualquier agent o contexto de LLM
Auditables: Las violaciones de reglas producen eventos explícitos con nombre del tool, parámetros y razón

Desafíos

Las reglas deben definirse explícitamente para cada operación protegida
No maneja lógica difusa o probabilística — las reglas son booleanas
Los casos límite requieren manejo explícito en las condiciones
Las reglas necesitan mantenimiento a medida que evoluciona la lógica de negocio

Mejores Prácticas

Define hooks para operaciones críticas: reservas, pagos, cancelaciones
Registra todas las violaciones de reglas con nombre del tool, parámetros y razón
Testea las reglas de forma independiente y exhaustiva
Combina con semantic tool selection (Parte 2) y multi-agent validation (Parte 5) para protección en capas

Siguiente Paso

Los guardrails simbólicos bloquean violaciones de reglas a nivel de tool. Pero bloquear detiene el flujo de trabajo — el usuario debe intervenir.

Parte 4: Runtime Guardrails muestra cómo Agent Control redirige a los agentes para que se autocorrijan en lugar de bloquearlos, completando flujos de trabajo sin intervención humana.

Conclusiones Clave

Los prompts son sugerencias: El LLM interpreta docstrings; puede alucinar cumplimiento con cualquier instrucción
Los hooks son aplicación forzada: BeforeToolCallEvent intercepta antes de la ejecución a nivel de framework — el LLM no puede anular un tool cancelado
Todas las operaciones inválidas bloqueadas: Cero cambios en tools, cero cambios en prompts, un hook agregado
Separación limpia: Los tools manejan operaciones; los hooks manejan la aplicación de restricciones
Auditable por diseño: Las violaciones de reglas son condiciones Python explícitas — testeables, registrables, trazables
Un hook, todos los tools: Un solo NeurosymbolicHook valida cada llamada a tool de forma centralizada

Ejecútalo Tú Mismo

git clone https://github.com/aws-samples/sample-why-agents-fail
cd stop-ai-agent-hallucinations/04-neurosymbolic-demo
uv venv && uv pip install -r requirements.txt
uv run test_neurosymbolic_hooks.py

Puedes cambiar a cualquier proveedor soportado por Strands — consulta Strands Model Providers para la configuración.

Referencias

Investigación

Strands Agents

Código

Repositorio de Código

Gracias!

🇻🇪🇨🇱 Dev.to Linkedin GitHub Twitter Instagram Youtube
Linktr

Elizabeth Fuentes LFollow

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