From Agent Harness to Team Harness

When an Agent can modify its tools, interface, and even the loop that controls its behavior, the interesting question is no longer how much code it can write.

The question is whether that growing capability can become something an entire team owns.

Most coding Agents still live inside one person’s terminal or chat window. They may understand a repository, run tests, and modify files, but their tools, memory, and working methods usually belong to one session and one user.

DeepSeek Harness changes that.

An Agent can finally modify itself

DeepSeek Harness describes its architecture with a simple line: “Everything is a Plugin.”

This goes much further than a conventional extension system. Model adapters are Plugins. Tools, session persistence, terminals, LSP, memory, and UI are Plugins. Even the Agent loop that decides what happens next is a Plugin.

Outside the underlying Cordis runtime, there is very little privileged core. The official architecture shows how a Plugin can intercept a model request, rewrite its input, alter tool execution, or stop a turn entirely.

An Agent no longer has to accept the environment its developer originally gave it. It can discover that it lacks a capability, write a Plugin, load it, and continue working.

Early users have already created real-time cost dashboards, Git status panels, worktree managers, planning interfaces, VS Code-style diff review, Kanban boards, Telegram notifications, and entirely new chat experiences. Some have simply asked the Agent to modify the Harness UI for them. These experiments are already happening.

The Harness is becoming less like a fixed application and more like a computer the Agent can reconfigure.

A personal computer is not yet a team capability

Suppose an Agent creates a useful Plugin on one engineer’s laptop.

Can another teammate use it? Who checks what files it can read? Which version is the team running? How does everyone learn that the Agent’s behavior has changed? Does the capability survive when the original session disappears?

A personal Harness can become increasingly powerful without becoming organizational capability.

That is where a shared workspace matters.

Inside Offloop, a team should not share one mutable DSH process. It should share a versioned Agent definition:

Workspace Agent
  = DeepSeek Harness
  + versioned Plugin Profile
  + model policy
  + connector permissions
  + team instructions

Each Run still receives an isolated session, workspace, and execution boundary. The team shares the Agent’s capabilities without allowing unrelated tasks to contaminate one another.

What changes when Harness enters a shared workspace

Imagine a product team with three Agents:

• @frontend-agent has React, LSP, browser, and UI review Plugins.
• @research-agent can work across the web, Drive, and Notion.
• @release-agent has Git, worktree, CI, and deployment capabilities.

These Agents do not live in one developer’s terminal. They appear in team Channels, accept assignments, publish plans, expose tool activity, submit diffs, and wait for a person when judgment or authorization is required.

When one person signs off, another can continue from the same task state. The Agent uses connectors authorized by the Workspace instead of asking every teammate to configure GitHub, Drive, and Slack again. Improvements to the Agent can belong to the Workspace rather than the session that created them.

DeepSeek Harness owns how the Agent reasons and uses its internal tools. Offloop owns who the Agent belongs to, what it may access, what it is currently doing, and when a person must decide.

We have built an independent dsh-acp adapter for this boundary. It translates DSH sessions, streaming output, permissions, steering, and cancellation into standard ACP events, allowing Offloop to operate DSH alongside other Agent runtimes.

Protected execution has been validated on macOS. Equivalent Linux and Windows confinement remains an explicit engineering gate. DeepSeek Harness is also still a Developer Preview, so compatibility changes should be expected.

From self-modification to team evolution

A shared workspace makes the most ambitious part of DSH much more useful.

While working, an Agent may discover a missing capability and generate a Plugin candidate. It can load that Plugin temporarily inside an isolated Run and test whether the change improves the result. If it works, the Agent can submit the Plugin to the Workspace.

The team can inspect what changed, what the Plugin may access, and what evidence supports it. The new capability can run on a small set of tasks before becoming part of the default Agent profile.

Discover a capability gap
→ Generate a Plugin
→ Run it in isolation
→ Test the result
→ Submit it for review
→ Canary it on selected work
→ Promote it to a shared capability

The Agent can improve itself without silently deciding how the entire team will work.

The organization gains the speed of self-modification while preserving versions, permissions, evidence, and responsibility.

Agents are becoming organizational assets

DeepSeek Harness makes the Agent programmable. It demonstrates that models, tools, memory, UI, and the Agent loop can all become replaceable runtime components.

A shared workspace supplies the other half: identity, collaboration, authorization, durable state, and collective ownership.

We do not think the future of team AI is everyone talking to the same assistant in the same chat window. Teams will own Agents adapted to their operating methods. Those Agents will gain new tools and behaviors over time while preserving clear history and boundaries.

DeepSeek Harness gave the Agent its own computer.

With Offloop, that computer can become something the whole team owns.