AgentCore Managed Hosting for DeepSeek Harness: From Solo Tool to Enterprise Infrastructure

Introduction

DeepSeek Harness (DSH) is an open-source Agent Harness released under MIT in August 2026. It decomposes model adapters, tools, sessions, sandboxes, UI, and the agent loop into plugins registered on the Cordis microkernel. Sessions are the authoritative event source, supporting replay and forking. Teams are bounded by a root session, with child agents communicating via a shared task board. Child agents can run in-process, via ACP in separate processes, or through Claude Code and Codex backends. While a single user can quickly get results, scaling to a department creates isolated session logs, plugins, and credentials with no unified identity, network, data, or operations support. AgentCore, Alibaba Cloud's agent building and governance platform, provides managed hosting for DSH alongside Qoder, Codex, Pi, and QwenPaw to fill this gap.

Why Hosting Is Needed

DSH's Team concept solves a single operator managing multiple child agents, not multiple people sharing one environment. The article presents a comparison table highlighting the gaps:

Who uses it: Only personal DeepSeek accounts; no organization, role, or department structure.

Where it runs: Official docs state unaudited, recommended for ephemeral environments; plugin checksums are not a code sandbox.

Data destination: Session logs upload with API requests by default, including prompt snapshots and tool parameters; configurable to disable.

Memory maintenance: DSH lacks long-term memory; relies on third-party MCP plugins, disabled by default in examples.

Experience retention: Sessions, plugins, and Skills live in ~/.dsh personal profile; lost when the person leaves.

Hosting connects DSH into existing enterprise identity, network, data, and operations systems, turning a personal tool into dependable department infrastructure.

Four Deployment Scenarios

Scenario 1: Refactoring a Legacy Service

An engineer tasks an agent to add idempotency to a 2019 order service: read repo, locate entry points, modify three call sites, add tests. Standalone: engineer pulls repo locally, pastes team conventions into prompts, handles local dependencies for tests. Hosted: agent accesses code and artifact repos inside VPC; MCP connects internal code search and build platform; Skills encode branch, commit, and review conventions; artifact credentials are vault-signed. Tasks run overnight unaffected by laptop sleep; failed sessions persist for replay after config fixes. Metrics: first-pass test rate, average task rounds, regression suite pass rate.

Scenario 2: Monthly Analysis Initiated from Chat

A manager requests channel cost breakdown by region vs budget, with a 20-minute slide deck. Traditionally done manually by analysts. Hosted: agent pulls data via MCP from data warehouse, renders using templates mounted from OSS, encodes definitions in Skills, retains key conclusions in memory. Finance adds data in chat; agent updates the same task. Next day, definitions and prior conclusions retrieved from memory; prior queries and edits traceable in session and Trace; session TTL handles cleanup, cross-day work continues via Team Task. Metrics: time from request to first draft, rework count, rework due to definition drift.

Scenario 3: On-Call Debugging

Alert arrives; on-call asks agent to investigate. Agent checks service topology, related resources, logs, recent changes; proposes three root-cause hypotheses with verification steps. For risky actions (restart, scale), agent only advises; on-call confirms execution. Hosted: debugging trace persists — services queried, log segments viewed, hypothesis elimination rationale. Next-day postmortem uses same trace; common debugging patterns codified as Skills for reuse. Metrics: MTTR, human-escalation rate, diagnosis-confirmation consistency.

Scenario 4: One Agent Serving Multiple Customers

Delivery team builds similar assistants (policy Q&A, ticket routing, report interpretation) for different clients. Standalone: copy config per client; credentials scattered on individual machines. Hosted: each client gets a Workspace with isolated credentials and OSS directories; FAQs and delivery docs exposed as MCP; only Endpoint and API Key exposed externally. Differences handled via config and assets, not code duplication; data boundaries auditable per Workspace. Metrics: new client onboarding time, config items changed per client, audit readiness rate.

Common thread: not making the agent smarter, but making inputs reachable, outputs auditable, processes reusable.

What Enterprises Gain: Compute, People, Risk, Assets

Compute: Standalone — one machine per person, peak via adding machines. Hosted — one instance hosts multiple sessions; session TTL reclaims idle sessions; auto-scaling adjusts to load. Metrics: peak concurrent sessions, per-session CPU/memory, scale-out triggers.

People: Standalone — each person installs environment, debugs, records config. Hosted — versioned Agent templates, Skills, MCPs; platform observability. Metrics: new-hire time to first successful task, duplicate config count.

Risk: Standalone — logs upload with requests, no unified audit trail. Hosted — platform mediates model connections and gateway egress; three-layer identity; session and Trace retention. Metric: can you answer who asked the agent to do what and when.

Assets: Standalone — sessions, plugins, Skills in personal profile. Hosted — versioned Skills and MCPs, managed knowledge bases and memory, shared within Workspace, evaluation sets. Metric: after a colleague leaves or rotates, can the same task continue.

Compute and people benefits appear in month one. Risk and asset benefits surface later: when a user leaves, audit arrives, or model/Harness version changes. Pilots must cover these three events, not just machine count and onboarding time.

Stakeholder Acceptance Criteria

Engineering: Wants low config, flexibility, speed. Hosted provides config-driven managed hosting, custom images for modifications, MCP/Skill integration with internal systems. Pilot success: create agent and complete a real task same day.

Platform/Ops: Wants control, visibility, traceability. Hosted provides specs/quotas, VPC, identity, observability, session retention. Pilot success: a failed request traceable to a specific Step.

Business/Finance: Wants cost attribution and value. Hosted provides usage attributed by agent and department, token quotas. Pilot success: monthly usage matches completed task volume.

Pilot fails if only engineering is happy; platform lacks data, management lacks accounts, next budget stalls. A pilot delivering same-day usability, auditability, and cost attribution reduces rollout friction.

Three Integration Modes for DSH on AgentCore

Config-Managed Hosting: Console configuration; platform handles runtime, scaling, observability, quotas. Suits most teams starting out.

Custom Image or Code Package: Package DSH runtime with custom profile, plugins, modifications; platform injects model connections, MCPs, Skills, credentials. Suits teams with existing DSH customizations.

Local/Remote Managed: DSH keeps running on employee machines or customer environments; LoongSuite Pilot collects telemetry into platform. Suits teams not ready to migrate runtime but need observability and cost tracking.

All three can coexist. Start with one, expand to others.

Config-Managed Hosting Details

Console creation organizes config into four blocks: Model & Prompt (bind platform-compatible model connection, select model, set system prompt or reuse role template); Assets (add Skills, Subagents, MCPs, knowledge bases, credentials, enable memory plugins); Session Management (choose instance spec, max sessions per instance, session TTL, auto-scaling); Network & Storage (optional public net, VPC, OSS mount points). Built-in Shell and file tools require no addition.

Instance, Session, Context relationship: Instance = compute environment; Session = continuous interaction set; Context = prior dialogue + tool results. One agent → multiple instances; one instance → multiple sessions. Sessions originate from Endpoint calls, IM channels, collaboration instance chats and Tasks. Collaboration instance = agent joined Team as Leader/Worker; each human-agent round counts as a session. Existing sessions stay on original instance; new sessions prefer ready instances under limit, then those with more existing sessions. Session TTL drives idle reclamation and scale-in rhythm.

Config changes: model, prompt, Skill, Subagent, MCP, credentials support hot update; instance spec, image, mount points require restart (do after tasks). Prerequisite: all three paths share platform model connections; DSH context caching optimization relies on DeepSeek official API contract — switching providers breaks caching. Session log upload must be explicitly disabled or fields stripped; not defaulted off.

Entry Points: Endpoint, IM, Team

Not just web. Hosted Harness supports direct Endpoint access, DingTalk, Feishu, WeCom, and Team chat/Task. Employees ask in their usual apps; agent runs on platform; identity, permissions, audit stay platform-side. External apps integrate via AG-UI protocol; responses stream as events; continuation uses same threadId. Integration needs only Endpoint and API Key; no per-agent app changes.

Cross-session, multi-day work uses TeamHarness: agent joins Team as Leader/Worker; Leader creates task, dispatches sub-tasks to Workers; execution moves to task room. User need not stay connected; state changes notified via platform Bot. Start timeout, run timeout, session loss, terminal archival handled by platform. Advice: run a real task end-to-end before configuring.

Governance: Identity, Credentials, Network, Audit

Resources isolated by Workspace. Three identity layers: Business identity (who: uid, tenant, cloud account); Execution identity (which session/run); Resource identity (which tools, Skills, sandboxes, child agents). Inbound via IAM/OAuth; outbound credentials vault-signed; apps hold no long-lived keys. The four scenarios map to three permission types: query (data fetch, log read), modify (code change), external access (delivery) — all grounded in the three identity layers.

Network default deny: public access explicit opt-in; VPC access requires both platform and target service allow; OSS data via mount points. Usage and rate-limiting platform-side: token quotas and agent-level concurrency limits set and enforced on platform, not app.

Session logs and config changes retained platform-side; audit pulls by agent and session. Custom images versioned; cross-version rollback and plugin-granular versioning still in progress.

Observability to Evaluation to Tuning

DSH session logs naturally suit observability: system prompt, tool schemas, model requests, streaming output, tool results, permission changes, cancellation reasons appended to single log; trace split into Turn, Step, tool call layers. Gap: native OTLP Logs plugin disabled by default; standalone requires manual injection via $DSH_HOME/cordis.patch.yml.

Onboarding automates this: Pilot injects collector plugin without modifying DSH source. Verify with loongsuite-pilot status and info. Data organized in three layers:

Session: A multi-turn conversation. Answers: which task, who initiated.

Trace: One request round. Answers: where latency/errors occurred.

Span: Model call, tool call, etc. Answers: params, return, latency, retries.

Trace usability validated by three checks: complete steps (model + every tool call have spans with readable I/O); correct nesting (child agents/async tasks retain parent span); correct baggage propagation (business fields propagate and attach to correct spans). Existing OTel Context-based tracing systems need separate context keys to avoid mis-parenting child agent spans.

Evaluation not just model scoring. Platform supports Code, LLM, and Agent-as-a-Judge evaluators. AgentCore team's open evaluation practice uses terminal-bench 2.1's 10 tasks plus three orthogonal deterministic evaluators: task completion, red-line rule judgment, execution reliability — all rule-based scripts, no LLM scoring variance. This measures Harness+model combo; swapping Harness allows same-criteria comparison.

The metrics from four scenarios are computable because every step has a landing point: failed sessions → Trace → Step → regression set → re-run after config/model change. Observability, evaluation, tuning chain linked by this pipeline. Missing any link leaves only impressions.

Reproducible Rollout Sequence

Choose Mode: Start with config-managed to validate; decide later on custom image. Done when console creates DSH agent and completes a real task.

Connect Model: Bind platform-compatible model connection; define usage/quota scope. Done when requests exit via platform gateway, usage attributable by agent/department.

Map Accounts: Map employees, agents, service accounts to enterprise identities. Done when every action answers who and which session.

Install Tools: Publish internal APIs as MCPs; version Skills; enable platform-managed knowledge bases and memory. Done when session tool list matches asset versions; knowledge base and memory return latest content.

Add Entry Points: Integrate DingTalk/Feishu/WeCom or AG-UI as needed; configure Team+Task for multi-day delivery. Done when users start from their usual apps; status notifications reach humans.

Enable Observability: Turn on reporting; run evaluations on platform. Done when failed sessions traceable to Step and added to regression set.

Establish Baseline: Fix a set of real tasks, model, config. Done when version/model changes have comparable scores.

Timeline: Week 1 — one scenario end-to-end; Weeks 2-4 — tools, accounts, entry points; Week 5 — lock task set, record first baseline. First three steps determine if it runs; last four determine if it's manageable and swappable. Common bottlenecks at steps 4 and 6: tool assets lack versioning; observability installed but nobody reviews scores.

Boundaries to Know

Hosting solves runtime and governance, not DSH maturity. All DSH tags are alpha/rc; official recommends ephemeral environments. Hosting provides session-level isolation and platform retention, but does not guarantee every version is production-mainline ready.

Knowledge base, memory, TeamHarness, observability/evaluation integrations roll out per Harness capability matrix; console configurability is source of truth. Evaluation and regression capabilities already available; platform-pushed Harness versions release in phased canary batches.

If single-user, chasing DSH caching for lowest unit cost, no compliance/collaboration needs — standalone with one-click script remains cheaper. Hosting value appears with multi-user, concurrent tasks, audit requirements.

Simple test for hosting worth: can a new person take over the same task, continuing the prior person's session, tools, permissions, and evaluation baseline? If yes, the Harness has truly entered the organization.