{"slug": "what-s-the-minimum-architecture-a-modern-agent-harness-needs", "title": "What's the Minimum Architecture a Modern Agent Harness Needs?", "summary": "A developer built MiniDSH, an open-source minimal agent harness derived from studying DeepSeek Harness, to determine the smallest architecture that remains architecturally complete. The project defines explicit answers for where truth lives, who owns state, where permissions are enforced, and how sessions survive crashes, and was largely developed through Claude Code sessions with an architecture-first process. The developer notes it is an early v1 and deliberately incomplete, and is seeking feedback on agent runtime design.", "body_md": "I built this mainly to answer one question while trying to understand coding-agent systems:\n\n**What's the smallest agent harness that is still architecturally complete?**\n\nBy \"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.\n\nI 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.\n\nRather 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**.\n\nThe resulting design ended up with a few principles that matter more than LOC:\n\nThe last point became a useful rule:\n\n**everything evolvable has a seam, but not everything needs to become a plugin.**\n\nAnother valuable experiment was the development process itself.\n\nMost 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.\n\nA 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.\n\nSo I tried to invert the process:\n\n**architecture defines sessions; sessions do not define architecture.**\n\nBefore 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.\n\nMeanwhile, 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.\n\nThat combination now seems important to me:\n\n**design the system space before filling it, but continuously try to falsify the system space itself.**\n\nThis 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.\n\n**GitHub:** [https://github.com/earthwalker17/MiniDSH](https://github.com/earthwalker17/MiniDSH)\n\nIf you want to try it in browser:\n\n```\nnpm install -g minidsh\nminidsh web --cwd .\n```\n\nI’d especially appreciate feedback from people who have worked on agent runtimes, plugin ecosystems, compilers, distributed systems, or similar things.\n\nWhere do you think this architecture is over-designed, under-designed, or simply wrong?\n\nAnd more broadly: **what do you consider the true minimum set of invariants/components for a modern agent harness?**", "url": "https://wpnews.pro/news/what-s-the-minimum-architecture-a-modern-agent-harness-needs", "canonical_source": "https://dev.to/earthwalker17/whats-the-minimum-architecture-a-modern-agent-harness-needs-6eg", "published_at": "2026-09-21 14:35:28+00:00", "updated_at": "2026-09-21 14:54:59.716077+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "ai-infrastructure"], "entities": ["MiniDSH", "DeepSeek Harness", "Claude Code", "GitHub", "Codex"], "alternates": {"html": "https://wpnews.pro/news/what-s-the-minimum-architecture-a-modern-agent-harness-needs", "markdown": "https://wpnews.pro/news/what-s-the-minimum-architecture-a-modern-agent-harness-needs.md", "text": "https://wpnews.pro/news/what-s-the-minimum-architecture-a-modern-agent-harness-needs.txt", "jsonld": "https://wpnews.pro/news/what-s-the-minimum-architecture-a-modern-agent-harness-needs.jsonld"}}