I built this mainly to answer one question while trying to understand coding-agent systems:
What's the smallest agent harness that is still architecturally complete?
By "complete" I don't mean feature-complete. I mean that the system still has clear answers to questions like: where truth lives, who owns state, where permissions are enforced, how models and tools are composed, how a session survives a crash, and whether adding another feature requires another agent implementation.
I studied DeepSeek Harness as the main reference. I found it interesting because its architecture is fairly explicit: capabilities have lifecycle and dependency semantics, model-visible history is derived from durable session state, authority is separated from model reasoning, and user surfaces sit over a shared runtime.
Rather than fork-and-prune to make it look smaller, I tried to re-derive those properties into a minimal system, which now exists as a small open-source project called MiniDSH.
The resulting design ended up with a few principles that matter more than LOC:
The last point became a useful rule:
everything evolvable has a seam, but not everything needs to become a plugin.
Another valuable experiment was the development process itself.
Most of this project was built through Claude Code sessions. One failure mode I kept noticing in AI-assisted development: coding agents are very good at producing locally reasonable code, while the overall system quietly becomes fragile and incoherent over time.
A feature needs browser verification, so a browser module appears; Another needs memory, so a memory manager appears. Each addition can make sense locally while the architecture gradually becomes a collection of parallel subsystems rather than a self-consistent system.
So I tried to invert the process:
architecture defines sessions; sessions do not define architecture.
Before implementing a new feature, I tried to answer where it belongs, what it owns, what it may depend on, what its lifecycle is, and where its durable state goes. If there was no clear architectural home, I treated that as an architecture problem rather than an excuse to create another parallel subsystem.
Meanwhile, the architecture itself wasn’t treated as sacred. Several sessions were deliberately hardening/review sessions whose job was to falsify the existing design. They found documented invariants that were not actually true, implementation assumptions that failed against real providers or operating systems, and some original plans that contradicted the implementation evidence or upstream DSH research.
That combination now seems important to me:
design the system space before filling it, but continuously try to falsify the system space itself.
This project is the concrete experiment behind these ideas. It's still an early v1 and deliberately incomplete; I don't consider it a mature coding-agent product like Claude Code, DSH, Codex, etc. The useful part for me has been making the architecture explicit enough that a later session can still answer "where does this belong?" before touching code.
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 from people who have worked on agent runtimes, plugin ecosystems, compilers, distributed systems, or similar things.
Where do you think this architecture is over-designed, under-designed, or simply wrong?
And more broadly: what do you consider the true minimum set of invariants/components for a modern agent harness?