Towards v7

Status: design proposal, September 2026. This describes a direction and release criteria, not shipped APIs or a committed release date.

The evolution

Go Micro’s foundation is service communication: RPC, discovery, encoding, transport, and pub/sub, with pluggable storage and infrastructure. Agents extend that foundation by discovering service capabilities and choosing how to use them.

The proposed next step is a framework for applications built from services and agents. A developer can write an application or ask an agent to build it, then run, inspect, revise, and recover it through the same contracts. Existing RPC applications remain first-class; adopting AI is optional.

An app can provide a UI, a callable capability, or both. App generation is one use of the framework. The framework also needs to make the resulting software understandable and operable after the generating conversation ends.

Responsibilities

The model/agent split in this table is a v7 target. In v6, providers with a ToolHandler execute tools inside Generate. Removing that behavior is a public contract change and needs an explicit migration.

First: compatible v6 cleanup

1. Share duplicated protocol code and preserve history, model options, tools, and errors consistently. The first change consolidates the compatible OpenAI, Groq, Mistral, Together and MiniMax generation loops. Other provider protocols and CLI orchestration remain separate at this stage.
2. Define provider conformance for one model turn: structured tool calls and results, provider continuation data, streaming events, usage, and stop reasons. Provider-specific reasoning state must survive the common representation.
3. Bring CLI chat and registered-agent execution onto the same harness, keeping generation as an explicitly supplied tool. Keep routing and terminal rendering at the CLI boundary.
4. Make work completion, limit exhaustion, cancellation, approval pauses, and recoverable failures explicit. A reply or a saved checkpoint alone does not establish that the requested effect occurred.

These changes should ship incrementally where the v6 contract can be preserved. A major-version number is not needed for deduplication or bug fixes.

The first app package

An app is the human-facing interface to capabilities that agents can also call through services. Start with identity (name, description and version), an entry point, assets, and declared service dependencies. Validate that definition and serve it through the existing HTTP/web infrastructure. A hand-written app and an agent-generated app use the same definition.

The first package does not own generation, storage, publishing, accounts, or a revision database. Those can be supplied by services and runtimes. An app’s dependency declaration describes what it needs; it does not grant access. The host supplies authenticated service access and decides how generated code may run. Static asset serving is not an isolation boundary for untrusted code.

Prove this in Go Micro with one runnable app: a human uses its interface while an agent can call the same underlying service. Mu can adopt the package or contribute improvements without being a prerequisite for the example.

Over time, distinguish the app’s stable identity, a particular revision, and the run that builds or invokes it. Any later build/revision APIs should preserve a working revision on failure and recover work without resetting its attempt budget. Reports, files, and images are outputs too; they are not necessarily apps.

Go Micro, Mu, and Micro

• Go Micro is the developer framework for services, agents, and apps.
• Mu is a runtime that hosts those components, with an operating-system role.
• Micro is the personal assistant hosted by Mu and presented at micro.mu.

This proposal concerns Go Micro. Mu’s runtime and the hosted assistant have separate development priorities. They use the framework and contribute where needed; their product requirements do not automatically become framework APIs.

A developer must be able to use these framework components without Mu’s accounts, conversation model, UI, or hosted services. The repositories remain separate. Reusability for developers beyond Mu is the test for adding a framework API.

What makes this v7

A credible v7 release has a coherent execution contract and a usable application lifecycle, not merely a new package:

• Providers perform model turns; one agent harness owns tool execution and its streaming and recovery semantics.
• CLI chat and registered agents use that harness with explicitly configured tools.
• Defined workflows compose services and agents without duplicating their loops.
• Apps can be created, revised, run, and recovered through stable references.
• Independent applications can use the contracts; Mu can adopt them without coupling the framework to the personal assistant product.
• Existing service-only applications have a documented migration; core RPC, registry and broker contracts change only where a demonstrated need requires it.

The migration must cover direct v6 Generate callers that depend on automatic tool execution, provider plugins, stored run formats, and cross-version service communication. New run formats need versioned decoding or an explicit migration; old state cannot silently be interpreted under new semantics.

The acceptance criterion is practical: ask for useful software, use it, change it, and keep it working after a restart. The framework must also remain a good way to write the same software directly in Go.