I studied DeepSeek Harness to answer: what's the minimum architecture a modern agent harness actually needs?

I’ve been trying to understand agent harness at the system level, and DeepSeek Harness ended up becoming the main project I studied. Rather than fork-and-prune to make it look smaller, I tried to read its architecture, subsystem docs, package boundaries and design notes as a textbook, then re-derive a minimal harness from scratch, which now exists as 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 Another useful lesson 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. Meanwhile, 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: github.com/earthwalker17/MiniDSH If you want to try it in browser: bash 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.