Title: Today's Custom Harness Is Tomorrow's Skill Slug: today-custom-harness-is-tomorrow-skill Date: 2026-08-09 18:00:00 Author: Kartones Lang: en Tags: Development, Tools, AI & ML, Patterns & Practices og_image: https://images.kartones.net/posts/screenshots/herdr-test-watch.png Description: Agent orchestration doesn’t need another custom harness: a portable session manager, existing coding agents, and a thin skill can be enough. ### Introduction I firmly believe in tool composition. Dedicated tools are good, but the moment one tool tries to do too much, it becomes bloated with features and, almost always, speed and quality degrade. Agentic tools are no exception, and now everyone wants to build their custom agent harness, their custom coding harness, their custom agent orchestrator, or everything together! That's great for experimentation, but building a general-purpose harness means competing with frontier labs, big tech companies, and a large open-source ecosystem. Unless you have a strong differentiator, that's a difficult fight. More importantly, many features that look intrinsic to a coding harness don't need to be. For example, a surprisingly large part of Claude Code's sub-agent system was defined through prompting, backed by a system for spawning agents and exchanging messages [1]. And similar with the tools: A's grep-like tool might be better than B's, but both in the end could just be a standalone binary, invoked through a skill. Subagents may share context, have isolated contexts, support nesting, or not exist at all. Memory and compaction differ too. So I prefer small tasks and small sessions, and avoid workflows that require a specific harness [2] or a giant context window to work. I review my `AGENTS.md` after I switch models, but avoid getting into a vendor lock-in: What Opus 5 infers and does automatically might not be the case with Sonnet 5, or even less with Qwen 3.6, or with GPT Terra. In summary, I stay away from overfitting the agent harness (the overall AI guidance, instructions, skills and such), instead defining *a common and portable baseline*. I have it under version control, and I symlink all the coding harnesses so they read the same `AGENTS.md` and same skills and agents folders. Whatever does not work, is out. ### On Agent Orchestrators One of the aspects that I wasn't yet thrilled with was orchestrating agents. My usual setup used to be several terminal tabs running coding agents, with one or a few of them spawning subagents when necessary. It worked well, so I wasn't actively looking for an orchestrator. Until I came across [Herdr](https://herdr.dev/). Quick summary of what it is: - It is a persistent client/server terminal session manager **designed for agents**: workspaces → tabs → panes, locally or remotely - Install [its skill](https://github.com/herdrdev/herdr/blob/f6060cf682f69ef8302c25e8924c0b27aef7ae16/skills/herdr/SKILL.md) so an agent can inspect, create, and interact with panes - I recommend to also install [integrations](https://herdr.dev/docs/integrations/#install-integrations), to improve coding harness (agents) lifecycle/session handling - You start one agent as the lead/orchestrator; the, instruct it to create coding-agent workers in other panes and delegate work to them That last point looks simple, and it is why I'm so amazed with this tool: such a simple concept works so well, that suddenly, you can effortlessly have a Sonnet 5 orchestrator agent directing a herd of an Opus 5 planner, Codex Terra coding workers, and maybe an OpenCode Qwen 3.6 test and lint writer. No need to handle the different OpenAI, Anthropic and other API messaging protocols, no need to deal with context issues (each worker has its own), no need to deal with subagent limitations (each worker can spawn subagents on its own, if supported and deemed necessary)... **The agent orchestrator became a basic session manager and a skill**. The best abstraction is the one you don't need. The second-best software abstraction is one that works universally with little or no glue code. In Herdr, you only need to create tiny integrations, and those are only needed [to properly report lifecycle state](https://herdr.dev/docs/integrations/#integrate-your-own-agent) and session management. As the orchestrator is an agent, not code, even if it runs into an issue, it can easily recover [3]. What is crucial for me is that suddenly, **you no longer need a fancy harness to orchestrate agents**, and that you in fact orchestrate agents **via their own coding harnesses**, so you are very much platform-agnostic. You can combine local models with remote models, cheap models with the latest and greatest, and each coding agent runs using its own supported authentication mechanism. Herdr doesn't need to replace those harnesses or understand their internals, it simply composes and leans on them. I am prototyping a small Herdr skill around this workflow [4]. I've already used it successfully for long agent-first coding loops on personal projects, including a cross-compiled Go application for macOS and Windows with a substantial test suite. ### Not Everything Should Be an Agent Because Herdr manages processes rather than only agents, not all of the work needs to go through an agent. Before coding agents, I often kept unit tests running continuously through a watcher or simple loop. There's no reason to stop doing that just because an agent is writing the code. This is an example from a Python project's Makefile: ```makefile test: build set -o pipefail; \ $(COMPOSE_CMD) uv run --no-sync --group dev pytest test-watch: build $(COMPOSE_CMD) sh -c 'while true; do clear; uv run --no-sync --group dev pytest; sleep 5; done' ``` I now include in my Herdr skill invocation instructions as the following: ```markdown - In the same `workers` tab, create another pane to run `make test-watch`, which will re-run tests every few seconds. Tell any worker that writes code and/or tests to watch it after each change, instead of running tests on their own. ``` ![Herdr running worker agents and a test-watch pane](https://images.kartones.net/posts/screenshots/herdr-test-watch.png) Executing that loop is now not consuming any token (only when an agent inspects it), and you have a deterministic way of ensuring that tests pass after any change (of course, as long as the agents look at it). No more "Did you run the tests? ALL of them?" manual prompts. Tests are just one example. Linters, type-checkers, dev servers, logs, profilers, and other deterministic processes can live in their own panes too. The agent doesn't need to perform (or know how to perform) everything; sometimes it only needs to observe. ### Footnotes [1] : Since I checked, now Claude Code also supports multiple levels of sub-agents, so the system has surely evolved. But I'd bet something that much of it will probably still be prompt-defined, as that's simpler to tweak and evolve. [2] : In my opinion, most coding harnesses look heavily vibe-coded these days: You just need to follow the changelogs to see that many features feel just hacked in, then tested in production via the customers, then bugfixed as you go. Half of the fixes would be embarrassing in pre-GenAI times. [3] : And you can both learn from it, e.g. prompting to one-shot teach it how to deal with more complex scenarios. [4] : I always create the orchestrator agent in a `lead` tab, and the skill instructs to create the workers in a `workers` tab, alongside some personal guidelines.