Top Related Projects
A standard library for microservices.
The Go language implementation of gRPC. HTTP/2 based RPC
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.
High performance, minimalist Go web framework
Package gorilla/mux is a powerful HTTP router and URL matcher for building Go web servers with 🦍
⚡️ 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
- Defining a service:
import (
"github.com/micro/go-micro/v3"
)
service := micro.NewService(
micro.Name("greeter"),
micro.Version("latest"),
)
service.Init()
- 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
}
- 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
-
Install Go Micro:
go get github.com/micro/go-micro/v3 -
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) } } -
Run the service:
go run main.go
Competitor Comparisons
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.
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.
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.
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
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
⚡️ 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
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
Go Micro

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
- Why an Agent Harness
- Writing Services
- Building Agents â Plan & Delegate, Pluggable, Paid tools (x402), A2A
- Features
- CLI
- Autonomous improvement loop
- Multi-Service Projects
- Data Model
- AI Providers
- Examples
- Commercial Support
- Docs
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:
- 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.
micro agent demoâ print the provider-free first-agent demo command and next docs steps from the installed CLI.micro agent quickcheck(ormicro agent debug) â when scaffold â run â chat â inspect stalls, print the short recovery map before you dive into the full debugging guide.micro examplesâ print the maintained provider-free runnable examples in copy/paste order.micro zero-to-heroâ print the maintained one-command no-secret lifecycle harness and runnable examples.- Examples wayfinding index â choose the smallest no-secret first-agent, maintained 0âhero support reference, and next interop examples from one map.
- Smallest first-agent example â run one service-backed agent with a mock model and no provider key.
- No-secret first-agent transcript â run the maintained support agent with a mock model and see services â agents â workflows succeed without a key.
- Your First Agent â build a
service-backed agent and talk to it with
micro chat. - Debugging your agent â use
micro agent preflightbeforemicro run,micro agent doctoraftermicro run, thenmicro chatandmicro inspect agent <name>to recover run history, memory, and provider checks when the first conversation does something unexpected. - 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
| Feature | Details |
|---|---|
| Agents | micro.NewAgent() â intelligent layer that manages services |
| Plan & delegate | Built-in agent tools â plan multi-step work, delegate subtasks to other agents |
| Pluggable memory | Durable store-backed conversation memory by default; swap with AgentMemory |
| Custom tools | AgentTool â give an agent any function as a tool, beyond its services |
| Guardrails | MaxSteps (stop on count), LoopLimit (stop repeated no-progress calls), ApproveTool (human-in-the-loop) |
| Tool middleware | AgentWrapTool â wrap tool execution for logging, metrics, or retries (like client/server wrappers) |
| Workflows | micro.NewFlow() â event-driven; one step, ordered durable steps, or triggers an agent |
| Durable execution | Checkpointed flow steps survive a crash and resume where they stopped; store-backed by default, pluggable backend |
| MCP gateway | Every endpoint is an AI tool automatically |
| A2A gateway | Every 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 providers | Anthropic, OpenAI, Gemini, Groq, Mistral, Together, Atlas Cloud, MiniMax, Ollama (local + cloud) |
| Interactive console | micro run includes a chat console for talking to services |
| Service generation | micro run --prompt â describe a system, get running services |
Framework
| Feature | Details |
|---|---|
| Service registry | mDNS (default), Consul, etcd |
| RPC client/server | gRPC transport, load balancing, streaming |
| Pub/sub events | NATS, RabbitMQ, HTTP broker |
| Key-value store | File (bbolt), Postgres, NATS KV |
| Typed model layer | CRUD + queries, SQLite/Postgres backends |
| Everything swappable | All abstractions are Go interfaces |
Developer experience & deployment
| Feature | Details |
|---|---|
| Hot reload | micro run watches files, rebuilds on change |
| Templates | micro new --template crud/pubsub/api |
| One-command deploy | micro deploy user@server â SSH + systemd, no Docker |
CLI
| Command | Purpose |
|---|---|
micro run --prompt "..." | Generate services + agent, start with interactive console |
micro run | Dev mode: hot reload, gateway, interactive console |
micro run -d | Detached mode (no console) |
micro chat | Standalone chat (when not using micro run) |
micro agent list | List registered agents |
micro new myservice | Scaffold a service |
micro call service endpoint '{}' | Call a service or agent from the CLI |
micro build | Compile production binaries |
micro deploy user@server | Deploy 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:
| Provider | Default Model |
|---|---|
| Anthropic | claude-sonnet-4-20250514 |
| OpenAI | gpt-4o |
| Google Gemini | gemini-2.5-flash |
| Groq | llama-3.3-70b-versatile |
| Mistral | mistral-large-latest |
| Together AI | meta-llama/Llama-3.3-70B-Instruct-Turbo |
| Atlas Cloud | deepseek-ai/DeepSeek-V3-0324 |
| MiniMax | MiniMax-M3 |
| Ollama | llama3.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
- Getting Started
- AI Integration
- Your First Agent
- 0âhero Reference
- Agents and Workflows
- Agent Design
- Plan & Delegate
- Agent Guardrails
- Payments (x402)
- MCP & AI Agents
- Data Model
- Deployment
- Plugins
Package reference: https://pkg.go.dev/go-micro.dev/v6
Top Related Projects
A standard library for microservices.
The Go language implementation of gRPC. HTTP/2 based RPC
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.
High performance, minimalist Go web framework
Package gorilla/mux is a powerful HTTP router and URL matcher for building Go web servers with 🦍
⚡️ Express inspired web framework written in Go
Convert
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot