Follow-up cleanup after merging the Ollama provider (#3636):
- Add the `ollama` row to the AI provider capability matrix in the provider
guide, and blank-import `ai/ollama` in provider_capabilities_test.go so the
matrix stays enforced against the registry (the provider registers a stream
but wasn't imported in that test, so its row went unchecked).
- README: bump "7 LLM providers" → 8 and list Ollama (local + cloud); add its
default model (`llama3.2`) to the model table.
- Fix a fictional model name shipped in the example and package doc:
`gemma4:31b-cloud` → `gpt-oss:120b`. gemma4 doesn't exist, and the `-cloud`
suffix is for cloud models proxied through a local Ollama, not the direct
ollama.com/v1 endpoint the example uses.
- Record the provider and the new agent.BaseURL/micro.AgentBaseURL option in
the CHANGELOG [Unreleased] section.
Claude-Session: https://claude.ai/code/session_01CmdEY7pYmV5zzwCjNJ4ykL
Co-authored-by: Claude <noreply@anthropic.com>
There was no working, prominent Discord link. Update the stale invite code
(WeMU5AGxD → G8Gk5j3uXr) everywhere it appeared (README, docs, blog, landing,
SECURITY, issue templates, contrib), and add the link prominently: the site
nav and footer includes (so it shows on every landing/docs/blog page), a
Discord badge + a Community line in the README, and a "Join Discord" button on
the landing.
Co-authored-by: Claude <noreply@anthropic.com>
Add a blog post for the OpenAI Codex for Open Source grant, list it on
the blog index, and repoint the OpenAI sponsor logo (README + landing) to
the post — matching how the Anthropic (/blog/3) and Atlas Cloud (/blog/8)
sponsor logos link to their posts.
Co-authored-by: Claude <noreply@anthropic.com>
Go Micro received an OpenAI Codex for Open Source grant. Add the OpenAI
logo to the README and landing-page sponsors, alongside Anthropic and
Atlas Cloud.
Co-authored-by: Claude <noreply@anthropic.com>
Plain 'go install go-micro.dev/v6/cmd/micro@latest' fails on the public
module proxy with a version-constraints conflict: the proxy has cached the
sub-paths go-micro.dev/v6/cmd and .../cmd/micro as standalone v0/v1 modules
(from old github.com/micro/go-micro tags, surfaced during an earlier vanity
meta bug), so @latest resolves to v1.18.0 with a mismatched module path.
A version-prefix query (@v6) sidesteps it: those cached sub-path modules
have no v6.x.x versions, so Go falls back to the go-micro.dev/v6 root
module and builds correctly. Verified against proxy.golang.org.
Claude-Session: https://claude.ai/code/session_01CmdEY7pYmV5zzwCjNJ4ykL
Co-authored-by: Claude <noreply@anthropic.com>
* support: advertise commercial support, consulting, and sponsorship
Adds a clear path to fund the project and pay for help, surfaced where
people look:
- SUPPORT.md + website /docs/support.html with a tier ladder (community,
sponsor, support retainer, consulting)
- Commercial Support / Consulting issue template (the GitHub inbound funnel)
and an issue-chooser config linking Sponsors and docs
- FUNDING.yml custom link to the support page; README section + nav entry
Community support stays free via issues; paid support and consulting are
scoped per engagement.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CmdEY7pYmV5zzwCjNJ4ykL
* ci: migrate golangci-lint to v2 config and enforce in CI (#2988)
- Rewrite .golangci.yaml for the v2 schema: start from the standard linter
set (errcheck, govet, ineffassign, staticcheck, unused) plus bodyclose,
misspell, unconvert, usestdlibvars. Sensible exclusions: generated code,
built-in presets, looser tests, SA1019 deprecations (coordinated migration
is separate), and the ported protoc-gen-micro generator for unused.
- Add a Lint workflow running golangci/golangci-lint-action with
only-new-issues, so linting is enforced on new/changed code without a
flag-day cleanup of the existing backlog.
The pre-existing backlog (errcheck/unused/naming and a few real bugs the
linter surfaces) is left for a dedicated follow-up so it can be reviewed on
its own rather than buried in this wiring change.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CmdEY7pYmV5zzwCjNJ4ykL
---------
Co-authored-by: Claude <noreply@anthropic.com>
* test(harness): read agent plan from the scoped store
The store-scoping change moved an agent's plan from the default table
key agent/{name}/plan to its own table (database "agent", table {name},
key "plan"). The plan-delegate harness tests still read the old key and
failed with 'not found'; read through store.Scope(mem, "agent", name)
like the agent does.
* docs: orient agents-first across README, landing, and docs overview
Lead with agents (then services and flows), surface MCP + A2A as the
interop story, and frame agents as services. Landing hero and feature
grid reordered agents-first with an A2A gateway card.
* v6: module path go-micro.dev/v6, TLS secure by default, NewService
Cut v6. Three breaking changes, bundled so the major bump is paid once:
- Module path go-micro.dev/v5 -> go-micro.dev/v6 across all imports + go.mod.
- TLS verification on by default (was off). MICRO_TLS_SECURE removed;
MICRO_TLS_INSECURE=true opts out for self-signed/dev.
- micro.NewService(name, opts...) is the canonical service constructor,
symmetric with NewAgent/NewFlow; micro.New kept as a deprecated alias;
the old name-less NewService(opts...) removed. Generators emit NewService.
Also ports the JWT auth token provider in-module (go-micro.dev/v6/auth/jwt/token
on golang-jwt/jwt/v5), dropping the v5-pinned github.com/micro/plugins/v5/auth/jwt
and the deprecated dgrijalva/jwt-go.
Docs/README/landing updated to v6 and @latest; v5->v6 migration guide added;
CHANGELOG cut as [6.0.0]. Blog posts left at their historical versions.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Refactor the A2A handler into a reusable dispatcher + Invoke seam and
expose NewAgentHandler(card, invoke) + Card(). An agent now serves its
own A2A endpoint with AgentA2A(addr) / WithA2A — handling tasks
in-process (no RPC hop, no separate gateway). The gateway and embedded
agent share the same handler; the only difference is RPC vs in-process
invocation. Docs, README, and changelog cover both deployment modes.
Co-authored-by: Claude <noreply@anthropic.com>
* feat(a2a): Agent2Agent protocol gateway
Add gateway/a2a — exposes registered agents over the open A2A protocol so
agents on other frameworks can discover and call them. Agent Cards are
generated from registry metadata (the same way the MCP gateway derives
tools from service endpoints); incoming A2A tasks translate to the
agent's existing Agent.Chat RPC, so there's no per-agent code.
v1 is the synchronous JSON-RPC binding: message/send returns a completed
Task, tasks/get retrieves it, and Agent Cards are served for discovery;
streaming and push notifications are advertised as unsupported. Run with
'micro a2a serve' (cmd/micro/a2a). Tests cover card generation,
message/send, tasks/get, listing, and unknown-method errors.
* docs: A2A guide, README contents + A2A section, universe A2A check
- Add a Contents table of contents at the top of the README and an A2A
subsection under Building Agents.
- Add the Agent2Agent (A2A) guide and register it in the docs nav.
- Exercise the A2A gateway in the universe harness: the concierge agent
is reached over A2A (message/send -> Agent.Chat -> completed task).
* feat(a2a): outbound client — call external A2A agents
Add a2a.Client (Send/Card) so a Go Micro agent or flow can call an agent
on any framework by URL — the outbound counterpart to the gateway. Wired
in two places: flow.A2A(url) as a workflow step (the cross-framework
Dispatch), and agent delegate to an http(s) URL routes over A2A. The
universe harness now drives the gateway through the client, exercising
both directions. Tests cover client send/card and the round trip.
* docs: A2A both-directions — guide, README, changelog, blog #26
---------
Co-authored-by: Claude <noreply@anthropic.com>
* docs: design note for flow steps + Checkpoint durable execution
* docs: fold in durable-execution decisions (State struct, single Step, run retention, retry)
* docs: rename State.Payload to State.Data
* feat(flow): ordered steps + Checkpoint durable execution
A flow can now be an ordered list of steps (a task with stages) instead
of a single LLM turn. State carries typed Data plus a Stage marker; each
step is checkpointed before and after via a pluggable Checkpoint
(store-backed by default), so a run survives a crash and resumes where it
stopped without re-running completed steps. Flow-level Retry with a
per-step override; runs retained for audit unless DeleteOnSuccess.
Step actions: Call (RPC), LLM (augmented turn), Dispatch (to an agent),
or any StepFunc. Single-step and agent-dispatch flows are unchanged.
* feat(flow): top-level re-exports + durable flow example
Expose the step/checkpoint API from the micro package (FlowSteps,
FlowStep, FlowState, FlowRetry, FlowWithCheckpoint, FlowCall/LLM/Dispatch,
Checkpoint, StoreCheckpoint) and add a runnable, key-free example
demonstrating crash + resume.
* docs: document durable flow steps (guide, README, CLI help)
* docs: blog post + changelog for durable workflows
* fix(flow): scope checkpoint keys by flow name (flow/{name}/runs/{id})
Run keys were flow/runs/{id} — a single global keyspace shared by every
flow on the default store. Namespace them by flow name so each flow's
state is kept apart. StoreCheckpoint now takes a scope argument (the flow
passes its name by default).
* feat(store): Scope handle; scope agent and flow state by name
Add store.Scope(s, database, table) — a store handle that confines every
operation to a database/table without mutating the shared store, so
co-located components don't clobber each other's table (the failure mode
of the global Init(Table(...)) approach).
Use it to keep each agent's memory and plan in its own table
(agent/{name}) and each flow's runs in its own (flow/{name}), instead of
one global table partitioned only by key prefix. Services already scope
by service name.
* feat: consistent state model — service store scoping, flow registry, list/history CLI
- service: scope store via store.Scope (database service / table name),
retiring the Init(store.Table(name)) global-mutation hack; bridge the
default store so handlers using store.DefaultStore stay isolated.
- flow: register in the registry as type=flow while running (with trigger
and step count), deregister on Stop. Live discovery, like agents.
- cli: micro flow list (registry), micro flow runs <name> (durable store),
micro agent history <name> (durable store). list = running, runs/history
= durable, mirroring the service model.
* test: mini-universe end-to-end harness + scheduled GitHub Action
internal/harness/universe boots a small but real go-micro world — four
services, a durable checkout flow that crashes at payment and resumes,
and a guardrailed agent with a tool wrapper reached over RPC — drives the
scenario, asserts the end state (10 checks), and shuts down. Everything
is real except the LLM (mocked), so it's deterministic and needs no key;
-provider anthropic runs it live. Exits non-zero on failure, so it's an
end-to-end test, not just a demo.
Adds .github/workflows/universe.yml (push/PR/daily/dispatch) running the
universe + existing harnesses on the mock provider, plus an opt-in job
that runs live when ANTHROPIC_API_KEY is set. 'make harness' runs them
locally.
* ci: run the live universe job against AtlasCloud (ATLASCLOUD_API_KEY)
* ci: run the live universe job only on schedule or manual dispatch
The deterministic mock job still runs on push/PR/daily; the live
(AtlasCloud) job runs daily and on manual workflow_dispatch only, so
changes don't burn API credits on every PR but can still be checked
against a real model on demand.
---------
Co-authored-by: Claude <noreply@anthropic.com>
* feat(agent): tool-execution wrappers via WrapTool
Restructure ai.ToolHandler to the structured, ctx-carrying shape that
mirrors a go-micro RPC handler:
func(ctx context.Context, call ai.ToolCall) ai.ToolResult
This reuses the existing ToolCall (with its correlation ID) and
ToolResult types instead of the flat (name, input)->(any, string)
signature, and adds ToolCall.Scan for typed argument access.
Add ai.ToolWrapper and the agent option WrapTool / micro.AgentWrapTool —
the tool-side analogue of client.CallWrapper and server.HandlerWrapper.
Reframe the built-in guardrails (MaxSteps, LoopLimit, ApproveTool) as
composed wrappers around a base handler; developer wrappers compose
outermost, so they observe every call and result, including refusals.
Update all provider call sites, the MCP server and chat handlers, the
integration harnesses, and docs to the new signature.
* examples: add agent-wrap-tool showing AgentWrapTool
A runnable example of tool-execution middleware: an observe wrapper that
times calls and records per-tool metrics (correlated by call ID), and a
retry wrapper that recovers a flaky service call before the model sees
it. Demonstrates outermost-first composition and the wrapper/guardrail
interaction (retries are seen by loop detection).
* docs: note AgentWrapTool in README capabilities and CHANGELOG
* fix(generate): pin scaffolded go.mod to one version constant
The two generators pinned different, stale go-micro versions (v5.24.0
for services, v5.25.0 for agents). Centralize on a single
goMicroVersion constant (v5.29.0) so generated services and agents stay
in sync with the framework and there's one place to bump on release.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Add LoopLimit: refuse a tool call repeated with identical arguments in
one Ask, with a self-heal message so the model changes approach. Catches
the no-progress loop that MaxSteps (count) and the gateway circuit
breaker (failures) miss. Enforced at the same tool-handler choke point as
MaxSteps/ApproveTool; on by default (lenient 3); AgentLoopLimit(0) to
disable. Tests cover repeats, distinct calls, disabled, and default-on.
Docs: new Agent Guardrails guide (MaxSteps/LoopLimit/ApproveTool, the
ApproveTool integration seam for external policy engines, and the
gateway's RateLimit/CircuitBreaker), nav + README + AGENT_DESIGN updates,
and blog/23 'Agent Guardrails'.
Co-authored-by: Claude <noreply@anthropic.com>
Follow-up to the merged x402 integration (#2964). Drop the commerce-y
'price' vocabulary for the protocol's own 'amount', and add per-tool
pricing as an operator concern (the way scopes/rate-limits are set at the
gateway).
- x402.Config: Price -> Amount (default), plus Amounts map for per-tool
overrides; AmountFor(tool) resolves per-tool -> default. Add a Require
primitive (per-request enforcement) and LoadConfig for an operator
config file.
- MCP gateway: enforce payment per-tool inside /mcp/call (where scopes
are enforced) using AmountFor, instead of a flat path-based middleware.
- CLI: --x402-price -> --x402-amount; add --x402-config (per-tool file)
to micro mcp serve and micro-mcp-gateway.
- docs: new Payments (x402) guide + nav + README section; blog/22
updated to Amount/Amounts and the config-file model.
Co-authored-by: Claude <noreply@anthropic.com>
Integrate the x402 payment protocol (HTTP 402) so a tool can require a
stablecoin payment and an agent can settle it — the next step after
autonomous agents (blog 21): agents that act, and pay.
- wrapper/x402: HTTP middleware enforcing the 402 challenge/verify flow,
with a pluggable Facilitator interface. Go Micro carries no chain or
crypto code — verification/settlement is delegated to a facilitator
(Coinbase CDP, Alchemy, self-hosted), so Base and Solana are just
different facilitators behind one interface. HTTPFacilitator default;
tests cover challenge / accept / reject via a mock facilitator.
- MCP gateway: optional Options.Payment gates /mcp/call (listing tools
and health stay free); off unless configured.
- micro mcp serve and micro-mcp-gateway: opt-in --x402-pay-to/-price/
-network/-facilitator flags (env vars on the standalone binary).
- blog/22 'Integrating x402: Payments for Agents'; README feature row.
Pricing is flat per call for now; richer models and an agent-side spend
cap (next to MaxSteps/ApproveTool) are follow-ups.
Co-authored-by: Claude <noreply@anthropic.com>
* docs: add 'become a sponsor' call-to-action linking to Discord
Now that there are a couple of sponsors, invite more: a short CTA under
the Sponsors section in the README and on the landing page, pointing to
the Discord to get in touch.
* fix(health): remove duplicate RegistryCheck declaration
Two PRs (#2957 and #2958) each added a RegistryCheck to the health
package, leaving the package uncompilable on master (RegistryCheck
redeclared: health/registry.go vs health/health.go). Keep the
health.go implementation — it honors the check's context timeout so a
hung registry (e.g. an unreachable etcd) reports down instead of
blocking the probe — and remove the duplicate registry.go and its test.
registry_check_test.go already covers healthy/down/nil/timeout/not-ready.
* feat(agent): pluggable memory and custom tools
Make agents compose the way services do — pluggable pieces with working
defaults — by adding the two abstractions an agent needs beyond the model:
- Memory: a pluggable interface for conversation memory. The default is
store-backed and durable across restarts (the previous hardcoded
behavior, now behind an interface); supply your own with WithMemory
(in-memory, database, semantic store). NewMemory / NewInMemory provided.
- Custom tools: WithTool registers any function as a tool the agent can
call, so agents are no longer limited to orchestrating RPC services.
Both exposed at the micro package (AgentMemory, AgentTool, NewMemory,
NewInMemory). Behavior-preserving refactor of the agent's history into
the default Memory; tests cover persistence, in-memory, clear, custom
tool dispatch and errors. README + AGENT_DESIGN document the pluggable
composition (model / memory / tools / guardrails).
* blog: 'Doubling Down on Agents' (#20)
The vision post for making agents a first-class framework the way
services were: opinionated, batteries-included, pluggable. Frames an
agent as a composition of model + memory + tools + guardrails with
working defaults; introduces the new pluggable memory and custom tools;
makes the microagents argument (an agent for everything, distributed
like microservices); and lays out the three primitives — services,
agents, workflows — as one substrate, with an honest list of the gaps
still to fill (knowledge/retrieval, streaming, explicit loop).
---------
Co-authored-by: Claude <noreply@anthropic.com>
Now that there are a couple of sponsors, invite more: a short CTA under
the Sponsors section in the README and on the landing page, pointing to
the Discord to get in touch.
Co-authored-by: Claude <noreply@anthropic.com>
* docs: group README features by section (AI / Framework / DX)
The features table repeated 'AI' down the Category column. Split into
three grouped tables — AI, Framework, Developer experience & deployment —
dropping the repetitive column. Adds a Guardrails row (MaxSteps,
ApproveTool).
* test: flow-to-agent end-to-end in the harness
Proves 'Flow triggers, Agent reasons': a workflow with FlowAgent hands an
event to the registered conductor agent over RPC, which plans, creates
tasks, and delegates to comms — the whole chain over real RPC with only
the LLM mocked. Deterministic (shared in-memory registry, no sleeps),
passes under -race.
* blog: 'The Evolution of Microservices' (#19)
A technical history of distributed-systems eras — the monolith's
coordination cost, the distributed-systems tax, containers and
declarative orchestration, the service mesh, and the modular-monolith
correction — establishing the durable unit (named, typed, discoverable,
independently deployable) that every runtime wave required. Then the
technical argument for agents: an LLM tool call needs exactly a service
interface, so the caller shifts from deterministic code to a reasoner
that composes typed capabilities from intent, with the honest caveats
(non-determinism, cost, guardrails). Not a product pitch.
* docs: bump install version to v5.27.0
---------
Co-authored-by: Claude <noreply@anthropic.com>
* docs: group README features by section (AI / Framework / DX)
The features table repeated 'AI' down the Category column. Split into
three grouped tables — AI, Framework, Developer experience & deployment —
dropping the repetitive column. Adds a Guardrails row (MaxSteps,
ApproveTool).
* test: flow-to-agent end-to-end in the harness
Proves 'Flow triggers, Agent reasons': a workflow with FlowAgent hands an
event to the registered conductor agent over RPC, which plans, creates
tasks, and delegates to comms — the whole chain over real RPC with only
the LLM mocked. Deterministic (shared in-memory registry, no sleeps),
passes under -race.
* blog: 'The Evolution of Microservices' (#19)
A technical history of distributed-systems eras — the monolith's
coordination cost, the distributed-systems tax, containers and
declarative orchestration, the service mesh, and the modular-monolith
correction — establishing the durable unit (named, typed, discoverable,
independently deployable) that every runtime wave required. Then the
technical argument for agents: an LLM tool call needs exactly a service
interface, so the caller shifts from deterministic code to a reasoner
that composes typed capabilities from intent, with the honest caveats
(non-determinism, cost, guardrails). Not a product pitch.
---------
Co-authored-by: Claude <noreply@anthropic.com>
* blog: 'Not Everything Should Be an Agent' (#18) on workflows
The workflow counterpart to the plan/delegate post: when the path is
known, use a deterministic Flow, not an autonomous agent. Frames flow vs
agent as two modes of the same building blocks, covers flow-triggers-
agent dispatch and the agent guardrails, and gives the simplest-first
guidance (single call -> workflow -> agent). Continues the arc from
blog 14/16/17; references Building Effective Agents in passing.
* docs: fix new-user onboarding friction
- README: lead Quick Start with a no-key 30-second path (micro new ->
micro run -> curl), then the AI --prompt path with an explicit
'export ANTHROPIC_API_KEY' so the headline command no longer fails
silently for users without a key.
- Unify all install versions to v5.26.0 (README + docs were split across
v5.16.0 / v5.25.0).
- Refresh the docs landing overview from the old 'microservices
framework' framing to 'services and agents', matching the README.
- getting-started: add Prerequisites (Go 1.21+, and that a provider key
is only needed for AI features).
- README features: Flows -> Workflows wording.
---------
Co-authored-by: Claude <noreply@anthropic.com>
* docs: map go-micro onto Anthropic's workflows-vs-agents taxonomy
- new guide 'Agents and Workflows': adopts Anthropic's Building Effective
Agents vocabulary — workflow (predefined path) = flow, agent (dynamic
self-direction) = agent — maps the augmented-LLM building block and the
five workflow patterns onto go-micro, and shows routing (chat router)
and orchestrator-workers (conductor + plan/delegate) are already native.
- flow package doc reframed as a workflow (predefined path) per the same
taxonomy, with guidance on flow vs agent.
- nav + README link the new guide.
* feat: agent guardrails — step limit and tool approval hook
Anthropic's Building Effective Agents stresses stopping conditions and
human-in-the-loop checkpoints for autonomous agents. Add both as plain
options enforced at the tool-handler choke point — no provider changes,
no new abstraction:
- MaxSteps(n): bound tool executions per Ask; beyond the limit, actions
are refused and the model is told to stop and summarize.
- ApproveTool(fn): gate each action before it runs; returning false
blocks it and surfaces the reason to the model. The internal plan tool
is never gated.
Exposed at the micro package (AgentMaxSteps, AgentApproveTool, ApproveFunc).
Tests cover the limit, blocking, and that plan is not gated. Guardrails
section of the agents-and-workflows guide updated from 'active work' to
documented options.
* feat: flow can dispatch to an agent (flow triggers, agent reasons)
Unify the engine without collapsing the workflow/agent distinction. A
Flow with Agent set hands each event's rendered prompt to a named
registered agent over RPC (Agent.Chat) instead of running its own LLM
step — so the workflow stays the deterministic trigger and the agent is
the reasoning engine, with its plan, delegate, memory, and guardrails.
A plain flow is unchanged (single augmented-LLM step).
- flow.Agent(name) / micro.FlowAgent(name); flow stores the client and
skips model setup when dispatching.
- test: dispatch routes to comms.Agent.Chat with the rendered prompt and
records the reply.
- guide: 'Flow triggers, Agent reasons' section.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Asim Aslam