Asim Aslam
c7657f73f4
goreleaser / goreleaser (push) Has been cancelled
* test(harness): read agent plan from the scoped store
The store-scoping change moved an agent's plan from the default table
key agent/{name}/plan to its own table (database "agent", table {name},
key "plan"). The plan-delegate harness tests still read the old key and
failed with 'not found'; read through store.Scope(mem, "agent", name)
like the agent does.
* docs: orient agents-first across README, landing, and docs overview
Lead with agents (then services and flows), surface MCP + A2A as the
interop story, and frame agents as services. Landing hero and feature
grid reordered agents-first with an A2A gateway card.
* v6: module path go-micro.dev/v6, TLS secure by default, NewService
Cut v6. Three breaking changes, bundled so the major bump is paid once:
- Module path go-micro.dev/v5 -> go-micro.dev/v6 across all imports + go.mod.
- TLS verification on by default (was off). MICRO_TLS_SECURE removed;
MICRO_TLS_INSECURE=true opts out for self-signed/dev.
- micro.NewService(name, opts...) is the canonical service constructor,
symmetric with NewAgent/NewFlow; micro.New kept as a deprecated alias;
the old name-less NewService(opts...) removed. Generators emit NewService.
Also ports the JWT auth token provider in-module (go-micro.dev/v6/auth/jwt/token
on golang-jwt/jwt/v5), dropping the v5-pinned github.com/micro/plugins/v5/auth/jwt
and the deprecated dgrijalva/jwt-go.
Docs/README/landing updated to v6 and @latest; v5->v6 migration guide added;
CHANGELOG cut as [6.0.0]. Blog posts left at their historical versions.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Agent Plan & Delegate
Demonstrates the two built-in agent capabilities — planning and delegation — in a small multi-agent system.
What it shows
| Capability | Tool | What happens |
|---|---|---|
| Planning | plan |
The conductor records an ordered list of steps before doing multi-step work. The plan is saved to its store-backed memory and shown back to it on later turns. |
| Delegation | delegate |
The conductor hands the notification step to a separate comms agent. Because comms is a registered agent, the hand-off goes over RPC — not an in-process call. |
Both plan and delegate are added to every agent automatically. There's no harness or graph to configure: they're plain tools the model calls, the same as any service endpoint.
Layout
task (service) Add, List ← owned by conductor
notify (service) Send ← owned by comms
comms (agent) manages notify
conductor (agent) manages task, delegates notifications to comms
Run
Set any provider key and run — the example auto-detects the provider:
export ANTHROPIC_API_KEY=sk-ant-... # or OPENAI_API_KEY, GEMINI_API_KEY, ...
go run main.go
(You can also force a provider with MICRO_AI_PROVIDER / MICRO_AI_API_KEY.)
The conductor is asked to "Create three launch tasks: Design, Build, and Ship. Then make sure owner@acme.com is notified that the launch plan is ready."
Expected shape of the run:
--- conductor tool calls ---
→ plan({"steps":[{"task":"create Design task","status":"pending"}, ...]})
→ task_TaskService_Add({"title":"Design"})
→ task_TaskService_Add({"title":"Build"})
→ task_TaskService_Add({"title":"Ship"})
→ delegate({"task":"Notify owner@acme.com that the launch plan is ready","to":"comms"})
📨 notify: to=owner@acme.com message="The launch plan is ready"
--- conductor reply ---
Created the three launch tasks and asked comms to notify owner@acme.com.
Delegate-first
delegate is hybrid:
- If
tonames a registered agent that owns the relevant services, the subtask is sent to it over RPC (Agent.Chat). That's what happens here —commsownsnotify. - Otherwise a focused ephemeral sub-agent is created for the subtask with a fresh, isolated context, asked the task, and torn down. Ephemeral sub-agents have no built-in tools, so they can't re-delegate.
This keeps intelligence distributed: the conductor doesn't need to know how to send notifications — it knows who does.