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 everything the next day. The model is not broken: models are stateless by design, and memory belongs to the harness you build around them. Bigger context windows do not fix it. Re sending full history burns tokens every turn and still vanishes between sessions. This talk maps the agent memory landscape through one question asked four ways: retrieval by key, by meaning, and by relationship. You will learn when key value, vector, graph, and hybrid memory each win, plus the capabilities layer on top: selective memory, hygiene against dirty and poisoned entries, and reasoning memory for auditable decisions. 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

Your anti-hallucination techniques look great on your laptop: the agent pulls precise answers, blocks bad operations, and catches made-up data. Then you ship, and the notebook falls apart: hardcoded keys, data that only lived in memory, no way to see what happened. This talk takes five anti-hallucination techniques from demo to deployed agent: answers pulled from a knowledge graph instead of guessed, tool routing by meaning without a custom index, rules in a database you change in seconds without shipping code, self-corrected near-misses, and cross-agent checks. You see them run together on a hotel booking agent against real hallucination attempts, and you leave with the full architecture you can deploy yourself.

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, the agent's 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 just quietly cost you money and accuracy. In this hands-on session you build the fix for all three: keep large outputs out of the window and pull them back by reference, give the agent a clear done signal so fourteen calls drop to two, and hand a slow tool back a tracking id so a seventeen second freeze becomes under two. You run the broken version, build the fix, and compare the numbers. You leave with working code, an open source repo, and a simple rule for which fix each failure needs.

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 do better: it talks with you, listens, and adapts to you. You will build one that holds a real conversation out loud, catches your pronunciation and grammar slips as you speak, and corrects you one at a time without killing the flow. The demo is an English practice tutor built around a set of short stories, and it remembers each learner: their name, the words they struggled with, and their progress, so the next session picks up where they left off. The same idea works for technical onboarding, training, or anything that should adapt to the person using it.

Keep Conversation and Context Apart, Cut Your Token Bill en

Your agent fetched a large dataset to answer one question. No error. But that payload now rides along in every model call, burning your token budget. The instinct is more memory. Your agent already has two. Conversation memory holds turns and facts, recalled by meaning. Context memory holds large tool outputs like logs, recalled by an exact reference. Most token and cost failures are one stored as the other. The fix is not more memory, it is the right memory. Store large outputs outside the window and keep a short reference in context. Each memory does what it is good at, and you decide where state lives by how you recall it.

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 a slow external service, and it takes 30 seconds or never answers. The agent waits, then dies with a cryptic error. One slow dependency took down the whole run. The fix is an async call: if a tool can be slow, do not wait on it. One tool starts the work and hands back a tracking id right away, another checks if it is done. The agent stays responsive and polls for the result. That turns a 300 second hang into about a 4 second response, and timeouts and cleanup keep stalled jobs from piling up.

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

Your booking agent just charged a customer fourteen times for the same flight. It called the booking tool, got a vague response, was not sure it worked, and tried again. And again. Fourteen calls where two would do, twenty one seconds wasted, a pile of burned tokens. The cause is simple: when a tool answer is unclear, the agent cannot tell if it succeeded, so it retries. The fix is to make the answer impossible to misread. Give every tool a clear done or failed signal so the agent knows when to stop, block repeat calls before they run, and cap how many times any one tool can fire as a safety net. That takes fourteen calls down to two, and twenty one seconds to four. You leave with all three patterns ready to drop into your own agents.

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 agent passes every test you wrote, because every test assumes the world behaves. Production does not: tools return wrong data, and some users push the agent on purpose. Two kinds of trouble, and you need both. Bad luck is chaos: a weather tool returns 12 degrees for Miami in June and the agent reports it as fact. A guardrail that range-checks the value the moment a tool returns catches it. Bad intent is red teaming: an attacker escalates over several turns until the agent leaks a stored card number. You generate these multi-turn attacks instead of scripting them, then score whether the agent held. Both are stochastic: run them many times and you get a correctness rate and a breach rate, not a single pass.

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

You tried to jailbreak your own agent, it refused, and you called it secure. That told you almost nothing. A real attacker opens innocently, escalates over several turns, backs off when refused, then comes at the same goal from a new angle. That patient pressure is what breaks agents. Red teaming writes those attacks for you: it reads your agent's prompt and tools, generates multi-turn attacks for the risks you care about, like leaking a stored card number, runs them, and scores whether the agent held. The finding is uncomfortable: run the same setup many times and the agent defends most runs and breaches some. Security is not a pass, it is a rate you track.

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

Chaos Testing: When Your Agent Trusts Bad Data en

A weather tool returns 12 degrees for Miami in June, buried in a verbose dump of logs. The real value is around 31, but your agent cannot tell it is wrong, so it reports 12 as fact and pays tokens to read the junk. Your tests never caught it, because every test assumes the tool behaves. That is chaos testing: feed the agent a wrong but believable value on purpose and see if it notices. It usually does not, because the value is plausible and nothing throws an error. The fix is a guardrail that runs the moment a tool returns, before the model sees it. It range-checks the value and, on failure, swaps the whole result for a one-line error. The bad value is gone and the token cost drops at once.

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

Your research agent works great in a notebook. Then it leaks API keys in a stack trace, forgets what it researched two messages ago, and returns citations that link to pages that do not exist. One made-up citation kills trust for good. This talk fixes all three. Keep credentials out of the agent and hand it short-lived ones that expire. Give it memory that carries across turns so it builds on its own work. And check every citation before the user sees it: the link is real, the page is reachable, and it says what the agent claims. You leave with a way to ship a research agent that does not leak, does not forget, and does not invent its sources.

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

Your agent demo wowed the team. Shipping it is another story: it forgets users between sessions, you have no idea why it failed at 3 AM, it falls over at ten concurrent requests, and last month's bill was four times the estimate. The agent itself is fine. The problem is everything around it. This talk walks each piece: memory that survives a restart, a single secure entry point that turns your existing APIs into agent tools and handles their credentials, monitoring of every decision and token, scaling that absorbs spikes and drops to zero, and per-conversation budgets so cost never surprises you. You leave with a readiness checklist and a cost model that tells you the monthly bill before you ship.

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

When your agent has a lot of tools, every call packs all of their descriptions into the context window, whether the user asks about the weather or a hotel booking. That is thousands of tokens you pay for on every single query, and the bill grows with every tool you add, even for tools the request will never use. The fix is to stop sending every tool every time. Match the user's request to the few tools that actually fit and hand the model only those, so each call carries a fraction of the tokens. A shorter list also means fewer wrong tool picks, but the big win is the cost: you see the same agent run with and without this filtering on identical queries, token counts side by side, and you leave with code you can drop into your own agent.

Outline: • The Dual Problem • Solution Architecture • Live Implementation • Production Pattern • Advanced Patterns

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

A tool returns 214KB of logs. The window overflows, the agent's 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 just quietly cost you money and accuracy. This talk walks through the fix for all three: keep large outputs out of the window and pull them back by reference, give the agent a clear done signal so fourteen calls drop to two, and hand a slow tool back a tracking id so a seventeen second freeze becomes under two. You leave with working code, an open source repo, and a simple rule for which fix each failure needs.

When Prompts Fail: Enforcing Rules in Agents en

You wrote a clear rule: maximum 10 guests per booking. Your agent books 15 anyway and reports SUCCESS. To an agent, a rule written in the prompt is a suggestion, not a limit. So check it at the tool layer instead: a small piece of code inspects every tool call before it runs and compares it to your rules. But blocking is only half the answer. Rules that must never bend, like taking payment, you block hard. Limits you steer: the guardrail tells the agent what was wrong and it fixes its own call, so 15 guests becomes 10, the booking goes through, and the user is told what changed. You'll walk away knowing how to enforce a rule the agent can't talk past, and when to block versus steer.

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 an operation with full confidence: reference number, details, status. One problem, the data is made up. A single agent cannot check its own work; a plausible invented answer sounds just as sure as a real one. The fix is to stop trusting one agent to grade itself. Split the job: one agent does the work, a second independently checks that the data actually exists, and a third makes the final call. You see the same booking run through one agent that invents a hotel, then through the team that catches the lie before the user ever sees it. You'll walk away with the do, check, and decide pattern, and a simple way to tell when the extra agents are worth the cost.

Outline: • Single-Agent Hallucination • Multi-Agent Pattern • Live Implementation • Production Patterns • Advanced Applications

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

Your agent just ingested 214KB of server logs. No error, but the answer is garbage. The context window silently overflowed, the data got truncated, and the agent answered with confidence from half the information. It gets worse when several agents pass the same data between them. The fix is to stop putting big data in the window at all. Store the large output to the side and hand back a short reference, so 214KB becomes a 52 byte pointer. Agents that share the work read from that store instead of stuffing data into context. A 3 agent pipeline then handles 145KB of logs in about 14 seconds. You leave with a working pattern, a way to share that data across several agents, and a way to catch silent overflow before it reaches production.

Outline: • The Silent Killer • Memory Pointer Pattern Deep Dive • Multi-Agent State Sharing • Production Patterns • Advanced Techniques and Wrap-Up

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

Your RAG agent seems smart until you ask it to count. "How many items match X?" It answers "about 45 to 50" when the real number is 133. Vector search finds text that looks similar; it cannot count, add things up, or follow relationships across your data. The fix is to build a knowledge graph from your documents automatically, then turn each question into an exact query against that graph, so the model reports real numbers instead of inventing them. You see two agents take the same questions on the same data: one makes up results, the other gets them right every time. You leave knowing how to build it, when to use it over plain RAG, and how to combine both. All code is open source.

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

Build a Video Search Agent, Not a Pipeline en

You need to find one moment in 500 hours of video: a demo where someone mentions a pricing change while showing a dashboard. The old way extracts frames, runs OCR, transcribes the audio, builds separate text and image indexes, then queries across all of them and hopes the timestamps line up. The problem is the architecture. Treating video as separate streams means you take it apart before you can search it. Models that understand video directly skip all of that: they read what is shown, said, and on screen at once. You see a video search agent run against the old pipeline, replacing a 200-line orchestration script with a single call, plus an honest look at when the old approach is still the better choice. All code is open source.

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. It returns wrong answers when a tool output overflows the context window. It waits forever on a slow service. It calls the same tool 14 times because the response was vague. Nothing throws an error. It just wastes tokens and time. Three silent failures, three fixes, each with real numbers. When a 214KB log fills the window, store the big data outside it and pass back a short reference: about 7 times fewer tokens. When a tool hangs, return a tracking id right away and check back later, so a 17 second wait becomes under 2. When vague feedback causes retries, give a clear done signal and block repeats: 14 calls drop to 2. You leave with production-ready code and an open source repo with all demos.

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

Most teams add one guardrail and think they are safe. But an agent can hallucinate in many different ways, and each guardrail only closes one: it invents data when it finds nothing, picks the wrong tool when two look alike, ignores your rules, bends soft limits, or skips hard requirements. Using a hotel booking agent as the running example, this talk pairs five common failures with five defenses: pull answers from a structured source so the agent computes instead of guessing, route to the right tool by meaning instead of keywords, keep rules in a database you change in seconds, let the agent fix its own near-misses, and hard-block the actions it must never take. You leave knowing which defense any given failure needs.

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: 5 Techniques + Production Patterns en

A hotel booking agent that books 15 guests into a 10-person room. One that makes up occupancy numbers the database never had. One that picks the wrong tool out of 29. These are not prompt problems you can word your way out of. In this hands-on workshop you build five structural fixes yourself: pull answers from a structured source so the agent computes instead of guessing, narrow a crowded tool list to the few that match the request, add checker agents that validate the work before the user sees it, keep rules in code the agent cannot bypass, and let it correct its own near-misses. Each fix is live code with before and after numbers, plus a final part on taking them to production. You leave with working Python, an open source repo, and a way to pick the right fix for each failure. No cloud account or cost needed, sandboxes are provided.

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 and both get it right. One made a single tool call. The other called a tool it did not need, then called the same one twice more. A pass or fail test scores both 100 percent, because it only sees the final answer, not the path. But those extra calls cost tokens, latency, and money every time it runs. This talk covers two ways to catch what pass or fail misses: score the answer with a clear rubric so results are consistent and explainable, and score the path by capturing every tool call and flagging duplicates, irrelevant tools, and wrong order. Together they catch the wasteful or unsafe runs that still land on a correct answer. You leave with working code for both.

Your Agent Lies and Passes Every Test en

Your agent gives a confident answer. It sounds right, your tests say PASS, and it is completely made up. A test that only checks "did it finish the task" never catches a lie. It gets worse across a conversation: an agent can start safe and drift, one reasonable sounding turn at a time, into advice it should never give. This talk shows how to catch both: spot a fabricated answer with zero-shot detection that needs no labeled training data, score every turn so you see drift as it happens instead of only grading the final answer, and add a real-time guardrail that swaps an unsafe answer for a safe one before the user ever sees it.

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

A demo is one clean session with a friendly prompt. Production adds four things the model cannot detect on its own: it hallucinates a fact and stores it as trusted memory, it reads a poisoned web page and keeps the attacker's instruction, it ships a multi-step task where one step silently never saved, and it re-pays for the same reasoning on every call. None of these is a prompt problem. They are harness problems. This talk reproduces each failure and fixes it in the harness around the model: validate what enters memory before the write, gate the dangerous action at the tool boundary, verify each step against ground truth and retry only what failed, and turn repeated reasoning into a tool the agent writes once and reuses. You leave knowing which harness-level control each failure needs, and what each one cannot catch.

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