Ensuring AI Agent Reliability: From Hallucination Prevention to Exception Handling — A Practical Python Code Guide

Ensuring AI Agent Reliability: From Hallucination Prevention to Exception Handling — A Practical Python Code Guide

In the previous episode, we looked at how AI agents are evolving beyond simple chatbots into “intelligent workflows” that carry out complex tasks. An agent’s potential is unlimited, but it is just as easy to hit the wall of reliability. You have probably all had the experience of something that looks perfect in theory but keeps producing off-the-wall results once you actually ship it.

AI agent reliability cannot be secured with a simple “write your prompts carefully” guideline. Like a car’s seatbelt or airbag, defensive mechanisms (guardrails) that are robustly designed at the code level are essential.

The goal of this article is to turn the abstract idea of “reliability” into concrete Python code blocks you can immediately test and apply in your development environment. Let’s move beyond theory and look at practical code that makes agents more resilient.

Implementing a Guardrail to Verify the Truthfulness of Search Results

The most common problem is hallucination. Even with RAG (retrieval-augmented generation), retrieved documents may not fit the context, or the LLM may misinterpret the retrieved information and draw the wrong conclusion.

Simply stuffing search results into a prompt and instructing “answer based on this” is equivalent to offloading verification onto the LLM. That is very dangerous.

💡 Key comparison: Prompt instructions vs. code-based validation

In a real service, you absolutely need a layer that validates in code whether the retrieved information satisfies specific conditions. For example, if the rule is “you must only use data from 2023 onward,” you should filter in code instead of leaving it to the LLM.

The following is an example Guardrail function that takes search results (Context) and checks whether they satisfy a specific business rule (e.g., a date range).

from datetime import datetime

def validate_context_by_date(context_chunks: list[str], required_year: int) -> bool:
    """
 required Guardrail .
    """
 print("--- [Guardrail] Context when ---")
    valid_count = 0
    for i, chunk in enumerate(context_chunks):
 # . NLP .
        if f"{required_year}" in chunk:
 print(f"✅ {i+1}: {required_year} . .")
            valid_count += 1
        else:
 print(f"❌ {i+1}: {required_year} .")

 # 2
    if valid_count >= 2:
 print("✅ : . run .")
        return True
    else:
 print("🛑 failed: required . User Request .")
        return False

# example:
context_data = [
 "2022 when ...",
 "2023 AI .",
 "2024 ."
]
can_proceed = validate_context_by_date(context_data, required_year=2023)

A State Management Pattern That Doesn’t Lose Conversation Context

When an agent goes through multi-step conversations, it can forget the context of the initial conversation, or the order of information the user wants can get tangled. This is a state-management problem.

Frameworks like LangChain provide a Memory component, but simply storing things in memory is not enough. As conversations get longer, the memory itself grows too large, increasing cost and diluting key information.

The solution is summary-based memory management. When conversation history reaches a certain length, you have the LLM produce a core summary of the entire conversation record and use that summary as the context for the next step. This is the most stable approach.

# LangChain .
def summarize_and_manage_memory(chat_history: list[str], max_tokens: int) -> str:
 """ ."""

 # 1. .
 summary_prompt = f" , User 3 . ( {max_tokens} )"

 # 2. LLM call ( LLM API call .)
    # summary = llm_call(summary_prompt + "\n" + "\n".join(chat_history))

 # when Result
 summary = "User A B . compare ."

 print(f"✅ : {summary}")
    return summary

# example
history = ["User: A ?", "AI: 10.", "User: B ?"]
new_memory = summarize_and_manage_memory(history, 500)

🚨 Exception Handling: Preparing for Failure Scenarios

The most important piece is exception handling. Every API call or external service integration can fail.

def execute_api_call_with_retry(endpoint: str, payload: dict, max_retries: int = 3):
 """API call when, failed when (Exponential Backoff) when."""
    for attempt in range(max_retries):
        try:
 print(f"➡️ when : {endpoint} (when {attempt + 1}/{max_retries})")
 # API call (requests.post(endpoint, json=payload))

 # when: 3 when
            if attempt >= 2:
 return {"status": "SUCCESS", "data": " ."}
            else:
 raise ConnectionError(" ")

        except ConnectionError as e:
            if attempt < max_retries - 1:
 wait_time = 2 ** attempt # 1, 2, 4...
 print(f"⚠️ failed: {e}. {wait_time} after when.")
                import time; time.sleep(wait_time)
            else:
 print("❌ when failed. .")
 return {"status": "FAILED", "error": f" failed: {e}"}
 return {"status": "FAILED", "error": " "}

# run example
result = execute_api_call_with_retry("/api/data", {"query": "latest"})
print(f"\n Result: {result}")

💡 Summary and Core Principles

1. Guardrail: Do not blindly trust LLM output. Always force structured data with regular expressions or separate validation logic.
2. State Management: To avoid losing conversation context, periodically summarize conversation history and keep only core memory.
3. Resilience: You must implement retry logic and exponential backoff to prepare for network errors or API rate limits.