# Towards v7

> A proposal for a consistent application framework built on services and agents.

---

LLMS index: [llms.txt](/llms.txt)

---

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

| Component | Owns | Does not own |
|-----------|------|--------------|
| `service` | Capability contracts, operations, application data | Choosing a user's goal |
| `model` | Provider requests, responses, tool-call descriptions, usage | Executing tools or deciding when work is complete |
| `agent` | Model/tool execution, memory, limits, approval and continuation | App hosting or a product's account model |
| `flow` | Defined steps, verification and recovery boundaries | A second agent implementation |
| Proposed `app` | Application identity, revisions, resources and dependency contracts | Model prompting, billing or a particular hosting platform |

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.

| Go Micro | Mu and applications built with it |
|----------|------------------------------------|
| Communication, discovery and storage interfaces | Concrete services and their data |
| Provider adapters and common agent execution | Assistant instructions and model choices |
| Workflow and checkpoint contracts | User-facing work lists and conversation delivery |
| App definition, assets and service dependencies | App generation, storage, access policy and hosting |

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.