We replaced our custom Agent runtime with DeepSeek Harness — building MOVO as the enterprise layer

[juncheng-zheng]

We've been building MOVO, a self-hosted enterprise Agent platform.

Originally, we built most of the Agent runtime ourselves: planning, tool execution, Skills, sub-agents, session state, recovery, browser execution, sandbox integration, and so on.

After DeepSeek Harness was released, we made a fairly significant architecture decision:

we stopped building our own runtime and migrated MOVO to DSH.

The reason was not that our runtime could not continue evolving. The real question was whether this was the right layer for a small enterprise software team to keep investing in.

DSH's plugin-oriented architecture is very close to the direction we had already been moving toward. More importantly, if DSH develops a strong ecosystem around tools, Skills, sandboxes and runtime extensions, projects built on top of it can benefit from that ecosystem instead of rebuilding everything independently.

This migration also helped us clarify the boundary of MOVO:

DSH handles how an Agent runs.
MOVO focuses on how an Agent enters enterprise production.

Today, MOVO mainly focuses on the enterprise layer around DSH, including knowledge/RAG, identity and RBAC, governance, system integration, Agent management, private deployment and enterprise-facing workspace/admin capabilities.

The migration is now mostly complete, and we've open-sourced the MOVO Community Edition:

https://github.com/himovo/movo

We're still early, so we're especially interested in feedback from people building on DSH:

Does this separation between runtime and enterprise layer make sense?
Which enterprise capabilities do you think should remain outside DSH?
What are the hardest parts of integrating DSH into a multi-user enterprise platform?

Would love to hear how others are thinking about this boundary.

[argszero]

Congrats on shipping MOVO CE — and on making the "stop building the runtime" call. That boundary question is exactly what several of us have been circling in the discussions here (e.g. #5834 asks how to serve dsh as a multi-turn API to an enterprise backend — MOVO is now a working public answer to that thread), so a field report from a real migration is genuinely useful.

On whether the runtime/enterprise split makes sense: it matches the harness's own grain. dsh already treats most "enterprise-adjacent" concerns as pluggable layers rather than core: per-session agent composition is a preset layer, approval/interaction is a service with pluggable answerers, credentials are capability providers with env/.env/file backends, automation gets a dedicated stdio-only ACP server, and the webhook ingress is shipped as a reference custom-route adapter. What stays in core is the agent loop, session/durable-log invariants, and the tool/event surfaces. So "DSH runs the agent, MOVO runs the enterprise layer around it" is not a compromise — it's the architecture those seams were cut for.

Things I'd argue belong outside dsh (from the seams that exist today):

• Per-user identity/RBAC/authN. dsh has no per-user session ACL — the browser token is an anti-drive-by-device gate, not a human identity. Multi-user mapping must live in the gateway/MOVO layer (this is the dsh web: provide an opt-out for the mandatory browser token auth (reverse-proxy / trusted-LAN deployments) #5828/web settings: Host persistence is loopback-only — remote browsers get "settings are unavailable in this browser" #5829 discussion territory: trust fencing and where identity should be asserted).
• Org governance, quotas/billing, retention/compliance. These are org-policy layers; nothing in core models an "org".
• Agent fleet management (who may launch what preset on which session) — preset composition is per-session, not per-org.

Hardest parts integrating dsh into a multi-user enterprise platform (the ones that surprised us when mapping the surface):

1. Single-writer sessions. A dsh session has exactly one live agent; concurrent turns/steering from multiple users need a per-session serialization/queueing layer on your side (steer redirects at step boundaries, cancel(cause, keepInbox) aborts the active turn — there is no parallel-turn primitive).
2. Identity propagation through the RPC/WS dispatch. A known read-side gap: HTTP request context is dropped when RPC/WebSocket calls are dispatched to plugins, so a proxy-attested identity header can't reach plugin endpoints today (discussion A plugin serving an RPC endpoint cannot see the request that called it #5790/WebSocket-dispatched Remote invocations carry no request context #5791 — an ALS-style request-context fix is proposed but not landed). Enterprise integrations that need per-request identity at the plugin layer will hit this.
3. Approval/interaction routing. Approval is first-claimant-wins across answerers; if MOVO wants approvals surfaced in its UI/channels rather than the bundled browser UI, you're competing with the built-in answerer for the claim — worth designing the routing on your side deliberately.
4. Failure observability across the boundary. Sub-agent/session settlement notifications historically dropped failure causes at call sites (Subagent failure notices don't include the error reason — parent sees "Its closing message:" followed by nothing #4334 family); treat "did the turn actually complete and why" as something you must observe from events, not assume from the API response.

One integration shape worth considering: instead of the browser-facing server, mount a narrow custom gateway that reuses the session-controller RPC behind your own auth (the registerUpgrade/webhook-adapter pattern) — it sidesteps the browser token/cookie layer entirely and gives MOVO a clean service boundary. That's the shape #5834's thread converged toward too.

Happy to go deeper on any of these — the "what stays outside" list is the one I'd most like to see the ecosystem converge on, because plugin authors keep re-deriving it independently.

[juncheng-zheng]

Thanks for the detailed feedback. We went through your points against the current MOVO implementation, and a few of them map quite closely to things we’ve already had to deal with.

Session serialization

MOVO currently allows only one active turn per conversation.

We use an atomic DB claim, and concurrent requests get 409 session_already_running, so multiple writers can’t reach the same DSH session.

This works for our current tenant/user-scoped conversations, but it’s still fail-fast rather than a real queue.

If we move toward shared sessions later, we’ll need proper semantics around queued follow-ups, steering, cancellation, idempotency and ordering.

Identity propagation

For MOVO-managed enterprise tools, we don’t rely on request-local identity surviving the DSH boundary.

MOVO issues a short-lived signed Tool Gateway token containing tenant, user, runtime profile, allowed tools and scopes. The gateway validates those claims again before execution.

The open question is native DSH plugins that bypass the MOVO Tool Bridge.

Those plugins don’t automatically get the same trusted user context, so we probably need either a standard attested identity contract or a stricter enterprise plugin boundary.

Approval ownership

We also ran into the “multiple answerers” problem.

Right now, MOVO enterprise tools and native desktop tools have separate approval handlers, so they don’t race for the same request.

This works for tools we register ourselves, but third-party plugins make the boundary less clean.

I agree that an explicit approval-owner policy would be better than relying on naming conventions.

Failure observability

For top-level turns, we treat the DSH event stream as the source of truth and persist terminal events before releasing the active-turn lock.

The bigger gap for us is subagent failure causality.

We can tell that a parent turn failed, but we don’t yet persist a complete parent/child session graph with structured child failure causes.

We’re planning to add explicit parent_session_id / child_session_id relationships and structured child settlement events.

If DSH already has, or is planning, a canonical way to expose child-session settlement/failure events, we’d much rather align with that than invent a parallel mechanism.

So the two concrete things your reply made us prioritize are:

1. a real per-conversation command queue before shared multi-user sessions;
2. full parent/child correlation for subagent failures.

Really appreciate the references to the DSH internals.

If there are preferred extension points for identity propagation or child-session observability, we’d be very interested in following those.