# Beyond the Hype: How ‘AI Psychosis’ and the OpenAI Agents API Are Exposing the Fragility of Modern Software Engineering > Source: > Published: 2026-09-11 00:01:04+00:00 *Originally published on [tamiz.pro](https://tamiz.pro/insights/ai-psychosis-openai-agents-api-fragility-software-engineering).* 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. 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: 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. 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: 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. 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. 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. 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 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. To build systems that survive AI Psychosis, we need new patterns: `Zod` or `Pydantic` to validate the agent's `delete_user` with ID `"foo"`, reject it before the tool is called. 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](https://tamiz.pro/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. 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. 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. 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.