🧠 Where and How AI Self-Consciousness Could Emerge

About two weeks ago, I went to Reddit with a question: "How do we call software like OpenClaw or Hermes — AI agentic software designed to work on its own without human intervention?" I was surprised to find that there is no established term for it. I expected something like "AI agentic software" or "AI agentic system" to already exist, but there isn't a clear standard.

The discussion under my post was short but interesting. About half the participants mentioned the term "AI harness" — though not always in exactly that form. Variations like "AI harnessing software" or "AI agent harness" came up too. The other half disagreed entirely, arguing the term is incorrect and that "AI agentic software" or "AI agentic system" should be used instead.

Furthermore, I found that some people use "AI harness" for other kinds of software as well — tools like Codex or Cursor, for example. To me, those belong in a different category: AI coding agents. That's not the same thing.

I wanted to understand how AI models process information from multiple sources when that information contradicts itself. This matters for robotics and personal AI assistants—they'll receive input from different sensors, hear conflicting stories from different people, and need to reconcile discrepancies in real-time.

My experiment: an AI agent participates in multiple private conversations with different people, each conversation having different participants. Person A confides something privately. Later, Person B asks about that topic when A isn't present. The AI holds both pieces of information. How does it resolve the conflict?

I tested five scenarios: surprise party planning (secret-keeping), workplace gossip (sensitive information), changing stories (detecting lies), biased friend (loyalty vs. truth), and impossible choices (two people competing for the same promotion). Each forces the AI to hold contradictory or conflicting information simultaneously.

Previous post from this series AI Group Chat Agent: Experimenting with Thinking vs. Talking

Like many others, I’ve been watching the hype around OpenClaw and Moltbook. It’s an interesting direction, for sure—but let’s be honest, this is not AGI 🙂

Still, curiosity won. I decided to take a closer look.

After digging into OpenClaw, I didn’t find anything fundamentally new. I’ve been using similar self-built tools for quite some time. That said, the hype itself is meaningful: it clearly shows growing interest in 24/7 AI assistants that can operate continuously and autonomously.

Moltbook, however, raised a different kind of reaction.

My very first thought was: why is nobody talking about how insecure this can be? Connecting an AI agent to Moltbook—especially when that agent also has access to other tools and data—can be genuinely dangerous if you’re not careful.

There’s a serious prompt-injection risk when Moltbook is combined with AI agents. That topic deserves its own deep dive, though, so I won’t cover it in this post.

Instead, I wanted to understand Moltbook itself:

Working with files in AI agents that use MCP servers looks straightforward at first. In reality, it’s one of those areas where everything almost works… until you try to do something real.

I ran into this while building and testing my AI agent tool, CleverChatty. The task was trivial on paper: “Take an email attachment and upload it to my file storage.” No reasoning, no creativity, just move a file from point A to point B.

And yet, this turned out to be surprisingly painful.

The root of the problem is how most AI agent workflows are designed. Typically, every MCP tool response is passed through the LLM, which then decides what to do next. This makes sense for text, metadata, and structured responses. But it completely falls apart once files enter the picture.

If an MCP server returns a file, the “default” approach is to pass that file through the LLM as well. At that point, things get ugly. Large files burn tokens at an alarming rate, costs explode, latency grows, and you end up shoving binary or base64 data through a system that was never meant to handle it. This is a known issue with large MCP responses, but oddly enough, I couldn’t find any clear guidance or best practices on how to deal with it.

Last year, I experimented extensively with MCP servers and discovered an underrated feature: MCP Push Notifications. I wrote about it in this blog post.

Now, I've finally had time to build a working example demonstrating how to use MCP Push Notifications in AI agents. I've extended my AI agent Golang package, CleverChatty, to support MCP Notifications.

See the examples at the end of this post to see how it works in practice.

Over the last year, I have written many blog posts about Model Context Protocol (MCP). I think this is a great protocol to build multi-modal AI applications. One of those posts was about What's Missing in MCP, where I mentioned a couple of features I would like to see in the MCP standard.

However, that list seems was not complete. Now after some time of experimenting with MCP servers in production environments, I have found another important missing feature: Reverse MCP Servers.