🧠 Where and How AI Self-Consciousness Could Emerge

Almost every MCP tutorial starts the same way: install an SDK, run a server process, and keep a long-lived connection open between the client and the server. STDIO does this by design. The remote transports (SSE, and now Streamable HTTP) are usually presented the same way — a stream that stays open so the server can push messages to the client at any time.

That is fine for a local tool or a small integration. But I keep thinking about a different scenario: online stores. Imagine every shop on the web exposing an MCP endpoint so AI tools can browse the catalog and help a user buy. If each of those endpoints expects a persistent connection, we are back to holding thousands of open sockets for clients that send one request every few minutes. That is a lot of unnecessary load on the network infrastructure for almost no benefit.

So I wanted to check a simple question: can an MCP server work as a normal, stateless web app — one request, one response, connection closed — the way websites have worked for decades?

In this tutorial, I'll demonstrate a simple way to organize communication between two AI agents that are not part of the same system. This answers questions such as:

"How can I call Claude Code running on my server from GitHub Copilot on my laptop?"

The same approach works for many combinations of AI agents and enables them to collaborate while each operates in its own environment.

Use case

Imagine you maintain a knowledge base for your team. It consists of structured Markdown files containing documentation, plans, notes, blog drafts, CRM data, and other information.

The dataset is relatively small—not billions of files—so it can easily be handled by modern AI coding agents such as Claude Code, Codex CLI, or GitHub Copilot CLI. Although this is not source code, it doesn't matter: AI coding agents work just as well with plain text.

A typical directory structure might look like this:

KnowledgeBase
.
├── AGENTS.md
├── Automation
│   ├── assignments.md
├── BlogDrafts
│   ├── AI_Memory_Forgetting_Post_Ideas.md
│   ├── IDEAS.md
......
├── Briefs
│   └── SUMMARY.md
├── CRM
│   ├── README.md
│   ├── communications-log.md
│   ├── companies.md
│   ├── people.md
......
├── Insights
│   ├── ideas-log.md
├── Presentations
├── Scheduler
│   ├── 2026-06-23
│   │   ├── plan.md
│   └── 2026-07-10
├── Strategy
│   ├── Intro.md

Suppose your favorite AI coding agent runs on the same machine where this knowledge base is stored. Asking questions about the data or updating it becomes trivial.

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.