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>
* feat: add plan and delegate as built-in agent tools
Give agents two self-capabilities, expressed as plain tools wired into
the existing tool handler — no harness or graph, consistent with
"services are the only abstraction":
- plan: record/update an ordered plan, persisted to store-backed memory
and surfaced in the system prompt on later turns (externalized
planning).
- delegate: hand a self-contained subtask to another agent.
Delegate-first — if the target names a registered agent it is called
via RPC; otherwise a focused ephemeral sub-agent is created with
agent.New + Ask in a fresh, isolated context (loads/persists no
history, no built-in tools, so it cannot re-delegate).
Both are added automatically to any non-ephemeral agent, so existing
micro.NewAgent services and micro chat routing get them for free.
Tests are hermetic (memory store + memory registry).
* feat: add agent-plan-delegate example and document plan/delegate
- examples/agent-plan-delegate: coordinator that plans multi-step work,
creates tasks with its own tools, and delegates notification to a
separate registered comms agent over RPC.
- integration tests driving the full Ask loop through a fake provider:
plan tool exposure + persistence, ephemeral delegation with isolated
context, delegate-first RPC routing to a registered agent.
- docs: README (Building Agents + features + examples), AGENT_DESIGN
(Built-in Capabilities), agent-patterns guide (Pattern 9), CLAUDE.md.
* docs: blog post and guide for plan & delegate
- blog/17: "Plan & Delegate: Deep Agents in Go" — what the feature is,
how plan and delegate work, and a runnable getting-started path.
- guides/plan-delegate: reference guide with the smallest-agent snippet,
plan/delegate semantics, and the multi-agent example; linked in nav.
- example: auto-detect provider/key from common env vars (ANTHROPIC_API_KEY,
OPENAI_API_KEY, ...) so 'export KEY && go run main.go' just works.
- onboarding: getting-started paths now include go mod init / go get and a
clone-and-run path, so a reader can actually run it from a cold start.
* refactor: reframe plan/delegate blog and clean up sub-agent construction
- blog/17 retitled "Agents That Plan and Delegate" and reframed around
intent (plan = state intent, delegate = direct it), positioned as the
next beat after blog 15/16 and tied to the existing store + agent RPC
rather than re-announcing them. "Deep agents" now a single in-passing
nod, matching how blog 14 references LangChain.
- agent: add unexported newEphemeral constructor for sub-agents instead
of type-asserting the public Agent interface to set an internal field;
matches the options-only construction idiom used elsewhere.
* feat: expose plan & delegate in the micro chat fallback
Add agent.Builtins(opts...) — returns the built-in tools plus a handler,
so the plan/delegate capabilities can be wired into a tool loop that
isn't a running Agent. micro chat's direct-service fallback now reuses
it (single source of truth, no duplicated handler logic), so planning
and delegation are available there too, not just for registered agents.
Adds a test for the accessor; notes CLI availability in the guide.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Run Tests / Etcd Integration Tests (push) Has been cancelled
goreleaser / goreleaser (push) Has been cancelled
* perf: compress hero image — 1.4MB to 80KB
Resized from 1536px to 1200px, converted to JPEG at quality 80.
80KB loads instantly vs 1.4MB stalling on slower connections.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* docs: micro run drops into interactive console
One command does everything — generate, start, and chat. No
separate micro chat step. The landing page shows micro run
dropping straight into the > prompt.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* feat: interactive console in micro run, -d for detached mode
micro run now drops into an interactive chat console after services
start. The console discovers services, exposes them as tools, and
lets you talk to them through an LLM — same as micro chat but
built into the run experience.
- Detects MICRO_AI_PROVIDER and MICRO_AI_API_KEY from environment
- Falls back to provider-specific env vars (ANTHROPIC_API_KEY, etc.)
- If no API key, prints hint and blocks on Ctrl-C (no console)
- -d / --detach flag skips the console (background mode)
- Ctrl-C always shuts everything down
Removed adopters section from README.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
---------
Co-authored-by: Claude <noreply@anthropic.com>
* docs: reposition hero — framework for services and agents
Landing page: "Build Services and Agents in Go" — positions as a
framework, not a code generator. Tagline: "A framework for
microservices that AI agents can discover, use, and manage."
Hero command reverts to go get (the framework) instead of
micro run --prompt (a feature).
README matches: "framework for building services and agents in Go."
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* perf: compress hero image — 1.4MB to 80KB
Resized from 1536px to 1200px, converted to JPEG at quality 80.
80KB loads instantly vs 1.4MB stalling on slower connections.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
---------
Co-authored-by: Claude <noreply@anthropic.com>
* docs: update blog posts 15 and 16 to reflect RPC-based agents
Blog 15: replaced broker-based agent communication with RPC —
agents are services, they communicate via standard RPC, no pub/sub
hacks. Updated the framework mapping section.
Blog 16: added proto definition, micro call example, and explanation
that agents are real services with proto-defined endpoints. Updated
Ask() method name.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* docs: update agent design doc and blog posts for RPC-based agents
Rewrote AGENT_DESIGN.md — agents are services with proto-defined
Agent.Chat endpoints, communicate via RPC, no broker dependency.
Includes proto definition, CLI examples, generation output.
Blog 15: replaced broker references with RPC.
Blog 16: added proto definition and micro call example.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* docs: purge all stale broker-based agent references
Updated across all surfaces:
- README: agents described as services with RPC, Ask() not Chat(),
micro call example instead of micro agent chat
- Blog 15: replaced broker communication with RPC description
- Blog 16: replaced "coordinate through the broker" with RPC
- Getting started: agent is a service with proto endpoint, Ask()
not Chat(), added micro flow CLI commands (run/exec), expanded
CLI workflow table
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
---------
Co-authored-by: Claude <noreply@anthropic.com>
* docs: Agent interface design sketch
Proposes Agent as a top-level abstraction alongside Service in the
micro package. Agent manages services — scoped tools, system prompt,
conversation memory, registry-discoverable.
Design only, no implementation.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* feat: Agent as a first-class abstraction
Introduce micro.NewAgent() alongside micro.New() — Agent is to
intelligence what Service is to capability.
Agent interface:
- Chat(ctx, message) (*Response, error) — core interaction method
- Run() — registers in registry, subscribes to broker, blocks
- Stop() — graceful shutdown
- Scoped tools — only sees endpoints of its assigned services
- Persistent memory — conversation history stored in store
- Agent-to-agent — communication via broker topics
Top-level API:
agent := micro.NewAgent("task-mgr",
micro.AgentServices("task"),
micro.AgentPrompt("You manage tasks."),
micro.AgentProvider("anthropic"),
)
agent.Run()
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* feat: wire agents into chat router, add micro agent CLI, expose Flow
Three top-level abstractions:
micro.New("task") — Service (capability)
micro.NewAgent("task-mgr") — Agent (intelligence)
micro.NewFlow("onboard-user") — Flow (event-driven orchestration)
micro chat as router:
- Discovers agents from registry on startup
- Single agent: routes directly
- Multiple agents: LLM classifies intent, dispatches to right agent
via route_to_agent tool
- No agents: falls back to current direct-service behaviour
- Banner shows discovered agents
micro agent CLI:
- micro agent list — shows registered agents and their services
- micro agent describe <name> — shows agent details from registry
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* feat: move flow to top level, update docs for three abstractions
Package structure now consistent:
service/ — Service (capability)
agent/ — Agent (intelligence)
flow/ — Flow (event-driven orchestration)
ai/flow/ kept as backward-compatible re-export.
Updated across all surfaces:
- CLAUDE.md: added agent/ and flow/ to project structure
- README: added "Building Agents" section with NewAgent() examples,
updated features table (Agents, Flows, Chat router), CLI table
(agent list, agent describe), docs links
- Website: features grid shows Services, Agents, Flows as the three
pillars alongside generation, MCP, and pluggable architecture
- micro.go: Flow imported from top-level flow/ package
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* docs: rewrite getting-started, fix ai-integration import paths
Getting started now covers all three abstractions:
- Service (write handlers, micro run, templates)
- Agent (micro.NewAgent, scoped tools, memory, CLI)
- Flow (event-driven LLM orchestration)
Leads with prompt-based generation, then manual service creation.
ai-integration.md: fixed flow import path from go-micro.dev/v5/ai/flow
to go-micro.dev/v5/flow, updated stack diagram to show agent/flow/chat.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* blog: Introducing micro.NewAgent()
Post 16 — announces Agent as a first-class abstraction. Shows the
API (NewAgent, AgentServices, AgentPrompt, AgentProvider), scoped
tools, persistent memory, multi-service agents, multi-agent systems,
and the three-abstraction comparison table (Service/Agent/Flow).
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* feat: fix agent registration, blog post 16
Agent registration:
- Add node with address so mDNS can discover agents
- Store type and services in node metadata (mDNS requirement)
- Connect broker before subscribing, non-fatal if broker unavailable
- Print registration confirmation on Run()
Agent/chat discovery:
- Check both service-level and node-level metadata for type=agent
(mDNS stores metadata on nodes, not services)
Blog post 16: "Introducing micro.NewAgent()" — announces the Agent
abstraction with code examples, comparison table, multi-agent patterns.
Tested end-to-end: micro run → micro agent list discovers the agent →
micro chat routes to it → agent calls service endpoints.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* feat: agents are proper services with RPC Chat endpoint
Refactored agent to use server.Server instead of fake registry entries.
An agent now:
- Creates a real RPC server with server.Name(agentName)
- Registers an Agent.Chat handler callable via standard RPC
- Sets server metadata type=agent, services=x,y for discovery
- No more fake addresses or broker hacks
micro chat calls agents via RPC (client.Call) instead of creating
local agent instances. The registry stays clean — agents are real
services with real endpoints.
Removed broker dependency from agent options. Agent-to-agent
communication is just RPC like everything else.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* feat: agent uses proto-defined RPC interface
Added agent/proto/agent.proto with Agent service definition:
rpc Chat(ChatRequest) returns (ChatResponse)
Agent now implements the generated AgentHandler interface and
registers via pb.RegisterAgentHandler. The Chat endpoint is a
standard proto-based RPC callable by any go-micro client.
Renamed the programmatic API from Chat() to Ask() to avoid
collision with the proto handler method name.
micro chat calls agents via standard RPC with JSON-encoded
request/response — no special types needed on the caller side.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* feat: generate agent alongside services, update all docs
micro run --prompt now generates an agent binary that manages all
the generated services. The agent reads MICRO_AI_PROVIDER and
MICRO_AI_API_KEY from the environment. micro run propagates these
when started with --prompt.
Run banner shows services and agents separately.
Updated README, getting-started guide, and landing page to show
the complete flow: generate → services + agent start → micro chat
routes to agent → agent orchestrates services.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
---------
Co-authored-by: Claude <noreply@anthropic.com>
Quick Start now flows through the full AI experience: generate →
review → run → chat → grow (mid-conversation service generation).
The reader sees the complete prompt-to-production story without
interruption.
"Writing Services" is a separate section below for developers who
want to understand the framework underneath. Shows Go code, doc
comments, @example tags, micro run, and scaffolding templates.
Features table and CLI table reordered: AI first, then framework.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
Co-authored-by: Claude <noreply@anthropic.com>
* docs: add binary install option to README quick start
Show curl install.sh first (no Go required), go install second.
Uses the existing install script at go-micro.dev/install.sh which
downloads pre-built binaries from GitHub releases.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* docs: regenerate hero image for new AI-native positioning
New hero shows terminal running micro run with service generation,
an AI agent orchestrating, and task/shipping/category service nodes.
Matches the "Microservices That AI Agents Can Use" headline.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
---------
Co-authored-by: Claude <noreply@anthropic.com>
Both surfaces now lead with the same line: "Go Micro is a framework
for building microservices that AI agents can use."
README:
- Leads with prompt generation + chat (the differentiator)
- Features as a compact table instead of paragraph-per-feature
- CLI workflow table
- Removed redundant sections, tightened to ~150 lines
Website:
- Hero: "Microservices That AI Agents Can Use"
- Hero command: micro run --prompt instead of go get
- Features grid reordered: AI tools, orchestration, generation first
- First two-col section: describe/generate/run/chat story
- Architecture and DX sections follow
Both tell the same story in the same order:
1. What it is (microservices framework)
2. What makes it different (every service is an AI tool)
3. How you use it (prompt → run → chat)
4. What's underneath (registry, RPC, store — all pluggable)
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
Co-authored-by: Claude <noreply@anthropic.com>
* feat: add micro new --prompt and micro run --prompt
Add AI-powered service generation: describe a system in natural
language and get real go-micro services with proto definitions,
handlers, doc comments, and MCP support.
micro new --prompt "a contact book with notes and tags" \
--provider anthropic
Generates:
contacts/ — CRUD service with name, email, phone fields
notes/ — notes linked to contacts
tags/ — tagging system
Each service gets:
proto/{name}.proto — domain model + CRUD endpoints
handler/{name}.go — in-memory store, @example tags for MCP
main.go — MCP-enabled, proper imports
go.mod + Makefile — compiles with go mod tidy + make proto
micro run --prompt does the same then starts all services.
The LLM designs the architecture (service names, fields, endpoints,
descriptions) and returns structured JSON. Code generation uses
the existing template patterns — the output is standard go-micro
code that compiles, runs, and is immediately callable via MCP
and micro chat. No AI dependency at runtime.
* feat: LLM generates real business logic with compile-fix loop
Rebuild the generate package so the LLM writes actual handler
code with business logic, not just CRUD scaffolding.
The flow is now:
1. LLM designs architecture (service names, fields, endpoints)
→ returns structured JSON
2. Proto, main.go, go.mod, Makefile generated deterministically
from the design (guaranteed to be correct)
3. go mod tidy + make proto compiles the protos
4. LLM generates handler code with REAL business logic
→ given the proto, endpoint descriptions, and go-micro patterns
5. go build — does it compile?
6. If no: feed errors back to LLM, get fixed code (up to 3 attempts)
7. If yes: service is ready
The handler prompt instructs the LLM to:
- Use sync.RWMutex for thread-safe in-memory state
- Include validation, edge cases, meaningful errors
- Write doc comments with @example tags for MCP
- Implement actual domain logic, not just map operations
Proto generation still uses deterministic templates (CRUD +
custom endpoints from the design spec) to guarantee correctness.
The compile-fix loop catches LLM mistakes automatically.
Both micro new --prompt and micro run --prompt use this flow.
* fix: handle edge cases in prompt-based generation
- Fix PATH for protoc-gen-micro in child processes
- Handle existing directories: skip structural files (main.go,
go.mod, Makefile) if dir exists, always regenerate proto,
only write placeholder handler if none exists
- Allow re-running micro new --prompt on same directory to
iterate on business logic without clobbering user edits
Tested end-to-end: "a simple todo list with tasks and categories"
generates 2 services (task-service, category-service) with real
business logic (validation, toggle complete, etc.), compiles
after 1 fix iteration, and runs with 6 MCP tools discovered.
* feat: auto-detect modified handlers on regeneration
Instead of requiring a --keep-handlers flag, the generate package now
tracks a SHA-256 hash of each generated handler in a .micro metadata
file. On re-run, if the user has edited the handler since generation,
it's left untouched. Unmodified handlers are regenerated normally.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* feat: add tests, fix go.mod, gitignore, proto tracking, spinner
- Add 12 tests covering helpers, proto generation, hash tracking
- Fix go.mod: write minimal module file, let go mod tidy resolve deps
- Add .gitignore to prompt-generated services
- Protect user-edited proto files (same hash tracking as handlers)
- Add spinner during LLM calls so it doesn't look hung
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* feat: signal handling, existing service discovery, help text
- Ctrl+C during generation now cancels LLM calls immediately via
signal-aware context; re-run picks up where it left off
- Design() scans for existing services in the working directory and
includes their proto definitions in the prompt, so the LLM extends
the system rather than redesigning from scratch
- Updated --prompt help text with usage examples on both new and run
- Listed all supported providers in flag descriptions
- Added discoverExisting test
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* feat: show endpoints in run --prompt output, add micro chat hint
Print endpoint names and descriptions when designing services so users
see what was built. Add a micro chat hint to the run banner so users
know how to interact with their services after startup.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* fix: generated go.mod uses go 1.24 with explicit go-micro require
go 1.22 with no explicit require caused Go to resolve sub-packages
(gateway/mcp, client, server) as separate modules, hitting stale v1.18
tags. Pin to go 1.24 + require go-micro.dev/v5 v5.24.0 so go mod tidy
resolves all sub-packages from the root module correctly.
Tested end-to-end: 4 services generated and compiled successfully.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* fix: skip handler regeneration when proto unchanged
Compare proto hash before and after structure generation. If the proto
didn't change and the handler wasn't edited by the user, skip go mod
tidy, make proto, LLM handler generation, and compile-fix entirely.
Prints "(unchanged)" instead.
Reduces re-run of 4-service project from ~2 minutes to ~10 seconds.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* feat: confirm design before generating code
Show the service design (names, endpoints) and prompt "Generate? [Y/n]"
before spending LLM time on handler generation. Applies to both
micro new --prompt and micro run --prompt. Default is yes (enter).
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* fix: use port :0 for MCP in generated multi-service projects
Each generated service had mcp.WithMCP(":3001") hardcoded, causing
port conflicts when running multiple services. Use :0 to auto-assign
a free port. micro run's central gateway handles unified MCP access.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* feat: truncation detection, tool result display in chat
- Detect truncated LLM responses (unbalanced braces, doesn't end
with '}') and retry with a conciseness hint before falling through
to compile-fix
- Show tool call results in micro chat output (← for success, ✗ for
errors) so users can see what the LLM did
- Add Result/Error fields to ToolCall, populated by Anthropic provider
after tool execution
- Add isTruncated tests
Tested end-to-end with Anthropic: services generate, compile, start,
register, respond to RPC calls, and micro chat discovers and calls
tools correctly.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* fix: Anthropic tool loop, service naming, chat tool results
Anthropic provider:
- Fix tool execution loop to properly iterate (was re-processing all
tool calls instead of only new ones each round)
- Clean assistant content blocks before sending back (strip 'id' from
text blocks that Anthropic rejects on input)
- Include tools in follow-up requests so model can make additional calls
- Loop up to 10 rounds until model responds with text only
Service naming:
- Strip '-service' suffix from micro.New() name so services register
as 'task', 'category' instead of 'taskservice', 'categoryservice'
Chat:
- Show tool results (← for success) and errors (✗) in chat output
Tested end-to-end: create task → list tasks works as multi-step
orchestration through micro chat with Anthropic Claude.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* feat: blog post 13 — from prompt to production
Covers the full micro run --prompt flow: design, generate, compile-fix,
run, and chat orchestration. Positions agent-as-orchestrator as the
answer to service coordination.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* fix: timeouts, max_tokens, TTY detection, smaller services
- Add 60s timeout on design, 90s on handler generation, 60s on
compile-fix LLM calls so hung providers don't block forever
- Bump Anthropic max_tokens from 4096 to 8192 to reduce truncation
- Add TTY detection: spinner prints static message in non-TTY (CI/pipes)
instead of ANSI escape codes
- Tighten prompts: max 200 lines per handler, 2-4 services, 5-8 fields,
explicit "services don't call each other" rule
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* feat: chat suggests creating services when capabilities are missing
Update system prompt with the list of available services. When the user
asks for something no existing service can handle, the agent explains
what's available and suggests the exact micro new --prompt command to
create the missing service.
This is the natural evolution path: start with a few services, talk to
them via chat, and when the domain grows, the agent tells you what to
add. Each service stays small and focused.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* feat: chat generates and starts services inline, drop -service suffix
Chat agent now has a micro_generate_service tool. When the user asks
for a capability that doesn't exist, the agent generates the service,
compiles it, starts it as a background process, waits for registration,
re-discovers tools, and uses the new endpoints immediately — all within
the conversation.
Service naming: design prompt now instructs LLM to return names without
'-service' suffix (e.g. 'task' not 'task-service'). buildMain keeps
TrimSuffix as safety net for backward compatibility.
Spawned processes are cleaned up when chat exits.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* docs: rewrite blog post 13 with inline service generation
Updated to reflect the full UX: services generate and start within
the chat conversation. Added the shipping example showing the agent
creating a service mid-conversation. Removed -service suffix from
all examples. Tightened the narrative around agent-as-orchestrator.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
* feat: persistent storage, README quickstart, auto-detect new services
Storage: generated handlers now use go-micro's store package instead
of in-memory maps. Data persists across restarts. The handler prompt
includes store API examples so the LLM generates correct store usage.
README: added "Generate From a Prompt" section with micro run --prompt
and micro chat examples, linking to blog post 13.
Watcher: micro run now scans for new service directories every 5s. When
micro chat generates a service, micro run detects the new directory,
builds it, starts it, and adds it to the watcher — fully automatic.
Added AddDir/Dirs methods to the watcher.
Blog: updated post 13 with persistent storage example and watcher note.
https://claude.ai/code/session_01QTp4SshuVmLAvvEGJe4TJd
---------
Co-authored-by: Claude <noreply@anthropic.com>
* refactor(ai): rename ToolSet to Tools, simplify wiring with WithTools
Move tool discovery/execution fully into the ai package as ai.Tools
(formerly ai.ToolSet), and simplify the usage model:
- NewTools(reg, ai.ToolClient(c)) takes the execution client as an
option instead of threading it through Handler(c) per call
- New ai.WithTools(tools) option wires the tool handler into a model
in one call, replacing ai.WithToolHandler(set.Handler(c))
- ai.DiscoverTools(reg) for one-shot discovery
Before:
set := ai.NewToolSet(reg)
list, _ := set.Discover()
m := ai.New(p, ai.WithToolHandler(set.Handler(client)))
After:
tools := ai.NewTools(reg, ai.ToolClient(client))
list, _ := tools.Discover()
m := ai.New(p, ai.WithTools(tools))
Update ai/flow, micro chat, README, ai integration doc, Atlas Cloud
guide, and blog posts 3/8/9/10.
* feat(cli): add per-interface commands (registry, broker, store, config)
Map go-micro's core interfaces onto the CLI so the framework's
building blocks are inspectable and manipulable from the terminal:
micro registry list/get/watch service discovery
micro broker publish/subscribe pub/sub messaging
micro store read/write/delete/list persistence
micro config get/dump dynamic config (from env)
Structured pluggably in cmd/micro/resource: each interface is one
file exposing a Command() func, all wired through a commandFuncs
slice in resource.go. Adding a new resource command is a single
file plus one slice entry. Shared printJSON/fail helpers keep
output and errors consistent across commands.
Each command's verbs mirror the interface methods. Output is JSON
for structured data, raw for single values. Update README and
getting-started with an "inspecting the framework" section.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Move tool discovery/execution fully into the ai package as ai.Tools
(formerly ai.ToolSet), and simplify the usage model:
- NewTools(reg, ai.ToolClient(c)) takes the execution client as an
option instead of threading it through Handler(c) per call
- New ai.WithTools(tools) option wires the tool handler into a model
in one call, replacing ai.WithToolHandler(set.Handler(c))
- ai.DiscoverTools(reg) for one-shot discovery
Before:
set := ai.NewToolSet(reg)
list, _ := set.Discover()
m := ai.New(p, ai.WithToolHandler(set.Handler(client)))
After:
tools := ai.NewTools(reg, ai.ToolClient(client))
list, _ := tools.Discover()
m := ai.New(p, ai.WithTools(tools))
Update ai/flow, micro chat, README, ai integration doc, Atlas Cloud
guide, and blog posts 3/8/9/10.
Co-authored-by: Claude <noreply@anthropic.com>
Asim Aslam