In this post, I want to review what kinds of delegation of tasks by AI agents to other AI agents exist. THis is based on my experience with building AI harnesses and observing how other people build their own harnesses.

Most basic architecture - just a loop

Simplest AI agent harnesses are built as a loop. The main AI agent receives a prompt, sends it to LLM, gets a response. If a response contains a request to call some tool, then the main AI agent calls that tool, gets a result, appends this result to the context, and sends it back to LLM. This loop continues until a LLM response does not contain any request to call a tool. Then the main AI agent returns the final result to the user.

This approach works well for simple tasks, but it has an important drawback - each request to LLM costs tokens and when context grows tool requests become too expensive. A delegation of subtasks is one of the solutions to this problem.

I am a regular user. I buy clothes online, I order food, I get things for the home. And, like most people, I have my favourite places. I go back to the same shops because I know them, because I trust them, and — often — because I have a discount or a loyalty price there.

Now watch what happens when I bring an AI assistant into this.

I open ChatGPT and ask it to find the best price for my favourite model of jeans. It runs a generic web search. It uses its own rules about where to look. Even if it happens to land on my favourite store, the price it shows me is the public price — not my price. My discount, my loyalty status, my active promo — none of that is there. The assistant has no idea I am me.

There are two problems tangled together here:

1. My favourite store has no MCP interface. The agent can only use the open web, and sometimes a public API. There is no clean way for it to say "this user is a logged-in customer, show them their real prices."
2. I can't easily teach the agent my preferences. I would love to just type in the chat: "When I ask you to find clothes, search on https://next.co.uk/ and https://www.riverisland.com/ first." And I'd expect it to remember that and do it next time. Today that is still awkward. For a regular, non-technical user it basically doesn't happen.

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.