The editorial argues this isn't a LangChain/AutoGen rewrite but a bet on a specific architectural primitive: everything is a plugin and plugins hot-reload without restarting the process. This shifts the framing away from tool-calling mechanics toward operational agility.
Points out what's buried under the lede: the harness uses Cordis v4, a plugin system whose lineage (v3) has been running the Koishi chatbot framework for roughly four years. The real story is hot-loading and unloading plugins without restarting a running process.
Highlights the README claim that every run is traceable via an append-only session log capturing system prompts, reasoning, tool calls, results, subagent scheduling, and every context injection. The Trajectory view lets you inspect by source and resume, fork, search, and replay — treating agent runs as versionable artifacts.
Frames the trajectory system as 'git-for-agent-runs, baked in at the runtime layer' — a first-class primitive rather than an afterthought. Argues this reflects a bet that the tool loop is basically solved and the real pain is operational: inspection, replay, and swapping implementations without losing state.
The author is up-front in the README and HN thread that this is an early developer preview and users should 'expect lots of rough edges and compatibility-breaking changes.' The framing is deliberately experimental, not production-ready.
DeepSeek pushed a new repo to GitHub this week — `deepseek-ai/deepseek-harness` — and it climbed to the top of trending fast. The pitch, per the README and one of the authors posting in the HN thread, is an early developer preview of an agent harness: the plumbing layer that sits between a model and the tools, subagents, and UI it drives. It's MIT licensed. The author (tianyicui) is up-front that it's rough: "Expect lots of rough edges and compatibility-breaking changes."
What's easy to miss on a quick skim is that this isn't a rewrite of the LangChain / AutoGen pattern — it's a bet on a specific architectural primitive: everything is a plugin, and plugins hot-reload without restarting the process. That primitive comes from Cordis v4, a plugin system whose v3 has been running the Koishi chatbot framework for roughly four years. As one commenter (ef2k) noted in the HN thread: "What's buried under the lede: this harness is using Cordis v4 (the paper that dropped today). Cordis itself is a way of hot loading and unloading plugins without restarting a running process."
The second thing the repo takes seriously is trajectory logging. From the README, as quoted by SwellJoe on HN: "Every run is traceable. Everything the model sees is recorded in an append-only session log: system prompts, reasoning, tool calls and results, subagent scheduling, and every context injection. In the Trajectory view, you can inspect these records by source. Resume, fork, search, and replay all" — the quote gets cut off, but the shape is clear. This is git-for-agent-runs, baked in at the runtime layer.
Most open-source agent frameworks today treat the tool loop as the hard part: how do you get a model to call a function without malforming JSON, how do you retry, how do you route to a subagent. DeepSeek is quietly making a different bet — that the tool loop is basically solved, and the actual pain is operational: swapping a tool implementation without killing a long-running session, inspecting exactly which context bytes flipped a decision, and running two candidate agent configurations against the same trajectory to see which one produces a better answer.
Framing agent runtimes as hot-swappable plugin buses is what production teams have already been building in-house — DeepSeek just published the reference implementation under MIT. If you've operated a serious agent in production for more than a quarter, you've hit the wall where restarting the process to try a new tool version is unacceptable — the model has state, the task is mid-flight, the user is watching a spinner. You either build the hot-reload machinery yourself or you accept the restart tax. Cordis-style plugin systems have been solving this for chatbot frameworks for years; it's overdue that agent harnesses caught up.
The skepticism in the HN thread is worth taking seriously though. From invaliduser: "«It uses an architecture where everything is a plugin» Ok, that's enough for me. I have developed over the year a plugin fatigue. Every product relying on 'community plugins' for their features implies it works fine the 6 first months, then it's a nightmare of incompatible, deprecated..." That's not a strawman — it's the honest failure mode of plugin-first architectures. Eclipse, Jenkins, WordPress, Sublime, VS Code, Backstage: every one of them started clean and ended up as a dependency graph nobody can reason about. The Cordis defenders point to Koishi's four-year track record as evidence the design holds up, but a chatbot framework's plugin surface is much narrower than an agent runtime's will be.
The other honest reaction, from lxdlam, who apparently read the underlying paper: "I have read the underlying paper, and found it may be useful, but not that useful." The specific novelty over Cordis v3 is applying the hot-swap contract to UI components and to the plugin system itself — which is genuinely useful if you want agent operators to reconfigure a live production agent from a dashboard, and merely academic if you don't. Whether that lands depends on whether anyone builds the dashboards.
If you're currently writing agent code against LangGraph, LlamaIndex agents, or a homegrown tool-calling loop, this doesn't obsolete your work. It's an early developer preview from a team that expects breaking changes. Don't port anything critical.
What is worth doing right now is stealing the two ideas that matter: append-only trajectory logging, and a plugin contract for tools that supports hot swap. You can retrofit both onto whatever runtime you're already running. The trajectory log is the higher-leverage one — most teams debug agent behavior by staring at cURL output and re-running with print statements. An append-only structured log of every turn, with fork and replay, is the difference between debugging agents like it's 2023 and debugging them like a distributed system.
For teams evaluating harnesses fresh: watch this repo for the next quarter but don't build on it yet. The author's own warning about compatibility breaks is not marketing modesty — MIT-licensed developer previews from AI labs move fast and leave scars. The signal to wait for is a stable plugin ABI and a real community catalog of third-party plugins that outlives the initial hype. That's the point at which the plugin-fatigue crowd gets vindicated or refuted.
The interesting thing about `deepseek-harness` isn't that DeepSeek shipped it — it's that a major model lab thought the harness layer was worth open-sourcing at all. Anthropic, OpenAI, and Google keep their agent runtimes proprietary; the open source stack has been leaning on LangChain-family tooling built by companies whose incentives are increasingly downstream of the frontier labs. A well-designed reference harness from a lab, with real production DNA behind its plugin core, changes the substrate everyone else builds on. Whether Cordis-on-agents ends up as the pattern or as an interesting dead end is a question the next six months will settle in public.
"Every run is traceableEverything the model sees is recorded in an append-only session log: system prompts, reasoning, tool calls and results, subagent scheduling, and every context injection. In the Trajectory view, you can inspect these records by source. Resume, fork, search, and replay all
I have read the underlying paper, and found it may be useful, but not that useful.For those who want to know what it achieves: it adds hot-reload and dynamic enable/dispose capabilities to a plugin system, like the one in Pi agents, though they push the boundaries further, to the UI components
What's buried under the lede: this harness is using Cordis v4 (the paper that dropped today). Cordis has already been used for four years in a different project called Koishi that uses v3. Cordis itself is a way of hot loading and unloading plugins without restarting a running process. The cool
«It uses an architecture where everything is a plugin» Ok, that's enough for me. I have developped over the year a plugin fatigue.Every product relying on "community plugins" for their features implies it works fine the 6 first months, then it's a nightmare of incompatible, depre
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Hi I'm one of the authors of DeepSeek Harness. It's just an early developer preview version we're presenting in MIT license currently. Expect lots of rough edges and compatibility-breaking changes. Any feedback and suggestions are more than welcome!