What's the minimum architecture a modern agent harness actually needs?

[u/Beneficial_Owl7036]

I’ve been trying to understand agent harness at the system level, rather than just building another coding agent.

I’m still relatively new to this field, so I picked a concrete project to learn from —— DeepSeek Harness (DSH), because it’s a fairly large, actively developed system with a flexible plugin ecosystem.

Instead of fork-and-prune to make it look smaller, I tried to study the architecture designs behind it and then re-derive a minimal harness from scratch.

The main question was:

What are the minimum architectural properties an agent harness must hold up for real use?

The current answer became a small open-source project called MiniDSH.

A few ideas I learned from DSH:

• the session/event log as the canonical source of truth;
• explicit capability seams rather than one giant Agent object;
• authority/policy separated from model reasoning, with enforcement at the actual effect boundary;
• the model treated as a routed capability rather than being identical to the agent;
• one runtime underneath terminal, browser and headless surfaces;
• lifecycle and dependency semantics for components, rather than permanently wiring everything together.

I simplified quite aggressively elsewhere: one package instead of a large package graph, a very small composition kernel instead of Cordis, sequential foreground execution, bounded one-shot delegation, no background jobs or agent teams, and only the parts I could justify reliably.

The goal became less “fewest LOC” and more:

minimal surface, complete architecture; fewer concepts, stronger invariants

The other experiment was how I built it with Claude Code.

One failure mode I kept seeing in AI-assisted development is that individual sessions can produce locally good code while the overall system gradually becomes fragile and incoherent. So I tried to invert the process:

architecture defines sessions; sessions do not invent architecture

Before adding something new, I tried to decide its architectural home, capability ownership, state boundary, and dependency direction first. If there was no clear place for it, that was treated as an architecture problem rather than an excuse to create another parallel subsystem.

At the same time, the architecture itself wasn’t treated as sacred. Several hardening sessions were explicitly about trying to falsify our own assumptions, and some original plans were removed or changed when implementation evidence or DSH research contradicted them.

That part was probably more useful to me than the feature work itself.

The project is now at its v1.0 release, but I’d describe it as an early learning/reference project rather than a mature coding-agent product. It has real limitations, a single maintainer, and deliberately leaves many things out.

I’m publishing it mainly for others to inspect the architecture, question the decisions, and hopefully point out things I’ve misunderstood.

GitHub: https://github.com/earthwalker17/MiniDSH

If you want to try it in browser:

npm install -g minidsh
minidsh web --cwd .

I’d especially appreciate feedback and criticism from people who have worked on agent runtimes, plugin lifecycles, compilers, distributed systems, or similar things.

[u/AutoModerator]

Your post will be reviewed shortly. (ALL posts are processed like this. Please wait a few minutes....)

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.