Discussion: install and run agents and services without rebuilding Mu

Why

Mu is a runtime for agents and services. Like an OS running apps, that creates an expectation that an operator can add something for Mu to run without forking or rebuilding the runtime. Micro is the first product on that runtime: a personal assistant. Future business deployments should use the same foundation with custom domains, organisation configuration, own keys/agents and external integrations.

This is a discussion proposal to revisit, not an implementation commitment.

What exists

• User-defined agents are configuration (name, instructions, scoped tools), executed by Mu without rebuilding.
• Built-in Go services are compiled into Mu's single binary.
• External programs can consume Mu's API/MCP without being hosted by Mu.
• Separately running go-micro services can be discovered with MU_REGISTRY=mdns. Mu calls them but does not install, start or supervise their processes. This mode also switches internal calls to HTTP and trusts the discovery network; it is not an authenticated extension boundary.
• Importing an external Go module into the binary still requires rebuilding.

Proposed operating model

An operator installs a versioned agent/service package. A small manifest describes its identity, executable or image, version, configuration, requested capabilities and exposed interfaces. Mu validates it, obtains explicit operator approval for privileges, and starts it under a defined execution boundary. It registers the resulting capabilities, reports health and manages stop/restart/update/remove. Installation must not grant unscoped access to account data or host credentials.

Keep existing services in-process with memory transport. External services may run as separate processes or containers on the same machine; remote services are connected endpoints with separately owned lifecycle. Separate process placement should not force every built-in call onto network transport.

An external agent may bring its own reasoning loop and model keys while accessing scoped Mu tools. A configured Mu agent remains the simpler default. Service capability discovery should supply tool schemas and permissions; a custom UI is a separate concern, not implied by RPC registration.

Questions to resolve

• Smallest first package format and execution backend: binary/process, container, or another sandbox? Who supplies and updates artifacts?
• Use existing systemd/container supervision or own the lifecycle directly? Keep the runnable core simple and self-hostable.
• Authentication, account identity propagation, capability grants, secrets and revocation across the external boundary.
• Namespacing and collision rules; an extension must not impersonate a built-in service.
• Discovery/schema contract: go-micro RPC, MCP, HTTP, or adapters? Support integrations without requiring every author to use Go.
• Health, logs, resource limits, restart policy, upgrades, rollback and uninstall/data retention.
• Separate local installation from connecting a remote endpoint in both API and UI.
• How extensions appear in the existing service catalogue and assistant tool access without cluttering Home or adding competing navigation.

Possible first slice

One operator-installed example service, no Mu rebuild, isolated credentials and an authenticated connection, visible in the catalogue and callable by an authorised agent. Demonstrate start, stop, restart and removal while built-in calls remain in memory. A marketplace, arbitrary autonomous installation and business UI are outside that first slice.

The goal is a useful extension contract, not a requirement that every service become an agent or that every workload become multi-agent.

No files, tests, or implementation entry points are named. Start by resolving the open questions around the package format, execution boundary, authentication, lifecycle, and discovery contract. Done would be a decided first-slice contract covering one operator-installed service without a Mu rebuild, isolated credentials, authenticated access, catalogue visibility, authorised calls, and start/stop/restart/removal.