At the same time I’ve taken the leap into the undeniably funky realm of running an LLM as a persistent virtual assistant. This post introduces my new Groundhog project. It’s an extremely thin orchestration layer, defined at the systemd level in a 200-line Nix module.

The State of Play

I held out for a long time on adopting harness-powered workflows. I preferred high-granularity manual control offered by Zed. This gave me ways to control

• cost. My token spend was a few dollars per month, even with (to me) heavy usage.
• outcome. (model quality) x (harness quality) was simply not at a threshold where I’d have a successful outcome.

However, the tooling evolved out from under me, and I’ve had to thoroughly rebase my assumptions. The two forcing factors were:

1. My preferred Zed workflows were deprecated. The Text Thread feature was removed in favor of agent-only structure.
2. the Claude Code harness evolved, eventually addressing all of my gripes and achieving high success rates with the same models.

Additionaly, Claude Code authentiates with a Pro account and I’ve never run up against limits. Thus I’ve finally arrived at the common consensus that you simply can’t beat Claude Code as a driver. I have ceased to struggle and joined the Borg, like in The Star War.

Autonomy

I’ve felt a twinge of FOMO at autonomous agent projects like OpenClaw. Of course I want a little digital assistant looking out for my interests, keeping tabs on things I care about and pinging me when I need to know something.

There’s one big problem: None of these projects has ever come remotely close to my comfort zone to run or interact with.

There’s a tendency to bloat, especially once you get these things working on themselves. You expect me to install this app that’s 15,000 lines written in some wretched goblin language like Python or Javascript? You must be getting out of town.

Obsidian workflows

I’m a longtime pre-AI user of Obsidian. I self-host with syncthing to keep notes synced between my phone and computers. In my day-to-day work I naturally fell into a workflow that some have dubbed the “Second Brain” system. It’s the logical conclusion of both

1. Managing your own knowledge base and
2. Creating context for AI agents.

It just involves an extra step for the agent. Here’s a few simple examples of prompts for Claude Code, where I have an Obsidian vault sitting at ~/o

Read the design document at ~/o/topic/design.md. Investigate the codebase and update the document with any potential blockers. Create a plan.md with a step-by-step breakdown.

Execute on step 1 of ~/o/topic/plan.md.

Essentially you want to keep a durable view of reality that’s shared by consensus across agent sessions. Nobody needs to juggle sessions and figure out which chat to resume.

Groundhog

Anyways, all this is to say that these 3 facts came together:

1. Claude Code is now good enough to do anything
2. I appreciate a graph-based (as opposed to linear) approach to managing durable knowledge
3. I’d like to give my system a little more autonomy

This is a problem that’s solved at the systemd level with a few lines of Nix. The groundhog module definition slots into my VPS config like this:

inputs.groundhog = {
    url = "github:roriholm/groundhog";
};

services.groundhog = {
  enable = true;
  tokenFile = "/etc/groundhog/oauth-token";
};

An initial vault gets bootstrapped and registered with Syncthing. Then there’s simple logic:

1. A note syncing to the /inbox folder triggers a Claude Code instance.
2. The CC instance has access to the vault and is instructed to drain the inbox to end the wake cycle.
3. A configurable “heartbeat” wakeup triggers routine tasks.

That’s all that’s happening at the system level. The behavior and vault structure emerge from usage. We don’t need MCPs, complex integrations, and expansive harness logic. Claude already knows how to navigate through Markdown links, and knows what to do!

Extension

The control plane is shoved entirely into the context!

Scheduled tasks are introduced by conventions. The heartbeat prompt routes to a CLAUDE.md which gives instructions. Those instructions route to a scheduled_tasks.md. Every line of that looks like:

do once a week, last done 8/9/2026, route/to/task.md

CC is smart enough to downselect and fan out subagents. Maybe task.md just says to check the price of Bitcoin and mention in my daily note if it’s above $100k. (Just kidding don’t care!). None of the scheduling logic ends up in my harness!

Security

Groundhog runs CC with --dangerously-skip-permissions. The agent is an unprivileged system user in a systemd jail. Everything is read-only except the vault and its own home. What the jail can’t bound is the network, the inbox should be treated (guarded) like a shell.

The Dream

AI is kind of a trap for a lot of computer-touching individuals. Lots of raw brainpower has been dumped into agent frameworks and harnesses. There’s a dopamine hit of seeing an agent start to improve itself. My goal has been largely to remain aware while resisting the mind virus. Most of these projects are dead ends - Commentators have noted the dynamics at play lead to vertical absorption of anything interesting. If your product is a thin wrapper around a Claude model, then there’s not much barrier to them just implementing it.

Fear of being left behind drives a lot of AI-adjacent development. Instead I would like to engage with hope: that this technology should allow us to achieve more in less time, to make better decisions, and to be more aware of the world and the things that we care about.

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!