Director vs Platform Admin

Director and the Platform Admin tools (host.control, mx-cli, hivecast) operate on the same Matrix Host but answer different questions. Confusing them leads to operators looking for start/stop buttons in Director that do not exist, or expecting hivecast to render an actor tree.

The boundary in one sentence

Director observes and converses. Platform Admin supervises and configures.

Boundary table

Concern	Director	Platform Admin
List runtimes	yes (read-only via system.runtimes runtimes.registered)	yes (hivecast runtimes, matrix runtimes)
Start a runtime	no	yes (hivecast up, matrix up, host.control runtimes.start)
Stop a runtime	no	yes (hivecast down, matrix down)
Install a Host	no	yes (hivecast install)
Inspect an actor's ops/state	yes (via $introspect)	partial (matrix invoke <mount> $introspect)
Prompt a promptable actor	yes (Chat tab → system.agents $prompt)	indirectly (via Chat or matrix invoke)
Read logs	partial (Ops Feed via system.observability.logging)	yes (per-runtime files under <host-home>/logs/runtimes/, journalctl -u matrix-host-edge)
Modify runtime config	no	yes (matrix init, host.control ops, manual edits to <host-home>/runtimes/*.json)
Pair to HiveCast	no	yes (hivecast login --device)
Browse actor tree visually	yes	no
Search ops/traces by mount/text	yes	no

Why Director does not start things

Director runs entirely in the browser. The runtime/process supervisor lives in @open-matrix/host-service and is reached via @open-matrix/host-control (which provides runtimes.start, runtimes.stop, runtimes.register, etc.). Director's DirectorRuntimeAdapter only invokes read ops on system.runtimes, system.registry, system.bindings, and system.catalog (verified by reading src/services/DirectorRuntimeAdapter.ts):

• system.runtimes runtimes.registered (read)
• system.registry registry.list (read)
• system.bindings bindings.children, bindings.roots, bindings.tree (read)
• system.catalog catalog.list (read)
• <actor> $introspect, $prompt, $sessionList, session_state.read, memory.search — application-level reads on selected actors.

The adapter does not call runtimes.start, runtimes.stop, runtimes.register, or host.control.*. That is intentional: lifecycle authority belongs on the supervisor side, with audit trails through the Host home and via journalctl/pm2/launchd for the wrapping service.

When you reach for which tool

• "I changed code and want to verify the new actor came up" → Platform Admin restarts the runtime; Director verifies it is registered and inspectable.
• "I want to know what system.config accepts" → Director (Interface tab on the actor).
• "Why is this Host using port 3100?" → Platform Admin (<host-home>/host.json, hivecast status).
• "What sent the last chat-status.set op?" → Director (Ops Feed, filter by op or by source mount).
• "I need to allow a new package to mount" → Platform Admin (matrix init + manifest + matrix up).

Target state

DESIGN.md §3.4 describes a future operator mutation surface inside Director (steering / persistent state / config / source code, with explicit permission boundaries). None of that ships today. Until those ops exist on the backend actors and Director's adapters call them, treat Director as observational. Mutations route through mx-cli, hivecast, and direct actor invokes.

See also

• Director vs Agent Platform
• Integration: system.runtimes
• Integration: system.registry
• Reference: actor ops consumed

Source: projects/matrix-3/packages/director/src/services/DirectorRuntimeAdapter.ts for the read-only adapter surface; projects/matrix-3/packages/host-control/src/ and projects/matrix-3/packages/host-service/src/ for the supervisor that Director does not call.