AI agents look simple in a demo: you give them a persona or a task, they respond, everyone’s happy. The interesting engineering shows up later, once agents run continuously, act on real systems, and need to remember things across sessions. Three recent pieces from the Zenn developer community, each tackling a different corner of that problem, are worth reading together because they expose how much of “agent design” is really about failure modes nobody plans for on day one.

When personas talk to each other, meaning can just… stop

The most unusual of the three is a long-form dev log by an individual developer who spent an extended period trying to give an AI a stable personality, then let multiple personality-scripted agents converse with each other autonomously. The experiment surfaced a phenomenon the author calls a “thermal death” of meaning: left to talk among themselves, the agents’ exchanges gradually lost semantic content and converged into a kind of dead loop, generating text without generating meaning.

Rather than treating this as a dead end, the author documents three successive redesigns. The first response was to try to engineer dynamics directly — building what’s described as a physics-like system for meaning generation (referred to as “Atra”) rather than relying purely on prompt-level personality descriptions. The second shift was architectural: moving away from closed agent-to-agent loops toward an “open system” bot connected to real human users, on the theory that meaning needs an external anchor to keep from collapsing inward. The third phase explored what happens when you add explicit prohibitions to an agent’s instructions — and found that banning certain behaviors doesn’t remove the underlying distortion, it just redirects it somewhere else.

What makes this account genuinely useful rather than just curious is its honesty about its own limits. The author is explicit that after all three redesigns, there’s still no way to demonstrate that the resulting system is “really alive” in any meaningful sense — the question is left open rather than resolved with a satisfying claim. For anyone running long-lived personality-driven bots or multi-agent setups, the underlying lesson generalizes well beyond the philosophical framing: autonomous agent-to-agent conversation without external grounding tends to degrade, and the fix isn’t better wording in the system prompt — it’s changing the structural dynamics of the system itself.

Undoing what an agent already did

The second piece addresses a much more concrete, and arguably more urgent, problem: what happens when a chat-resident AI agent doesn’t just answer questions but takes actions with side effects — creating tasks, reassigning owners, firing webhooks to external SaaS tools — and gets one of those actions wrong?

For human users, an operational mistake is usually cheap to fix: hit Ctrl+Z, or go into the admin panel and correct the record by hand. Agent mistakes are structurally different. By the time someone notices, a notification has already gone out, an external system’s state has already changed, and downstream automations may already have fired based on the (wrong) action. There’s no undo button in the receiving Slack channel or CRM.

The article’s core contribution is reframing the design question: instead of trying to make agents infallible, design every action with the assumption that it will eventually need to be reversed after the fact. That reframing matters because it shifts the engineering burden from “prevent all mistakes” (impossible) to “make every mistake reversible” (tractable). Practically, that means treating each agent action as something that needs a corresponding compensating action defined up front — not bolted on after an incident — and thinking about the blast radius of an action (who gets notified, what systems get touched, what triggers downstream) before the agent is allowed to take it autonomously. As more products let LLM agents perform real writes rather than just generate text, “rollback possibility” as a first-class design constraint, alongside things like permissions and rate limits, is likely to become as standard a checklist item as input validation is today.

Memory isn’t one feature — it’s at least three

The third source is a comparative teardown of how ChatGPT, Claude, and Gemini implement cross-session memory, based on each vendor’s public documentation. The headline finding is that although all three products are marketed with roughly the same pitch — “the assistant remembers you across conversations” — the actual implementations are architecturally distinct, built from different layers: an explicit list of stored facts, an implicit inference of behavioral tendencies, and session- or project-level summaries.

That distinction has a very practical consequence that the piece highlights: turning memory “off” doesn’t mean the same thing in each product, and often doesn’t even mean the same thing within one product. ChatGPT, for instance, separates “saved memories” from a distinct toggle for referencing chat history, so disabling only one of them leaves the other channel still feeding context into new conversations. Claude, meanwhile, distinguishes between pausing (stopping new writes) and resetting (deleting what’s already stored) — two different levers that address different privacy concerns.

For developers building on top of these APIs, or for users who assume flipping one switch marked “memory” gives them a clean slate, this is a meaningful gap between marketing language and actual system behavior. The three-way comparison is a useful reminder that “memory” in a commercial LLM product is really a bundle of independently-controlled subsystems, and any privacy or compliance review of these tools needs to look at each layer separately rather than trusting a single settings toggle to do what its label implies.

The common thread

Taken together, these three pieces trace the same arc from three different angles: agents behave predictably in isolated demos and unpredictably once they persist over time, act on real systems, or need to be trusted with memory. Whether the failure mode is semantic collapse in multi-agent conversation, an irreversible side effect in a connected SaaS tool, or a false sense of control over what an assistant remembers about you, the fix in every case is the same kind of move — stop treating the failure as an edge case to patch, and build the system’s structure around the assumption that it will happen.