With model capabilities going parabolic, attention is turning to the control plane (or “harness” - the orchestration layer between your code and your model) as the next bottleneck. It seems to be a source of low-hanging fruits as well as contention from the model providers who have very good reasons to force you to use theirs.

Many AI users are happy to treat the harness as a solved problem within their IDE of choice, or as a compositional primitive in their orchestration system (“Claude Code instances lashed together”).

However, examining some of the most basic workflows implies a better way forward!

These are simplified illustrations. Production frameworks handle these specific cases, but the pattern applies everywhere. Most projects have similar inefficiencies waiting to be optimized.

Re-Learning The Whole Codebase At Every Step

You task an agent within a workspace. It knows how to orient itself:

• System prompt
• Tasking prompt
• Command-line tool calls: pwd, cat AGENTS.md, or whatnot.

After ascertaining the structure and identifying the locations of interest, it proceeds. Now during the problem-solving phase, the orientation steps are just noise. Why do we need to infer these command line operations to begin with?

Instead of CLI tools, we could expose a prompt-rewriting wrapper called orient that brings in the directory tree and picks out the potential relevant files to feed forward into the actual task execution stage.

These precious early-stage token savings compound through the rest of the context. The orientation alone can consume 15-20% of your context tokens as it’s dragged through every subsequent reasoning stup.

Paying A Bot To Read Terminal Output

At the end of a task, the agent knows to compile and test. It makes the appropriate CLI call and ingests the whole output.

First, note that this is all happening at the tail of all the task-related context: Unnecessary cost.

Next, note the extra overhead involved in generating the compile command and reading from the entire terminal: Unnecessary cost.

A compile tool should wrap the CLI call, parse and truncate any errors or warnings.

Terminal Management Anti-Pattern

Have you ever seen an agent try to kill a process running in a different terminal, so it can run its own for testing purposes? This is an anti-pattern if I’ve ever seen one.

How about for Nix users, where the agent needs to discover a flake.nix before it knows how to enter the development shell?

A test tool should be overridden to fit the workflow at hand. Maybe it does need to start its own instance. Maybe the reins go to the user who’s active in a different window and gives a validation response.

Summary

Harness development is the next critical step for lowering costs, improving outcomes, and improving security of AI-assisted workflows. You don’t need to build everything yourself, but understanding the harness/model boundary helps you choose better tools and know when to customize.

Building agent workflows? Email me to discuss your use case for harness design and optimization.

Always wary of getting caught up in hype, I’d like to chime in again and try to tease out some common threads behind some of the most interesting and successful experiments. In doing so, I’ll suggest a potential way forward that I’d like to explore.

Coding Agents: Claude Code

This is the daily driver of many a vibe-coder. I only mention it first because it’s used as a building block in the next section. Most “coding agents” share the basic structural features:

• System Prompt: The base “personality” of the LLM.
• Tools: Special types of messages that the LLM can send to invoke some out-of-context execution and retrieve results.
• Skills: Markdown files that can be brought into context, effectively extending the system prompt for some specific task. These are requested by the agent through tool invocation.
• Context: The sum total of all the above, plus conversation history and tool results.

Tools give the ability to traverse, edit, and compile filesystem objects. That’s basically it - let it loose in your project folder, say a prayer, and you may get some useful work done. Your context will probably grow very rapidly, leading to high costs. A wrong turn early in the context can lead to an expensive dead end that needs to be backed out and re-attempted.

My main issue with Claude Code is that the control plane is somewhat opaque:

• Can you reduce the system prompt?
• Can you characterize tool invocations and modify their implementations to use context more frugally?
• Can you understand and modify the permission scopes and easily sandbox the agent?
• Can you decide when to prune or compact the context to reduce costs?

The answer to all might be yes - especially if you adopt an open-source alternative and really dig into the tool. My point isn’t that these are limitations, but that coding agents simply haven’t been appealing enough to dig into their peculiarities. Just YOLO with off-the-shelf settings and maybe you’ll get your money’s worth.

Orchestration: Gas Town

This highly deranged and entertaining article on the Gas Town project describes experiments with assigning roles and lashing together instances of Claude Code. The author admits that Gas Town is “expensive as hell”. The math is simple: if Claude Code munches a ton of tokens, then dozens of Claude Codes munch dozens of tons of tokens.

The results are undeniably interesting. I struggle to get my head around the numerous roles and abstractions invented by the author, who seems delightfully able to come up with ideas faster than anyone can keep up with. The issue here is that the orchestration plane is highly opinionated and, as above, difficult to reorganize without really digging into the tool.

Research from Google finds that multi-agent systems aren’t always the best tool for the job - so orchestrated agents like Gas Town might never be the default.

Pi

Pi is the “Minimal Agent” powering OpenClaw. It is fundamentally similar to any other coding agent, but with a focus on starting with a slim set of core tools (Read, Write, Edit, Bash) and encouraging extension into modular components.

The core philosophy seems to be that a coding agent should know how to extend itself. This lead to a rapid bootstrapping of integrations, plus easy onboarding.

The tool has gone viral as an always-on AI assistant. While the idea is appealing, I can’t personally recommend it as the security attack surface seems way too large.

What Next?

My recent work in data modeling has centered around one idea: By starting at the modeling level, you lock yourself into architecture and tooling. An alternative approach is to work from a metamodel foundation that has introspection - the ability to self-host. This gives you flexibility, provenance, and reproducibility.

My hypothesis at this point is that a true Minimal Agent shouldn’t work with filesystem and command-line primitives. Instead, the minimal tools for bootstrapping any kind of agent architecture might be:

• defining tools
• defining agent profiles
• creating workspaces (sandboxed VMs!)
• spawning agents into workspaces

This meta-agent’s prime concepts are security, scope, and orchestration. It has a self-definition. It could end up spawning new agents that look like Gas Town in one VM, or Pi in another.

I just need a catchy project name and I’ll get a proof of concept online!