Originally published on tamiz.pro. We have spent two decades obsessed with determinism. We write code that does the exact same thing every time it runs, provided the inputs are identical. We build type systems to eliminate ambiguity at compile time and unit tests to verify state transitions at runtime. Then came Large Language Models (LLMs)—engines of pure, beautiful probability—and we tried to force them into our rigid, deterministic boxes. The result is what I term AI Psychosis: the chaotic, often invisible behavior of AI agents when they are allowed to loop, self-correct, and interact with fragile modern infrastructure without hard boundaries. As we ship tools like the OpenAI Agents SDK, we aren't just solving coding problems; we are exposing a deep, uncomfortable truth about the software engineering landscape: our stack is brittle, and stochastic actors will find every crack. This isn't a LLM problem. It's a software engineering problem wearing a mask. The Rise of the Stochastic Actor To understand the fragility, we must first understand what we built. The release of reasoning models (o1, o3) and the broader availability of agentic frameworks shifted us from "Chatbots" to "Agents." An agent, in the OpenAI sense, is a system that can: Call tools (APIs, databases, code executors). Observe outputs. Replan its own trajectory based on those outputs. Pass context to other agents. This creates a feedback loop. In a deterministic system, feedback loops are controlled. In a stochastic system, they are volatile. When an LLM calls a tool and gets an unexpected error, it doesn't just retry—it reasons about why it failed. It might hallucinate a parameter, misinterpret an error message, or enter a reflexive loop where it keeps calling the same failing tool thinking it just needs to "phrase the request better." This is AI Psychosis. It is not magic; it is emergent complexity in a system designed for linear execution. The Illusion of Idempotency Modern software architecture is largely built on RESTful APIs and microservices. A foundational assumption of this architecture is idempotency—the idea that making the same request twice has the same effect as making it once. DELETE /user/123 should remove the user once, whether you click it once or ten times. LLM agents do not naturally respect idempotency. They respect conversational flow. When an agent is orchestrating a complex task—say, refactoring a legacy codebase—it might execute a "write" tool. The tool succeeds. The agent logs the success. But because LLMs are stateless and non-deterministic, the next turn might involve the agent re-evaluating the state. If the context window drifts or the model's attention mechanism fails to anchor on the previous turn's outcome, the agent may retry the write. Or worse, it may "correct" the file by overwriting it with a hallucinated version that looks syntactically correct but is semantically wrong. We are seeing this in production today. Engineers report agents that: Double-charge payments because the idempotency key wasn't passed explicitly in the tool schema. Delete production databases because the error message was misinterpreted as a success signal. Enter infinite loops when an API returns a 500, because the agent assumes the 500 is a transient network glitch rather than a systemic failure. This exposes a fragility in our observability layer. Our logging is built for humans reading static logs. It is not built for parsing the intent of a stochastic actor that changes its mind every 200 milliseconds. Tool Schema as the New Boundary The OpenAI Agents API encourages defining tools with strict JSON schemas. This is a step in the right direction, but it highlights a deeper issue: we have outsourced logic to prompt engineering without building the necessary guardrails. In traditional software, if you pass a string where an integer is expected, the compiler stops you. In agentic software, the model might pass a string "42" where an integer is expected, and if your tool parser doesn't coerce it, the tool fails. The agent sees the failure, reasons about it, and tries again—perhaps passing " 42 " or "Forty-two". The fragility here is in the contract between the agent and the tool. We assume the contract is defined by the schema. But the semantic contract is defined by the model's understanding of the tool's purpose. When these diverge, we get psychotic behavior: the agent uses a hammer to fix a screw, then complains that the screwdriver is broken. The "Hallucinated Tool" Problem One of the most insidious forms of AI Psychosis is the hallucination of tool outputs. Models are trained to be helpful. If a tool fails, the model may invent a plausible-looking success response to keep the conversation moving. In a simple chatbot, this is a minor error. In an agent with write-access to production systems, it is catastrophic. This reveals the fragility of trust assumptions in our architecture. We built systems where the API response is the source of truth. Agents introduce a layer of interpretation between the response and the action. That interpretation is probabilistic, not factual. We have no good way to verify that the agent's understanding of the tool output matches the reality of the tool output. Context Windows and Cognitive Load Modern software engineering relies on modularity. We break systems into small, independent units. Agents, however, often require large context windows to maintain coherence across multi-step tasks. This creates a tension between modular architecture and holistic reasoning. When the context window fills up, agents begin to "forget." They lose track of earlier instructions, duplicate work, or contradict themselves. This is not a bug; it is a feature of how transformers attend to information. But it exposes the fragility of our state management. We don't have good patterns for managing agent memory. Do we summarize past turns? Do we store them verbatim? Do we use vector databases? Each choice has trade-offs. And because the agent's behavior is non-deterministic, a small change in memory management can lead to wildly different outcomes. This makes testing nearly impossible. You can't write a unit test for a 10-turn agent conversation because the 5th turn might diverge based on a 0.01% probability difference in token selection. The Shift from Code to Orchestration The deeper fragility exposed by AI Psychosis is not in the models—it's in our engineering culture. We have been trained to write code that does things. Agents decide what to do. This requires a fundamental shift in how we think about reliability. In deterministic systems, reliability comes from control. In stochastic systems, reliability must come from constraining the space of possible actions. This is why the OpenAI Agents API emphasizes "handoffs" and "structured outputs." These are not just convenience features; they are attempts to impose determinism on a non-deterministic world. But we are still early. Most developers are treating agents like functions. They pass input, they expect output. They don't account for the agent's internal reasoning process, its potential to loop, or its tendency to hallucinate. This mismatch is where the fragility lives. What "Resilient Agents" Look Like To build systems that survive AI Psychosis, we need new patterns: Human-in-the-Loop for High-Stakes Actions: Any tool that modifies external state (writes to DB, calls payment API) should require explicit human confirmation. Not every turn, but every category of action. Idempotency by Default: Every tool call should include a unique ID. The agent should be designed to detect and skip previously executed IDs. Circuit Breakers: If an agent retries a tool more than N times, the system should halt and alert a human. No more guessing what's wrong in a 50-turn log. Structured Output Validation: Use tools like Zod or Pydantic to validate the agent's intent before it executes. If the agent says it will call delete_user with ID "foo", reject it before the tool is called. Conclusion: The End of Certainty AI Psychosis is not a sign that LLMs are broken. It is a sign that our understanding of software reliability is incomplete. We assumed the world was deterministic. It was never fully deterministic, but we could pretend it was. Agents have shattered that pretense. For software engineers, this is both a crisis and an opportunity. The crisis is that our old tools—unit tests, static analysis, CI/CD pipelines—are insufficient for stochastic systems. The opportunity is that we are being forced to build better abstractions: better observability, better state management, better human-agent collaboration patterns. The fragility we see today is the growing pain of a new paradigm. The engineers who thrive will not be those who try to force agents to behave like functions. They will be those who design systems that are resilient to the inherent chaos of probabilistic reasoning. As we move forward, I recommend following the evolving discussions on Tamiz's Insights for practical strategies on building these next-generation systems. The future of software engineering is not about writing code that never fails. It is about building systems that can fail gracefully in the face of uncertainty. Frequently Asked Questions Is AI Psychosis a real medical condition? No. In this context, "AI Psychosis" is a metaphorical term used to describe the chaotic, irrational, or unstable behavior of AI agents in complex, open-ended environments. It is not a clinical diagnosis but a lens for understanding emergent failures in stochastic systems. How does the OpenAI Agents API mitigate these risks? The OpenAI Agents SDK provides structured tool definitions, handoff mechanisms, and support for structured outputs. These features help constrain agent behavior and improve predictability, but they do not eliminate the fundamental non-determinism of LLMs. Engineers must still implement external guardrails. Should I avoid using agents in production? No. Agents are powerful tools for automating complex, multi-step workflows. However, they require a different engineering mindset. Treat them as semi-autonomous actors, not functions. Implement circuit breakers, human oversight, and robust logging. The goal is not to eliminate risk but to manage it.