Mu is an open runtime for personal assistants. It brings together agents, connected services, accounts, permissions and persistent history. You can run it yourself or use a hosted instance, then access it through a web, mobile, desktop or command-line client.
The purpose is to provide a deliberate way to use connected services without an advertising-driven or engagement-driven experience. You choose the agents and connections, and use them to get something done: read your mail, find information, organise your day or carry out a task.
A personal assistant needs more than a conversation with a model. It needs access to useful capabilities, a record of what has happened, and a way to continue work when you close the app. It also needs boundaries around which accounts, data and tools it can access. Mu puts those responsibilities in a runtime that can be used through different interfaces.
What runs in Mu
There are three names worth distinguishing. Go Micro is the underlying Go framework. Mu is the running system built on it. Micro is the general-purpose assistant within that system. Other agents can have their own instructions and permitted tools.
Services provide capabilities such as mail, calendar, contacts, information, media and storage. Agents use those capabilities to fulfil requests. Accounts, permissions and persistent history connect the work to the person asking for it.
For example, a request about your day may need calendar information and relevant messages. The agent uses its permitted tools to retrieve that information and produce an answer. The runtime handles account access and retains the conversation. The client displays the result.
Mu packages these pieces together as one Go binary. Self-hosting gives you control of that runtime and its configuration. External model providers and connected services still receive the data needed for the operations you enable; running Mu yourself does not automatically make those operations local.
An assistant protocol
As Mu has grown beyond its original web interface, we have needed a consistent way for clients to interact with it.
The Android app, web client, desktop apps and standalone CLI should be able to use the same agents and history on a chosen server. Each should not need to reproduce the runtime’s execution logic, store model-provider credentials or invent its own approach to recovering a request.
That is the role of MUCP, the Micro Communication Protocol. Mu is the runtime implementation; MUCP describes the contract through which clients use it.
The client handles input and presentation. The runtime owns execution, identity, permissions, provider credentials, billing and history.
The broader web console remains useful for overview, administration and direct access to services. It is not currently a standalone MUCP client, and existing integrations such as email and XMPP retain their own interfaces.
What the protocol covers
MUCP provides operations for discovering agents, accessing personal conversations, reading Home and Inbox views, discovering services, and submitting and retrieving work.
The implemented binding uses readable JSON over HTTPS. Headers identify the service and operation, and the body carries the request. Protobuf schemas define shared message types, but a client can use JSON directly without generated code or a protobuf library. It does not need Go Micro’s internal infrastructure.
Personal requests can be submitted as durable operations. The runtime returns an operation identifier that the client can use to retrieve the outcome. If a phone loses connectivity after submitting a request, the client can recover the result instead of assuming nothing happened and submitting the same work again.
The contract also describes authentication, access modes, errors and structured results. Those details determine whether independently written clients behave consistently, especially when something fails.
Direct service access through MUCP is being added incrementally. Existing services also have their own interfaces and agent tools; defining a service schema does not by itself make its operations available through the protocol.
Keeping the protocol open
The implementation and the protocol have separate licensing boundaries.
Mu’s runtime and our client implementations are AGPLv3. The MUCP specification, protocol contracts and generated types are Apache-2.0 licensed. Independently written clients and runtimes can reuse those contracts, including in proprietary products.
Connecting to Mu does not itself require a commercial licence. Commercial use of the implementation is also permitted under the AGPL’s terms. Alternative commercial terms for covered implementations are available separately, with enquiries through Micro on GitHub Sponsors.
The aim is for people to be able to run Mu, adapt it, or build a different client or runtime around the shared contract.
Why a protocol
MCP provides a shared way for AI applications to reach tools and context. gRPC provides typed remote procedure calls, widely used between services. HTTP and SMTP underpin the web and email. Each established a useful contract for a particular layer of communication.
Personal assistants need a contract at their own layer. A client needs to discover which assistants are available, open a conversation, submit work, check its outcome and recover after a disconnect. Identity, permissions, conversation ownership and the lifetime of a request need agreed meanings across implementations.
Those interactions can travel over HTTP, as MUCP does today. The missing piece is the shared assistant-level behaviour above that transport. Exposing an assistant as a tool or giving every application its own endpoints does not, by itself, establish that common contract.
MUCP is an attempt to define it for assistants and services. The specification should be sufficient for someone to write a client or server without reading Mu’s implementation. That means documenting the messages and their meaning, discovery, authentication requirements, errors, versioning and what happens when a request fails partway through.
The useful model is an Internet protocol specification: precise requirements, explicit extension rules, and examples and interoperability tests that independent implementations can use. Publishing an RFC-style document would not make MUCP an IETF standard. It would give the proposal a form that others can implement, examine and improve.
Why another runtime
Other layers of the stack have shared interfaces that allow different implementations to coexist. HTTP lets browsers and servers evolve independently. POSIX describes common operating-system interfaces. Container specifications define boundaries between images and runtimes. The benefit comes from agreement on behaviour across implementations.
We need to work towards a similar foundation for personal assistants. A client should be able to connect to a compatible runtime without being rewritten around that runtime’s internals. Implementers should be able to choose their models, storage and execution mechanisms while preserving the contract exposed to users and clients.
Projects such as Hermes and pi are part of the wider work on agents. Making an implementation open source is valuable, but source availability alone does not establish an open runtime standard. That requires a published contract that others can implement independently, a way to establish compatibility, and a process for evolving it.
Mu does not become a standard simply because we call it open either. It is an implementation through which we can develop and test this proposal. The protocol needs to stand on its own, and its usefulness needs to be demonstrated by independently built clients and runtimes.
That is the reason for separating MUCP from Mu’s implementation and licensing the specification and contracts for reuse. The goal is a shared foundation for assistants and services, with Mu as one implementation of it.
Where it stands
Android, the standalone web client, desktop and the CLI now use MUCP. The full web experience continues to provide Home, Inbox, Agents, Services and administration.
The current protocol supports request and response operations and durable personal requests. Streaming, subscriptions and cancellation are not implemented yet. Work continues on client usability, broader service access, and consistent recovery and error handling.
The direction is an assistant you can use through the interface that suits you, connected to services you choose, with a runtime you can host and inspect. The protocol gives those interfaces a shared foundation.