Convert Figma logo to code with AI

micro logogo-micro

A Go agent harness and service framework

22,964
2,410
22,964
8

Top Related Projects

27,436

A standard library for microservices.

23,012

The Go language implementation of gRPC. HTTP/2 based RPC

89,059

Gin is a high-performance HTTP web framework written in Go. It provides a Martini-like API but with significantly better performance—up to 40 times faster—thanks to httprouter. Gin is designed for building REST APIs, web applications, and microservices.

32,544

High performance, minimalist Go web framework

21,833

Package gorilla/mux is a powerful HTTP router and URL matcher for building Go web servers with 🦍

39,997

⚡️ Express inspired web framework written in Go

Quick Overview

Go Micro is a framework for distributed systems development in Go. It provides the core requirements for distributed systems development including RPC and event-driven communication. Go Micro abstracts away the details of distributed systems, allowing developers to focus on building business logic.

Pros

  • Simplifies the development of microservices in Go
  • Provides a pluggable architecture for flexibility and extensibility
  • Offers built-in service discovery, load balancing, and fault tolerance
  • Supports multiple protocols (gRPC, HTTP, etc.) and encodings

Cons

  • Learning curve for developers new to microservices architecture
  • May be overkill for simple applications or small projects
  • Documentation can be sparse or outdated in some areas
  • Community support might be less compared to some other frameworks

Code Examples

  1. Defining a service:
import (
    "github.com/micro/go-micro/v3"
)

service := micro.NewService(
    micro.Name("greeter"),
    micro.Version("latest"),
)
service.Init()
  1. Implementing a handler:
type Greeter struct{}

func (g *Greeter) Hello(ctx context.Context, req *proto.Request, rsp *proto.Response) error {
    rsp.Greeting = "Hello " + req.Name
    return nil
}
  1. Calling a service:
client := proto.NewGreeterService("greeter", service.Client())
rsp, err := client.Hello(context.Background(), &proto.Request{Name: "John"})
if err != nil {
    fmt.Println(err)
    return
}
fmt.Println(rsp.Greeting)

Getting Started

  1. Install Go Micro:

    go get github.com/micro/go-micro/v3
    
  2. Create a new service:

    package main
    
    import (
        "github.com/micro/go-micro/v3"
        "log"
    )
    
    func main() {
        service := micro.NewService(
            micro.Name("my.service"),
        )
    
        service.Init()
    
        if err := service.Run(); err != nil {
            log.Fatal(err)
        }
    }
    
  3. Run the service:

    go run main.go
    

Competitor Comparisons

27,436

A standard library for microservices.

Pros of kit

  • More flexible and modular architecture, allowing developers to pick and choose components
  • Extensive documentation and examples for various use cases
  • Strong focus on observability with built-in support for metrics, tracing, and logging

Cons of kit

  • Steeper learning curve due to its flexibility and numerous concepts
  • Requires more boilerplate code to set up services
  • Less opinionated, which may lead to inconsistencies across projects

Code Comparison

kit example:

func main() {
    svc := service.New(myService{})
    endpoints := endpoint.New(svc)
    http.ListenAndServe(":8080", endpoints)
}

go-micro example:

func main() {
    service := micro.NewService(micro.Name("my.service"))
    service.Init()
    micro.RegisterHandler(service.Server(), new(Handler))
    service.Run()
}

The kit example shows a more explicit setup process, while go-micro provides a more streamlined approach with built-in service discovery and registration. go-micro offers a higher level of abstraction, making it easier to get started but potentially less flexible for complex scenarios. kit's modular design allows for more customization but requires more setup code.

23,012

The Go language implementation of gRPC. HTTP/2 based RPC

Pros of grpc-go

  • More widely adopted and battle-tested in production environments
  • Extensive documentation and community support
  • Highly performant with efficient binary serialization

Cons of grpc-go

  • Steeper learning curve, especially for developers new to gRPC
  • Requires more boilerplate code for setup and configuration
  • Limited to gRPC-specific communication patterns

Code Comparison

grpc-go:

s := grpc.NewServer()
pb.RegisterGreeterServer(s, &server{})
lis, err := net.Listen("tcp", ":50051")
if err != nil {
    log.Fatalf("failed to listen: %v", err)
}
if err := s.Serve(lis); err != nil {
    log.Fatalf("failed to serve: %v", err)
}

go-micro:

service := micro.NewService(
    micro.Name("greeter"),
)
service.Init()
pb.RegisterGreeterHandler(service.Server(), &Greeter{})
if err := service.Run(); err != nil {
    fmt.Println(err)
}

Summary

grpc-go is a robust, high-performance gRPC implementation with extensive community support, while go-micro offers a more abstracted, microservices-oriented framework. grpc-go excels in raw performance and gRPC-specific features, whereas go-micro provides a more flexible, plugin-based architecture for building microservices with various communication protocols.

89,059

Gin is a high-performance HTTP web framework written in Go. It provides a Martini-like API but with significantly better performance—up to 40 times faster—thanks to httprouter. Gin is designed for building REST APIs, web applications, and microservices.

Pros of gin

  • Lightweight and fast HTTP web framework
  • Simple and intuitive API for building web applications
  • Extensive middleware support for easy customization

Cons of gin

  • Limited to HTTP-based applications
  • Lacks built-in support for microservices architecture
  • Requires additional libraries for advanced features like service discovery

Code Comparison

gin example:

r := gin.Default()
r.GET("/ping", func(c *gin.Context) {
    c.JSON(200, gin.H{"message": "pong"})
})
r.Run()

go-micro example:

service := micro.NewService(micro.Name("greeter"))
service.Init()
proto.RegisterGreeterHandler(service.Server(), new(Greeter))
service.Run()

Summary

gin is a lightweight HTTP web framework focused on simplicity and performance, while go-micro is a more comprehensive framework for building microservices. gin excels in creating HTTP-based applications quickly, but lacks built-in microservices features. go-micro provides a complete toolkit for microservices development, including service discovery and message encoding, but may be overkill for simple web applications. Choose gin for straightforward web projects and go-micro for complex, distributed systems.

32,544

High performance, minimalist Go web framework

Pros of Echo

  • Lightweight and minimalist web framework, focusing on HTTP routing and middleware
  • Excellent performance and low memory footprint
  • Simple and intuitive API, making it easy to learn and use

Cons of Echo

  • Limited built-in features compared to full-stack microservices frameworks
  • Less suitable for complex distributed systems and microservices architectures
  • Smaller ecosystem and fewer plugins/extensions available

Code Comparison

Echo:

e := echo.New()
e.GET("/", func(c echo.Context) error {
    return c.String(http.StatusOK, "Hello, World!")
})
e.Logger.Fatal(e.Start(":1323"))

go-micro:

service := micro.NewService(
    micro.Name("helloworld"),
)
service.Init()
proto.RegisterGreeterHandler(service.Server(), new(Greeter))
if err := service.Run(); err != nil {
    fmt.Println(err)
}

Key Differences

  • Echo is primarily a web framework, while go-micro is a microservices framework
  • go-micro provides more built-in features for distributed systems, such as service discovery and load balancing
  • Echo focuses on HTTP routing and middleware, while go-micro offers a broader range of communication protocols
  • go-micro has a steeper learning curve but offers more scalability for complex microservices architectures
  • Echo is better suited for simpler web applications or APIs, while go-micro excels in distributed systems
21,833

Package gorilla/mux is a powerful HTTP router and URL matcher for building Go web servers with 🦍

Pros of gorilla/mux

  • Lightweight and focused solely on HTTP routing
  • Easy to learn and use, with a straightforward API
  • Highly flexible and customizable for specific routing needs

Cons of gorilla/mux

  • Limited to HTTP routing, lacking built-in support for microservices architecture
  • Requires additional libraries for more complex features like service discovery or load balancing

Code Comparison

gorilla/mux:

r := mux.NewRouter()
r.HandleFunc("/api/{key}", ApiHandler)
r.HandleFunc("/", HomeHandler)
http.ListenAndServe(":8080", r)

go-micro:

service := micro.NewService(
    micro.Name("my.service"),
)
service.Init()
proto.RegisterGreeterHandler(service.Server(), new(Greeter))
service.Run()

Key Differences

  • go-micro is a comprehensive microservices framework, while gorilla/mux focuses on HTTP routing
  • go-micro provides built-in support for service discovery, load balancing, and message encoding
  • gorilla/mux offers more granular control over HTTP routing and middleware
  • go-micro is better suited for complex, distributed systems, while gorilla/mux excels in simpler web applications

Use Cases

  • Choose gorilla/mux for straightforward web applications or APIs with custom routing requirements
  • Opt for go-micro when building a microservices-based architecture with multiple interconnected services
39,997

⚡️ Express inspired web framework written in Go

Pros of Fiber

  • Extremely fast and lightweight web framework
  • Express-inspired API, making it easy for Node.js developers to transition
  • Built-in support for WebSocket, middleware, and static file serving

Cons of Fiber

  • Focused primarily on HTTP services, less suitable for complex microservices architectures
  • Smaller ecosystem and community compared to Go-Micro
  • Limited built-in support for service discovery and load balancing

Code Comparison

Fiber example:

app := fiber.New()

app.Get("/", func(c *fiber.Ctx) error {
    return c.SendString("Hello, World!")
})

app.Listen(":3000")

Go-Micro example:

service := micro.NewService(
    micro.Name("helloworld"),
)

service.Init()

proto.RegisterGreeterHandler(service.Server(), new(Greeter))

service.Run()

Go-Micro is more focused on building microservices with features like service discovery and message encoding, while Fiber is a lightweight web framework optimized for HTTP services. Go-Micro provides a more comprehensive toolkit for distributed systems, whereas Fiber excels in simplicity and performance for web applications. The choice between them depends on the specific requirements of your project.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Go Micro Go.Dev reference Discord

Go Micro is an agent harness and service framework for Go.

Overview

A harness is the runtime around an agent: the tools it can call, the memory it keeps, the guardrails that bound it, the workflows that trigger it, the services it depends on, and the protocols other agents use to reach it.

Go Micro gives you the harness as Go code. Build an agent and it gets a model, memory, tools, planning, delegation, guardrails, and service discovery; it is reachable over MCP and A2A. Write services and every endpoint becomes an AI-callable tool. Orchestrate the deterministic parts with durable flows. Agents, services, and flows share one runtime because an agent is a distributed system, and building one is building a service.

Sponsors

     

Want to support Go Micro and see your logo here? Become a sponsor — reach out on Discord.

Community

Questions, ideas, or just want to build alongside us? Join the Discord.

Commercial Support

Running Go Micro in production, or building on it and want help? Paid support, consulting, training, and retainers are available directly from the maintainer — and they're what keep the project maintained. See Support for the tiers, or open a request.

Contents

Quick Start

Install the CLI:

# Binary (no Go required)
curl -fsSL https://go-micro.dev/install.sh | sh

# Or with Go
go install go-micro.dev/v6/cmd/micro@latest

If install or PATH checks fail, use the install troubleshooting guide before scaffolding your first service.

Fastest start — no API key

Scaffold a service, run it, call it:

micro new helloworld
cd helloworld
micro run

Then in another terminal:

curl -X POST http://localhost:8080/api/helloworld/Helloworld.Call \
  -H 'Content-Type: application/json' -d '{"name":"World"}'

This install → scaffold → run → call path is covered by no-secret CI harnesses. To verify just the local installer and first-run CLI boundaries without network access or provider keys, use:

make install-smoke

To verify the focused CLI inner-loop contract — scaffold → run/chat/inspect → deploy dry-run — use:

make inner-loop

To run only the ordered 0→hero services → agents → workflows transcript that CI guards, use:

make zero-to-hero-transcript

To run the broader local contract (including that transcript, chat/inspect CLI boundaries, and deploy dry-run), use:

make harness

First agent on-ramp

After install and the first micro new/micro run smoke check, take the walkable agent path in this order:

  1. Install troubleshooting — verify the binary installer or go install, PATH, micro --version, and the no-secret smoke path before agent work.

Run make docs-wayfinding to verify the focused no-secret docs/CLI contract that keeps these README and website commands aligned with the installed CLI.

  1. micro agent demo — print the provider-free first-agent demo command and next docs steps from the installed CLI.
  2. micro agent quickcheck (or micro agent debug) — when scaffold → run → chat → inspect stalls, print the short recovery map before you dive into the full debugging guide.
  3. micro examples — print the maintained provider-free runnable examples in copy/paste order.
  4. micro zero-to-hero — print the maintained one-command no-secret lifecycle harness and runnable examples.
  5. Examples wayfinding index — choose the smallest no-secret first-agent, maintained 0→hero support reference, and next interop examples from one map.
  6. Smallest first-agent example — run one service-backed agent with a mock model and no provider key.
  7. No-secret first-agent transcript — run the maintained support agent with a mock model and see services → agents → workflows succeed without a key.
  8. Your First Agent — build a service-backed agent and talk to it with micro chat.
  9. Debugging your agent — use micro agent preflight before micro run, micro agent doctor after micro run, then micro chat and micro inspect agent <name> to recover run history, memory, and provider checks when the first conversation does something unexpected.
  10. 0→hero Reference — complete the services → agents → workflows loop with scaffold, run, chat, inspect, flow history, and deploy dry-run commands that match the maintained harness.

Autonomous improvement loop

Want the same services → agents → workflows lifecycle applied to your repository? micro loop scaffolds the autonomous improvement loop used by Go Micro itself: a North Star, ranked issue queue, role prompts, GitHub Actions workflows, and verification for CI-gated PRs.

micro loop init --roles all
micro loop verify

Before turning on the schedule, configure a dispatch token such as CODEX_TRIGGER_TOKEN, protect the default branch with required CI checks (go build ./..., go test ./..., and golangci-lint run ./... for this repository), and seed .github/loop/PRIORITIES.md with one scoped issue per increment. See the micro loop quickstart for the setup checklist and operating model.

Generate from a prompt — with an LLM key

Set a provider key, describe what you want, and the AI designs services, writes handlers, compiles, and starts them:

export ANTHROPIC_API_KEY=sk-ant-...   # or OPENAI_API_KEY, GEMINI_API_KEY, ...
micro run --prompt "a task management system with categories" --provider anthropic

The AI designs the architecture, you review it, then it generates handlers with real business logic, compiles them, and starts them:

Services:
  ● task — Task management with status tracking
  ● project — Project organization

Generate? [Y/n]

Micro
  Services:
    ● task
    ● project
  Agents:
    ◆ agent

Then talk to your services from the console:

> Create a project called Launch, then add three tasks to it

→ project_Project_Create({"name":"Launch"})
← {"record":{"id":"p1..."},"success":true}
→ task_Task_Create({"title":"Design specs","project_id":"p1..."})
→ task_Task_Create({"title":"Write code","project_id":"p1..."})
→ task_Task_Create({"title":"Ship it","project_id":"p1..."})

Created project Launch and added three tasks to it.

When you need a capability that doesn't exist, the agent generates a new service mid-conversation:

> I need to track shipping. Create a shipment for order 123 to London.

  ⚡ generating shipping service...
  ✓ shipping
  → shipping_Shipping_Create({"order_id":"123","destination":"London"})
  ← {"record":{"id":"xyz...","status":"pending"}}

  Created shipment for order 123 going to London.

Edit the generated code by hand at any time — re-running preserves your changes. Read more.

Why an Agent Harness

The first wave of agent frameworks helped developers put a model in a loop. The next problem is operating that loop: connecting it to real tools, scoping what it can touch, preserving state, routing work to specialists, recovering from failures, observing what happened, and letting other agents call it. That is harness work.

Go Micro's answer is to make the harness the same thing you already deploy:

  • Tools are services — endpoint metadata becomes tool schema; RPC executes the call.
  • Agents are services — they register, discover, load-balance, and expose Agent.Chat.
  • Workflows are durable code paths — use flows when the path is known; dispatch to agents when it is not.
  • Safety lives at execution — MaxSteps, LoopLimit, ApproveTool, and tool wrappers run where actions happen.
  • Interop is built in — MCP for tools, A2A for agents, x402 for paid tools.

Use Go Micro when the agent has to operate a system, not just answer a prompt.

Writing Services

Under the hood, a service is a struct with methods. Doc comments and @example tags become tool descriptions for AI agents automatically.

package main

import (
    "context"

    "go-micro.dev/v6"
)

type Request struct {
    Name string `json:"name"`
}

type Response struct {
    Message string `json:"message"`
}

type Say struct{}

// Hello greets a person by name.
// @example {"name": "Alice"}
func (h *Say) Hello(ctx context.Context, req *Request, rsp *Response) error {
    rsp.Message = "Hello " + req.Name
    return nil
}

func main() {
    service := micro.NewService("greeter")
    service.Handle(new(Say))
    service.Run()
}

Run it and everything is accessible — REST, gRPC, MCP, agent playground:

micro run
# Dashboard:   http://localhost:8080
# API:         http://localhost:8080/api/{service}/{method}
# Agent:       http://localhost:8080/agent
# MCP Tools:   http://localhost:8080/mcp/tools

You can also scaffold a service from a template:

micro new helloworld
micro new contacts --template crud

Building Agents

An Agent is a service with an LLM inside it. It has a proto-defined Agent.Chat RPC endpoint, registers in the registry, and is callable like any service:

agent := micro.NewAgent("task-mgr",
    micro.AgentServices("task", "project"),
    micro.AgentPrompt("You manage tasks and projects. You understand deadlines and priorities."),
    micro.AgentProvider("anthropic"),
)
agent.Run()

The agent discovers its services from the registry, scopes its tools to their endpoints, and maintains conversation memory in the store. It registers itself so micro chat and other agents can find it.

// Programmatic interaction
resp, _ := agent.Ask(ctx, "What tasks are overdue?")
fmt.Println(resp.Reply)

Multiple agents coordinate via RPC — each is a service with an Agent.Chat endpoint. micro chat routes to the right one.

micro agent list                    # list registered agents
micro call task-mgr Agent.Chat '{"message": "What tasks are overdue?"}'

Plan & Delegate

Every agent gets two built-in harness capabilities, exposed as tools — no extra setup or separate graph runtime:

  • plan — for multi-step work, the agent records an ordered plan in its store-backed memory and stays oriented across turns.
  • delegate — the agent hands a self-contained subtask to another agent. If a registered agent already owns the relevant services, the hand-off goes over RPC to that agent; otherwise a focused, short-lived sub-agent is created for the subtask with its own isolated context.

This keeps intelligence distributed: an agent doesn't need to know how to do everything, only who does. See examples/agent-plan-delegate.

// A sub-agent is just an agent — created with New, talked to with Ask.
// delegate-first: reuse a registered agent, or spin up a focused one.
resp, _ := agent.Ask(ctx, "Plan the launch, create the tasks, and have comms notify the owner.")

Batteries included, pluggable

Just as a service composes pluggable abstractions (registry, broker, store), an agent composes a model, memory, and tools — sane defaults out of the box, each swappable.

agent := micro.NewAgent("assistant",
    micro.AgentProvider("anthropic"),                 // model — swap the provider
    micro.AgentCompactMemory(40, 12),                 // memory — durable, summarized, recallable
    micro.AgentTool("weather", "Get the weather for a city",
        map[string]any{"city": map[string]any{"type": "string"}},
        func(ctx context.Context, in map[string]any) (string, error) {
            return getWeather(in["city"].(string))    // tools beyond your services — any function
        }),
    micro.AgentMaxSteps(8),                            // guardrails
)

Memory is durable and store-backed by default (Postgres, NATS KV, or file), so an agent picks up where it left off after a restart — or supply your own with AgentMemory. Long-running agents can opt into AgentCompactMemory(maxMessages, keepRecent): older turns are collapsed into a deterministic summary, recent turns stay verbatim, and relevant archived turns are recalled on future asks without replaying the whole conversation. Tools are your services automatically, plus any function you register with AgentTool.

Paid tools (x402)

Every endpoint is an AI-callable tool — and it can be a paid tool. Go Micro supports x402, the HTTP 402 payment standard for agents, so a tool can require a stablecoin payment and an agent can settle it autonomously. It's opt-in and carries no crypto in the framework: verification is delegated to a pluggable facilitator (Coinbase, Alchemy, self-hosted), so Base and Solana are just different facilitators.

# Charge for tool calls at the MCP gateway (off unless you set a pay-to address)
micro mcp serve --x402_pay_to 0xYourAddress --x402_network solana --x402_amount 10000
# Per-tool amounts via a config file
micro mcp serve --x402_config x402.json

See the Payments (x402) guide.

Reachable by other agents (A2A)

Within a Go Micro system, agents reach each other over RPC. To make them reachable by agents on other frameworks, Go Micro speaks the Agent2Agent (A2A) protocol. The A2A gateway discovers your agents from the registry, generates an Agent Card for each from its metadata — the same way the MCP gateway derives tools from service endpoints — and translates incoming A2A tasks to the agent's Agent.Chat RPC. No per-agent code: register an agent and it's reachable over A2A.

micro a2a serve --address :4000    # gateway: expose every registered agent over A2A
micro a2a list                     # agents and their Agent Card URLs

Or skip the gateway entirely — an agent can serve its own A2A endpoint directly, handling tasks in-process:

micro.NewAgent("task-mgr", micro.AgentServices("task"), micro.AgentA2A(":4000"))

It works both ways. To call an agent on another framework, an a2a.Client is wired into the two places that hand off work: flow.A2A(url) as a workflow step (the cross-framework Dispatch), and delegate to an http(s) URL from inside an agent.

MCP exposes your services as tools; A2A exposes your agents as agents. See the A2A guide.

Features

AI

FeatureDetails
Agentsmicro.NewAgent() — intelligent layer that manages services
Plan & delegateBuilt-in agent tools — plan multi-step work, delegate subtasks to other agents
Pluggable memoryDurable store-backed conversation memory by default; swap with AgentMemory
Custom toolsAgentTool — give an agent any function as a tool, beyond its services
GuardrailsMaxSteps (stop on count), LoopLimit (stop repeated no-progress calls), ApproveTool (human-in-the-loop)
Tool middlewareAgentWrapTool — wrap tool execution for logging, metrics, or retries (like client/server wrappers)
Workflowsmicro.NewFlow() — event-driven; one step, ordered durable steps, or triggers an agent
Durable executionCheckpointed flow steps survive a crash and resume where they stopped; store-backed by default, pluggable backend
MCP gatewayEvery endpoint is an AI tool automatically
A2A gatewayEvery agent is reachable over the Agent2Agent protocol; cards generated from the registry (micro a2a)
Payments (x402)Opt-in per-call payments for tools via the x402 standard; pluggable facilitator (Base, Solana, …)
9 LLM providersAnthropic, OpenAI, Gemini, Groq, Mistral, Together, Atlas Cloud, MiniMax, Ollama (local + cloud)
Interactive consolemicro run includes a chat console for talking to services
Service generationmicro run --prompt — describe a system, get running services

Framework

FeatureDetails
Service registrymDNS (default), Consul, etcd
RPC client/servergRPC transport, load balancing, streaming
Pub/sub eventsNATS, RabbitMQ, HTTP broker
Key-value storeFile (bbolt), Postgres, NATS KV
Typed model layerCRUD + queries, SQLite/Postgres backends
Everything swappableAll abstractions are Go interfaces

Developer experience & deployment

FeatureDetails
Hot reloadmicro run watches files, rebuilds on change
Templatesmicro new --template crud/pubsub/api
One-command deploymicro deploy user@server — SSH + systemd, no Docker

CLI

CommandPurpose
micro run --prompt "..."Generate services + agent, start with interactive console
micro runDev mode: hot reload, gateway, interactive console
micro run -dDetached mode (no console)
micro chatStandalone chat (when not using micro run)
micro agent listList registered agents
micro new myserviceScaffold a service
micro call service endpoint '{}'Call a service or agent from the CLI
micro buildCompile production binaries
micro deploy user@serverDeploy via SSH + systemd

Multi-Service Projects

Run multiple services together:

users := micro.NewService("users", micro.Address(":9001"))
orders := micro.NewService("orders", micro.Address(":9002"))

users.Handle(new(Users))
orders.Handle(new(Orders))

g := micro.NewGroup(users, orders)
g.Run()

Or use a micro.mu config file:

service users
    path ./users

service orders
    path ./orders
    depends users

Data Model

Typed persistence with CRUD and queries:

type User struct {
    ID    string `json:"id" model:"key"`
    Name  string `json:"name"`
    Email string `json:"email" model:"index"`
}

db := service.Model()
db.Register(&User{})
db.Create(ctx, &User{ID: "1", Name: "Alice", Email: "alice@example.com"})

var results []*User
db.List(ctx, &results, model.Where("email", "alice@example.com"))

Backends: memory (default), SQLite, Postgres.

AI Providers

Swap providers with a single import — same interface everywhere:

ProviderDefault Model
Anthropicclaude-sonnet-4-20250514
OpenAIgpt-4o
Google Geminigemini-2.5-flash
Groqllama-3.3-70b-versatile
Mistralmistral-large-latest
Together AImeta-llama/Llama-3.3-70B-Instruct-Turbo
Atlas Clouddeepseek-ai/DeepSeek-V3-0324
MiniMaxMiniMax-M3
Ollamallama3.2 (local)
m := ai.New("anthropic", ai.WithAPIKey(key))
resp, _ := m.Generate(ctx, &ai.Request{Prompt: "hello"})

Examples

New to agents? Follow the first-agent on-ramp, then use the examples index for the full services → agents → workflows map.

  • hello-world — Basic RPC service
  • multi-service — Multiple services in one binary
  • mcp — MCP integration with AI agents
  • first-agent — Smallest provider-free service-backed agent
  • agent-plan-delegate — Agent planning and multi-agent delegation
  • agent-durable — Checkpoint and resume an agent run without replaying completed tool side effects
  • grpc-interop — Call go-micro from any gRPC client

See all examples.

Docs

Package reference: https://pkg.go.dev/go-micro.dev/v6