When the Harness Is a Plugin Bag, You Still Need a Boss

DeepSeek Harness is a useful answer to one specific kind of lock-in. Its architecture makes the model adapter, tool registry, session log, sandbox, approval policy, and agent loop replaceable plugins. That turns several commitments normally fused inside a coding agent into configuration choices.

In the official architecture reference, the agent loop, sandbox, model adapter, and session log are all plugins with no privileged core. That lets an operator change pieces that integrated tools choose as a bundle. The runtime review covers the modes and session-log core; this piece asks what remains unsolved above them.

Unbundling the harness improves runtime portability and still leaves the operating layer above it open. You can swap loops without gaining a cross-provider session archive or a stall signal outside the harness. The two-layer picture is the useful one: pick any harness philosophy; the operator layer above it still needs an owner.

The heat is agent harness lock-in, not plugin love

Ignore star counts and focus on the design claim. Every serious harness on the landscape map commits you to some combination of loop, sandbox policy, tool wiring, session format, and model relationship. The bundle is convenient until one element must change independently.

A model gets repriced, a sandbox policy no longer fits, or a supplier agreement changes after an acquisition. In those cases, an MIT-licensed runtime whose pitch is “no privileged core” is not merely an architecture exercise; it reduces the number of changes bundled into a migration.

One current example went from hypothetical to dated in August: OpenAI said it intends to wind down Cursor model access after SpaceX acquired Anysphere and proposed a November 12 cutoff. A plugin architecture cannot change that contract, but it can keep the rest of the loop from being coupled to the affected adapter.

What the DeepSeek Harness plugins actually buy

Be precise about the win, because it is real. A plugin model adapter means a dead or repriced model lane is a config edit, not a migration. A plugin sandbox means the paranoid policy for client repos and the loose one for scratch projects are both first-class, not forks. A plugin loop means you can run a thin, readable loop under fat tooling, or someone else’s clever loop under yours. And a plugin session log means your transcripts are, at least in principle, a formal interface instead of an implementation detail.

The session log may be the most underrated item in the bag. Model swaps get attention; durable event semantics determine whether old work can be replayed.

DeepSeek’s current session subsystem is an append-only event log that can be replayed, and its backend is replaceable. For that abstraction to protect operators long-term, event compatibility and migration policy matter as much as the plugin seam. The repository also labels the whole project a developer preview and warns that major breaking changes should be expected. Treat today’s log shape as inspectable, not yet frozen.

The layer no plugin touches

Put six sessions across three harnesses on one machine and the questions change: which session is stalled? What did the overnight work consume? Where is the earlier transcript that solved the same migration, and which tool produced it?

No single harness answers those questions across unrelated tools without adapters. Fleet health is a cross-tool property. The archive is a cross-tool property: search that covers one tool’s history is a library with one shelf. Redaction must cover every deliberate export path where sensitive records may leave the local boundary. A stall flag inside one harness is a smoke detector in one room of a six-room house.

The meter makes the same point in currency. A fan-out can spend across vendors and plans, while each loop knows only its own provider view. A useful fleet ledger sits above the participating harnesses and labels unsupported lanes instead of pretending the total is complete.

This is the boss layer, and the crucial thing is that it is not a bigger plugin. It is a different layer with a different job description: not running agents — knowing about them. The loop’s job is to act. The boss’s job is to remember, meter, and notice. Bolting the second job onto any single harness just rebuilds the lock-in one floor up, in the tool you happened to bolt it to.

Prime Agent and Pi choose different composition boundaries

Prime Agent is an RLM-native coding and research harness built around a persistent IPython kernel, recursive subagents, durable sessions, and a multi-process local runtime. It began as a hard fork of Pi but now has its own CLI and product boundary. Pi is a broader agent toolkit with a unified LLM API, agent core, coding CLI, and extension system. It deliberately ships no built-in permission system or sandbox; users add an external containment boundary when they need one.

The trade remains real. A more integrated runtime has a larger upgrade surface. A composable toolkit moves more assembly and security responsibility to the operator. Neither choice automatically supplies cross-harness visibility; that concern sits above both.

The fork also explains why harness bake-offs answer a narrower question than fleet operations. An evaluation that runs model, loop, and sandbox as one bundle measures that bundle; change a plugin and the result must be revalidated. Measuring software that acts is its own discipline, and even done properly it answers “how good is this configuration on that task?” Fleet health asks whether the live sessions are progressing now. The lab and control room need different evidence.

The two-layer picture

Here is the whole deliverable, small enough to redraw on a whiteboard.

	Layer one: the harness	Layer two: the boss
Job	Run one agent well	Know about all of them
Philosophy	Fat, thin, or plugin bag — your call	Constant, whichever you pick below
When you swap tools	Changes completely	Does not move
Concerns	Loop, sandbox, model adapter, tool wiring	Sessions, stall flags, archive, vault, meter

Layer two, stated as requirements: supported sessions enumerable in one place, with unsupported lanes clearly identified. A transcript archive that outlives any single tool, with search and portable exports. Stall detection and carefully bounded keepalive for the loops the manager recognizes. Redaction for deliberate sharing, plus usage signals labeled by source and completeness. That set is an AI command center: the operating layer, not another harness with opinions.

Across its current Windows x86_64, Apple silicon macOS, and Linux x86_64 downloads, Automater Lite is one implementation of that layer: awareness of supported CLIs, stall indicators, and a local Library that normalizes supported transcript formats. It does not gain automatic compatibility merely because a new harness exposes a log plugin; each schema still needs an importer or a documented export path. The Desktop ADE beta adds Session Explorer for supported histories. Automater Lite is free on automater.ai; Pro is $29/year.

The honest limits are adapter boundaries and role boundaries. A listed download does not guarantee that every assistant on that platform exposes an importable transcript, activity signal, usage meter, or resume action. Lite also does not run the agents for you. Layer two knows; layer one does. Where an adapter is missing, keep the gap visible and use a documented export rather than claiming fleet coverage that the evidence cannot support.

The practical payoff shows up when a new runtime enters the fleet. If its durable log can be exported and normalized, a trial can join the same evidence system as established tools. If not, record that gap before the trial starts. A plugin seam is an opportunity for portability, not proof that portability already exists.

Test portability as a migration drill, not an architecture slogan. In a disposable repository, pin the current harness and plugin configuration, retain the original session record, and define the existing checks that the replacement must pass. Change one seam at a time. A model-adapter swap should leave the intended loop, sandbox, tools, and logging policy unchanged; a sandbox swap should not quietly widen tool permissions. Compare the resulting behavior and records with the pinned baseline, then restore the original configuration. The drill can establish that a particular replacement works for that task and version. It cannot establish that every plugin is interchangeable.

Run a separate check at the boss layer. Confirm whether the changed runtime still appears in inventory, whether activity and attention states remain meaningful, whether its durable record can be searched or exported, and whether usage evidence retains a named source. Mark missing adapter coverage as unsupported rather than treating a successful harness run as fleet integration. This separation matters because runtime portability and operational portability fail independently: the agent may complete work while disappearing from the archive, or remain visible while a replacement plugin changes the work’s behavior. A reversible harness needs both tests before an operator can call the migration reversible in practice.

Where the plugin bag actually saves you

Now cash in the dated example. OpenAI has proposed ending Cursor model access on November 12 after a change-of-control process between companies that are not the operator. Inside an integrated tool, the model roster is upstream policy. In a plugin-bag harness, an equivalent supplier loss can be maintenance: change the model adapter, rerun the eval set, and leave the rest of the runtime in place.

That is the strongest operator case for the architecture. But watch what survives in each scenario. The adapter seam can preserve the rest of the loop; it does not automatically preserve history, stall coverage, redaction, or usage records. Those capabilities either live above the harness or need their own compatible plugins and migration paths.

There is a quieter benefit: a tested adapter swap reduces technical switching cost. It does not guarantee a quick migration, better vendor terms, or compatibility with the replacement model. The boss layer supplies the records needed to measure the move instead of guessing.

Pick a bag, keep the boss

Fat harness, thin loop, or plugin bag is an engineering choice that can vary by machine and workload. The operating requirements change less often: session records, archive, health signals, redaction, and usage evidence. Keep those on the operator’s side of each vendor boundary while the runtime underneath evolves.

FAQ: plugin harnesses and the boss layer

What does “everything is a plugin” mean in DeepSeek Harness?

The agent loop, sandbox, model adapter, tool registry, and session log are replaceable plugins with no privileged core. That lowers coupling inside the runtime. DeepSeek Harness is still a developer preview, so compatibility and security must be rechecked as the architecture changes.

How do I avoid agent harness lock-in?

Keep the portable things portable: config and rules in repos, transcripts archived outside any tool, secrets in one vault, spend metered where you can see it. Then harness choice becomes reversible. Plugin runtimes help at the loop level; the archive and the fleet view have to live above every harness.

What is an AI command center?

An AI command center is the operating layer above agents: one place for supported session records, stall signals, cross-tool transcript search, redaction before sharing, and provider usage evidence, with unsupported lanes stated explicitly. It stays comparatively stable while harnesses and models change underneath — the boss layer, not another harness.

Sources

• DeepSeek Harness repository — license, preview status, and project entry point
• DeepSeek Harness architecture — plugin model and service seams
• DeepSeek Harness session subsystem — append-only event log and replay model
• DeepSeek Harness sandbox subsystem — sandbox provider and policy separation
• Prime Agent — current runtime scope and lineage
• Pi — toolkit scope and explicit permission/sandbox boundary