Guides

• 1: Migration Guides
• 1.1: Add MCP to Existing Services
• 1.2: Migrating from gRPC
• 1.3: Migrating from v5 to v6
• 2: `micro loop` quickstart
• 3: 0→hero reference path
• 4: Adding an AI Provider to Go Micro
• 5: Agent Guardrails
• 6: Agent Integration Patterns
• 7: Agent Loops
• 8: Agent2Agent (A2A)
• 9: Agents and Workflows
• 10: Atlas Cloud Integration
• 11: Best Practices for Tool Descriptions
• 12: Building AI-Native Services
• 13: CLI & Gateway Guide
• 14: Contributing
• 15: Debugging your agent
• 16: Deployment Guide
• 17: Error Handling for AI Agents
• 18: Framework Comparison
• 19: Health Checks
• 20: Install troubleshooting
• 21: MCP Security Guide
• 22: MCP Troubleshooting
• 23: micro run - Local Development
• 24: Native gRPC Compatibility
• 25: No-secret first-agent transcript
• 26: Payments (x402)
• 27: Plan & Delegate
• 28: Provider Conformance Matrix
• 29: Quick Start
• 30: Testing Micro Services
• 31: The Agent Harness
• 32: Your First Agent

1 - Migration Guides

Migration Guides

Step-by-step guides for migrating to Go Micro from other frameworks.

Available Guides

• v5 to v6 - Upgrade to v6: new module path, TLS secure by default, NewService
• Add MCP to Existing Services - Make your services AI-accessible in 5 minutes
• From gRPC - Migrate from gRPC to Go Micro with minimal code changes

Coming Soon

We’re working on additional migration guides:

• From go-kit - Migrate from Go kit microservices framework
• From Standard Library - Upgrade from net/http and net/rpc
• From Gin/Echo - Transition from HTTP-only frameworks
• From Micro v3 - Upgrade from older Go Micro versions

Why Migrate to Go Micro?

• Pluggable Architecture - Swap components without changing code
• Zero Configuration - Works out of the box with sensible defaults
• Progressive Enhancement - Start simple, add complexity when needed
• Unified Abstractions - Registry, transport, broker, store all integrated
• Active Development - Regular updates and community support

Need Help?

• Check the Framework Comparison guide
• Review Architecture Decisions to understand design choices
• Ask questions in GitHub Discussions
• See the Contributing Guide to contribute new migration guides

1.1 - Add MCP to Existing Services

Add MCP to Existing Services

You have a working go-micro service and want to make it accessible to AI agents via MCP. This guide covers the three approaches, from simplest to most flexible.

Option 1: One-Line Setup (Recommended)

Add a single option to your service constructor:

import "go-micro.dev/v6/gateway/mcp"

func main() {
    service := micro.NewService("myservice",
        mcp.WithMCP(":3001"),  // Add this line
    )
    service.Init()
    // ... register handlers as before
    service.Run()
}

That’s it. Your service now exposes all registered handlers as MCP tools at http://localhost:3001/mcp/tools.

Option 2: Standalone MCP Gateway

If you want the MCP gateway to run separately from your services (e.g., in production with multiple services):

import "go-micro.dev/v6/gateway/mcp"

// Start MCP gateway alongside your service
go mcp.ListenAndServe(":3001", mcp.Options{
    Registry: service.Options().Registry,
})

This discovers all services in the registry and exposes them as tools.

Option 3: CLI (No Code Changes)

If you don’t want to modify your service code at all:

# Start your service normally
go run .

# In another terminal, start the MCP gateway
micro mcp serve --address :3001

The CLI approach uses the same registry to discover running services.

Improving Agent Experience

Once MCP is enabled, improve how agents interact with your service by adding documentation.

Step 1: Add Doc Comments

Before:

func (s *Users) Get(ctx context.Context, req *GetRequest, rsp *GetResponse) error {

After:

// Get retrieves a user by their unique ID. Returns the full user profile
// including email, display name, and account status.
//
// @example {"id": "user-123"}
func (s *Users) Get(ctx context.Context, req *GetRequest, rsp *GetResponse) error {

The MCP gateway automatically extracts these comments and presents them to agents as tool descriptions.

Step 2: Add Struct Tag Descriptions

type GetRequest struct {
    ID string `json:"id" description:"User ID in UUID format"`
}

type GetResponse struct {
    Name   string `json:"name" description:"Display name"`
    Email  string `json:"email" description:"Primary email address"`
    Active bool   `json:"active" description:"Whether the account is active"`
}

Step 3: Add Auth Scopes (Optional)

Restrict which agents can call which endpoints:

handler := service.Server().NewHandler(
    new(Users),
    server.WithEndpointScopes("Users.Delete", "users:admin"),
    server.WithEndpointScopes("Users.Get", "users:read"),
)

Then configure the MCP gateway with auth:

mcp.ListenAndServe(":3001", mcp.Options{
    Registry: service.Options().Registry,
    Auth:     authProvider,
    Scopes: map[string][]string{
        "myservice.Users.Delete": {"users:admin"},
        "myservice.Users.Get":    {"users:read"},
    },
})

Using with Claude Code

Once your service is running with MCP, connect it to Claude Code:

# Option A: stdio transport (recommended for local dev)
micro mcp serve

# Option B: Add to Claude Code settings

{
  "mcpServers": {
    "my-services": {
      "command": "micro",
      "args": ["mcp", "serve"]
    }
  }
}

Verify It Works

# List all tools the MCP gateway exposes
curl http://localhost:3001/mcp/tools | jq

# Test a specific tool
curl -X POST http://localhost:3001/mcp/call \
  -H 'Content-Type: application/json' \
  -d '{"tool": "myservice.Users.Get", "arguments": {"id": "user-123"}}'

What Doesn’t Need to Change

• Handler signatures - No changes needed to your RPC handlers
• Proto definitions - Existing protos work as-is
• Client code - Services calling each other still use the normal RPC client
• Tests - Existing tests continue to work
• Deployment - Add a port for MCP, everything else stays the same

Next Steps

• Tool Descriptions Guide - Write better descriptions for agents
• MCP Security Guide - Auth, scopes, and audit logging
• Agent Patterns - Architecture patterns for agent integration

1.2 - Migrating from gRPC

Step-by-step guide to migrating existing gRPC services to Go Micro.

Why Migrate?

Go Micro adds:

• Built-in service discovery
• Client-side load balancing
• Pub/sub messaging
• Multiple transport options
• Unified tooling

You keep:

• Your proto definitions
• gRPC performance (via gRPC transport)
• Type safety
• Streaming support

Migration Strategy

Phase 1: Parallel Running

Run Go Micro alongside existing gRPC services

Phase 2: Gradual Migration

Migrate services one at a time

Phase 3: Complete Migration

All services on Go Micro

Step-by-Step Migration

1. Existing gRPC Service

// proto/hello.proto
syntax = "proto3";

package hello;
option go_package = "./proto;hello";

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

// Original gRPC server
package main

import (
    "context"
    "log"
    "net"
    "google.golang.org/grpc"
    pb "myapp/proto"
)

type server struct {
    pb.UnimplementedGreeterServer
}

func (s *server) SayHello(ctx context.Context, req *pb.HelloRequest) (*pb.HelloReply, error) {
    return &pb.HelloReply{Message: "Hello " + req.Name}, nil
}

func main() {
    lis, _ := net.Listen("tcp", ":50051")
    s := grpc.NewServer()
    pb.RegisterGreeterServer(s, &server{})
    log.Fatal(s.Serve(lis))
}

2. Generate Go Micro Code

Update your proto generation:

# Install protoc-gen-micro
go install go-micro.dev/v6/cmd/protoc-gen-micro@latest

# Generate both gRPC and Go Micro code
protoc --proto_path=. \
  --go_out=. --go_opt=paths=source_relative \
  --go-grpc_out=. --go-grpc_opt=paths=source_relative \
  --micro_out=. --micro_opt=paths=source_relative \
  proto/hello.proto

This generates:

• hello.pb.go - Protocol Buffers types
• hello_grpc.pb.go - gRPC client/server (keep for compatibility)
• hello.pb.micro.go - Go Micro client/server (new)

3. Migrate Server to Go Micro

// Go Micro server
package main

import (
    "context"
    "go-micro.dev/v6"
    "go-micro.dev/v6/server"
    pb "myapp/proto"
)

type Greeter struct{}

func (s *Greeter) SayHello(ctx context.Context, req *pb.HelloRequest, rsp *pb.HelloReply) error {
    rsp.Message = "Hello " + req.Name
    return nil
}

func main() {
    svc := micro.NewService("greeter",
    )
    svc.Init()

    pb.RegisterGreeterHandler(svc.Server(), new(Greeter))

    if err := svc.Run(); err != nil {
        log.Fatal(err)
    }
}

Key differences:

• No manual port binding (Go Micro handles it)
• Automatic service registration
• Returns error, response via pointer parameter

4. Migrate Client

Original gRPC client:

conn, _ := grpc.Dial("localhost:50051", grpc.WithInsecure())
defer conn.Close()

client := pb.NewGreeterClient(conn)
rsp, err := client.SayHello(context.Background(), &pb.HelloRequest{Name: "John"})

Go Micro client:

svc := micro.NewService("client")
svc.Init()

client := pb.NewGreeterService("greeter", svc.Client())
rsp, err := client.SayHello(context.Background(), &pb.HelloRequest{Name: "John"})

Benefits:

• No hardcoded addresses
• Automatic service discovery
• Client-side load balancing
• Automatic retries

5. Keep gRPC Transport (Optional)

Use gRPC as the underlying transport:

import (
    "go-micro.dev/v6"
    "go-micro.dev/v6/client"
    "go-micro.dev/v6/server"
    grpcclient "go-micro.dev/v6/client/grpc"
    grpcserver "go-micro.dev/v6/server/grpc"
)

svc := micro.NewService("greeter",
    micro.Client(grpcclient.NewClient()),
    micro.Server(grpcserver.NewServer()),
)

This gives you:

• gRPC performance
• Go Micro features (discovery, load balancing)
• Compatible with existing gRPC clients

Streaming Migration

Original gRPC Streaming

service Greeter {
  rpc StreamHellos (stream HelloRequest) returns (stream HelloReply) {}
}

func (s *server) StreamHellos(stream pb.Greeter_StreamHellosServer) error {
    for {
        req, err := stream.Recv()
        if err == io.EOF {
            return nil
        }
        if err != nil {
            return err
        }
        
        stream.Send(&pb.HelloReply{Message: "Hello " + req.Name})
    }
}

Go Micro Streaming

func (s *Greeter) StreamHellos(ctx context.Context, stream server.Stream) error {
    for {
        var req pb.HelloRequest
        if err := stream.Recv(&req); err != nil {
            return err
        }
        
        if err := stream.Send(&pb.HelloReply{Message: "Hello " + req.Name}); err != nil {
            return err
        }
    }
}

Service Discovery Migration

Before (gRPC with Consul)

// Manually register with Consul
config := api.DefaultConfig()
config.Address = "consul:8500"
client, _ := api.NewClient(config)

reg := &api.AgentServiceRegistration{
    ID:      "greeter-1",
    Name:    "greeter",
    Address: "localhost",
    Port:    50051,
}
client.Agent().ServiceRegister(reg)

// Cleanup on shutdown
defer client.Agent().ServiceDeregister("greeter-1")

After (Go Micro)

import "go-micro.dev/v6/registry/consul"

reg := consul.NewConsulRegistry()
svc := micro.NewService("greeter",
    micro.Registry(reg),
)

// Registration automatic on Run()
// Deregistration automatic on shutdown
svc.Run()

Load Balancing Migration

Before (gRPC with custom LB)

// Need external load balancer or custom implementation
// Example: round-robin DNS, Envoy, nginx

After (Go Micro)

import "go-micro.dev/v6/selector"

// Client-side load balancing built-in
svc := micro.NewService("greeter",
    micro.Selector(selector.NewSelector(
        selector.SetStrategy(selector.RoundRobin),
    )),
)

Gradual Migration Path

1. Start with New Services

New services use Go Micro, existing services stay on gRPC.

// New Go Micro service can call gRPC services
// Configure gRPC endpoints directly
grpcConn, _ := grpc.Dial("old-service:50051", grpc.WithInsecure())
oldClient := pb.NewOldServiceClient(grpcConn)

2. Migrate Read-Heavy Services First

Services with many clients benefit most from service discovery.

3. Migrate Services with Fewest Dependencies

Leaf services are easier to migrate.

4. Add Adapters if Needed

// gRPC adapter for Go Micro service
type GRPCAdapter struct {
    microClient pb.GreeterService
}

func (a *GRPCAdapter) SayHello(ctx context.Context, req *pb.HelloRequest) (*pb.HelloReply, error) {
    return a.microClient.SayHello(ctx, req)
}

// Register adapter as gRPC server
s := grpc.NewServer()
pb.RegisterGreeterServer(s, &GRPCAdapter{microClient: microClient})

Checklist

• Update proto generation to include --micro_out
• Convert handler signatures (response via pointer)
• Replace grpc.Dial with Go Micro client
• Configure service discovery (Consul, Etcd, etc)
• Update deployment (remove hardcoded ports)
• Update monitoring (Go Micro metrics)
• Test service-to-service communication
• Update documentation
• Train team on Go Micro patterns

Common Issues

Port Already in Use

gRPC: Manual port management

lis, _ := net.Listen("tcp", ":50051")

Go Micro: Automatic or explicit

// Let Go Micro choose
svc := micro.NewService("greeter")

// Or specify
svc := micro.NewService("greeter",
    micro.Address(":50051"),
)

Service Not Found

Check registry:

# Consul
curl http://localhost:8500/v1/catalog/services

# Or use micro CLI
micro services

Different Serialization

gRPC uses protobuf by default. Go Micro supports multiple codecs.

Ensure both use protobuf:

import "go-micro.dev/v6/codec/proto"

svc := micro.NewService("greeter",
    micro.Codec("application/protobuf", proto.Marshaler{}),
)

Performance Comparison

Go Micro with gRPC transport performs similarly to pure gRPC

Next Steps

• Read Go Micro Architecture
• Explore Plugin System
• Check Production Patterns

Need Help?

• Examples
• GitHub Issues
• API Documentation

1.3 - Migrating from v5 to v6

v6 is a small, mechanical upgrade. The bulk of it is the Go module path; the behavioral changes are two, both with a one-line fix.

1. Module path: go-micro.dev/v6

Go puts the major version in the import path, so every import changes:

// before
import "go-micro.dev/v5"
import "go-micro.dev/v5/server"

// after
import "go-micro.dev/v6"
import "go-micro.dev/v6/server"

A repo-wide find/replace does it:

grep -rl 'go-micro.dev/v5' --include='*.go' . \
  | xargs sed -i 's|go-micro.dev/v5|go-micro.dev/v6|g'
go mod tidy

Update the CLI too:

go install go-micro.dev/v6/cmd/micro@latest

2. TLS is verified by default

In v5, TLS certificate verification was off by default (you opted in with MICRO_TLS_SECURE=true). In v6 it is on by default — the safe choice now that an agent, not just a human on a trusted network, can reach an endpoint.

• Production: nothing to do. Verification is on.
• MICRO_TLS_SECURE is gone — remove it; it’s the default now.
• Self-signed certs (local/dev): opt out with MICRO_TLS_INSECURE=true, or call tls.InsecureConfig() directly.

3. NewService is the service constructor

The service constructor is now symmetric with NewAgent and NewFlow:

service := micro.NewService("greeter", micro.Address(":8080"))
agent   := micro.NewAgent("task-mgr", micro.AgentServices("task"))
flow    := micro.NewFlow("onboard", micro.FlowTrigger("events.user.created"))

• micro.New("greeter", ...) still works as a deprecated alias — no rush, but prefer NewService.
• The old name-less form micro.NewService(micro.Name("greeter"), ...) is removed; pass the name positionally: micro.NewService("greeter", ...).

Generated services already use NewService — re-running micro new or micro run --prompt emits the v6 form.

That’s it

No other API changed. Agents, services, flows, the registry/broker/store interfaces, MCP, A2A, and x402 all work as they did — just under go-micro.dev/v6 and secure by default.

2 - `micro loop` quickstart

micro loop scaffolds the autonomous improvement loop that Go Micro uses on this repository: GitHub Actions workflows for planning, building, evaluation feedback, coherence, security, and release. Use it when you want a repository to continuously turn a ranked queue into small PRs while CI remains the merge gate.

1. Initialize the loop

Run the default loop from the repository root:

micro loop init

For every role used by Go Micro itself, scaffold all workflows:

micro loop init --roles all

The command writes:

• .github/loop/NORTH_STAR.md — the direction every increment should optimize.
• .github/loop/PRIORITIES.md — the ranked queue; the builder takes the top open issue.
• .github/loop/prompts/*.md — editable policy for planner, builder, triage, coherence, and security roles.
• .github/workflows/loop-*.yml — generated GitHub Actions mechanics.

Edit the files under .github/loop/ to steer the loop. Re-run micro loop init --roles all --force only when you want to regenerate workflow mechanics from the installed CLI.

2. Configure the dispatch token

The scheduled builder needs a repository secret containing a token from a user account that the coding agent will answer. Go Micro names that secret CODEX_TRIGGER_TOKEN by default. If you use another secret name, pass it when you initialize the loop:

micro loop init --agent @codex --token-secret LOOP_TOKEN --roles all

The token needs enough repository permission to open issues, comment, push branches, create pull requests, and enable auto-merge. Run gh auth setup-git in the environment that will push branches so git push uses the same credentials as gh.

Choosing an agent

The loop is agent-agnostic by design. Each run opens a fresh tracking issue and summons the agent with an @mention comment; the prompt file (.github/loop/prompts/<role>.md) is the instruction. Any coding agent that (a) responds to an @mention on an issue and (b) can open a PR with gh works — you select it with --agent.

• Codex (--agent @codex, the default). Point --token-secret at a PAT for the user account Codex follows, and make sure the Codex environment installs gh and runs gh auth setup-git. This is the path Go Micro itself runs on.
• Claude Code (--agent @claude). Install anthropics/claude-code-action in the repo so a workflow responds to @claude comments and runs Claude with a repo-scoped token; then the loop’s dispatch triggers it like any other mention.
• Any other mention-driven agent — pass its handle to --agent. The mechanics don’t care which agent it is.

Not supported by the mention model: agents triggered by issue assignment rather than a comment (e.g. GitHub Copilot’s coding agent, which you assign an issue to). The dispatch would need an “assign” adapter for those; it isn’t wired yet, so stick to mention-driven agents.

3. Make CI the gate

The loop should not be its own reviewer. Protect the default branch so PRs merge only after the required checks pass. At minimum, require the same commands the Go Micro loop verifies locally and in CI:

go build ./...
go test ./...
golangci-lint run ./...

If your repository has a harness or end-to-end grader, make that required too. Keep human approval requirements out of the autonomous path unless you intend the loop to pause for review.

4. Verify the wiring

After editing the North Star, queue, prompts, token secret, and branch protection, run:

micro loop verify

micro loop verify checks that the loop direction, queue, prompts, role workflows, and non-loop CI gate are present. Fix any reported missing items before relying on scheduled increments.

5. Operate the queue

Keep one ranked list in .github/loop/PRIORITIES.md. Each item should link a scoped issue and be small enough for one PR. The builder closes both the priority issue and the per-run tracker issue in the PR body, for example:

Closes #1234
Closes #5678

Use the North Star to keep the queue honest: favor small improvements that move developers through the services → agents → workflows lifecycle, and surface breaking API or brand/positioning decisions for humans instead of auto-merging them.

3 - 0→hero reference path

The 0→hero path is the maintained, no-secret reference for the Go Micro services → agents → workflows lifecycle. It ties the CLI inner loop and the runtime harness together so a contributor can prove the framework still works as one system, not as separate demos.

Use it when you want to answer: “Can I scaffold a service, run it locally, talk to an agent, inspect durable work, and reach the deployment boundary without cloud credentials?”

What the contract covers

Find the one-command entrypoint

After installing the CLI, ask micro for the maintained no-secret lifecycle command:

micro zero-to-hero

The command prints the exact harness command below plus the smaller runnable examples, so a new developer can discover the 0→hero path from CLI help instead of translating this guide by hand.

Run the runnable example

From the repository root, start with the smallest service-backed agent when you want the fastest no-secret success path:

go run ./examples/first-agent

Then run the support-desk example when you want to see the full lifecycle in one terminal:

go run ./examples/support

It starts typed services, a support agent, an event-driven intake flow, and an approval gate with a deterministic mock model. Change one service method, agent prompt, or guardrail decision and run it again to learn the system by modifying a working path.

Run the whole no-secret path

From the repository root:

make harness

For the focused ordered transcript only, run:

make zero-to-hero-transcript

That target runs the scaffold contract, the CLI boundary smoke tests, the 0→hero runtime harnesses, the event-driven agent-flow harness, and mock provider conformance. It is intentionally deterministic: no provider key, cloud account, SSH access, or remote service is required.

Run focused checks while iterating

Use the dedicated inner-loop target when you need the provider-free CLI contract in one focused command:

make inner-loop

Use the smaller checks when you are working on one seam:

# Install script and first-run CLI boundary, with no network or provider keys.
make install-smoke

# Scaffold → run/call contract.
go test ./cmd/micro/cli/new -run TestZeroToOne -count=1

# First-agent walkthrough boundary: scaffold, preflight, run, chat, inspect.
go test ./cmd/micro -run TestFirstAgentWalkthroughCLIBoundaries -count=1

# CLI inner-loop commands: run, chat, inspect, flow runs, deploy --dry-run.
go test ./cmd/micro -run TestZeroToHeroCLIBoundaries -count=1
go test ./cmd/micro/cli/deploy -run TestDeployDryRun -count=1
go test ./internal/harness/zero-to-hero-ci -run TestZeroToHeroDeployDryRunCommandSmoke -count=1

# Smallest no-secret service-backed first agent.
go test ./examples/first-agent -run TestRunFirstAgent -count=1

# Maintained 0→hero support-desk reference app.
go test ./examples/support -run 'TestRunSupportMockSmoke|TestZeroToHeroReadmeDocumentsLifecycle|TestZeroToHeroInspectTranscript' -count=1

# Durable services → agents → workflows reference scenarios.
./internal/harness/zero-to-hero-ci/run.sh

# Event-as-prompt agent flow.
go run ./internal/harness/agent-flow

# Cross-provider semantics with the deterministic mock provider.
make provider-conformance-mock

Reference scenarios

• examples/first-agent is the smallest no-secret service-backed agent: one notes service, one scoped assistant agent, and a deterministic mock model.
• examples/support is the runnable support-desk story: customers, tickets, notify, a support agent, an intake flow, and an approval gate in one no-secret example.
• examples/agent-plan-delegate is the smallest runnable planning/delegation example for multiple agents.
• internal/harness/plan-delegate is the compact 0→hero scenario: real task and notify services, a conductor agent, a comms agent, plan persistence, delegation, and a workflow handoff.
• internal/harness/universe boots a larger mini-world: inventory, payment, order confirmation, a concierge agent, durable checkpoint/resume, agent run history, flow run history, and A2A reachability.
• internal/harness/agent-flow shows the event-driven path where a user.created event prompts an agent to call services and complete onboarding.

Together these scenarios keep the North Star executable: services expose typed capabilities, agents use those capabilities with memory and guardrails, and workflows compose the work over time.

Keeping the guide honest

If you change the CLI inner loop, durable flow APIs, agent run history, or the provider/tool semantics, update this guide and the harness in the same PR. The point of 0→hero is not a polished sample app that drifts from reality; it is a CI-verifiable contract that the documented lifecycle still works.

4 - Adding an AI Provider to Go Micro

This guide walks you through implementing a new AI model provider for go-micro’s ai package. After following these steps your provider will be available via ai.New("yourprovider") and automatically usable by the MCP gateway, the agent playground, and any service that calls service.Model().

Overview

The ai package uses the same plugin pattern as the rest of go-micro: define an interface, register an implementation, and let users swap providers with a single import. All providers live under ai/<name>/.

Files you will create:

ai/
└── yourprovider/
    ├── yourprovider.go       # Provider implementation
    └── yourprovider_test.go  # Unit tests

Discover registered provider capabilities

Go Micro exposes the provider interfaces registered in the current build, so runtime tooling and docs can report what is actually available after blank imports are linked in:

for _, row := range ai.CapabilityRows() {
    fmt.Printf("%s: chat=%t image=%t video=%t stream=%t tool_stream=%t\n", row.Provider, row.Model, row.Image, row.Video, row.Stream, row.ToolStream)
}

The built-in providers currently register these capability interfaces:

Step 1: Implement the ai.Model Interface

Every provider must satisfy ai.Model:

type Model interface {
    Init(...Option) error
    Options() Options
    Generate(ctx context.Context, req *Request, opts ...GenerateOption) (*Response, error)
    Stream(ctx context.Context, req *Request, opts ...GenerateOption) (Stream, error)
    String() string
}

Skeleton

Create ai/yourprovider/yourprovider.go:

package yourprovider

import (
    "bytes"
    "context"
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "strings"

    "go-micro.dev/v6/ai"
)

func init() {
    ai.Register("yourprovider", func(opts ...ai.Option) ai.Model {
        return NewProvider(opts...)
    })
}

type Provider struct {
    opts ai.Options
}

func NewProvider(opts ...ai.Option) *Provider {
    options := ai.NewOptions(opts...)
    if options.Model == "" {
        options.Model = "your-default-model"
    }
    if options.BaseURL == "" {
        options.BaseURL = "https://api.yourprovider.com"
    }
    return &Provider{opts: options}
}

func (p *Provider) Init(opts ...ai.Option) error {
    for _, o := range opts {
        o(&p.opts)
    }
    return nil
}

func (p *Provider) Options() ai.Options { return p.opts }
func (p *Provider) String() string      { return "yourprovider" }

Generate

Generate is the core method. It must:

1. Convert req.Tools into the provider’s native tool format.
2. Send the request to the provider API.
3. Parse the response into ai.Response (text in Reply, tool calls in ToolCalls).
4. If p.opts.ToolHandler is set and there are tool calls, execute each tool and make a follow-up API call to get the final answer in Answer.

func (p *Provider) Generate(ctx context.Context, req *ai.Request, opts ...ai.GenerateOption) (*ai.Response, error) {
    // 1. Build provider-specific tool definitions
    var tools []map[string]any
    for _, t := range req.Tools {
        tools = append(tools, map[string]any{
            // Map to your provider's schema
            "name":        t.Name,
            "description": t.Description,
            "parameters":  map[string]any{
                "type":       "object",
                "properties": t.Properties,
            },
        })
    }

    // 2. Build the API request body
    apiReq := map[string]any{
        "model":    p.opts.Model,
        "messages": []map[string]any{
            {"role": "system", "content": req.SystemPrompt},
            {"role": "user", "content": req.Prompt},
        },
    }
    if len(tools) > 0 {
        apiReq["tools"] = tools
    }

    // 3. Call the API
    resp, rawMsg, err := p.callAPI(ctx, apiReq)
    if err != nil {
        return nil, err
    }

    // 4. No tool calls → return immediately
    if len(resp.ToolCalls) == 0 {
        return resp, nil
    }

    // 5. Execute tools and follow up
    if p.opts.ToolHandler != nil {
        // ... build follow-up messages with tool results ...
        followUpResp, _, err := p.callAPI(ctx, followUpReq)
        if err == nil && followUpResp.Reply != "" {
            resp.Answer = followUpResp.Reply
        }
    }

    return resp, nil
}

Stream

If streaming is not supported yet, return a clear error:

func (p *Provider) Stream(ctx context.Context, req *ai.Request, opts ...ai.GenerateOption) (ai.Stream, error) {
    return nil, fmt.Errorf("streaming not yet implemented for yourprovider")
}

API Helper

Use net/http directly — no external SDK needed:

func (p *Provider) callAPI(ctx context.Context, req map[string]any) (*ai.Response, map[string]any, error) {
    reqBody, err := json.Marshal(req)
    if err != nil {
        return nil, nil, fmt.Errorf("failed to marshal request: %w", err)
    }

    apiURL := strings.TrimRight(p.opts.BaseURL, "/") + "/v1/chat/completions"
    httpReq, err := http.NewRequestWithContext(ctx, "POST", apiURL, bytes.NewReader(reqBody))
    if err != nil {
        return nil, nil, fmt.Errorf("failed to create request: %w", err)
    }

    httpReq.Header.Set("Content-Type", "application/json")
    httpReq.Header.Set("Authorization", "Bearer "+p.opts.APIKey)

    httpResp, err := http.DefaultClient.Do(httpReq)
    if err != nil {
        return nil, nil, fmt.Errorf("API request failed: %w", err)
    }
    defer httpResp.Body.Close()

    respBody, _ := io.ReadAll(httpResp.Body)
    if httpResp.StatusCode != 200 {
        return nil, nil, fmt.Errorf("API error (%s): %s", httpResp.Status, string(respBody))
    }

    // Parse your provider's response format into ai.Response
    // ...
}

Step 2: Write Tests

Create ai/yourprovider/yourprovider_test.go. At minimum test:

• String() returns the correct name.
• Init() applies options.
• Default values are set when no options are provided.
• Generate() without API key returns an error.
• Stream() not implemented returns an error.

package yourprovider

import (
    "context"
    "testing"

    "go-micro.dev/v6/ai"
)

func TestProvider_String(t *testing.T) {
    p := NewProvider()
    if p.String() != "yourprovider" {
        t.Errorf("got %q, want %q", p.String(), "yourprovider")
    }
}

func TestProvider_Defaults(t *testing.T) {
    p := NewProvider()
    opts := p.Options()
    if opts.Model != "your-default-model" {
        t.Errorf("default model = %q, want %q", opts.Model, "your-default-model")
    }
    if opts.BaseURL != "https://api.yourprovider.com" {
        t.Errorf("default base URL = %q", opts.BaseURL)
    }
}

func TestProvider_Init(t *testing.T) {
    p := NewProvider()
    if err := p.Init(ai.WithModel("custom"), ai.WithAPIKey("key")); err != nil {
        t.Fatalf("Init: %v", err)
    }
    if p.Options().Model != "custom" {
        t.Errorf("model not updated")
    }
}

func TestProvider_Generate_NoAPIKey(t *testing.T) {
    p := NewProvider()
    _, err := p.Generate(context.Background(), &ai.Request{Prompt: "hi"})
    if err == nil {
        t.Error("expected error without API key")
    }
}

func TestProvider_Stream_NotImplemented(t *testing.T) {
    p := NewProvider()
    _, err := p.Stream(context.Background(), &ai.Request{Prompt: "hi"})
    if err == nil {
        t.Error("expected error for unimplemented streaming")
    }
}

Run:

go test ./ai/yourprovider/...

Step 3: Register the Provider

The init() function in your package calls ai.Register. Users enable your provider with a blank import:

import _ "go-micro.dev/v6/ai/yourprovider"

Then use it:

m := ai.New("yourprovider",
    ai.WithAPIKey("your-api-key"),
    ai.WithModel("your-model-name"),
)

resp, err := m.Generate(ctx, &ai.Request{
    Prompt:       "Hello!",
    SystemPrompt: "You are a helpful assistant",
})

Step 4: Update the README

Add your provider to the Supported AI Providers section in the project README.md. Follow the existing format:

### YourProvider

```go
m := ai.New("yourprovider",
    ai.WithAPIKey("your-key"),
    ai.WithModel("your-default-model"),
)

Default model: your-default-model Default base URL: https://api.yourprovider.com

Also add an entry in `ai/README.md` under "Supported Providers".

## Checklist

Before submitting your PR:

- [ ] `ai/yourprovider/yourprovider.go` implements `ai.Model`
- [ ] `init()` calls `ai.Register("yourprovider", ...)`
- [ ] `Generate()` handles tool calls via `ToolHandler` when set
- [ ] `ai/yourprovider/yourprovider_test.go` covers basics
- [ ] `go test ./ai/yourprovider/...` passes
- [ ] `go vet ./ai/yourprovider/...` is clean
- [ ] Provider added to `ai/README.md` under "Supported Providers"
- [ ] Provider added to project README.md under "Supported AI Providers"
- [ ] No new dependencies beyond `go-micro.dev/v6/ai` and stdlib (use
      `net/http` directly rather than an SDK)

## Design Notes

**Why `net/http` instead of an SDK?** Keeping providers dependency-free
means `go get go-micro.dev/v6` never pulls in heavy SDK trees. All
existing providers (Anthropic, OpenAI) use raw HTTP for the same reason.

**OpenAI-compatible APIs.** Many providers (Together, Groq, Fireworks,
Atlas Cloud, etc.) expose an OpenAI-compatible `/v1/chat/completions`
endpoint. In that case, users can often just use the `openai` provider
with `ai.WithBaseURL("https://api.yourprovider.com")`. A dedicated
provider package is only needed when the API differs or you want to set
provider-specific defaults.

**Tool call loop.** The current contract is one round of tool execution:
`Generate` calls tools via `ToolHandler`, feeds results back, and
returns the final answer. Multi-turn agentic loops are handled at a
higher level (e.g. the MCP gateway).

## Sponsorship

If you are an AI infrastructure company interested in becoming a
supported provider, we welcome both code contributions and sponsorships.
See the Supported AI Providers section in the project README for
current partners, and reach out via a GitHub issue or the Discord
community to discuss integration.

5 - Agent Guardrails

An autonomous agent decides its own actions at runtime, which is what makes it useful — and what makes it risky. The common failure modes are mundane: it loops, repeating the same call without making progress; it runs away, taking far more steps (and cost) than the task warrants; it takes an action that should have had a human or a policy in the way.

Go Micro separates orchestration (the model deciding what to do) from execution safety (whether a decided action is allowed to run). Every tool call an agent makes passes through one choke point, and that’s where the guardrails live — so they apply uniformly to service calls, custom tools, and delegate, without touching the model or your services.

The three agent guardrails

Stop on count — MaxSteps

Bounds the total number of tool executions in a single Ask. Once exceeded, further calls are refused and the model is told to stop and summarize. The blunt backstop against runaway cost.

micro.NewAgent("worker", micro.AgentMaxSteps(8))

Stop on repeat — LoopLimit

Bounds how many times the agent may call the same tool with the same arguments in one Ask. Identical repeated calls make no progress — MaxSteps only bounds them by total count, and a circuit breaker only catches failures, not a call that succeeds and is pointlessly repeated. When the limit is hit, the call is refused with a message that tells the model it’s looping, so it changes approach instead of spinning:

loop detected: you have already called “search.Search.Query” with the same arguments 3 times and the result will not change. Stop repeating it — try a different approach, or finish with what you have.

micro.NewAgent("worker", micro.AgentLoopLimit(3))

LoopLimit is on by default (a lenient 3) because identical repeated calls are never useful. Set AgentLoopLimit(0) to disable it.

Gate the action — ApproveTool

A hook called before each action runs. Return false to block it, with a reason that’s surfaced to the model. Use it for human-in-the-loop approval, spend limits, allow/deny lists, or any policy:

micro.NewAgent("worker", micro.AgentApproveTool(
    func(tool string, input map[string]any) (bool, string) {
        if strings.HasPrefix(tool, "billing_") {
            return false, "billing actions require sign-off"
        }
        return true, ""
    }))

ApproveTool is the integration seam

ApproveTool is also where an external policy engine plugs in. It sees every tool call before execution and can veto, so you can route decisions to your own rules, a budget service, or a third-party runtime-safety layer — without go-micro depending on it. Orchestration stays in the agent; execution safety stays in the hook. That separation is the whole point: you can swap the safety layer without touching the agent.

Wrap the whole execution — WrapTool

ApproveTool is a before gate. When you need the full lifecycle — timing, logging, metrics, retries, or inspecting the result — wrap the execution instead. WrapTool is the tool-side analogue of go-micro’s client.CallWrapper and server.HandlerWrapper: a wrapper takes the next handler and returns a new one, so code before the next(...) call runs before the tool, and code after runs after.

import "go-micro.dev/v6/ai"

func logging(next ai.ToolHandler) ai.ToolHandler {
    return func(ctx context.Context, call ai.ToolCall) ai.ToolResult {
        start := time.Now()
        res := next(ctx, call)
        log.Printf("id=%s tool=%s took=%s", call.ID, call.Name, time.Since(start))
        return res
    }
}

micro.NewAgent("worker", micro.AgentWrapTool(logging))

The handler signature is the same one every provider uses to execute a tool, and it mirrors a service handler — context first, the call in, a result out:

type ToolHandler func(ctx context.Context, call ToolCall) ToolResult
type ToolWrapper func(ToolHandler) ToolHandler

call.ID is a correlation ID carried through from the provider, so a wrapper can tie a tool call back to the request it came from. call.Scan(&v) decodes the arguments into a typed struct when you’d rather not work with the raw map.

Wrappers run outside the built-in guardrails, so they observe every call and its result — including a guardrail’s refusal. Multiple wrappers compose outermost-first (the first registered is the outer layer). A “before/after” hook is just the two halves of one wrapper, and retry is calling next again — so the wrapper is the single, composable seam for everything around execution, while MaxSteps, LoopLimit, and ApproveTool remain the named guardrails on top of it.

Reliability metadata

A wrapper has what it needs to build reliability tooling — loop handling, retry policies, auditing — without coupling to the agent:

• What happened — a guardrail refusal is tagged with a structured reason on the result, so you switch on it rather than parse a message:

  res := next(ctx, call)
  switch res.Refused {
  case ai.RefusedLoop:     // the agent repeated an identical call
  case ai.RefusedMaxSteps: // the step budget was exhausted
  case ai.RefusedApproval: // ApproveTool blocked it
  }
  

• Which run — ai.RunInfoFrom(ctx) returns a correlation id for the run, the agent’s name, and the parent run when the call came from a delegated sub-agent:

  if run, ok := ai.RunInfoFrom(ctx); ok {
      log.Printf("run=%s parent=%s agent=%s tool=%s", run.RunID, run.ParentID, run.Agent, call.Name)
  }
  

• Per-call detail — call.ID (correlation), call.Name; duration is time.Since(start) around next, and step/attempt counts are naturally counted by the wrapper itself (it sees every call).

Execution safety at the gateway

When agents reach tools through the MCP gateway, the gateway adds its own per-tool policies, independent of the agent:

• RateLimit — requests-per-second per tool.
• CircuitBreaker — a tool that fails repeatedly is temporarily blocked, so a failing dependency doesn’t cascade.

Together with the agent-side guardrails, that’s a full set: bound the count, stop the spin, gate the action, rate-limit and circuit-break at the edge.

Why it matters for autonomous agents

These are most important when no human is in the loop. An agent triggered by an event runs unattended — there’s no one to notice it looping or to approve a risky call. The guardrails are what let it fail safely and recover on its own rather than quietly burning resources.

See also

• Plan & Delegate — the agent’s built-in tools
• Agents and Workflows — where agents fit

6 - Agent Integration Patterns

This guide covers common patterns for integrating AI agents with Go Micro services, from single-agent workflows to multi-agent architectures.

Pattern 1: Single Agent with Multiple Services

The simplest and most common pattern. One AI agent has access to multiple microservices as MCP tools.

User → AI Agent → MCP Gateway → [Service A, Service B, Service C]

Setup

Run multiple services and expose them all through one MCP gateway:

users := micro.NewService("users", micro.Address(":8081"))
tasks := micro.NewService("tasks", micro.Address(":8082"))
notifications := micro.NewService("notifications", micro.Address(":8083"))

// Run all together as a modular monolith
g := micro.NewGroup(users, tasks, notifications)
g.Run()

With micro run, all services are discovered automatically via the registry, and the MCP tools endpoint at /mcp/tools exposes every endpoint from every service.

When to Use

• Most applications start here
• Agent needs to orchestrate across services (e.g., “create a task and notify the assignee”)
• You want the agent to choose which service to call based on the user’s request

Pattern 2: Scoped Agents

Different agents have access to different subsets of tools via scopes.

Customer Agent  → MCP Gateway → [orders:read, support:write]
Internal Agent  → MCP Gateway → [orders:*, users:*, billing:*]
Admin Agent     → MCP Gateway → [*]

Setup

Create tokens with different scopes for each agent:

// Gateway with scope enforcement
mcp.ListenAndServe(":3000", mcp.Options{
    Registry: reg,
    Auth:     authProvider,
    Scopes: map[string][]string{
        "billing.Billing.Charge":    {"billing:admin"},
        "users.Users.Delete":        {"users:admin"},
        "orders.Orders.List":        {"orders:read"},
        "orders.Orders.Create":      {"orders:write"},
        "support.Support.CreateTicket": {"support:write"},
    },
})

Then issue different tokens:

• Customer-facing agent token: scopes=["orders:read", "support:write"]
• Internal agent token: scopes=["orders:read", "orders:write", "users:read"]
• Admin agent token: scopes=["*"]

When to Use

• Different trust levels for different agents
• Customer-facing vs internal agents
• Compliance requirements (e.g., PCI, HIPAA)

Pattern 3: Agent as Service Consumer

Your Go Micro service itself calls an AI model to process data, using the ai package.

User → API → Your Service → AI Model (Claude/GPT)
                          → Other Services

Setup

import (
    "go-micro.dev/v6/ai"
    _ "go-micro.dev/v6/ai/anthropic"
)

type SummaryService struct {
    ai    ai.Model
    tasks *TaskClient
}

func NewSummaryService() *SummaryService {
    return &SummaryService{
        ai: ai.New("anthropic",
            ai.WithAPIKey(os.Getenv("ANTHROPIC_API_KEY")),
            ai.WithModel("claude-sonnet-4-20250514"),
        ),
    }
}

// Summarize generates an AI summary of a project's tasks.
// Returns a natural language summary of task status, blockers, and progress.
//
// @example {"project_id": "proj-1"}
func (s *SummaryService) Summarize(ctx context.Context, req *SummarizeRequest, rsp *SummarizeResponse) error {
    // Fetch tasks from another service
    tasks, err := s.tasks.List(ctx, req.ProjectID)
    if err != nil {
        return err
    }

    // Use AI to summarize
    resp, err := s.ai.Generate(ctx, &ai.Request{
        Prompt:       fmt.Sprintf("Summarize these tasks:\n%s", formatTasks(tasks)),
        SystemPrompt: "You are a concise project manager. Summarize task status in 2-3 sentences.",
    })
    if err != nil {
        return err
    }

    rsp.Summary = resp.Reply
    return nil
}

When to Use

• Your service needs to process natural language
• Generating summaries, classifications, or extractions
• Enriching data with AI before returning to the caller

Pattern 4: Agent with Tool Calling

An AI model calls your services as tools, with automatic tool execution via the ai package.

User → Your App → AI Model ←→ MCP Tools (your services)

Setup

import (
    "go-micro.dev/v6/ai"
    _ "go-micro.dev/v6/ai/anthropic"
)

// Define tools from your service endpoints
tools := []ai.Tool{
    {
        Name:        "create_task",
        Description: "Create a new task with title and assignee",
        Properties: map[string]any{
            "title":    map[string]any{"type": "string", "description": "Task title"},
            "assignee": map[string]any{"type": "string", "description": "Username"},
        },
    },
    {
        Name:        "list_tasks",
        Description: "List tasks filtered by status",
        Properties: map[string]any{
            "status": map[string]any{"type": "string", "description": "Filter: todo, in_progress, done"},
        },
    },
}

// Handle tool calls by routing to your services. The handler mirrors a
// go-micro RPC handler: context first, the call in, a result out.
toolHandler := func(ctx context.Context, call ai.ToolCall) ai.ToolResult {
    switch call.Name {
    case "create_task":
        var rsp CreateResponse
        err := client.Call(ctx, "tasks", "TaskService.Create", call.Input, &rsp)
        if err != nil {
            return ai.ToolResult{ID: call.ID, Content: fmt.Sprintf(`{"error": "%s"}`, err)}
        }
        b, _ := json.Marshal(rsp)
        return ai.ToolResult{ID: call.ID, Value: rsp, Content: string(b)}
    case "list_tasks":
        var rsp ListResponse
        err := client.Call(ctx, "tasks", "TaskService.List", call.Input, &rsp)
        if err != nil {
            return ai.ToolResult{ID: call.ID, Content: fmt.Sprintf(`{"error": "%s"}`, err)}
        }
        b, _ := json.Marshal(rsp)
        return ai.ToolResult{ID: call.ID, Value: rsp, Content: string(b)}
    }
    return ai.ToolResult{ID: call.ID, Content: `{"error": "unknown tool"}`}
}

m := ai.New("anthropic",
    ai.WithAPIKey(os.Getenv("ANTHROPIC_API_KEY")),
    ai.WithToolHandler(toolHandler),
)

// The model will automatically call tools and return the final answer
resp, err := m.Generate(ctx, &ai.Request{
    Prompt:       "Create a task for Alice to review the PR and tell me what tasks she has",
    SystemPrompt: "You are a helpful project management assistant",
    Tools:        tools,
})

fmt.Println(resp.Answer)
// "I've created a task for Alice to review the PR. She now has 3 tasks: ..."

When to Use

• Building a chatbot or assistant that manages your services
• The agent playground in micro run uses this pattern
• You want the AI to decide which tools to call and in what order

Pattern 5: Event-Driven Agent Triggers

Services emit events that trigger agent actions via the broker.

Service → Broker Event → Agent Handler → AI Model → Action

Setup

// Publisher: emit events from your service
broker.Publish("tasks.created", &broker.Message{
    Body: taskJSON,
})

// Subscriber: agent handler reacts to events
broker.Subscribe("tasks.created", func(p broker.Event) error {
    var task Task
    json.Unmarshal(p.Message().Body, &task)

    // Use AI to auto-assign based on task content
    resp, err := aiModel.Generate(ctx, &ai.Request{
        Prompt: fmt.Sprintf("Who should handle this task? Title: %s, Description: %s. Team: alice (frontend), bob (backend), charlie (devops)", task.Title, task.Description),
        SystemPrompt: "Reply with just the username of the best person to handle this task.",
    })

    // Auto-assign
    client.Call(ctx, "tasks", "TaskService.Update", map[string]any{
        "id": task.ID,
        "assignee": strings.TrimSpace(resp.Reply),
    }, nil)

    return nil
})

When to Use

• Automated workflows triggered by service events
• AI-powered routing, classification, or triage
• Background processing without user interaction

Pattern 6: Claude Code Integration

Developers use Claude Code with your services as MCP tools for local development workflows.

Developer → Claude Code → stdio MCP → [local services]

Setup

# Start services locally
micro run

# In another terminal, use Claude Code with your services
# Claude Code config (~/.claude/claude_desktop_config.json):

{
  "mcpServers": {
    "my-project": {
      "command": "micro",
      "args": ["mcp", "serve"]
    }
  }
}

Now in Claude Code:

"List all tasks that are blocked"
"Create a user account for the new hire"
"Check the health of all services"

When to Use

• Developer productivity workflows
• Managing services during development
• Testing and debugging with natural language

Pattern 7: LangChain / LlamaIndex Integration

Use the official Python SDKs to connect agent frameworks directly to your services.

LangChain

from langchain_go_micro import GoMicroToolkit

# Connect to MCP gateway
toolkit = GoMicroToolkit(
    base_url="http://localhost:3000",
    token="Bearer <token>",
)

# Get LangChain tools automatically
tools = toolkit.get_tools()

# Use with any LangChain agent
from langchain.agents import AgentExecutor, create_tool_calling_agent
agent = create_tool_calling_agent(llm, tools, prompt)
executor = AgentExecutor(agent=agent, tools=tools)
executor.invoke({"input": "Create a task for Alice"})

LlamaIndex

from go_micro_llamaindex import GoMicroToolkit

toolkit = GoMicroToolkit(
    base_url="http://localhost:3000",
    token="Bearer <token>",
)

# Use as LlamaIndex tools
tools = toolkit.to_tool_list()

# Use with a LlamaIndex agent
from llama_index.core.agent import ReActAgent
agent = ReActAgent.from_tools(tools, llm=llm)
agent.chat("What tasks are assigned to Bob?")

When to Use

• Python-based agent pipelines
• RAG (Retrieval-Augmented Generation) workflows with LlamaIndex
• Multi-step LangChain chains that orchestrate your services
• Teams that prefer Python for AI/ML work

Pattern 8: Standalone Gateway for Production

Run the MCP gateway as a separate, horizontally scalable process.

                    ┌──────────────────┐
Claude/GPT/Agent ──→│ micro-mcp-gateway │──→ Service A (consul)
                    │   (standalone)    │──→ Service B (consul)
                    └──────────────────┘──→ Service C (consul)

Setup

micro-mcp-gateway \
  --registry consul \
  --registry-address consul:8500 \
  --address :3000 \
  --auth jwt \
  --rate-limit 10 \
  --rate-burst 20 \
  --audit

Or via Docker:

docker run -p 3000:3000 ghcr.io/micro/micro-mcp-gateway \
  --registry consul \
  --registry-address consul:8500

When to Use

• Production deployments where you want the gateway to scale independently
• Multiple teams deploying services but sharing one MCP endpoint
• Enterprise environments needing centralized auth and audit

Pattern 9: Planning and Delegation

Built into the Agent abstraction. Every agent gets two harness tools — plan and delegate — with no extra setup. They are plain tools, not a separate graph runtime.

Conductor ──plan──→ (records ordered steps in memory)
            ──delegate──→ registered agent (RPC)  or  ephemeral sub-agent

Setup

Nothing to wire — the tools are added to every agent automatically. Guide their use with the prompt:

conductor := micro.NewAgent("conductor",
    micro.AgentServices("task"),
    micro.AgentPrompt(
        "For multi-step requests, call the plan tool first to record your steps. "+
            "For notifications, delegate to the \"comms\" agent (to: \"comms\")."),
    micro.AgentProvider("anthropic"),
)