TL;DR: I run a self-hosted AI assistant using OpenClaw, accessed via Telegram. After weeks of normal operation, the assistant suddenly started alternating between remembering everything and remembering nothing. Messages would flip-flop—one response coherent and contextual, the next completely blank. Hours of frustrating troubleshooting later, I discovered a MacBook Pro had been turned back on, running a second instance. Classic split-brain: two systems, no shared state, round-robin responses. The fix was simple. The lesson was about how failure modes in distributed systems can look like AI behavior problems.
The Setup
At home, I run several different AI options for testing. The latest addition is OpenClaw, an open-source AI assistant platform that I’ve been evaluating for local inference work. I originally installed it on a MacBook Pro just to see what was going on—the usual process of kicking the tires, understanding how it handles memory, context, and the various configuration files that define its personality and continuity.
Eventually, that installation moved to a ProxMox container on one of my home servers. Cleaner separation, easier to manage, fits better with how I run everything else. I kept using Telegram as the messaging interface because it’s what I had set up, and honestly, messaging-based AI interaction has grown on me. It fits the way I actually want to interact with these systems—asynchronous, persistent, accessible from anywhere. There are a whole bunch of security considerations, but I’ll get into that in a later post.
Fast forward a couple weeks. Everything was working fine. The assistant remembered context. It knew what we’d discussed. The SOUL.md file (which defines the assistant’s personality and behavioral guidelines) was doing its job. Normal operation.
And then it forgot everything.
What Broke
January 24th. I send a message, something referencing a previous conversation. The response comes back: “I don’t remember that.”
Okay. That’s strange. These systems are supposed to have memory persistence. Maybe something went wrong with the storage backend? I respond, ask what’s going on, try to probe a little.
The next message: “Yeah, everything’s right here.”
Wait. What?
This went on for hours. One message would get a response from an assistant that had no idea what we’d talked about. The next message would get a perfectly contextual response like nothing was wrong. Back and forth. Alternating. No pattern I could identify, no obvious trigger.
I’m using Telegram for this, which means I’m staring at a chat window watching responses flip between coherent and amnesiac. My frustration went through the roof. Was this a model problem? A memory corruption issue? Some bizarre context window failure mode I hadn’t seen before?
I spent way too long debugging in the wrong direction.
The Actual Problem
Long story short: the MacBook Pro got turned back on.
When I moved to the container, I didn’t bother wiping the laptop — why would I? It was off. Except my daughter saw an unplugged laptop, did what any kid would do, and plugged it in. Now I had two copies of my assistant running, both fighting to answer the same Telegram messages, neither knowing the other existed.
Classic split-brain.
Every other message was being routed to a different instance. They didn’t share memory. They didn’t share SOUL.md. They didn’t share any of the continuity mechanisms that make these systems feel coherent. One of them had weeks of context; the other had nothing.
From my perspective, sitting in the Telegram chat, it looked like the AI was having some kind of breakdown. Personality fragmentation. Memory failure. Something deeply wrong with the system itself. And I’m no stranger to AI going deeply wrong. In reality, there was nothing wrong with either instance. The problem was that there were two of them, and I didn’t know it.
Why This Matters
This is a failure mode that looks like an AI behavior problem but isn’t. If I’d been less familiar with how these systems work under the hood, I might have concluded that local AI memory just isn’t reliable. Or that OpenClaw had some fundamental flaw. Or that I needed to switch to a cloud-hosted solution with “real” persistence.
None of that was true. The technology was working exactly as designed. The architecture was wrong.
This is something I keep running into across my AI work: the symptoms you observe rarely point directly at the cause. A model that seems to hallucinate might be getting bad input data. A chatbot that ignores constraints might be hitting context window limits. An assistant that forgets everything might be… two assistants that don’t know about each other.
The instinct to blame the AI is strong. The reality is usually more mundane and more fixable.
The Fix
Shut down the MacBook Pro instance. Done.
The container-based installation immediately went back to normal. Memory intact, context preserved, no more flip-flopping responses. The “AI behavior problem” that had consumed hours of my evening disappeared the moment I understood it wasn’t an AI problem at all.
I’ve since added better process management and some basic sanity checks to prevent this from happening again. Nothing exotic—just the kind of operational hygiene you learn to appreciate after debugging something obvious for way too long.
What I Took Away
A few things.
Failure modes in distributed systems are sneaky. Split-brain is a well-understood problem in clustering and replication. I’ve dealt with it in traditional infrastructure contexts plenty of times. But I didn’t initially pattern-match to it here because I was thinking about AI behavior, not system architecture. The framing blinded me to the obvious.
Messaging interfaces can hide what’s happening underneath. Telegram shows me a clean chat window. It doesn’t show me which backend instance is responding to each message. That abstraction is usually helpful. In this case, it actively obscured the problem.
“The AI is broken” is rarely the right first hypothesis. The AI layer is the most visible part of these systems, so it’s where attention naturally goes. But the stack underneath—networking, process management, storage, routing—fails in ways that manifest as AI weirdness. Debugging AI systems means debugging the whole stack.
Test your assumptions about what’s running. I assumed one instance was running because that’s what I intended. Reality disagreed. docker ps and process checks are not optional.
This wasn’t a sophisticated problem. It was an embarrassing one. But embarrassing problems are often the most useful to write about, because they’re the ones other people are also hitting and not talking about.
The assistant is fine now. It remembers who it is. I’m the one who learned something.
Written by Andy Watkins | Edited and formatted with AI assistance
These thoughts are my own and an accumulation of 30+ years of technology experience.