Fixing AI Agent Hallucinations at the

There's a category of AI agent failure that prompt engineering cannot fix. Elizabeth Fuentes, developer advocate at AWS, opened her recent workshop at the AI Engineer conference with a deliberately uncomfortable list: agents that confirm hotel bookings for nonexistent properties, agents that fabricate aggregated statistics from partial data, agents that burn through tokens selecting wrong tools because they're reading 29 tool descriptions when they need two. "Each one is a code change, not a prompt change," she said. That framing is the entire thesis.

The workshop walks through five structural interventions, each demonstrated live in a Jupyter notebook against a dummy travel agent built on Strands—the open-source agent framework AWS maintains. The demos are refreshingly honest about their own limits ("this is a demo, please, it's not something that you can use to go to production"), and the failure cases are shown before the fixes, which is exactly the right pedagogical move.

The Five Techniques, Briefly

Semantic tool selection addresses a problem that scales badly. With 29 tools loaded into context, the model reads all 29 descriptions on every single call before deciding what to use—whether the query needs a flight search or a cancellation handler. Fuentes's fix is a semantic vector index over the tool schemas: at query time, you retrieve only the handful of tools most likely to be relevant and swap everything else out of context. The token reduction in her demo was dramatic, dropping from thousands of tokens per call down to a few hundred. For agents with conversation history accumulating on top of that, the compounding cost without this technique gets ugly fast.

Graph-RAG targets a structural weakness of standard retrieval-augmented generation. As Fuentes put it: "Vector search always returns something even when nothing is truly relevant." For aggregation questions—how many hotels have a pool, what's the average rating across all properties—a vector store retrieves a handful of chunks and the LLM does math on that sample. If your dataset has 50 hotels and the retriever grabs three, you're getting an answer invented from partial information presented as fact. Her demo uses Neo4j with Cypher queries: instead of sampling, the model writes a query that runs across the full dataset and gets back a computed result. When she asks about hotels in Antarctica (there are none), the RAG agent hedges and suggests she might want to visit anyway; the graph agent says there are zero hotels listed, because the Cypher query returned zero.

Multi-agent validation adds an Executor-Validator-Critic swarm using Strands' built-in Swarm class. The core problem it addresses is that a single agent operating in one loop has no external check on its own rationalizations—it calls a tool, gets an error, and surfaces a confident success response to the user. Adding a validator and critic in sequence means fabricated confirmations get caught before they reach anyone.

Neurosymbolic guardrails are where Fuentes makes her sharpest argument: "A rule in the prompt the model reads as a suggestion. A rule in the code the model cannot escape it." Strands' lifecycle hooks let you intercept tool calls before they execute. You write business logic in Python—maximum guests per booking, payment-before-confirmation, check-in before checkout—and if parameters fail validation, the call is cancelled. Same model, same tools, same prompt; different outcome because the rules live in code, not in text the model treats probabilistically.

Runtime steering distinguishes between hard blocks and soft guidance. Lifecycle hooks are all-or-nothing: the agent stops, the user retries. But some constraints are better handled through redirection—a group of six doesn't need a hard failure, they might need two rooms. Fuentes demos this using agent-control, an open-source library that registers steering rules via API on a local server. When a rule fires, instead of blocking, it sends guidance back to the model, which self-corrects and completes the task. The practical difference she highlights is operational: changing a lifecycle hook means touching code and redeploying; changing a steering rule in agent-control means an API call that takes effect immediately.

The Governance Questions Nobody Asked During the Demo

Here's where I want to slow down, because the workshop covered the technical terrain well and left the political terrain almost entirely uncharted.

Strands is open-source. AWS open-sourced it, AWS maintains it, and Fuentes—an AWS developer advocate—is demoing it. The GitHub repository for this workshop is under her account and points to Amazon Bedrock Agent Core for production deployment. None of that is hidden; Fuentes is transparent about who she works for. But "open source" and "community governed" are not synonyms, and for developers evaluating whether to build on Strands versus LangGraph, CrewAI, or AutoGen, that distinction matters.

LangGraph ships from LangChain Inc. and has similar governance questions, but it has also accumulated substantial community contribution outside the company's own engineers and visible adoption across non-AWS infrastructure. Strands is newer to the public OSS ecosystem, and the workshop doesn't address what the contribution model looks like, who has commit rights, or how roadmap decisions get made. Those are exactly the questions that burned developers who built on frameworks that later pivoted, relicensed, or simply stagnated when corporate priorities shifted.

Agent-control, the library powering the runtime steering demo, appears even earlier in its community arc. It's genuinely useful—the separation between hard lifecycle blocks and soft steering guidance is a real architectural insight—but there's a difference between "this is open-source" and "this has a healthy contributor community that would survive if AWS deprioritized it." I don't know the answer to that question. The workshop doesn't tell me.

The production path Fuentes describes routes through Amazon Bedrock Agent Core: managed runtime, Agent Core Gateway for tool selection, DynamoDB for steering rules, CloudWatch for observability. That's a coherent production stack, and I understand why an AWS developer advocate would describe an AWS deployment story. But developers in the room building on GCP, Azure, or bare infrastructure need to understand which pieces of this technique stack are genuinely portable and which are designed to make the Bedrock migration path feel frictionless.

The Guardrails Governance Problem

The neurosymbolic guardrails section raises a question Fuentes doesn't address, possibly because it's beyond the scope of a technical workshop: who writes the steering rules in production, and who audits them?

In her demo, the rules are transparent and sensible—no double-booking, payment before confirmation, guest limits enforced. In a production deployment at, say, a financial services company or a healthcare platform, the rules encoding "business policy" into agent behavior are the policy. They determine what the agent can and cannot do on a user's behalf. When a business rule conflicts with what a user is trying to accomplish, the agent blocks or redirects without the user necessarily knowing why. That's not a hypothetical—it's the design. Fuentes demonstrates it approvingly.

For teams in regulated industries, this isn't a philosophical concern. It's compliance architecture. Who has write access to the DynamoDB table holding steering rules? What's the audit trail when a rule fires incorrectly? When a user gets steered away from an action, is that disclosed? These questions sit one layer above the technical workshop and they're not answered by picking the right Python library.

What This Workshop Actually Represents

It would be easy to read all of this as skepticism about Fuentes's work, and that would be wrong. The techniques she's demonstrating are real solutions to real problems, demonstrated with live code and honest failure cases. The insight that prompts are probabilistic suggestions while Python is deterministic logic is not novel, but articulating it clearly and showing it in runnable code is genuinely useful. Developers are shipping agents into production right now with none of these patterns in place, and the results are exactly the kinds of failures she opens with.

What the workshop represents, in a broader arc, is the developer community starting to move from "agents are hard to make reliable" to "agent reliability has named, addressable failure modes." That's a meaningful shift. The frameworks are still young, the governance structures are still thin, and the production patterns are still being invented in real time. A developer advocate at a major cloud provider giving a workshop with working code and honest demos is one part of how that knowledge propagates—and understanding who's propagating it, and why, is part of how you evaluate what you're learning.

By Dev Kapoor, Open Source & Developer Communities Correspondent, Buzzrag