Agent = Model + Harness
The formulation is not new, but DeepSeek Harness states it unusually cleanly: a raw model is not an agent. Everything that turns a model into something that can act reliably in a real environment — tools, skills, sessions, sandboxes, memory, the execution loop — is harness, and DeepSeek treats every one of those as a composable plugin rather than a fixed core.
It also explains something real about where the industry is heading: models are becoming more interchangeable, and the harness that wraps them is becoming the more durable layer.
The seam that matters: tools/pre-execute
DeepSeek Harness's tool execution pipeline documents a tools/pre-execute waterfall for extensible allow/deny/ask policy, followed by a monotonic tools.guard() whose denial cannot be overridden by a later listener in the chain, with tools/execute and tools/post-execute waterfalls handling dispatch, retries, and metrics afterward.
That is a legitimate, well-designed extension point — a place where a policy plugin can inspect a proposed tool call before it runs and stop it deterministically. It's also exactly the seam that matters for architectural governance: the moment before an action executes, not after.
What a policy seam does not give you
A pre-execute hook can only enforce what it is told to enforce. DeepSeek Harness's own plugin ecosystem shows this clearly — community plugins like dangerous-command guards and deny-by-default tool-name policies attach to tools/pre-execute to classify shell, SQL, and file-write calls against fixed rules. That is command-shape safety: useful, but generic. It has no way to know that a repository has an architectural decision forbidding Postgres in this service, or that a particular service boundary must not be crossed, or that a dependency was explicitly forbidden six months ago for reasons a new agent session has no memory of.
That gap is not a DeepSeek Harness shortcoming. It is the correct division of labor: a harness exposes the seam. It should not be in the business of knowing your architecture.
The corpus feeds the seam — the seam is the harness's, the decisions are not
What a decision corpus at that seam would actually look like
The abstract version of this argument is easy to nod along to and hard to act on, so it is worth being concrete about what a governance plugin on tools/pre-execute would do differently from the dangerous-command guards already in the ecosystem.
A command-shape guard receives a proposed tool call and pattern-matches its arguments: is this rm -rf, does this SQL contain a bare DROP, is this write targeting a protected path. It is a fixed ruleset, identical across every repository it is installed in, and that is precisely why it ships as a generic plugin.
An architectural guard receives the same tool call and asks a different question: given the decisions this repository has recorded, is this specific change allowed? That requires three things the harness does not have on hand:
- A corpus, not a config. The decisions live in a versioned artifact in the repository — the same one CI reads — rather than in the harness's plugin settings. The
mnemeCLI reads it via--memory, and every surface points at that one file. - Applicability, not just matching. A decision that forbids a dependency may be scoped with
include_pathsso it binds inservices/billing/**and stays silent elsewhere. The seam has to evaluate scope before it evaluates the rule, or every constraint becomes repository-wide and teams turn it off. - A verdict the loop can act on.
mneme checkreturns Unix exit codes —0pass,1warn,2fail. Pass maps naturally onto allow and fail onto deny; what a warn should do is adapter policy, not something the exit code decides — a team may route it to the harness’s ask path, or let it through with the finding recorded. A deny is wheretools.guard()would earn its monotonicity: once the architectural verdict is deny, a later listener in the waterfall should not be able to reverse it.
Read that way, DeepSeek Harness has not created a new problem for governance. It has published a well-specified socket — one shaped much like the seams Mneme already plugs into for Claude Code's PreToolUse hook and Kiro's write hook. No DeepSeek Harness adapter exists today, and the harness itself is still a developer preview, so this is an integration opportunity rather than a shipped path. What makes it worth naming is that the socket is open-source and vendor-neutral, so the same corpus could reach it without anyone negotiating a partnership.
Why the decisions need to be portable
DeepSeek Harness is one runtime among several an organization's agents will pass through — alongside Claude Code, Codex CLI, Kiro, and others, each with its own hook or middleware seam for the same class of pre-action check. If the architectural decisions live only inside one harness's plugin configuration, they don't survive a harness swap, a model swap, or a session reset. They have to be defined once, outside any single harness, and evaluated identically wherever an agent is about to act.
That is the argument this site has made about harness engineering and runtime harnesses more broadly: harnesses coordinate execution well, and that is a real, growing discipline. But coordinating execution reliably is not the same question as whether a given execution should have been allowed at all. DeepSeek Harness's own equation implies the next line rather than contradicting it:
Models change. Harnesses change. Your architecture shouldn’t — and it needs a layer of its own to survive both.
Conclusion
DeepSeek Harness is a credible, well-built addition to the harness layer, and its pre-execute/guard design is a genuinely good extension point for policy enforcement. The gap it leaves open isn't a flaw in the harness. It's the reminder that a harness was never supposed to own the organization's architectural decisions in the first place — something has to sit above it, portable across every harness an agent might run in.