Your Agent Works on Localhost. Now Ship It en

Your anti-hallucination tricks 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, and a custom search index nobody wants to maintain. The hard part of a reliable agent is not the technique, it is making the technique survive production. This talk takes five anti-hallucination techniques from a demo to a deployed agent: pulling answers from a structured source instead of guessing, routing to the right tool without a custom index, keeping your rules in a database so you change a limit in seconds without shipping new code, letting the agent fix its own near-misses, and checking results across more than one agent. You see them run together on a hotel booking agent, against real hallucination attempts and rule violations. You leave with the whole architecture you can deploy yourself, not just the ideas.

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? Build the Three Fixes, Live 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 on vague feedback. A third freezes seventeen seconds on a slow tool and times out. None of them crash. They just quietly cost you money and accuracy as your data grows. In this hands-on session you build the fix for all three yourself. Keep large tool outputs out of the window and pull them back by reference, so the data stops riding along on every turn. Give the agent a clear done signal and block repeat calls so a runaway loop drops from fourteen calls to two. Hand a slow tool back a tracking id and check on it later, turning a seventeen second freeze into under two. You run the broken version, build the fix, and compare the numbers. You leave with working code for all three, a simple rule for which fix each failure needs, and an open source repo. It works with any agent framework.

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: • Apply the two memory model to decide where any piece of agent state belongs before you write a tool • Design context offloading with a framework plugin so large tool outputs never re enter the window and your tools stay ordinary functions • Evaluate exact reference storage against semantic recall and choose the right one per data type • Build the production split across a managed memory service and object storage without leaking large payloads into the conversation • Implement selective tools that return summaries so the offloader stays a safety net, not the 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

ZZZ REUSAR — The Art of Prompt Engineering: Unlocking the Full Potential of Generative AI en

The rise of generative AI has made prompt engineering an essential skill. Through practical examples I'll demonstrate how to craft effective prompts that maximize AI models' potential, learn proven techniques, and understand how small changes in prompts can significantly impact AI responses. Whether you're new to AI or an experienced practitioner, you'll discover the strategies that make the difference between basic and exceptional AI interactions.

ZZZ REUSAR — Building Vector Search Solutions for Text, Images, and Video Content en

Data exploration has moved beyond text; now data encompasses images and videos. In today's data-driven world, processing and analyzing large volumes of data efficiently is crucial for many applications. Let's explore together the concept of RAG and how to create and manage text and image embeddings for similarity searches in a PostgreSQL database. We'll dive into a practical example using Python to show you how to create vector bases of images and text for smarter searches. Additionally, we'll explore how to search and understand videos

Let's explore together the concept of RAG and how to create and manage text and image embeddings for similarity searches in a PostgreSQL database. We'll dive into a practical example using Python to show you how to create vector bases of images and text for smarter searches. Additionally, we'll explore how to search and understand videos.

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, buried in junk, and the agent reports it as fact while paying tokens to read the noise. A guardrail that range-checks the value the moment a tool returns catches it, fixing accuracy and cost at once. Bad intent is red teaming. An attacker escalates over several turns until the agent leaks a stored card number or books above its limit. You generate these multi-turn attacks instead of scripting them, then score whether the agent held. Both are stochastic: run them once and you learn little, run them many times and you get the real picture, 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 does not stop at one. They open innocently, escalate over several turns, back off when refused, then come 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 or booking above a limit, 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. One clean pass is falsely reassuring; one breach is not a verdict.

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

ZZZ REUSAR — Building Production-Ready Generative AI Applications: From Concept to Deployment en

Learn to build, optimize, and deploy production-grade generative AI applications using AWS services. This hands-on workshop guides participants through the entire development lifecycle, from initial concept to production deployment, focusing on best practices, security considerations, and scalable architectures. Free test environment

Target Audience:
- Software developers with intermediate Python experience
- ML/AI practitioners interested in generative AI
- Solution architects planning AI implementations
- Technical leads evaluating gen AI solutions

Prerequisites:
- Basic Python programming experience
- Familiarity with AWS console
- Understanding of basic ML concepts
- Laptop with admin rights to install required tools

ZZZ REUSAR — Extending AI agents: Custom tools and Model Context Protocol en

As AI agents become increasingly prevalent in production systems, you face a critical challenge: extending these agents beyond their base capabilities to interact with proprietary systems, custom APIs, and domain-specific tools.

In this session, you'll build a fully functional AI agent using Strands Agents, an open-source framework, with minimal code. You'll learn how to enhance your agent's capabilities by integrating three types of tools: native framework tools, custom implementations, and Model Context Protocol (MCP) servers.

As AI agents become increasingly prevalent in production systems, you face a critical challenge: extending these agents beyond their base capabilities to interact with proprietary systems, custom APIs, and domain-specific tools.

In this session, you'll build a fully functional AI agent using Strands Agents, an open-source framework, with minimal code. You'll learn how to enhance your agent's capabilities by integrating three types of tools: native framework tools, custom implementations, and Model Context Protocol (MCP) servers

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 three citations, two of which link to pages that do not exist. The demo everyone loved is now a liability. Research agents break in ways generic deployment guides miss. They call several external services with different logins, they build on what they found a few turns ago so they need memory most setups throw away, and they have to show real sources, because 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 actually 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

ZZZ REUSAR — Building video search agents with TypeScript in minutes en

Build a production-ready video search agent from scratch using modern TypeScript frameworks. We'll create semantic video search, visual Q&A, and smart summaries in minutes—with clean, type-safe code you can ship today.

Build a video search agent from scratch in minutes. Using TypeScript, Strands Agents, and TwelveLabs, we'll create semantic video search with visual understanding and smart summaries. Production-ready code included.

Ship It: From Agent Demo to Production in Minutes en

Your agent demo wowed the team. Shipping it to production 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 gap between a demo and a real system is where agent projects stall. 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 for you, 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 Agent Call en

When your agent has a lot of tools, every single 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 wasted tokens on every query, and a long, crowded list also makes the model more likely to pick the wrong tool. The more tools you add, the worse both problems get. 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. Fewer tokens per call, and a shorter, cleaner choice means fewer wrong picks. You see the same agent run with and without this filtering on identical queries, with the token count and error rate 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 on vague feedback. A third freezes seventeen seconds on a slow tool and times out. None of them crash. They just quietly cost you money and accuracy as your data grows. This talk walks through the fix for all three. Keep large tool outputs out of the window and pull them back by reference, so the data stops riding along on every turn. Give the agent a clear done signal and block repeat calls so a runaway loop drops from fourteen calls to two. Hand a slow tool back a tracking id and check on it later, turning a seventeen second freeze into under two. You leave with working code for all three, a simple rule for which fix each failure needs, and an open source repo. It works with any agent framework.

Block, Then Steer: Guardrails Your Agent Can't Talk Past en

You wrote a clear rule: maximum 10 guests per booking. Your agent books 15 anyway and reports SUCCESS. The rule was ignored, because to an agent a rule written in the prompt is a suggestion, not a limit. It is the problem web apps solved long ago: do not trust the input, check it before the action runs. So check it at the tool layer instead. A small piece of code looks at every tool call before it happens and compares it to your rules. The prompt-only agent lets every violation through, the guarded one stops them. But blocking is only half the answer. Some rules must never bend, like taking payment, so you block hard. Others are just limits, so instead of dead-ending you steer: the guardrail tells the agent what was wrong, and it fixes its own call. Fifteen guests becomes ten, 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 hard versus steer it to self-correct.

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. The agent invented the whole result, and your user will not find out until it causes real damage. A single agent cannot check its own work. When it writes a plausible answer, nothing tells the real data from the invented data, and it sounds just as sure either way. The fix is to stop trusting one agent to grade itself. Split the job: one agent does the work, a second one independently checks that the data actually exists, and a third makes the final call. They hand off to each other on their own, sharing what they know. 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 for your own agents, and a simple way to tell when a second and third agent are worth the extra 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 cause is architectural. RAG pulls chunks of text that resemble your question and asks the model to write an answer from them. That is fine for looking one thing up, but it breaks on counting, totals, multi-step questions, and "is this even in my data" checks. 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 side by side: 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 search indexes, then queries across all of them and hopes the timestamps line up. That is not retrieval, that is suffering. The problem is the architecture. Treating video as separate streams means you take it apart before you can search it, and the glue that holds those parts together becomes the most fragile piece you own. 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 multi-tool pipeline, replacing a 200-line orchestration script with a single call, plus an honest look at when the old decomposition 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 gets stuck. It returns wrong answers when a tool output overflows the context window. It waits forever when a tool calls a slow service. It calls the same tool 14 times because the response said more results may be available. 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 on a slow service, return a tracking id right away and check back later, so a 17 second wait becomes under 2. When vague feedback makes the agent retry, give it a clear done signal and block repeats: 14 calls drop to 2. You'll walk away with: • Three production-ready patterns you can implement the same day • Working code with real metrics for each fix • An open-source repository 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 of them. It invents data when it finds nothing, picks the wrong tool when two look alike, ignores the rules you set, bends soft limits, or skips hard requirements. Using a hotel booking agent as the running example, this talk walks through five of the most common failures, each paired with its own defense. Pull answers from a structured source so the agent computes instead of guessing. Route to the right tool by meaning, not keyword matching. Keep the rules in a database so you change them in seconds without shipping new code. Let the agent fix its own near-misses, so a request for 15 guests becomes a booking for 10 with a note to the guest. And hard-block the actions it must never take. You leave with these five defenses and a way to decide which one any 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 and burns tokens on every call. These are not prompt problems you can word your way out of. They need structural fixes. In this hands-on workshop you build five of them yourself, on a hotel booking agent. Pull answers from a structured source so the agent computes instead of guessing. Narrow a crowded tool list down to the few that match the request. Add a second and third agent that check the work before the user sees it. Keep your rules in code the agent cannot bypass. And let it correct its own near-misses instead of dead-ending. Each one is live code with before and after numbers, and a final part on taking them to production. You leave with working Python, a way to pick the right fix for each failure, and an open source repo. 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, and still got there. A pass or fail test scores both 100 percent, because it only sees the final answer, not the path. But those extra calls are real: more tokens, more latency, more cost, every time it runs. This talk covers two ways to catch what pass or fail misses. Score the answer with a clear rubric so the results are consistent and explainable, not a vague "is this good". And score the path: capture every tool call and flag 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, because the agent looks just as sure when it invents an amenity as when it reports a real one. It gets more dangerous across a conversation. An agent can start safe and slowly drift, one reasonable sounding turn at a time, into advice it should never give. If you only grade the final answer, you miss the moment it went wrong. This talk shows how to catch both: spot a fabricated answer without any training data, score every turn so you see drift as it happens, and add a guardrail that swaps an unsafe answer for a safe one before the user ever sees it. You'll walk away with: • Zero-shot detection that needs no labeled training data • Per-turn monitoring that catches drift before harm • Real-time guardrails that block unsafe output before delivery

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

A demo is one clean session with a friendly prompt. Production is a different problem, and the same agent that dazzled in the demo starts failing in ways the model cannot detect on its own. It hallucinates a fact and writes it to memory, where it reloads as trusted context every future session. It reads a poisoned web page and stores the attacker's instruction as if it were its own. It books a three-step trip, trusts every tool that says "confirmed", and ships a trip with a step that silently never saved. It re-reasons the same deterministic answer a thousand times, miscounting and re-paying for it on every call. The instinct is to fix it in the prompt: a sharper system prompt, more rules, a bigger model. None of that holds, because none of these is a prompt problem. They are harness problems. This talk reproduces each failure, then 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 with a way to decide which harness-level control any given failure needs, and an honest account of what each control can and 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