Multi-Agent Reasoning Loops: Failure Modes & Mitigations in One-tap UPI Payments

Welcome, future AI engineers! When we talk about Generative AI, building a single chatbot is easy. But building a Multi-Agent System (MAS)—where multiple AI agents work together to solve a complex problem—is where the real magic (and the real headaches) happens.

Today, we are going to explore the failure modes in multi-agent reasoning loops and how to mitigate them. To make this practical, we will use a real-time fintech use case: Executing a "Zero-Login" UPI Payment.

The Real-Time Use Case: "Zero-Login" UPI Payments

Imagine a user is on a web browser or a smart TV. They want to make a payment, but they do not want to log into the mobile app. We need to support three entry points:

Pay to Mobile Number
Scan any QR Code and Pay
Pay using UPI ID

How It Works Without Login?

The user enters the details on a "Guest Portal". Our AI backend validates the request, creates a secure temporary guest session, and sends a Push Notification to the user’s already logged-in primary banking app (like GPay, PhonePe, or their Bank's app). The user simply taps "Approve" on the notification. No app login is required for this session!

High-Level Design (HLD): The Multi-Agent Architecture

To handle this, we don't use one monolithic LLM. We use a team of specialized agents:

The Intent & Parsing Agent: Reads the input (Mobile/QR/UPI ID) and extracts the Virtual Payment Address (VPA) and amount.
The Validation Agent: Pings the NPCI/Bank API to check if the VPA exists and the bank is live.
The Security Agent: Generates a secure, time-bound "Guest Token" without requiring a full app login.
The Execution Agent: Triggers the push notification to the user's primary device and listens for the "Approved" callback.

These agents operate in a Reasoning Loop, passing messages to each other until the payment is successful or fails.

Failure Modes Observed in Multi-Agent Loops

When agents talk to each other, things can go wrong in fascinating ways. Here are the top 4 failure modes I have observed, along with simple analogies to help you understand them.

1. The Infinite Buck-Passing Loop (Deadlock)

What happens: Agent A needs data from Agent B, but Agent B says, "I can't do this until Agent A gives me X." They pass the task back and forth infinitely.
Analogy: Two people meeting at a narrow door. Person 1 says, "After you." Person 2 says, "No, after you." Neither walks through.
In our Use Case: The Validation Agent says, "I need the Guest Token to validate the VPA." The Security Agent says, "I need the VPA to be validated before I issue a Guest Token." The loop never ends.

2. The Hallucination Cascade (The "Yes-Man" Effect)

What happens: Agent 1 hallucinates a fake piece of data. Agent 2 trusts Agent 1 and builds on that fake data. Agent 3 compounds the error.
Analogy: The childhood game of "Telephone". The first person whispers a wrong word, and by the time it reaches the last person, the meaning is completely destroyed.
In our Use Case: The Parsing Agent misreads a scanned QR code and hallucinates a fake UPI ID (user@okfake). The Execution Agent tries to send a push notification to a non-existent server, crashing the pipeline.

3. Context Window Overflow (State Amnesia)

What happens: Agents keep chatting. The conversation history grows so large that it exceeds the LLM’s context window. The system "forgets" the original user request.
Analogy: A team meeting that goes on for 4 hours. By the end, everyone has forgotten what the meeting was originally about and are just arguing about minor details.
In our Use Case: The agents spend 15 iterations arguing about the formatting of the QR string. When they finally try to process the payment, they forget the original Amount the user wanted to pay.

4. Goal Drift (The Over-Enthusiastic Intern)

What happens: An agent tries to be "too helpful" and starts doing tasks outside its scope, derailing the main objective.
Analogy: You ask an intern to "book a flight." They book the flight, but then also book a hotel, rent a car, and sign you up for a frequent flyer program, delaying the whole process.
In our Use Case: The Intent Agent is asked to extract the UPI ID. Instead, it decides to also check the user's credit score and fetch their transaction history, wasting API calls and time.

Mitigation Strategies: How We Fix Them

As AI Engineers, our job is to build guardrails. Here is how we mitigate these failures in production.

Mitigation 1: Enforce Directed Acyclic Graphs (DAGs) & Max Iterations

To prevent infinite loops, we never let agents chat freely in a circle. We use a State Machine (like LangGraph). The flow must strictly move forward:

Parse → Validate → Secure → Execute

Fix: We implement a hard max_iterations limit. If the loop exceeds 5 steps, it forcefully triggers a "Human-in-the-Loop" fallback or throws a timeout error.

Mitigation 2: Strict Pydantic Schemas (The Ultimate Truth)

To prevent hallucination cascades, agents never pass free text to each other. They must pass strictly validated JSON objects.

Fix: We use Pydantic models with Annotated and Field. If Agent 1 outputs a hallucinated UPI ID that doesn't match the regex pattern, Pydantic rejects it immediately before Agent 2 ever sees it.

Mitigation 3: The "Blackboard" Architecture (Shared Memory)

To prevent context overflow, agents do not read a long chat history. Instead, they read and write to a central, shared JSON state (the "Blackboard").

Fix: Each agent only extracts the specific keys it needs from the shared state, keeping the context size tiny and focused.

Mitigation 4: Single-Responsibility Prompting

To prevent goal drift, we restrict each agent's system prompt to exactly one job.

Fix: The Intent Agent prompt explicitly states:

"You are a parser. Extract VPA and Amount. Do NOT call any other tools. Do NOT fetch user history."

Code Sample: Mitigating Failures with FastAPI & Pydantic

Let’s look at how we implement Mitigation 2 (Strict Pydantic Schemas) to stop hallucinations in our UPI use case. We will use FastAPI and Pydantic's Annotated to enforce strict validation on the agent's output.

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, Field, ValidationError
from typing import Annotated, Literal, Optional
import re

app = FastAPI(title="Zero-Login UPI Multi-Agent System")

# --- 1. The Shared State (Blackboard) ---
class PaymentState(BaseModel):
    """
    This is the central memory. Agents read/write here.
    Using Annotated and Field to enforce strict validation and prevent Agent hallucinations.
    """
    input_type: Literal["MOBILE", "QR_CODE", "UPI_ID"] = Field(
        ..., description="The type of input provided by the user"
    )
    raw_input: str = Field(..., description="The raw mobile number, QR data, or UPI ID")

    # Strict Regex validation for UPI ID to prevent hallucinated VPAs
    extracted_vpa: Annotated[
        Optional[str],
        Field(pattern=r"^[\w.-]+@[\w.-]+$", description="Must be a valid UPI format like name@bank")
    ] = None

    amount: Annotated[
        float,
        Field(gt=0, lt=100000, description="Amount must be between ₹1 and ₹99,999")
    ] = 0.0

    guest_session_token: Optional[str] = None
    status: Literal["INITIATED", "VALIDATED", "APPROVED", "FAILED"] = "INITIATED"

# --- 2. The "Critic" Agent (Validation Guardrail) ---
def critic_agent_validate_vpa(state: PaymentState) -> PaymentState:
    """
    This agent acts as a guardrail. If the Parsing Agent hallucinated a bad UPI ID,
    Pydantic will catch it here during model_dump() or validation.
    """
    if state.input_type == "UPI_ID":
        # Simulating the Parsing Agent trying to set a hallucinated VPA
        # Let's say it hallucinates "fakeupi@okaxis" (which is actually valid format)
        # but what if it hallucinates "not-a-upi-id"? Pydantic pattern will block it!
        try:
            # Updating state with extracted VPA
            state.extracted_vpa = state.raw_input

            # Re-validating the entire state to ensure no rules were broken
            validated_state = PaymentState(**state.model_dump())
            validated_state.status = "VALIDATED"
            return validated_state

        except ValidationError as e:
            # MITIGATION IN ACTION: Catching the hallucination before it reaches the Execution Agent
            print(f"🛑 Hallucination Blocked by Pydantic: {e}")
            state.status = "FAILED"
            return state

    return state

# --- 3. FastAPI Endpoint ---
@app.post("/api/v1/upi/guest-pay")
async def initiate_zero_login_payment(payment_request: PaymentState):
    """
    Entry point for the user.
    FastAPI automatically validates the incoming JSON against our Pydantic model.
    """
    # 1. Parse Agent runs (simulated)
    current_state = payment_request

    # 2. Critic/Validator Agent runs
    final_state = critic_agent_validate_vpa(current_state)

    if final_state.status == "FAILED":
        raise HTTPException(status_code=400, detail="Invalid UPI format. Please check and try again.")

    # 3. Security & Execution Agents would run next...
    return {
        "message": "Validation successful. Sending push notification to your primary banking app.",
        "session_token": "guest_89237492", # Generated by Security Agent
        "vpa_masked": f"***@{final_state.extracted_vpa.split('@')[1]}"
    }

# Example of how model_dump(exclude={"id"}) is used to send clean data to the next agent
def prepare_for_execution_agent(state: PaymentState):
    # We exclude internal tracking fields before passing to the Execution Agent
    clean_payload = state.model_dump(exclude={"raw_input"})
    return clean_payload

Key Takeaways for Students

Never trust free text between agents: Always use strict data models (like Pydantic) to pass data. This is your first line of defense against hallucinations.
Control the flow: Use State Machines or DAGs instead of letting agents chat freely. Define exactly who speaks next.
Shared Memory is better than Chat History: Use a centralized "Blackboard" (a JSON state) so agents don't suffer from context window overflow.
Fail Fast: If an agent makes a mistake, catch it immediately with validation and throw a clear error, rather than letting the error cascade down the loop.

Building multi-agent systems is less about prompting the LLM perfectly, and more about building a robust software engineering architecture around the LLM.

Summary

Multi-agent systems introduce powerful capabilities but also create new failure modes such as deadlocks, hallucination cascades, context overflow, and goal drift. By enforcing DAG-based workflows, validating agent outputs with strict Pydantic schemas, using a shared blackboard architecture, and applying single-responsibility prompting, AI engineers can build reliable, scalable, and production-ready multi-agent systems that minimize errors and maintain predictable behavior.