DeepSeek Harness vs Pi Agent are they converging on the same philosophy?

[vishn9893]

I came across "DeepSeek Harness" very recently, whose core idea is literally “Everything is a Plugin.”

Coming from Pi agent and Looking at it alongside Pi, it feels like there’s a similar philosophy:

keep the core/harness small, and make capabilities composable at the session/plugin level.

Pi has extensions, skills, tools, prompts, etc., while DeepSeek Harness takes the plugin approach even further.

Is this essentially the same architectural direction?

And is “small core + everything else as a session/plugin” becoming the better design for coding-agent harnesses?

Curious what the Pi community thinks.

[weijiafu14]

They converge on the architectural principle while keeping different plugin ABIs.

Pi gives extensions a rich host surface around its agent loop: tools, commands, prompts, skills, lifecycle events, context transforms, model access, and session control. DeepSeek Harness decomposes runtime capabilities into Cordis services and providers.

pi2dsh connects those ecosystems as a general Host ABI. It does not rewrite each compatible package and does not require a conversion step:

dsh plugin --profile web add pi2dsh@0.11.0
dsh plugin --profile web add <compatible-Pi-package>

The engine discovers Pi packages in the DSH profile and mounts them through DSH-native surfaces. Where DSH already owns a capability, it stays the authority: model calls use the DSH llm directory, MCP uses the official DSH MCP client, credentials use DSH credentials, sessions use ctx.sessions, and Pi subagents become real DSH children through ctx.agents.

This has been exercised on real DSH loops, including tools, slash/prompt commands, skills, lifecycle hooks, context transforms, OAuth, cross-session memory, separately reviewed tool approvals, per-child model selection, and image-admission companion routes that let DeepSeek text routes work with Pi vision plugins.

So my current answer is: same small-core direction, different decomposition — and the boundary is concrete enough that compatible ecosystem capabilities can be reused instead of reimplemented.

[ciceroyang]

There is a real philosophical overlap — both move extensibility from "hooks at fixed points" to "the runtime itself is composed" — but the center of gravity differs:

• Pi (as I read it): the agent loop stays central; extensions plug into a rich surface around it. The loop is a product, extensions are a marketplace.
• Harness: there is no privileged loop. The session is an append-only event log, and tools/models/skills/compaction are interchangeable services mounted through capability seams (service definition / provider / consumer). What you cannot swap out is the log, not the loop.

A useful test: could an extension replace the compaction strategy, the persistence backend, or the shell implementation without touching any consumer? In Harness that is the design goal, and it is what makes "everything is a plugin" more than a slogan.

The honest caveat: both are young; philosophy converges fastest where the session model is explicit and durable. That is Harness strongest bet right now.

[SicutEst]

So that’s why DSH is named Harness instead of Agent, right? It offers an insight as you can pair any LLM with arbitrary harness components to build your own custom Agent, rather than subdividing capabilities on top of a pre‑built Agent. This feels like an enormous leap of faith in LLMs.

[ciceroyang]

Exactly — "Harness" is the most honest name in the field, and the naming carries the leap-of-faith answer too.

The leap is real, but note what the leap is ON. A pre-built Agent asks you to trust the loop; a Harness asks you to trust the log — and that is a much cheaper bet, because the log is checkable. Every model-visible byte is reconstructable (Harness invariant: model-visible means logged), so the wilder the agent behavior gets, the more the traceability safety net matters. The trajectory view, fork/resume/replay, and the ecosystem tools built on the event stream (session search, cross-session weekly reports, delivery receipts) are all the same bet being cashed out.

One more corollary of the naming: because it is a harness and not an agent, the ecosystem does not need permission from a product team to extend it — the community packages are first-class by design. pi2dsh bridging Pi packages in is a good proof of that openness from the other direction.