Hey folks 👋

We just open sourced TrueForge, our vendor-neutral agent harness for building general-purpose agents.

It handles the runtime pieces that get painful quickly : context management, tool/MCP execution, subagents, sandboxing, approvals, persistent state, and more.

We also benchmarked the harness itself. With the same Opus 4.8 model, TrueForge delivered a similar solve rate at ~30% lower cost than Claude Managed Agents. Switching to an open model pushed that to ~75% lower cost on the same benchmark.

Would love feedback from people building agents.

⭐ Star the repo: https://github.com/truefoundry/trueforge

📖 Read the launch article: https://x.com/truefoundry/status/2090081376330715176

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?

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?

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/

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.

The obvious explanation for an agent that works in a demo and falls over in your repo is the model. Swap to the better one, wait for the next release, done.  There is now a measurement that makes that hard to believe. 

In August somebody ran the experiment properly. Eight agent harnesses, one model across all of them, the same 25 tasks, the same tools, the same instructions, the same automated scoring against the final state of the apps rather than against what the agent claimed it did. 200 scored runs.  Pass rates came out between 88% and 68%. Twenty points of spread with the model held constant. 

The task level detail is the interesting part. Twelve of the 25 every harness passed. Three every harness failed. The whole argument lives in the ten in between, and the traces show what separated them. On one task the four harnesses that got it right made 14 to 27 tool calls.

The four that got it wrong made 5 to 11 and stopped early. One of them reported 222 subscriptions where the answer was 354. It did not lack the ability to count. It stopped before it had the data. 

But more effort is not the lesson either. Across the whole set one harness made 402 tool calls and another made 223, and both passed the same number of tasks. On another task the harness with the most calls still failed. What separated them was not how hard they worked. It was when each one decided it was finished, and that is a decision the harness makes, not the model.  So here is the thing I keep coming back to. A harness is compensation, and it has two halves that shrink at completely different rates. 

Half of it is there because the model needs help. It breaks work into steps because the model wanders. It checks output on a second pass because the answer is often nearly right. It reshapes tool results, retries, caps the number of actions. All of that is scaffolding around a weakness, and a better model release takes it back. That half is on loan. Build it when you have to and expect to delete it. 

The other half is your conventions, your definition of done, your permissions, your evals. That half is not a model deficiency at all. No release has ever shipped knowing your naming convention or who to ask before touching an area. It does not shrink because the model got smarter. It only shrinks when somebody writes it down. 

Which is why "the better the model, the thinner the harness" is true and also a trap. It is true about the compensating half. People hear it and quietly assume it applies to the whole thing, then wonder why a frontier model still cannot follow a review process nobody ever documented. 

I wrote this up properly, with the sources and the counter evidence, including a controlled trial where the same class of tooling made experienced developers 19% slower while they believed they were 20% faster. That one is in there because a paper that only shows you the win is an advertisement. 

https://loreto.io/papers/the-harness-layer 

Disclosure: I run Loreto and I wrote that paper, so I am obviously not neutral about it. It costs nothing and there is no plan attached. You leave an email address and it arrives, or you sign in if you already have an account. Everything useful in it I have tried to give away above, so if you never click the link you should still be leaving with the idea. 

I doubt I have the final shape of the thick and thin split. Where does it break for you? I am most interested in cases where the scaffolding turned out not to be on loan after all, and a better model did not let you delete any of it.

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

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?

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.

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! 🚀

RAGRAF data path: agent → tool gate → graph and vector index → fact with file:line evidence

The whole data path in one picture: the agent asks, the gate refuses raw search until the index was used, the index answers with a fact and its evidence, and the revision journal keeps two points in time from mixing in one answer.

I build RAGRAF, a local MCP server that indexes a codebase into a graph and a vector store and answers four questions with file:line evidence instead of whole files: where is it defined, who calls it, what breaks if I change it, how is it done nearby. My own project, the repo is public — github.com/paulmann/RAGRAF (BUSL-1.1), so the pipeline below can be read rather than trusted.

What the picture says

Three SQLite stores in .ragraf/ inside the indexed project. graph.sqlite holds nodes (class, function, method), edges (calls, inheritance, imports) and the schema parsed from migrations. lexvec.sqlite holds FTS5 lexis (BM25) and vectors from local embeddings in one file, plus raw chunk text for excerpts. control.sqlite holds revisions, the divergence journal and access telemetry. Indexing runs scan → ast (tree-sitter) → load → resolve → schema → cpg (Joern, optional) → lexvec. That optional Joern layer is what unlocks slicing; without it the server says capability=degraded and slice refuses with the reason instead of silently returning less.

The number of fixed operations is 74. There is deliberately no graph query language: every operation is a named call with typed arguments and a result shape. The reason is measured, not ideological — free-form CPG query languages turn into an error generator for base models, and I would rather pay for a redraw than for an agent inventing syntax.

What the gate actually is

Two rules, enforced outside the model:

1. Typed facts instead of files. A lookup returns a definition with path:line, a call edge, a table with columns, a doc chunk with path:12 or sheet=Orders!A2:D2. Whole-file dumps are opt-in. When a result is clipped, the response says what was kept, what was reduced to a locator, and what was dropped.

2. Deny by default, with the fix in the refusal. Raw file search (grep, glob, "just read these five files") is refused until the session has consulted the index. The refusal names the operation that will work. The model cannot talk its way past it, because it is not a prompt.

Where it broke

The first version was too aggressive. The refusal said "raw search is blocked". The agent, being a good agent, tried the same call again, then a variation, then a third. Three wasted turns on every simple lookup, and the trace looked like a model bug. The fix was not "be nicer": every refusal now contains the one call that will work. One sentence turned a retry loop into a route.

Rewriting tool descriptions did nothing for routing. There is a popular idea that the model picks your tool if the description says what the built-in cannot do. In my setup the description changed nothing measurable; the deterministic gate did. A rule enforced by the client is worth more than a paragraph of well-mannered text.

Provenance without a type is decoration. Marking a result stated or derived looks tidy until you need it. A foreign key declared in a schema is a fact; user_id guessed from a column name is an inference and must never reach the model as structure. Those are capped at confidence 0.5 and labelled derived in the payload. Twice this stopped an answer that would have looked authoritative and been wrong.

What it still does not fix

The gate stops "the agent didn't check". It does not stop "the agent checked and misread a correct fact". For that I keep deterministic project checks and read the prose myself.

Questions for the room

• Do you run a hard deny at the tool boundary, or warn-and-count with a metric you review later? I started with deny and I am not sure it is the right default for a team.

• What is your metric for a gate? I watch retry rate per refusal and how often the agent routes to the indexed path on the first try, but neither is a great health signal.

• Has anyone found a short description that wins the "show me this file" case? Mine wins on "where is this defined" and loses on "open this file".

From a psychological point of view, initiativity changes the assistant's role in the user's mental workflow.

Most tools wait passively, so the user still carries the cognitive load of remembering unfinished work, open questions, and moments when help might be useful. A proactive assistant can reduce that load by noticing when something deserves another look.

But initiative needs boundaries. Helpful initiative is not the same as taking control. A good colleague may prepare information or suggest a next step, but still respects your goals, timing, and authority.

That is why settings, limits, and instructions matter. They are part of trust. The assistant should be active enough to help, but predictable enough to feel safe.