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:

bash

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 [email protected] 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 [email protected] that the launch plan is ready","to":"comms"})
  📨 notify: [email protected] message="The launch plan is ready"

--- conductor reply ---
Created the three launch tasks and asked comms to notify [email protected].

Delegate-first

delegate is hybrid:

If to names a registered agent that owns the relevant services, the subtask is sent to it over RPC (Agent.Chat). That's what happens here — comms owns notify.
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.