2026-07-18 09:48 UTCIn-site rewrite5 min readUpdated: 2026-07-18 10:23 UTC

Go Micro – An agent harness and service framework in Go

Go Micro is an agent harness and service framework for Go. It turns services into AI-callable tools, agents into services with LLMs, and workflows into durable code paths. It supports MCP, A2A, and x402 protocols, with built-in planning, delegation, and safety layers.

SourceHacker News AIAuthor: asim

Uh oh!

There was an error while loading. Please reload this page.

Notifications You must be signed in to change notification settings

Fork 2.4k

Star 23k

BranchesTags

Open more actions menu

Folders and files

NameName

Last commit message

Last commit date

Latest commit

History

4,920 Commits

.github

.vscode

agent

auth

broker

cache

client

cmd

codec

config

contrib

debug

deploy/kubernetes

errors

events

examples

flow

gateway

health

internal

logger

metadata

model

registry

selector

server

service

store

transport

web

wrapper

.editorconfig

.gitignore

.golangci.yaml

.goreleaser.yaml

AGENTS.md

CHANGELOG.md

CLAUDE.md

CODEX.md

CONTRIBUTING.md

Dockerfile

LICENSE

Makefile

README.md

ROADMAP.md

SECURITY.md

SUPPORT.md

event.go

go.mod

go.sum

logo.png

micro.go

options.go

Repository files navigation

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

Community: questions, ideas, or just want to build alongside us? Join the Discord.

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.

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 (or micro 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 preflight before micro run, micro agent doctor after micro run, then micro chat and micro inspect agent 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 w

[truncated for AI cost control]