One idea, adapted to each platform.

An agent said "waiting", and I took that as reassurance. The word sounded safe. It meant the work was over. Yesterday I gave one of my agents a simple job: wait until a new image of my harness was published, then update the agents to it. The image did not exist yet, so the agent said waiting, which was the right answer. Then the image shipped, and nothing happened. The agent did not crash and did not stall. It finished its check and went quiet, exactly as it was built to, and nothing in my harness was set up to look at that wait again. I found out the job had stopped only because I asked why nothing had moved. That is the gap that bothers me. My agent could be wrong about being blocked, and it could be right about waiting and still have nowhere to go. Both end the same way: a task that quietly stops and a person who has to poke it. The change I wanted is not a smarter status message. It is a wait that lives outside the agent's own report. The harness keeps a time to look again, a bound, and a hard deadline, so the promise to come back later is subject to a check and an end, not left to the agent's word. The textbook answer is a webhook that rings the moment the image exists, and it is a good answer. I chose a timer, and I am comfortable being judged on it. A ring only covers the one thing you wired for it. A timer works for any condition an agent can name, a restart does not lose it, and a woken agent still has to go verify the thing really exists before it touches a rollout, because being woken proves nothing. The timer exposes a flaw the webhook hides: at no point do you get to trust the agent's word, only its latest check. There is a cost I am not hiding. The timer is cruder, it adds latency, and an agent can still misread its own state. I take that over the alternative, because what I get in return is knowing when a wait goes wrong. If your agents can wait, let something else hold the deadline and check it, because "waiting" will not tell you the truth on its own. This is the same argument as my earlier post about "done": an agent's report, whether finished or waiting, is evidence to check, not proof to trust. The changes below are public in the VanillaCore Agent Harness; released source is not proof any installation runs them, and I claim no compatibility with Hermes Agent, Claude Code, Codex or OpenClaw. Window 26 Oct 08:00 to 27 Oct 08:00 Berlin (CET). https://samaschke.com/Blog/Post/vanillacore-harness-waiting-needs-a-recheck

I woke up to an agent that had worked all night. Seven merges, six releases. The count is not the point. The point is what it can prove it did. Every turn now gets a durable ledger entry before it runs, and the result is settled before the usual snapshot is written. If the process dies between those two writes, recovery takes the saved result instead of asking the model again. That closes the gap between "the turn is finished" and "the Harness wrote that down". The part I like most is the crash case. Before an opaque turn, the dispatcher records an "unsafe" effect intent. If the worker is interrupted and nobody knows which external effects already happened, the task becomes blocked. There is no automatic reconciliation. An operator has to check what actually happened and submit new work deliberately. A dispatcher that retried an opaque turn on its own would generate duplicate invoices, duplicate pull requests and duplicate emails. This one stops and makes you look. That is the question I would put to every agent runtime that wants to work while I am asleep: after a crash, does a finished turn count as finished, does a stopped task stay stopped, and does an unknown effect get retried or handed back to a human? The Harness answers all three in writing, including the cases where the answer is "we do not know, so we block". https://samaschke.com/Blog/Post/vanillacore-harness-execution-ledger-dispatcher

Most of my agents run on Hermes. Hermes is good. It is also big: lots of tools, lots of features, lots of configuration, and whatever sits in the context costs tokens on every turn, whether the task needs it or not. For a personal agent that lives in a chat room, runs a few cron jobs and answers API calls, I wanted less of that. So I built a harness of my own on top of Pi-Agent, and as of today it is public under Apache 2.0. The VanillaCore Agent Harness is deliberately small. I see it as a possible replacement for Hermes in the way I run persistent agents, and for OpenClaw where people use it for the same job. It is not a clone of either, it does not aim for feature parity, and it does not try to cover every function those projects have. Why Pi? Pi's idea is that you adapt the harness instead of adapting to it. A coding agent that extends itself is useful at a terminal. The same property inside a long-running agent that lives in Matrix and takes runs from a control plane is worth a lot more. This is a build-in-public project. I use this harness every day, so it gets updated continuously, not in release cycles. In the coming weeks I'll publish it upstream to GitHub, and I'm looking for contributors. If you run persistent agents and want a smaller harness, the repo is a good place to start. The source is about 4,500 lines of TypeScript with four runtime dependencies, plus roughly 3,000 lines of tests. On a fresh checkout, all 171 tests pass. Lighter should mean cheaper per turn. That is the design intent. I do not have benchmark numbers yet, and I will not invent any. Once we have run the same agents on Hermes and on this harness, the measurements get their own post. This is version 0.1.0. Matrix works without end-to-end encryption, and media, edits of the agent's own messages and reactions as acknowledgements are still missing. There is no web UI and no Slack adapter yet. Repo: https://git.vanillacore.net/harness/core Post: https://samaschke.com/Blog/Post/vanillacore-agent-harness-built-on-pi

An agentic team can outrun its own review process, and ours did. Our development team became 3.5x faster, and two months later that number had doubled again. The speed was never the hard part. What we missed was that the processes on the developer and team level hadn't kept up. 👉 Developers stopped questioning their agents and demanding proof. The automated review gate had no human in the loop. The feedback that should have caught both landed unread. Read the blog post to learn more about it. https://samaschke.com/Blog/Post/speed-compounds-so-do-mistakes