DeepSeek Harness Creator Mode: When the Agent Builds Its Own Plugins — and Why That Needs Guardrails

On 2 November 2026, DeepSeek's Harness team announced Creator Mode for DeepSeek Harness, its open-source AI agent app. The pitch is short: describe a tool in plain language, and the agent writes it as a plugin, installs it, and checks that it works.

What actually happened

DeepSeek Harness is built on what DeepSeek calls an "everything is a plugin" architecture, based on the Cordis modularity framework. Tools, model providers, skills, memory, and visual panels are plugins rather than fixed application code. Creator Mode is the chat-driven way to add to that set: the official product page puts it plainly — "Install plugins, or create them through chat in 'Creator mode', to extend tools, skills, and the interface."

The official documentation adds a detail that matters more than the demo: plugin configuration belongs to the current profile, affects its sessions, and survives process restarts. With hot module replacement enabled, a newly configured tool can appear in the same running session. In other words, this is not just generating a snippet. It is changing the agent's own runtime, persistently, from inside a conversation.

Reported demonstration examples include a design workspace, a sandbox game, a 3D visualizer for how a language model works, a video-editing workbench, a paper annotator, and a floating Pomodoro timer. Harness itself is in public preview worldwide and open source, and can be run as a desktop app or launched locally with npx @deepseek-ai/dsh web.

Sources: DeepSeek Harness product page and Configure persistent plugins from a prompt — and the repository is at https://github.com/deepseek-ai/deepseek-harness

Why this is worth paying attention to

Most agent customization today lives in prompts, config files, or extensions written by a human and installed deliberately. Creator Mode moves that boundary: the agent becomes the author of its own extensions. That is a genuinely different loop, because the thing being customized is no longer just the answer — it is the toolset the next answer will be produced with.

That shift cuts both ways, and it is the interesting part:

• Friction drops, but so does the review step. Installing a plugin used to be a deliberate act with a visible artifact to inspect. When installation happens inside a chat turn, the natural moment to pause and review can disappear unless the workflow preserves it. The docs do point to a Plugin Manager for disabling or removing bundles — that control deserves to be as prominent as the creation flow.
• Persistence changes the stakes. A one-off generated script is easy to throw away. A plugin bound to a profile, surviving restarts, quietly becomes part of every later session. That makes versioning, rollback, and "what changed in my agent, and when?" first-class questions, not afterthoughts.
• Sharing is the next hard problem. A plugin that works for one person is useful. A plugin that can be shared, audited, and trusted by a team is a platform. Nothing in the announcement so far answers how that trust layer works — signing, review, or provenance of generated bundles.

There are also two caveats worth stating plainly. First, coverage of the launch notes that some demonstration plugins were refined over multiple rounds of conversation, so a single prompt may not reproduce the demo result — treat the demos as a direction, not a benchmark. Second, Harness is an experimental developer preview: its safety notice, as reported, says the software has not had a security audit and can run model-generated code and commands. A tool that installs its own plugins should be treated accordingly — powerful in a sandbox, not something to point at production credentials on day one.

The open questions

1. What does a good review flow look like for an agent-authored plugin — a diff to read before install, a dry run, or both?
2. How should profile-scoped plugins be versioned and rolled back when one quietly breaks a workflow weeks later?
3. If plugins become shareable, who vouches for a generated bundle — the author, the model, or a reviewer?
4. Which capabilities should be off-limits for self-installed plugins by default: network access, file writes outside the workspace, credential-adjacent tools?

The most useful plugin to build first is probably a boring one: something small, observable, and easy to remove. The interesting question is not whether an agent can build its own tools — this announcement suggests it can — but whether the surrounding workflow makes that power easy to inspect, undo, and trust.

What would you build first — and what would you forbid it from touching?