Begin by deploying Managed Agents independently and checking its health endpoint or console before touching a DSH profile. Decide where its database, artifacts, credentials, and sandbox execute. The upstream README distinguishes a default local sandbox that runs commands as the operating-system user from Docker or Kubernetes providers intended for stronger isolation; that decision belongs to the operator, not to this catalog entry.
Managed Agents
Managed Agents connects DeepSeek Harness Web to a self-hosted runtime through a local stdio MCP bridge for durable agent sessions, artifacts, and cancellation.
Review snapshot
- Manifest
- Passed
- Install
- Not tested
- Runtime
- Not tested
Static compatibility snapshot dated 2026-08-14; install and runtime remain independent checks.
Install / upstream documentation
Use the pinned upstream documentation
No version-pinned install command is recorded for this listing. Use the pinned README as the source of truth; AgentPlugin.net does not invent missing steps, Profiles, or recovery instructions.
The pinned README documents `dsh plugin --profile web add managed-agents`, but it does not pin a package version or commit in that command. This directory therefore links the fixed README instead of presenting the mutable command as a reproducible installation instruction.
Source: Pinned upstream integration READMEPlugin brief
What Managed Agents adds to DeepSeek Harness
Managed Agents is a DeepSeek Harness plugin bundle for a different shape of work than a one-off chat: it lets a DSH Web session delegate to a separately running, self-hosted agent runtime. The bridge exposes a small MCP surface for listing agents, creating sessions, running a streamed turn, reading artifacts, and stopping a session. It is useful when the durable runtime, its history, and its execution environment need to remain under an operator-controlled deployment rather than inside the browser profile.
The pinned package calls itself a local-first runtime with managed-agent-style APIs, sandboxed sessions, memory, tools, audit, replay, and a console. The DSH integration does not magically provide those services. It starts a stdio MCP child that reaches the URL supplied in MANAGED_AGENTS_URL, so the runtime must be deployed and healthy first. DSH is the caller in this arrangement; Managed Agents owns its agent records, session data, artifacts, and sandbox policy.
This listing records version 0.2.0 at a fixed source commit. The upstream README reports a successful composition and MCP handshake with one cited DeepSeek Harness commit, which is meaningful integration evidence but not a general compatibility promise. AgentPlugin.net has not installed the package, launched the child process, or exercised the remote tools. Treat the manifest and upstream verification as review material, then test in an isolated profile that resembles your real deployment.
The practical value is controlled delegation: a DSH user can hand long-running or stateful work to the runtime without pretending that the bridge itself is a sandbox. The practical constraint is equally important: a runtime that can create sessions, return artifacts, and execute tools can carry significant authority. The bridge reads credentials from the child environment and does not return them as tools, but the effective access remains whatever the configured API key and runtime permit.
Evaluation workflow
Evaluate Managed Agents with clear boundaries
Create a disposable DSH Web profile and configure only the required MANAGED_AGENTS_URL. If the runtime authenticates requests, set MANAGED_AGENTS_API_KEY in the child environment rather than embedding it in source, a prompt, or a shared profile export. Confirm network reachability first, because a failed URL or rejected key is a deployment issue rather than proof that the bundle layer is broken.
Use the fixed README as the authoritative installation reference because its published command is not version-pinned. After installation, inspect DSH startup logs for the mcp-sandbase-harness entry and for the expected mcp__sandbase__ tool namespace. Start with list operations or a harmless test agent before creating a session that can access project files, external services, or a production model credential.
Review artifacts and terminal-event metadata as data from the managed runtime, not as a substitute for audit. When a session needs to be cancelled, use the documented stop capability and verify the outcome in the runtime console. Remove the bundle from the profile and stop the DSH process before changing layers; keep any runtime secrets, session data, and workspace files outside public issue reports.
Verification ledger
Evidence, not installation claims
Manifest
PassedPinned package.json declares managed-agents 0.2.0 and dsh.bundle.patch -> ./examples/deepseek-harness/cordis.yml.
Checked Aug 14, 2026
Install
Not testedAgentPlugin.net has not installed the mutable upstream command into a clean DSH Web profile.
Runtime
Not testedUpstream reports a handshake at the cited DSH commit; AgentPlugin.net has not repeated that runtime test.
| Layer | Result | What was checked |
|---|---|---|
| Manifest | Passed | Pinned package.json declares managed-agents 0.2.0 and dsh.bundle.patch -> ./examples/deepseek-harness/cordis.yml.[Aug 14, 2026] |
| Install | Not tested | AgentPlugin.net has not installed the mutable upstream command into a clean DSH Web profile. |
| Runtime | Not tested | Upstream reports a handshake at the cited DSH commit; AgentPlugin.net has not repeated that runtime test. |
Source or manifest review can be recorded while Install and Runtime remain not-tested. Treat these as separate verification layers.
Execution surface
Prepare, build, and code-execution review
prepare
not recorded
No review record is available for this execution surface. Inspect the upstream repository before running it.
build
not recorded
No review record is available for this execution surface. Inspect the upstream repository before running it.
code execution
review recorded
Managed sessions can use a sandbox and tools; the upstream README says the default local sandbox runs commands as the OS user.
lifecycle script
notice recorded
The package declares build, test, and deployment scripts. Review source-build and deployment paths before executing them.
network
review recorded
The stdio MCP child connects to MANAGED_AGENTS_URL and its authority is controlled by the configured API key.
configuration
review recorded
Session artifacts, runtime data, URLs, and API keys need deployment-specific handling. Do not expose them in profile exports or public issues.
Declared scope
Capabilities and prerequisites
Capabilities
- Create, run, inspect, and stop managed-agent sessions through MCP tools.
- List agents and retrieve session artifacts from the configured runtime.
- Use a stdio child bridge whose URL and optional API key come from its environment.
- Keep the runtime deployment and its sandbox boundary outside the DSH Web profile.
Prerequisites
- Node.js 22 or newer, as declared by the package.
- A running managed-agents 0.2.0 runtime and a reachable MANAGED_AGENTS_URL.
- DeepSeek Harness with @deepseek-ai/dsh-mcp-client and stdio MCP support.
- Review the runtime authentication and sandbox choices before exposing a workspace.
Frequently asked questions
Managed Agents FAQ
What does Managed Agents add to DeepSeek Harness?
It adds an MCP bridge from DSH Web to a running Managed Agents runtime. The documented tools list agents, create and run sessions, fetch session information and artifacts, and stop work.
Is Managed Agents itself a DeepSeek Harness sandbox?
No. The bundle is an integration layer. The runtime selects and operates its own sandbox; the upstream README warns that its default local sandbox runs commands as the OS user.
Why is there no copyable installation command here?
Upstream documents a DSH command, but without a version or commit pin. This page deliberately links the pinned README rather than turning a mutable command into a reproducible-install claim.
What compatibility evidence exists?
The pinned README reports clean Cordis composition, stdio-child launch, and an MCP handshake on 2026-08-14 against the named DSH commit. AgentPlugin.net has not independently repeated it.
Where does the API key go?
The upstream integration reads MANAGED_AGENTS_API_KEY from the MCP child-process environment when runtime authentication is enabled. Do not paste that credential into prompts or commit it.
What should I troubleshoot first?
For startup failures, confirm the package or source build and that managed-agents-mcp is on PATH. For fetch failures, check the runtime URL; for 401 or 403, check the runtime-accepted API key.