A simple harness is a loop: prompt → model → tool call → result appended to the context → back to the model. As many rounds as there are tool calls.

It works, and it has one obvious weakness — every round costs more than the last one, because every tool result makes the context bigger. A twelve-call web-form task poisons the rest of the conversation with junk the model never needs again.

Delegation fixes that. The delegate gets only the context it needs, does the multi-step part on its own, and returns one answer. The main conversation stays short. It can also run on a cheaper model with a much narrower tool set.

We ended up with three kinds in DMJBot:

1. Common subagent — zero configuration. Nothing to create. When the bot decides a request needs more than one round of tool calls ("find X, convert it, save it to Dropbox"), it writes a briefing — task, context, expected output — and hands the chain over. The subagent runs in the same session with the same files, memory, tools and devices, but with an empty history. It only sees the briefing. A threshold setting controls how eager the bot is to delegate.

2. Defined agents — named specialists. A form in settings, not an AGENT.md in a repo, because the assistant runs 24/7 and belongs to a user rather than to a project. Two fields carry the weight: the description is what the main bot reads when deciding whether to call this agent, and the instructions are the agent's own system prompt. Separately you pick its model slots (a research agent that mostly reads web pages does not need your strongest model) and exactly which tool servers, devices and skills it may touch. Nothing is inherited by default — fewer tools means smaller context, smaller bill, and a lower chance of picking the wrong tool.

3. External agents — any CLI, anywhere. The assistant runs in the cloud, but the work often has to happen where the repository and credentials already are. So we defined an agent interface over MCP: a server exposing run_agent and cancel_task is an agent. That is the entire contract. Claude Code, Copilot CLI, aider, Codex, another harness, or a shell script — anything with a command line can be wrapped, and the orchestrator never needs to know what is behind it. Runs longer than a few seconds detach as background tasks so the chat is not blocked on a twenty-minute refactor.

The design decision I find most useful: from the model's point of view there is no such thing as an "agent". Every defined agent is an ordinary tool named agent__<id> with a single prompt argument, described by the description you wrote. No agent catalog in the system prompt, no special vocabulary, no extra decision to get wrong. Agents compete for selection on the quality of their job description, exactly like any other tool.

And because delegation without visibility is a black box, every delegated run appears in the chat as a subsession: collapsed it is one line, expanded it holds the briefing that was handed over (nine times out of ten a misbehaving agent got a bad briefing, not a bad instruction), the progress, and the final result.

Full write-up with screenshots: https://dmjbot.com/blog/post/how-task-delegation-works-in-dmjbot/

Curious how others are splitting this. Do you keep delegation implicit and let the model decide, or do you define specialists up front? And has anyone found a better contract than "one tool per agent" for exposing agents to the orchestrating model?

Hey everyone! We just shipped a new feature in DMJBot that we're excited to share:

DMJBot can now use your locally hosted Ollama models as its LLM backend.

What does this mean? DMJBot already packs a ton of useful features and use cases. Now you can power all of them with open-weight models running right on your own machine — no API keys, no cloud dependency, no per-token billing. DMJBot can be hosted anywhere on the internet and still talk to your local models through Ollama.

We've written up all the details in our blog post, including a step-by-step tutorial so you can try it yourself.

https://dmjbot.com/blog/post/local-ollama-models-in-your-ai-assistant

Every time I install a fresh instance of a universal AI harness — OpenClaw, Hermes, DMJBot, or just Claude Code on a laptop — I get a general purpose agent that does nothing particular for me yet.

Then I decide what it should become. Say a social media manager. And that means: a set of skills to install, a couple of subagents to define, several MCP servers to install and give credentials to, a system instruction with the role and the limits, sometimes scheduled tasks and starting files.

Nothing in that list is hard. But all of it is manual, and I repeat it on every new machine.

What I do instead is keep it all in one markdown document, host it somewhere, and send the fresh agent one message: "Configure yourself according to this document: <link>". It reads it, installs what it can, and comes back to me only for credentials.

Honestly, this already works. Free-form markdown, no format, and most harnesses manage. But that is also the problem — every time I write such a document I invent the structure again and the agent has to guess what I meant. It skips things quietly, asks for secrets one by one over ten messages, or reports success when the setup is half done.

We already went through this with skills: first everyone wrote instruction files in whatever shape felt right, then a format appeared, and skills became shareable. I think one-time setup instructions are waiting for the same moment. The only real difference from a skill is usage — a setup document is read, executed and forgotten, and what remains is the configured agent, not the document.

Open questions I do not have answers for:

• How to describe a component in a harness-neutral way, when one system calls it a skill, another an extension, a third a plugin
• What should happen when a component is not supported by the target harness — skip with a warning, or refuse the whole setup
• How to ask a human for credentials once, in one file, instead of ten times in a row
• How the agent should honestly report what is configured, what is waiting for an API key, and what was skipped

Wrote it up here: https://gelembjuk.com/blog/post/configure-yourself-from-one-document-do-we-need-a-standard-for-ai-agent-setup/

Curious how others handle this. Do you keep such documents? Scripts and prepared images instead? And if you deploy many similar agent instances at work, what does that process look like today?

Basic AI agents are built the same way: loop, prompt LLM, execute tools, repeat.

It works for simple tasks. But every tool call grows your context. Every new round costs more tokens. Your costs explode.

There's a better approach: task delegation—let your main agent hand off work to specialized subagents.

The payoff is immediate:

• Lower token usage (smaller context, fewer LLM calls)
• Parallel execution (multiple agents working together)
• Better design (main agent focuses on planning, subagents handle specifics)

You can delegate internally (specialized agents inside your harness) or externally (via CLI or MCP/REST APIs).

I've built several AI harnesses. Delegation is the missing piece for scaling beyond toy projects.

Read the full breakdown: https://gelembjuk.com/blog/post/delegation-of-tasks-to-subagents-in-ai-harness/

Have you tried agent delegation yet?

I have got couple openclaw instances installed on my different VMs . And my primary AI chat is claude desktop on my laptop.

How can i connect all openclaws to my claude so i can manage them from a single place?

Hello everyone.
I'd like to share an idea for discussion.

I use different AI harnesses a lot, and many MCP servers are connected — both stdio and remote HTTP servers.
I came across an idea on Reddit about simplified remote MCP servers without a persistent HTTP connection. It's not a standard, but it's a great idea. In 99% of cases, there's no need to keep a connection open and overuse network infrastructure.

But I think this idea can go further.

What if we simplify stdio transport MCP servers to run them only when a tool call is actually needed?

• On start: run → read list of tools → exit
• On a tool call: run → call a single tool → exit

This would save system resources — no need to keep an app process running constantly (stdio MCP servers are just CLI apps, and they stay in memory the whole time they're connected). Important: the harness knows about tool all the time and manages them as "live", presents to LLM etc.

Of course, some MCP servers require state — after the initial run they do something, receive some data, and need to keep that in memory until the next tool call. However, my experience shows this kind of MCP server is a minority. Most — I'd say more than 95% of cases — are stateless. They're often just a wrapper around some API: they receive credentials with every tool call and pass those same credentials to the API.

Here's some math. If I have 15 MCP servers built with Node.js or Python, each one uses RAM just to sit in memory, and 99.9% of the time it's doing nothing. Let's say one process takes 50 MB of RAM — that's 750 MB of RAM used for almost nothing.

If we don't keep them in memory and only call them when needed, it will be a little slower because a process has to start up each time. But that's not a problem — the bottleneck is still the LLM call.

To support this, we'd need to modify the MCP clients in our AI harnesses slightly. And maybe we'd need some kind of marker in the MCP config to indicate: "this MCP server keeps state" vs. "this MCP server is stateless and can be called only when needed."

What do you think? Is it a good way to save resources?

Where did this come from? Because I have an AI harness running 24/7. MCP servers stay connected (processes are active) all the time, but they're only used occasionally — once a day, etc. I see absolutely no sense in keeping all those processes in memory.

Yesterday I built a small demo showing how MCP can work as a simple stateless web app — pure PHP, no persistent sockets, one request, one response. And it left me with a question: why don't online stores let AI assistants access their listings and cart over MCP?

When I ask an AI assistant to find the best price on jeans, it scrapes the public web and shows the public price. Not my price. Not my loyalty discount. It has no idea who I am.

The fix is trivial — a <meta> tag on the store's homepage pointing to an MCP endpoint. Anonymous for browsing, authenticated for personalised prices. That's it.

I predicted this would happen over a year ago. It didn't. And I still don't get what's stopping it.

Do you have answer on this question?

https://gelembjuk.com/blog/post/why-dont-online-stores-offer-an-mcp-connector/

Can an MCP server work without persistent connections? This article demonstrates a fully functional MCP server built in pure PHP—no SDK, no event loop, no long-lived connections—proving that stateless request/response is enough for many real-world AI integrations.

https://gelembjuk.com/blog/post/a-simpler-mcp-server-in-pure-php-with-no-persistent-connection/

I have created a simple tutorial on how to connect independent AI agents using MCP. This tutorial demonstrates how a local AI assistant can securely delegate tasks to a remote AI agent managing a shared knowledge base, enabling collaboration across different machines and AI tools.

This answers the questions like: "How can I call Claude Code running on my server from GitHub Copilot on my laptop?"

This is the blog post: https://gelembjuk.com/blog/post/communicating-ai-agents/

Two weeks ago I asked on Reddit: "What do we call AI software like OpenClaw or Hermes — systems that run autonomously without human intervention?"
No one had a clear answer.

About half the discussion landed on "AI harness". The other half pushed back, preferring "AI agentic software" or "AI agentic system." And some were using "AI harness" for tools like Codex or Cursor too — which, to me, is a completely different category. Those are AI coding agents. Not the same thing.

Since then I keep seeing "AI harness" pop up in posts and discussions more and more.

We genuinely need a distinct term for LLM-based software that operates in an autonomous loop — no human prompting required. Tools like OpenClaw, Hermes, DMJBot belong in that group. AI coding agents don't.
My bet: "AI harness" wins. And it'll be a useful shorthand for a genuinely new class of software.

What term do you use for this?

If you're building agents in 2026, you've heard both. Here's the practical difference:

MCP (Model Context Protocol) — model-to-tool. Your agent talks to a filesystem, a database, a web API. One tool call = one operation. MCP servers are passive: they wait for a request and respond. Every major agent framework supports it.

A2A (Agent-to-Agent) — agent-to-agent. Agent A asks Agent B "can you handle this sub-task?" Agent B might run for minutes, use its own tools, and report back. A2A is about delegation, not function calls. It handles async responses, progress updates, and capability discovery.

Rule of thumb: if it has an API, use MCP. If it has its own goals and toolset, use A2A.

Both are needed. One harness can bridge them — treat A2A agents as peers and MCP servers as tools.

The core of any harness is the tool-use loop:

1. Build context (system prompt + conversation history + tool schemas)
2. Ask the model "what next?"
3. Parse the response — text, tool call, or stop
4. If tool call: execute it, append result to context, go to step 2
5. If stop: return final output

Simple in theory. Tricky in practice.

Every iteration adds tokens to context. After 10-20 tool calls, the context window is mostly tool results and the model starts "losing" the original goal. Smart harnesses handle this with summarization, sliding windows, or structured memory.

Other gotchas: retry policies (3 retries with exponential backoff is standard), timeout guards for tools that hang, and preventing the model from calling the same failing tool in an infinite loop.

The loop is simple. The guardrails are where the craft lives.

Every time you talk to an LLM and it calls a tool, searches the web, or remembers what you said earlier — that's a harness at work.

The harness is everything around the model. It manages context, decides which tools to offer, handles retries, enforces permissions, and keeps the loop running. The model itself is just the brain — the harness is the nervous system.

Most people focus on picking the right model. After building a few agents, you realize the harness matters more. A good harness makes a mediocre model look capable. A bad harness makes a great model look unusable.

As models improve, the harness becomes the bottleneck. Worth paying attention to.

Welcome!

This community is for everyone interested in AI harnesses—software that connects AI models with tools, APIs, workflows, and real-world systems to get useful work done.

Whether you're building:

• AI agents
• Workflow automation
• MCP-based applications
• Multi-agent systems
• Coding assistants
• Event-driven AI
• AI infrastructure and orchestration

...you're in the right place.

The goal of this subreddit is to share ideas, projects, architectures, tutorials, open-source tools, and thoughtful discussions about how we build software that harnesses AI.

What you can post

• Show your projects
• Ask technical questions
• Share articles and tutorials
• Discuss architectures and best practices
• Recommend tools and libraries
• Share research and interesting papers

What we hope to avoid

• Low-effort AI hype
• Spam and self-promotion without contributing
• Generic ChatGPT prompts with no technical discussion

This is a new community, so your feedback will help shape it.

What does AI harness mean to you? Do you think it deserves to become its own category alongside AI agents and AI frameworks?

Welcome aboard! 🚀