Wiki › Engineering with agents

Self-Extending Agent Harness

Coding-agent environment that rebuilds and hot-reloads itself while running, using coordinators, worktrees, a merge-on-green lander, standing agents, and non-waking notes.

A self-extending agent harness is a coding-agent environment that the agents themselves continuously modify while it runs: new tools, UI views, standing agents and core changes are built, tested and hot-reloaded from inside the same conversation that requested them. It turns Harness Engineering into something done mostly by the harness itself, with the human steering through one primary chat.

The fullest described example is Ultimate, Daniel Griesser's toy project built on Pi Durable, a durability layer for the Pi agent framework. Griesser calls working on it "the fastest I've ever iterated on software". The first version came from a single long Claude Code planning session, run overnight. About twenty commits later Ultimate was building itself.¹

Building blocks

• Hot self-reload. A supervisor process holds the server port. A freshly built process must boot successfully before the supervisor hands over the port, and the browser simply reconnects. The agent can therefore change its own core mid-conversation, and even switch models mid-run, without losing state.
• Durable everything. Every action of every conversation and subagent is persisted. The harness can replay its own failed tool calls, analyze behavior, codify new tools and delete unused ones. This is the Skillification ratchet applied to the harness itself.
• Coordinators, not a single agent. Each feature gets a coordinator with scout, designer, worker and reviewer subagents. It runs in its own git worktree and spawns its own test server, which it drives with a browser and screenshots. Griesser typically runs four to six features in parallel.
• The lander. A built-in *standing agent* (one that is never concluded, so it keeps its project memory) runs all tests locally, resolves merge conflicts between features and pushes to main only on green. In one example it merged two overlapping features, fixed a test the merge broke, and landed once all 407 tests passed. Other standing agents are project-specific, for example a Cloudflare deployer that watches errors for five minutes after a release.
• Notes. A message that does not trigger an agent turn and is simply present when the recipient's next turn starts. Coordinators leave workers notes when something lands on main or the plan changes, so parallel work drifts toward mergeable changes. Low-value progress updates become notes instead of interruptions.
• Questionnaires before building. For larger features, Ultimate first returns an assessment and a few decisions with its own picks pre-marked, plus a preview. Implementation is handed to a coordinator only after the human agrees.
• Side chats. Pressing Tab forks the main conversation for cleanup or a quick question with warm context. The result is either summarized back into the main thread or discarded.¹

From coding agent to project colleague

Griesser's stated goal is an agent that feels like a colleague who knows the project inside out and is the same every time you return. In his view, Claude Code and Codex feel distant from the actual project. When he plugged Ultimate into his blog, it read his earlier conversations, proposed a plan as a seven-question questionnaire, and in about an hour built a custom writing UI with a docked standing writer agent. That agent handles narration as well. This links the pattern to AI-Generated Personal Software: the harness grows bespoke helper UIs (database managers, status dashboards, deploy views) for each project it lives in.¹

Ultimate mixes models by role: Opus 5.5 as the main model, GPT 6.1 Sol for workers, Astra for correctness review, and Luna as a cheap summary model for labels and titles. Instances find each other over Tailscale, so one can tell another what changed in the core and get bug reports back.¹

Limits and open questions

• In Griesser's account, once the loop is tight and the codebase is "completely ready for agents", tokens per second become the bottleneck. This echoes the inference-as-capital point in Agentic Software Factories.
• He wants agents to solve the problem he describes rather than build his first, limited solution. That raises the stakes for the judgment concerns in Cognitive Surrender and Loop-Dependent Software: he reviews code mostly *after* merging, and relies on tests, reviewers and guardrails instead.
• This is a single-developer toy project with no stability guarantees, described by its author. It is evidence that the pattern can work for one experienced engineer, not that it generalizes to teams or long-lived production systems.¹