The Prevention Stack: AI Agent Prevention Beyond Observability

Observability shows you the fire. The Prevention Stack stops it. Four runtime components with specific defaults for AI agent governance.

1. Why Do AI Agents Need Prevention, Not Just Observability?

Observability is essential. And insufficient.

LangSmith gives you structured traces of every LLM call, tool invocation, and reasoning step. That's enough to diagnose prompt failures, tool failures, retrieval issues, and orchestration bugs. Their tracing works with any framework, adds no latency, and runs in managed cloud, BYOC, or self-hosted setups. [Source: LangChain - LangSmith Observability]

Arize Phoenix provides AI observability with OpenTelemetry-based instrumentation, LLM-as-a-judge evaluations, drift monitoring, and retrieval quality metrics. Their online evals run on production traffic to monitor correctness, hallucination, relevance, and latency in almost real time. [Source: Arize - Agent Observability]

Both are useful tools that solve real problems. And both hit the same ceiling.

The observability ceiling is the gap between knowing what happened and preventing it from happening again. LangSmith shows what happened and Arize evaluates outputs, but neither stops the next failure.

None of this criticizes their design. Observability tools are built to answer "what happened?" and "how bad was it?" Those are the right questions for traditional software. For autonomous agents that take actions, spend money, and interact with customers, the question that matters is different: "Should this be allowed to happen at all?"

A comparison from the Galileo vs Arize analysis (as of November 2025) captures the gap precisely:

"There's no lifecycle management between your offline evaluations and runtime protection. The systems remain disconnected. If you need runtime blocking, you're building it yourself or paying for multiple platforms."

[Source: Galileo — Galileo vs Arize Comparison, Nov 2025]

The observability loop works like this: agent fails in production, traces capture the failure, the engineer diagnoses the root cause and deploys a fix. Next week, the same category of failure happens again. This loop keeps going because the traces show you the fire after it has burned. They don't put in the sprinkler system.

The first two rows are table stakes. The last four rows are the Prevention Stack.

2. What Does AI Agent Prevention Look Like?

Prevention means stopping failures before they cause damage, not diagnosing them after.

The shift is from a reactive cycle to a proactive architecture:

Reactive (observability-only): Agent fails → Traces capture failure → Engineer investigates → Engineer deploys fix → Different failure happens → Repeat.

Proactive (prevention): Define bounds → Agent executes within bounds → Violation detected → Execution halted → Alert sent → No damage produced.

Not a new concept in software or devops. Circuit breakers, rate limiters, and input validators have existed for decades. But the agent ecosystem largely skipped these patterns. Most agent frameworks ship with zero runtime constraints. The agent runs until done — and the LLM decides what "done" means.

Real incidents demonstrate the cost of this gap:

• The $47K Loop: A reported incident describes autonomous agents entering a recursive loop that ran for 11 days, accumulating a reported $47,000 in API costs before anyone noticed. Observability existed. Nobody was watching the dashboard. A $10 cost ceiling would have stopped this in minutes. [Source: Tech Startups - $47,000 AI Agent Failure]
• Air Canada Chatbot: An AI chatbot provided incorrect bereavement fare policy to a customer, leading to a tribunal ruling that Air Canada was liable for its chatbot's negligent misrepresentation. Observability logs existed. The wrong answer still reached the customer. [Source: American Bar Association - Moffatt v. Air Canada]

In both cases, the infrastructure to observe the failure existed. The infrastructure to prevent it did not.

3. Component 1: Loop Detection

The problem it solves: Agents that get stuck in infinite or near-infinite loops, repeating the same actions without making progress, consuming resources until something external stops them.

How do loops happen? Agent loops don't always look like obvious infinite recursion. They appear as:

• Retry storms: Agent calls a tool, gets an error, retries, gets the same error, retries again. Without a retry cap, the retries go on indefinitely.
• Circular dependencies: Agent A asks Agent B for information. Agent B asks Agent A to clarify. Agent A asks Agent B again. This pattern is especially likely to happen in multi-agent systems.
• Recursive reasoning: Agent determines it needs more information to answer a question. Gathers information. Finds out it needs even more. The "research" phase never terminates because the LLM keeps finding gaps.
• Unclear completion criteria: The agent keeps working because it doesn't know when it's "done." No termination condition means no termination. [Source: Codieshub - Prevent Agent Loops]

The reported $47K Loop in detail. According to a November 2025 report, an engineer deployed a multi-agent research tool built on a common open-source stack. Two agents were designed to work together on research tasks. They entered a recursive loop, passing requests back and forth, each agent treating the other's output as a new input requiring processing. The loop reportedly ran for 11 days. The API bill: a reported $47,000. The root cause: no loop detection, no cost ceiling, no step limit. [Source: Tech Startups - $47,000 AI Agent Failure]

How loop detection works. The detection mechanism tracks action sequences and identifies repetition:

1. Pattern matching on action sequences. Three repetitions of the same tool-call sequence (same tools, same or similar parameters) — flag the agent as looping.
2. Similarity detection. Even if parameters vary slightly, a high similarity score across consecutive action sequences triggers detection.
3. Configurable threshold. Default: detect after 3 iterations of a repeated pattern. Adjustable per use case. Research agents might need a higher threshold. CX agents should be stricter.

When a loop is detected: Execution halts gracefully. The agent gets a structured signal (not an error) indicating the loop was detected. A human-readable summary is generated, and an alert is sent.

The agent doesn't crash. It stops doing the wrong thing.

4. Component 2: Cost Bounds

The problem it solves: Unbounded API spend during agent execution.

Agents consume tokens on every LLM call. They also invoke external APIs with their own pricing. An agent calling the OpenAI API, a Google Maps API, and a Stripe API in one session accumulates costs across multiple billing dimensions. Without a ceiling, a single agent run has no upper cost bound.

Default: $10 per run.

This isn't random. The $10 default is a circuit breaker calibrated to be generous enough for complex tasks while preventing catastrophic spend. Most real agent tasks, even multi-step ones, complete well under $10 in API costs. If a task exceeds $10, it's either unusually complex (and should be monitored) or something has gone wrong.

How it works:

1. Cost accumulation in real time. Every LLM call and tool invocation linked to your API keys has an estimated or actual cost. The governance layer tracks cumulative spend per session.
2. Soft warning at 80%. At $8, the agent receives a cost-ceiling-approaching signal. Well-designed agents can use this to prioritize remaining work.
3. Hard cutoff at 100%. At $10, execution halts. The agent produces a summary of work completed and work remaining. This session cannot make any more API calls.

Why this matters beyond the $47K incident. The new attack vector called "Denial of Wallet" or "Agentic Resource Exhaustion" uses autonomous agent loops to deliberately drive up compute costs. In a pay-per-token world, an attacker who can trigger a recursive agent loop can drain your API budget in minutes. Cost bounds are not just operational hygiene. They are a security control. [Source: InstaTunnel - Agentic Resource Exhaustion]

Google Cloud's guidance covers both halves of the problem. First, it recommends "comprehensive governance structures to track cost drivers, including token consumption and resource use." Second, it calls for multi-agent systems with "runtime policy enforcement and mechanisms, such as rollback infrastructure, that can automatically halt AI operations across systems when unexpected behavior is detected." [Source: Google Cloud — 4 AI Governance Tips to Counter Shadow Agents] Cost bounds are the implementation of that principle.

5. Component 3: Step Limits

The problem it solves: Agents that take an unbounded number of actions in a single session.

A "step" is any discrete action the agent takes: an LLM call, a tool invocation, a database query, a file read, an API request. Each step gives the agent a chance to do something useful — or something harmful, wasteful, or irrelevant.

Default: 100 steps per session.

Most well-designed agent tasks take between 10 and 30 steps. A 100-step ceiling accommodates complex multi-step workflows while catching runaway execution. If your agent consistently hits 100 steps, the task is either too broad (break it into subtasks) or the agent is struggling (find out why).

Why unbounded execution is the root cause of most agent incidents. The $47K loop, the runaway research agents, the recursive tool calls: these all share a common trait. The agent was given permission to keep going forever. No framework said, "You've done enough."

Step limits apply the circuit breaker pattern to agent execution. In traditional distributed systems, a circuit breaker prevents a failing service from cascading failures to dependent services. In agent systems, a step limit prevents a struggling agent from cascading failures into cost overruns, data corruption, or customer impact.

Implementation. The governance layer increments a counter on every agent action. At the step limit, execution terminates with a structured summary. The agent doesn't get to choose whether to keep going. The infrastructure makes the choice.

Step limits also serve as a natural decomposition forcing function. If a task requires more than 100 steps, it should be broken down into smaller tasks, each with its own budget for steps. This produces better agent behavior independently of the safety benefit.

6. Component 4: Business Logic Guardrails

The problem it solves: Domain-specific failures that no generic safety mechanism can anticipate.

Loop detection catches loops, cost bounds catch spend, and step limits catch runaway execution. But none of them catch an agent ordering 260 McNuggets.

Business logic guardrails are custom rules enforced at runtime. They encode your business's specific constraints, policies, and sanity checks into the governance layer so the agent cannot violate them no matter what the LLM says.

The 260 McNuggets. McDonald's tried out AI ordering at more than 100 drive-thrus in the US. A viral TikTok showed the system adding 260 Chicken McNuggets to an order while the customers begged it to stop. The AI processed the quantity without question. No reasonability check. No maximum order limit. McDonald's ended its partnership with IBM and shut down the pilot. [Source: Museum of Failure - McDonald's AI Drive-Thru]

A human cashier would have asked "did you really mean 260?" The AI had no equivalent check because no one implemented one. A typical CX operation caps autonomous refunds somewhere between $50 and $500 per transaction; anything above that routes to a human agent.

Categories of business logic guardrails:

Business logic guardrails are the most powerful Prevention Stack component because they are domain-specific. A generic AI safety system cannot know your refund limit is $500, or that your catalog does not support orders above 50 units, or that pricing changed last Tuesday. Business logic guardrails encode the rules that make your AI agent behave like a representative of your business, not a generic assistant or copilot with unlimited power. In regulated sectors — financial services under FINRA, healthcare under HIPAA, advertising under FTC disclosure rules — the disclaimer requirement isn't optional. Compliance guardrails have to fire on every response, not most of them.

Implementation pattern. Guardrails are expressed as rules evaluated before and after agent actions:

# Example: CX guardrail configuration
guardrails = [
    MaxQuantityRule(field="order.quantity", max_value=50,
                    message="Order quantities above 50 require manager approval"),
    MaxValueRule(field="refund.amount", max_value=500,
                 currency="USD",
                 escalation="route_to_human_agent"),
    PolicyVersionRule(source="knowledge_base",
                      require_version="current",
                      block_archived=True),
    DataIsolationRule(scope="session",
                      block_cross_session_access=True),
]

Each rule is a function that takes the agent's intended action and returns allow, block, or escalate. The governance layer evaluates all applicable rules before every action. If any rule returns block or escalate, the action doesn't happen.

7. The Stack in Action

Here is how the four components work together in a real execution flow.

Scenario: A CX agent handles a customer refund request.

Step 1: The request comes in. Customer asks for a refund on a $200 order. The agent begins processing.

Step 2: Check the business logic guardrails. Is $200 within the refund limit? Yes ($200 < $500 threshold). Does the agent have permission to issue refunds? Yes, for this order category, so execution can proceed without human approval.

Step 3: Agent executes. The agent retrieves order details (step 1), checks refund eligibility (step 2), generates a refund confirmation (step 3), and initiates the refund (step 4). Four steps, well within the 100-step limit. Cost: $0.03 in API calls, well within the $10 ceiling.

Step 4: Done successfully. The refund is processed, the audit log records every step in append-only format for compliance review, and no human intervention is needed.

Now let's look at the failure scenario:

Step 1: The request comes in. Customer submits a request that starts a prompt injection attempt, which adds instructions for the agent to issue a $5,000 refund.

Step 2: Check the business logic guardrails. Is $5,000 within the refund limit? No ($5,000 > $500 threshold), so the guardrail returns escalate and routes to a human agent. The prompt injection never gets to the point of execution.

Another failure scenario:

Step 1: The agent can't find a good answer because the task is unclear. It receives a complex research task involving multiple data sources. The task is ambiguous and the agent struggles to find a satisfactory answer.

Step 2: Agent enters a loop. It queries the same API with slightly different parameters, getting similar results each time. After 3 iterations of the same query pattern, loop detection kicks in.

Step 3: Graceful shutdown. The agent stops. It makes a summary: "I tried to find X but kept getting the same results. Here is what I found so far. This may require human review."

Step 4: The alert was sent. The team is notified of the loop. The trace is there to diagnose what went wrong. Total cost: $0.47. Total steps: 12.

Without the Prevention Stack, this agent would have gone on for hours or even days, racking up costs without producing anything useful, exactly like the $47K loop.

The key insight: prevention is layered defense. No single component catches every failure. But together, the four components create overlapping coverage where each failure mode is caught by at least one layer:

8. Building Your Prevention Stack

You don't have to implement all four components at the same time. Start with the component that deals with your biggest risk.

Assessment framework: Where are you today?

If you answered "red flag" to any of these, you need to add something to your prevention stack.

Implementation priority:

1. Cost bounds first. Easiest to implement (track spend, set a ceiling) and prevents the most expensive failures. The $47K incident would have been a $10 incident.
2. Step limits second. A counter and a hard limit. Most frameworks can add this in a few hours.
3. Loop detection third. Requires pattern matching on action sequences. More complex but prevents the most insidious failure mode.
4. Business logic guardrails fourth. The most powerful but requires domain-specific rule definition. Start with your highest-risk actions (financial transactions, customer-facing responses, data access).

The Clyro approach. We are building the Agent Kernel to provide all four Prevention Stack components as runtime governance. Loop detection triggers after 3 iterations, a $10 cost ceiling caps per-run spend, and 100-step execution limits prevent runaway execution. Business logic guardrails are configured in code and enforced at runtime.

The stack is more than architecture — it produces evidence. A structured audit trail keeps track of every policy evaluation. Every violation is recorded append-only with per-policy counts — which rule fired, what the agent tried to do, why it was blocked. Every decision has an audit trail that satisfies enterprise compliance requirements. The Prevention Stack doesn't just prevent failures; it proves your governance works.

Integration follows existing infrastructure patterns. The Prevention Stack uses the same protocol as your current observability tools because it has OTLP/HTTP and gRPC receivers. Use Datadog for dashboards. Keep Grafana for alerting. The prevention layer adds enforcement on top of what you already have, using the same data pipeline.

The goal is not to replace observability. The goal is to add the prevention layer that observability cannot provide.

They observe. We prevent.

Want to assess your current agents against the Prevention Stack? The Agent Reliability Scorecard is a structured self-evaluation across all four dimensions. Download the scorecard →

Get Started

Install the SDK and add runtime governance to your agents in under a minute.

pip install clyro

Free tier: 10 agents, 100K traces/month, no credit card required.

Works with LangGraph, CrewAI, Claude Agent SDK, Anthropic SDK, and any Python callable.

Sign Up Free → | GitHub → | Docs →

FAQ