Your AI Agent Isn't Crashing. It's Bleeding Tokens en

Your AI agent does not crash; it gets stuck. It silently produces wrong results when data overflows the context window. It waits forever when an MCP tool calls a slow API. It calls the same tool 14 times because the response said "more results may be available." None of these failures throw errors. They just waste tokens and time.

Three silent failures that cost real money. Context overflow: a tool returns 214KB of logs, the context window fills up, and the agent produces incomplete results with no error. MCP tools hanging: an external API takes 15 seconds and the agent gets a cryptic 424 error. Reasoning loops: ambiguous tool feedback causes 14 retries, burning tokens with zero progress.

I will cover the Memory Pointer Pattern (store large data outside context, return a pointer, based on IBM Research), async handleId for MCP (return job IDs immediately, poll for results, based on Octopus Research), and DebounceHook with clear SUCCESS states that block duplicate calls (14 calls to 2). Each fix includes a live demo with before/after metrics.

You'll walk away with:

• Three production-ready patterns you can implement the same day
• Working code with real metrics for each fix
• Understanding of which failure mode is causing your agent's problems
• Open-source repository with all demos

Most agent talks focus on capabilities. This focuses on efficiency: what agents waste.

Not All Agent Memory Is a Vector Database en

Your agent works in the demo, then forgets the user's name, preferences, and history the next day. The model is not broken. Models are stateless by design, and bigger context windows do not fix it: re sending full history costs tokens every turn and still vanishes between sessions.

This talk maps the full landscape of agent memory: key value, vector, graph, and hybrid, plus selective memory, memory hygiene, and reasoning memory. Leave knowing exactly which memory your agent needs and why.

What you'll learn:
• Choose between key value, vector, graph, and hybrid memory using one test: do you know the key, only the intent, or the relationship
• Design the write path and read path that move facts from conversations into storage and back into the context window
• Evaluate the three ways to decide what is worth remembering: agent driven tools, a custom extractor, or a managed extraction service
• Apply memory hygiene defenses, a write gate and selective forgetting, against dirty and poisoned memory
• Implement decision traces as reasoning memory so you can audit and reverse decisions built on a bad source

Outline:
• Memory decay: why your agent forgets
• How memory reaches the model
• The four memory types, one question four ways
• The capabilities layer
• Choosing, and the honest limits

Your Agent Works on Localhost. Now Ship It en

Anti-hallucination techniques work great in Jupyter. Production needs more: secure credentials, scalable databases, semantic tool routing, and business rules that change without code deploys.

This talk takes 5 techniques (GraphRAG, semantic tool selection, neurosymbolic guardrails, multi-agent validation, steering) and deploys them as a production agent. Steering rules live in a database, not code. The agent self-corrects via STEER messages, not hard failures. Live demo with 8 scenarios.

Outline:
• The Prototype-to-Production Gap
• Semantic Tool Routing via MCP Gateway
• Steering Rules in DynamoDB
• GraphRAG in Production
• Full Production Test
• Resources + Q&A

Context Window Is Full? Let's Fix That en

A tool returns 214KB of logs. The window overflows and answers get worse with no error, only rising cost and dropping accuracy.

In this hands on workshop you build three fixes and the strategies behind them. Externalize and select with a memory pointer that keeps large data outside the window, single and multi agent. Compress runaway reasoning loops with a debounce and clear states. Isolate slow tools behind an async handle. You leave with working code and before and after metrics.

Outline:
• Introduction: The Infinite Window Is a Myth
• The Four Context Engineering Strategies
• Module 1: Memory Pointer, Single Agent
• Module 2: Memory Pointer, Multi Agent
• Module 3: Compress Runaway Loops
• Module 4: Isolate Slow Tools
• Anti-Patterns, Decision Framework, Resources

Build a Voice Agent That Teaches and Remembers en

Most learning apps play the same script for everyone. A voice agent can listen instead. You will see one that holds a real conversation out loud, catches pronunciation and grammar slips as you speak, corrects one at a time without killing the flow, pulls reference material from your own documents, and remembers each learner: their name, the words they struggled with, where they stopped. The same pattern fits technical onboarding or any training that adapts to the person.

Outline:
• Introduction: The Adaptive Learning Gap
• Voice Agent Architecture Patterns
• Demo 1: Building the Knowledge Base
• Designing Pedagogical Prompts
• Demo 2: Voice Conversation with Adaptive Feedback
• Production Considerations
• When to Use Voice + RAG Beyond Learning
• Wrap-up

Keep Conversation and Context Apart, Cut Your Token Bill en

Your agent fetched a large dataset to answer one question, and that payload now rides along in every model call, burning your token budget. The instinct is more memory. The real fix is seeing your agent already has two. Conversation memory is recalled by meaning. Context data is recalled by an exact reference. Most token and cost failures are one stored as the other. This talk gives you the decision, measured live, and the production split that keeps the two memories separate.

What you'll learn:
• Tell conversation memory and context memory apart, and decide where each piece of agent state belongs before you write a tool
• Keep large tool outputs out of the context window so they stop riding along in every model call, while your tools stay ordinary functions
• Evaluate exact reference storage against recall by meaning, and pick the right one for each data type
• Build the production split: conversation in a managed memory service, large data in object storage, no payloads leaking into the chat
• Implement tools that return summaries so offloading stays a safety net, not your whole strategy

Outline:
• The large payload question
• An agent has two memories
• Context memory: offload large data outside the window
• Production: two memories on purpose
• Decide placement before you build

When an MCP Tool Hangs, So Does Your Whole Agent en

Your agent calls a tool, the tool calls an external API, and that API takes 30 seconds, or never answers. The agent blocks, then dies with a cryptic error. One slow dependency took down the whole workflow. The fix is decades old: never let a synchronous caller block on a dependency you do not control. At the tool boundary, return a handle immediately and poll for the result. Watch a live demo turn a 300 second hang into about a 4 second response, and learn when a call must go asynchronous.

What you'll learn:
• Apply a simple rule to classify any tool call as safe to block or required to go asynchronous
• Build the async handle pattern: one tool returns a tracking id instantly, another polls for the result
• Design job lifecycle and cleanup so completed and stalled jobs do not leak memory
• Implement clear error and timeout states so failed dependencies surface instead of hanging
• Evaluate polling against callback delivery and choose per use case

Outline:
• One slow dependency, whole workflow down
• The pattern is older than agents
• Build the async boundary
• Make it production safe
• The decision checklist

When Agents Loop: Cutting 14 Tool Calls to 2 en

AI agents waste massive resources calling the same tool over and over. 14 calls where 2 would suffice, burning tokens and frustrating users. The culprit: ambiguous tool feedback that leaves agents guessing whether they succeeded.

Three production solutions: DebounceHook with sliding window duplicate detection, clear SUCCESS/FAILED states that tell agents when to stop, and LimitToolCounts for hard ceilings. Live demo showing 14 calls reduced to 2 and response times dropping from 21s to 4s.

Outline:
• The Token Waste Problem
• DebounceHook: Detect and Block Duplicates
• Clear SUCCESS/FAILED States: Prevention by Design
• LimitToolCounts: Hard Ceiling Enforcement
• Production Patterns and Wrap-Up

Break Your Agent Before Production Does en

Your tests cover the happy path, so they pass right until production, where tools return wrong data and users push the agent on purpose. Two kinds of trouble. Bad luck: a tool returns a believable wrong value and the agent reports it as fact. Bad intent: an attacker escalates over several turns until the agent leaks a card number or acts past its limit. Chaos testing covers the first, red teaming the second. You need both, and results vary run to run, so you measure rates, not single passes.

Outline:
• The happy-path trap
• Bad luck: chaos testing
• Bad intent: red teaming
• One run is not a measurement
• Test both before you ship

Can Your Agent Survive a Multi-Turn Attack? en

Your agent refuses an obvious attack, so you call it safe. But a real attacker does not ask once. They escalate over several turns, back off when refused, and try a different angle, until the agent leaks a card number or books past its limit. Red teaming generates these multi-turn attacks for you, runs them against your agent, and scores whether it held. Across repeated runs the same agent defends most of the time and breaches sometimes. Security is a rate, not a fixed property.

Outline:
• One refusal proves nothing
• Generate the attacks, do not script them
• Run the multi-turn campaign
• Security is a distribution, not a pass
• Budget red teaming like any eval

Prompt Caching Isn't Enough en

Your agent answers "what's the weather in Madrid?" and three seconds later someone asks "how's Madrid looking weather-wise?" The whole loop runs again: planning, tool calls, generation. Prompt caching discounts the input and charges you for all of that. Two application level caches remove the work instead: a semantic cache that returns the stored answer for a paraphrase, and a reasoning cache that replays the known plan and tool path. Measured on a deployed system: 127 ms hit, 3,004 ms miss.

What you'll learn:
• A decision framework for which cache layer saves which cost (tokens, latency, API calls)
• Working open-source code for both caches, deployable on either backend
• Numbers from deployed system: 127 ms hit vs 3,004 ms miss; cold vs warm runs going from 24,561 tokens to 3,576 and fewer tool calls
• The honest failure story: the first iteration saved nothing until the hint prompt was fixed

Outline:
• The bill nobody itemizes
• Semantic response cache
• Reasoning cache
• Freshness, or how not to serve wrong answers
• Decision framework + resources

Chaos Testing: When Your Agent Trusts Bad Data en

Your tests only cover the happy path, so they pass until production, where tools time out and APIs return half a response. Chaos testing checks what your agent does when a tool returns a wrong but plausible value, like 12 degrees for Miami in June, buried in a verbose dump. The agent reports it as fact and burns tokens reading the junk. A small guardrail range-checks the value and replaces a bad result with a one-line error before the model ever sees it, fixing both accuracy and token cost.

Outline:
• The happy-path trap
• Inject realistic corruption
• The guardrail that catches it
• One run is not a measurement
• Build chaos into your test suite

Research Agents That Don't Invent Sources en

Research agents are deceptively easy to prototype and dangerously hard to productionize. The demo searches the web, summarizes findings, and cites sources. The production version leaks credentials, forgets what it researched two turns ago, and returns citations that lead nowhere.

In this session I build a production-ready research agent from scratch: API gateway security, identity-based credentials, context that persists across turns, and source verification that ensures every citation is real.

Outline:
• The Research Agent That Became a Liability
• Securing Credentials with API Gateways
• Persistent Conversation Context
• Source Verification That Actually Works
• The Complete Research Agent and Resources

Ship It: From Agent Demo to Production in Minutes en

The gap between a working agent demo and a production system is where most AI projects die. Memory resets every session, there is no observability, scaling means rewriting everything, and cost spirals without warning.

In this session I take a simple agent and deploy it to production live: cross-session memory with a managed vector store, zero-code monitoring, auto-scaling, and cost optimization patterns. You see every step from notebook to production endpoint, with reusable code.

Outline:
• The Six-Month Gap
• Cross-Session Memory with S3 Vectors
• Zero-Code Monitoring and Observability
• Auto-Scaling and Cost Optimization
• The Complete Picture and Resources

Stop Sending Every Tool on Every Call and Save Tokens en

Every call your agent makes packs the description of every tool into the context window, whether the question is about the weather or a hotel booking. That is thousands of tokens on every query, and the bill grows with each tool you add, including the ones the request will never touch. Match the request to the few tools that fit and send only those. You see the same agent run with and without the filter on identical queries, token counts side by side, and you leave with code you can reuse.

Outline:
• The Dual Problem
• Solution Architecture
• Live Implementation
• Production Pattern
• Tool Dependency Graphs, Caching, and Monitoring

Agent Speedrun: Idea → Code → Deploy → Observe, Fix → Ship en

You arrive with an idea and leave with a deployed agent. In this hands-on workshop you build one customer service agent with the open-source Strands Agents SDK across seven progressive modules: the agent loop and tools, hooks, skills and steering, session managers, multi-agent collaboration, and evals. Then you take it to production on Amazon Bedrock AgentCore Runtime, serverless with session isolation, and leave with a working endpoint, the full repo, and a self-paced version to keep going.

What you'll learn:
• A working agent harness built with Strands Agents: agent loop, custom tools, hooks, skills, and session managers
• A live production endpoint on Amazon Bedrock AgentCore Runtime that you deployed yourself
• The observe-break-fix workflow: tracing an agent, breaking it on purpose, and repairing it from the trace data
• The full workshop repo plus a self-paced AWS Workshop Studio version to re-run everything

Outline:
• Kickoff: Idea → Shipped in One Session
• Module 1: Agent Loop + Tools
• Module 2: Hooks
• Module 3: Skills + Steering
• Module 4: Session Managers
• Module 5: Multi-Agent
• Module 6: Evals + Observe, Fix
• Module 7: Deploy to AgentCore
• Wrap: Resources + Keep Going

Your Agent's Context Window Is Full. Now What? en es

A tool returns 214KB of logs. The window overflows, the answers get worse, and nothing throws an error. Another agent retries the same call fourteen times. A third freezes seventeen seconds on a slow tool and times out. None of them crash; they quietly cost you money and accuracy. The fix for all three: pull large output back by reference, give the agent a clear done signal, and hand a slow tool a tracking id. You leave with working code and a rule for which fix each failure needs.

What you'll learn:
• Recognize the three failures that never raise an error: output that overflows the window, a loop that repeats a call, and a slow tool that blocks the agent
• Keep large tool output out of the context window and pull it back by reference when a step actually needs it
• Give a tool a clear done signal so the agent stops retrying, with the before and after call counts
• Return a tracking id for slow work so the agent polls instead of blocking on the call
• Decide which of the three fixes a given failure needs, using the symptoms you can see in a trace

Outline:
• Three failures that never throw
• Fix 1: keep the payload out of the window
• Fix 2: give the agent a clear done signal
• Fix 3: return a job id instead of blocking
• Which fix for which failure, and resources

The Three Hidden Graphs in Every AI Agent en

Ask your agent "who do I know connected to flights to Spain?" and vector search returns Iberia, Madrid and Spain as three disconnected pieces. The pieces are there; nothing joins them. Store what the agent knows, what it did, and why as graphs, and traversal answers the question: in demos you can rerun, multi-hop goes from 1 of 4 to 4 of 4, and the reverse audit ("this source was wrong, what did it touch?") from 2 of 4 to 4 of 4, with the provenance path as the receipt.

What you'll learn:
• Identify the three graphs already hiding in any agent system: context, execution, and provenance
• Understand why vector similarity structurally cannot answer multi-hop questions, and why traversal can
• Store agent memory as a Neo4j knowledge graph and combine similarity (entry point) with Cypher traversal (answer)
• Capture decision traces automatically with framework lifecycle hooks, with zero changes to your tools
• Run the reverse audit a flat store cannot express: follow provenance at any depth with one variable-length Cypher query

Outline:
• The claim: your agent is already a graph
• Context Graph: multi-hop questions need edges
• Execution + Provenance Graphs: remember WHY, audit in reverse
• Close the loop

When Prompts Fail: Enforcing Rules in Agents en

You put business rules in the system prompt. The LLM finds ways around them. "Never confirm without payment" becomes "I'll make an exception this time." Prompts optimize for helpfulness, not compliance.

The fix is input validation, like in web apps: check before execution. Python hooks intercept every tool call and validate against rules defined as dataclasses. First you block violations the LLM cannot override. Then you steer: the hook guides the agent to fix its call, 15 guests becomes 10.

Outline:
• The Prompt Engineering Failure
• Neurosymbolic Architecture
• Live Implementation: Blocking
• From Blocking to Steering
• Production Patterns and Q&A

Catching Hallucinations with Multi-Agent Validation en

Your agent confirms a booking with a reference number, the details, and a status. The data is made up. A single agent cannot check its own work: an invented answer sounds exactly as sure as a real one. Split the job instead. One agent does the work, a second checks independently that the data exists, and a third makes the call. You watch the same booking run through the agent that invents a hotel and through the team that catches it, and you leave with the pattern and when it pays for itself.

Outline:
• Single-Agent Hallucination
• Multi-Agent Pattern
• Live Implementation
• Production Patterns
• N-Agent Voting, Specialized Validators, and Confidence Scoring

Context Engineering: Stop Agents from Choking on Their Own Data en

Your agent ingests 214KB of server logs. Nothing errors, and the answer is garbage: the window overflowed, the data was truncated, and the agent answered confidently from half of it. Stop putting big data in the window. Store the output to the side and hand back a short reference, so 214KB becomes a 52 byte pointer, and agents sharing the work read from it. A three agent pipeline then handles 145KB of logs in about 14 seconds. You leave with the pattern and a way to catch silent overflow.

Outline:
• The Silent Killer
• Memory Pointer Pattern Deep Dive
• Multi-Agent State Sharing
• Production Patterns
• Hierarchical Pointers, Lazy Loading, and Wrap-Up

When RAG Hallucinates Numbers: Graph-RAG for Precise Answers en

Traditional RAG works for simple lookups but fails on counting, aggregation, and out-of-domain queries, fabricating plausible but wrong answers. Graph-RAG uses knowledge graphs for structured, relationship-aware retrieval that returns precise results.

In a live comparison, two agents get the same queries on the same data. Traditional RAG invents counts and nonexistent results. Graph-RAG answers correctly every time using auto-built knowledge graphs and the Text2Cypher pattern.

Outline:
• The RAG Hallucination Problem
• Graph-RAG Architecture
• Live Implementation
• Production Patterns
• Decision Framework

Build a Video Search Agent, Not a Pipeline en

Searching video used to mean decomposing every file into frames, audio tracks, transcripts, and separate embedding spaces, then orchestrating six tools to answer one query. It was slow, fragile, and expensive.

Multimodal models remove the decomposition pipeline entirely. In this talk I build a video analysis agent live, contrast it with the multi-step pipeline, and show how an agent-based architecture makes video search production-ready, plus when decomposition still wins.

Outline:
• The 500-Hour Problem
• Why Decomposition Fails
• The Multimodal Shift
• Building the Video Agent
• When to Use What and Resources

Your AI Agent Isn't Crashing. It's Bleeding Tokens en

Your agent does not crash. A tool hands back 214KB of logs, the window overflows, and the answers quietly get worse with no error. Another agent calls the same tool 14 times because the response never said it was done. A third waits 17 seconds on a slow API and gets a 424. Three fixes, with before and after numbers from the demos: keep large output out of the window and return a pointer, give the agent a clear done signal, and hand back a job id instead of blocking.

Outline:
• Three Silent Failures
• Fix 1: Memory Pointer Pattern
• Fix 2: Async HandleId for MCP
• Fix 3: DebounceHook + Clear States
• Decision Matrix + Resources

RAG vs GraphRAG: Cuando los Agentes Inventan Respuestas en es

Tu agente RAG parece inteligente hasta que le pides contar algo. Pregunta: cuantos elementos cumplen X? RAG tradicional inventa: aproximadamente 45-50. La respuesta real? 133. La similitud vectorial no puede contar, agregar ni razonar entre relaciones.

El problema fundamental: RAG tradicional recupera fragmentos de texto por similitud y pide al LLM sintetizar respuestas. Esto funciona para consultas simples pero falla sistematicamente en cuatro tipos: conteo, agregacion, razonamiento multi-hop y deteccion fuera de dominio.

En esta charla veras:

- Por que RAG tradicional alucina en consultas estructuradas
- Como Graph-RAG construye grafos de conocimiento automaticamente con neo4j-graphrag
- Patron Text2Cypher: lenguaje natural a consultas precisas de base de datos
- Comparacion lado a lado con consultas identicas mostrando fabricacion de RAG vs precision de Graph-RAG
- Patrones de implementacion para produccion con herramientas open-source

Te llevaras:

- Implementar Graph-RAG con Neo4j y extraccion automatica de entidades
- Aplicar generacion de consultas Text2Cypher para obtener respuestas precisas
- Evaluar cuando usar RAG vs Graph-RAG con un framework de decision concreto
- Codigo open-source adaptable a cualquier dominio con datos estructurados

One Guardrail Won't Stop Your Agent Hallucinating en

You added a guardrail. Your AI agent still hallucinated. Agents fail in five ways: fabricating data, selecting wrong tools, ignoring business rules, failing to self-correct, and bypassing constraints. One guardrail covers one failure mode.

Five layered techniques: graph queries that compute instead of guess, semantic routing, database-driven rules updated in seconds, self-correction that guides instead of blocks, and hard hooks the LLM cannot bypass. Validated across 8 adversarial scenarios.

Outline:
• Your AI Agent Hallucinates in 5 Different Ways
• Grounded Retrieval with Graph Queries
• Semantic Tool Routing
• Steering Rules + STEER Messages
• Hard Hooks That Cannot Be Bypassed
• Full Layered Defense Test
• Resources + Q&A

Stop AI Agent Hallucinations With Code, Not Prompts en

Your AI agent books 15 guests despite a 10-person maximum. Another fabricates occupancy rates the database never had. A third picks the wrong tool from 29 and burns tokens.

This hands-on workshop walks through 5 techniques to stop these failures: Graph-RAG for grounded retrieval, semantic tool selection, multi-agent validation, neurosymbolic guardrails, and steering. You'll see live demos, then take the patterns to production.

Outline:
• Introduction - Why AI Agents Hallucinate Differently Than LLMs
• Demo 00 - Strands Agents Primer
• Demo 01 - Graph-RAG vs. Standard RAG
• Demo 02 - Semantic Tool Selection
• Demo 03 - Multi-Agent Validation
• Demo 04 - Neurosymbolic Guardrails
• Demo 05 - Agent Control Steering
• Demo 06 - Production on Amazon Bedrock AgentCore
• Workshop Recap + Resources
• Q&A

Two Agents, Same Answer, One Is Wasting Your Money en

Two agents answer the same question correctly. One made two tool calls; the other pulled irrelevant context and called the same API twice. Your pass/fail suite scores both 100 percent, and you pay for the difference in tokens and rate limits. This talk scores the answer with an LLM judge and a rubric, then scores the path the agent took to get there, so waste that produces a correct answer stops being invisible. You leave with the rubrics, the trajectory checks, and code to run them in CI.

Outline:
• Introduction: The Binary Metrics Problem
• Part 1: LLM-as-Judge Evaluation
• Part 2: Trajectory Evaluation
• Part 3: Combining Both Techniques

Your Agent Lies and Passes Every Test en

Your agent invents a hotel amenity that was never in the search results. The test says PASS, because all it checked was that a hotel came back. Across a conversation it gets worse: turn one is safe, turn five gives advice it should never give. You get zero-shot detection that needs no labeled data, per-turn scoring that shows drift while it happens, and a lifecycle hook that swaps an unsafe answer for a safe one before the user sees it, plus the monitoring setup to watch it in production.

Outline:
• Introduction: The Silent Failure Problem
• Part 1: Zero-Shot Hallucination Detection
• Part 2: Trajectory-Level Safety Drift Monitoring
• Part 3: Real-Time Guardrails with Lifecycle Hooks
• Production Monitoring and Q&A

A Better Prompt Won't Fix Your Agent. A Better Harness Will en

An agent that works once in a clean session meets four things in production it never saw: memory it cannot trust, untrusted input it does trust, multi-step tasks where a step silently fails, and repeated work it re-pays for every call.

No prompt fixes these. Each is fixed in the harness around the model: a deterministic gate before a write, a ground-truth check after a step, a tool the agent writes once and reuses. Five runnable demos, each reproducing the failure, then fixing it.

Outline:
• The demo lied to you
• Diagnose before you fix: break it on purpose
• Memory it cannot trust
• Memory it should not have trusted
• The step that silently failed
• Work it keeps re-paying for
• The decision rule + Q&A