Semantic tool selection reduces context and token use by giving the model only the tools relevant to the current query.
2
GraphRAG uses structured queries for counts, aggregations, and relationship-based questions where vector retrieval can make the model guess.
3
Validation agents, code-enforced rules, and runtime steering catch errors or help the agent correct them before the user receives a false result.
Summary
Elizabeth Fuentes presents five code-level techniques for reducing hallucinations and wasted tokens in AI agents. Semantic tool selection filters a travel agent's 29 tools down to the few relevant to each request. GraphRAG uses a Neo4j knowledge graph and Cypher queries for exact counts, averages, and relationship queries instead of asking a model to calculate from retrieved text chunks. A multi-agent swarm separates execution, validation, and criticism so tool errors do not become confident success messages. Neurosymbolic guardrails enforce business rules in Python hooks before tools run. Runtime steering handles softer rules by changing the agent's plan and continuing the task. The demos use Strands, OpenAI, local embeddings, file storage, and Neo4j. The final section maps these patterns to Amazon Bedrock AgentCore services, including Gateway, memory, observability, policies, and live steering rules.
Filtering tools before each call cuts unnecessary context
A travel agent with 29 tools sends every tool schema to the model on every request. Fuentes explains that each schema can use roughly 17 to 200 tokens, adding around 3,000 tokens before the user message and response. She builds a local tool database with embeddings, searches it for each query, and passes only the three most relevant tools to the agent. In her demo, usage falls from thousands of tokens to fewer than 300 for the tool descriptions. For conversations, she also swaps tools in and out of the agent loop so old tool definitions do not remain in the growing context.
Graph queries give exact answers for aggregation and relationship questions
Vector retrieval works for open questions, but it can fail when an agent must count, average, or traverse relationships across the full dataset. Retrieval returns a small sample of chunks, and the model may calculate from that sample as though it were the whole database. Fuentes builds a knowledge graph from text in Neo4j and has the model write a Cypher query. The graph executes the query across all the data and returns a computed result. Her examples compare hotel averages, amenity counts, room prices, and a search for hotels in Antarctica. The graph returns zero for Antarctica, while ordinary retrieval produces lengthy and uncertain answers.
A separate validation chain exposes failures hidden by the acting agent
A single agent can call a tool, receive an error, rationalize the failure, and return a confident success message. Fuentes uses a Strands swarm to separate these jobs among an executor, validator, and critic. The executor performs the booking, the validator checks what happened, and the critic approves or rejects the result. In the booking demo, the single agent claims success for an unknown hotel. The swarm receives the tool error, the validator identifies the problem, and the critic rejects the response. The user sees a clear failure instead of a fabricated confirmation.
Business rules need executable hooks because prompts are suggestions
Fuentes demonstrates rules such as checking that checkout follows check-in, limiting a booking to ten guests, requiring payment before confirmation, and preventing late cancellations. A prompt can state these requirements, but the model can still call a tool with invalid parameters because it processes the rule as text. Strands hooks run automatically before a tool executes. The hook inspects the call and cancels it when a rule fails. Her comparison uses the same model, tools, and prompt with and without the hooks. The unguarded agent confirms a booking without payment and exceeds the guest limit. The guarded agent blocks those calls.
Runtime steering lets an agent recover from soft constraints
Hooks are suitable for hard constraints because they stop an invalid tool call. Some situations need a different response. A room may fit four guests while six guests could be accommodated by splitting the reservation, or a full flight may have availability on the next one. Fuentes uses the Agent Control library to register steering rules on a local server through an API. The agent receives a decision and adjusts its plan instead of stopping. In the demo, a request for 50 guests is changed into a reservation split across two rooms. The rules can be updated without changing the agent code or redeploying the agent.
Production deployment separates agent runtime, tools, rules, and data services
Fuentes maps the local demos to Amazon Bedrock AgentCore. The agent runs inside the runtime, while Gateway routes tool calls to Lambda functions. Short-term and long-term memory, CloudWatch observability, and production policy support are part of the architecture she shows. Steering rules live in DynamoDB, so changing them affects the next call without a redeployment. Teams can keep using an external graph database such as Neo4j Aura DB. The repository includes notebooks and an application, along with deployment paths using a notebook or AWS CDK. The demos are intended as starting points rather than production-ready applications.
"A rule in the prompt the model read it as a suggestion. A rule in the code the model cannot escape it."36:31
Who should watch
You are building an agent that sends too many tool definitions or conversation tokens on every request and want a working filtering pattern.
Your agent answers counts, averages, or existence questions from retrieved text and needs a way to query structured data instead.
You need business rules that agents cannot ignore, or you want failed actions to be checked and corrected before users see them.
