docs(priorities): drop completed examples task

The DevRel pass now keeps the changelog living instead of letting it drift:
each daily run reconciles a Keep-a-Changelog `[Unreleased]` section against the
PRs that actually merged (user-facing entries only; internal loop/CI churn
skipped) and rolls it into a dated version heading whenever loop-release cuts a
new v6.MINOR.PATCH tag. When enough user-facing work has accumulated (roughly a
week's worth, not a near-empty post every day) it also drafts a "what's new"
changelog blog post narrating what shipped.

Autonomy boundary preserved: CHANGELOG.md upkeep is a safe factual change and
rides the auto-merged DevRel PR; the changelog blog post is opened as its own
PR but left for the human to review/merge, since blog voice stays with the human.

Also fix the CHANGELOG preamble: it claimed calendar versions (YYYY.MM) while
tags are semver (v6.MINOR.PATCH). Correct it, add an `[Unreleased]` section
seeded from real recent work, and note the historical 2026.0x headings.


Claude-Session: https://claude.ai/code/session_01CmdEY7pYmV5zzwCjNJ4ykL

Co-authored-by: Claude <noreply@anthropic.com>

.github/workflows/loop-devrel.yml

@@ -6,10 +6,16 @@ name: "Loop: DevRel"
 # code; this keeps the story coherent: docs/website aligned, README crisp, and
 # a steady supply of things worth blogging about.
 #
+# It also keeps the CHANGELOG living: each run reconciles the `[Unreleased]`
+# section of CHANGELOG.md against what actually merged (rolling it into a dated
+# version heading whenever a new tag was cut), and — when enough has shipped —
+# drafts a "what's new" changelog blog post narrating it.
+#
 # Like the increment loop it opens a fresh issue and dispatches Codex via
 # CODEX_TRIGGER_TOKEN (Codex ignores Actions-bot comments). Autonomy boundary:
-# SAFE factual-alignment and crispness fixes auto-merge; brand/positioning copy
-# and blog drafts are surfaced in the report for the human, never auto-merged.
+# SAFE factual-alignment and crispness fixes — including CHANGELOG.md upkeep —
+# auto-merge; brand/positioning copy and the changelog blog post are opened as a
+# PR but left for the human to review/merge (blog voice stays with the human).
 
 on:
   workflow_dispatch: {}
@@ -40,8 +46,16 @@ jobs:
           fi
           ISSUE_URL=$(gh issue create --repo "$REPO" \
             --title "DevRel coherence review #$RUN_NUMBER" \
-            --body "Daily DevRel / coherence pass over README, website (landing + docs), and the blog. North Star: internal/docs/THESIS.md.")
+            --body "Daily DevRel / coherence pass over README, website (landing + docs), and the blog, plus CHANGELOG.md upkeep and a changelog blog post. North Star: internal/docs/THESIS.md.")
           ISSUE_NUM="${ISSUE_URL##*/}"
           echo "Opened issue #$ISSUE_NUM — dispatching Codex (DevRel)."
           gh issue comment "$ISSUE_NUM" --repo "$REPO" --body \
-          "@codex Act as DevRel for go-micro. Audit the PUBLIC surface — \`README.md\`, \`internal/website/\` (landing \`index.html\` + \`docs/\`), and the blog under \`internal/website/blog/\` — for coherence with the North Star in internal/docs/THESIS.md (an agent harness and service framework; the services → agents → workflows lifecycle). Look for: (1) places where README / website / docs contradict each other, are stale, or describe behavior that has since changed (cross-check against the code and recent merged PRs / CHANGELOG.md); (2) whether the README is crisp and leads with the harness positioning; (3) one to three genuinely blog-worthy items from recently shipped work. Then do BOTH of these: (A) post a concise findings report as a comment on this issue (#$ISSUE_NUM) — what is aligned, what drifted, what you fixed, and the blog ideas; (B) for SAFE factual-alignment and crispness fixes only (NOT brand/marketing/positioning rewrites), open one PR: \`git switch -c codex/devrel-$ISSUE_NUM\`, \`git push -u origin codex/devrel-$ISSUE_NUM\`, \`gh pr create --base master --label codex --title \"<title>\" --body \"<summary, including 'Closes #$ISSUE_NUM'>\"\`, then \`gh pr merge --squash --auto --delete-branch\`. Leave brand/positioning copy and blog drafts for the human — describe them in the report, do NOT open auto-merging PRs for them. Do not use the make_pr tool (it is a no-op stub). If you touch code, verify go build/test/golangci-lint. Stay out of breaking public-API changes."
+          "@codex Act as DevRel for go-micro. Do FOUR things this run.
+
+          COHERENCE AUDIT. Audit the PUBLIC surface — \`README.md\`, \`internal/website/\` (landing \`index.html\` + \`docs/\`), and the blog under \`internal/website/blog/\` — for coherence with the North Star in internal/docs/THESIS.md (an agent harness and service framework; the services → agents → workflows lifecycle). Look for: (1) places where README / website / docs contradict each other, are stale, or describe behavior that has since changed (cross-check against the code and recent merged PRs); (2) whether the README is crisp and leads with the harness positioning; (3) one to three genuinely blog-worthy items from recently shipped work.
+
+          CHANGELOG UPKEEP (this is a SAFE factual task — it goes in the auto-merged PR). Keep CHANGELOG.md living, in [Keep a Changelog](https://keepachangelog.com/) format with the newest content at the top under \`## [Unreleased]\`. (a) Enumerate PRs merged to master since the last CHANGELOG update — \`gh pr list --repo $REPO --state merged --base master --limit 60 --json number,title,mergedAt,labels\` — and compare against what CHANGELOG.md already lists. (b) For each genuinely user-facing change not yet recorded (new capability, behavior/API change, notable fix — SKIP purely internal loop/CI/priorities-refresh churn), add a concise entry under the right \`### Added\` / \`### Changed\` / \`### Fixed\` / \`### Documentation\` subheading of \`## [Unreleased]\`, phrased for a user (what it does, which package), not a commit subject. (c) If a new \`v6.MINOR.PATCH\` tag has been cut since the last run (\`git fetch --tags --force\`; compare the newest \`v6.*\` tag to the versions already in CHANGELOG.md), RENAME the current \`## [Unreleased]\` heading to \`## [MINOR.PATCH] - <Month YYYY>\` for that tag and open a fresh empty \`## [Unreleased]\` above it. Keep it accurate — do not invent entries; if nothing user-facing merged, leave [Unreleased] as-is.
+
+          CHANGELOG BLOG POST (blog voice — open a PR but do NOT auto-merge; leave it for the human). If — and only if — enough user-facing work has accumulated since the last changelog post to be worth reading (a meaningful batch, roughly a week's worth; do NOT post an almost-empty update every day), draft a short 'What's new in Go Micro' post that narrates what shipped in plain language (grouped by theme, linking the docs/examples, closing with install/upgrade). Create it as the next-numbered file in \`internal/website/blog/\` (find the highest N, use N+1), mirroring the frontmatter (layout/title/permalink/description) and the post-nav 'previous post' link of the latest existing post, and add an entry at the TOP of \`internal/website/blog/index.html\`. Base it strictly on the CHANGELOG — no speculation.
+
+          THEN do all of these: (A) post a concise findings report as a comment on this issue (#$ISSUE_NUM) — what is aligned, what drifted, what you fixed, the CHANGELOG entries you added, whether you drafted a changelog post (and why / why not), and any other blog ideas. (B) Open ONE auto-merging PR for the SAFE factual work only — coherence/crispness fixes AND the CHANGELOG.md update (NOT brand/marketing/positioning rewrites, NOT the blog post): \`git switch -c codex/devrel-$ISSUE_NUM\`, \`git push -u origin codex/devrel-$ISSUE_NUM\`, \`gh pr create --base master --label codex --title \"<title>\" --body \"<summary, including 'Closes #$ISSUE_NUM'>\"\`, then \`gh pr merge --squash --auto --delete-branch\`. (C) If you drafted a changelog blog post, open it as a SEPARATE PR on its own branch (\`codex/devrel-blog-$ISSUE_NUM\`) with a title prefixed 'blog:' and do NOT enable auto-merge — leave it open for the human to review and merge. Do the same (separate, non-auto-merged PR or just a report note) for any brand/positioning copy. Do not use the make_pr tool (it is a no-op stub). If you touch code, verify go build/test/golangci-lint. Stay out of breaking public-API changes."

CHANGELOG.md

@@ -2,8 +2,33 @@
 
 All notable changes to Go Micro are documented here.
 
-Format follows [Keep a Changelog](https://keepachangelog.com/). Go Micro uses
-calendar-based versions (YYYY.MM) for the AI-native era.
+Format follows [Keep a Changelog](https://keepachangelog.com/) and versions
+follow [Semantic Versioning](https://semver.org/), matching the git tags and
+[GitHub releases](https://github.com/micro/go-micro/releases) (`v6.MINOR.PATCH`).
+Patch releases are cut automatically as the loop merges improvements; the
+`[Unreleased]` section below is kept current between tags and rolled into the
+next version when it ships.
+
+> Earlier `2026.0x` headings are historical calendar-style markers from before
+> v6 tagging; they are kept for continuity and not reused.
+
+---
+
+## [Unreleased]
+
+### Added
+- **Retrieval-backed agent memory** — agents can recall relevant prior turns by similarity, not just the recent window, with a summarizer hook that compacts older history so long conversations stay in budget. (`agent/`)
+- **Scheduled flows** — a flow can run an agent (or any step) on a cron-style schedule, with the dispatch traced end to end. (`flow/`)
+- **Flow verification/grader loop** — a workflow can grade its own step output against a rubric and retry until it passes, plus run-trace analysis to surface where a flow spends its time. (`flow/`)
+- **A2A streaming & continuity** — outbound agent streaming flows through the A2A binding (`message/stream`), with `tasks/resubscribe` and `input-required` handoffs for multi-turn interop. (`gateway/a2a/`)
+
+### Changed
+- **Agent tool-call resilience** — opt-in retries around agent tool calls, and a fallback that executes tool calls emitted as text by weaker models so they still make progress. (`agent/`)
+- **Hardened agent durability** — terminal failure statuses are classified and surfaced, and durable resume-after-restart is covered by tests. (`agent/`)
+
+### Documentation
+- **"Your first agent" walkthrough** and a canonical 0-to-hero reference path, lowering the on-ramp from install to a running agent. (`internal/website/docs/`)
+- **Discord** linked prominently across the README, website nav/footer, and docs. (`https://discord.gg/G8Gk5j3uXr`)
 
 ---
 

internal/docs/CONTINUOUS_IMPROVEMENT.md

@@ -23,7 +23,7 @@ Actions instead of subagents. Each role is a workflow:
 | **Generator** | `loop-builder.yml` — *Loop: Builder (Generator)* | Builds the top open queue item as a single-concern PR (via Codex) and self-merges on green CI. Does the work. |
 | **Evaluator** | `harness.yml` — *Harness (E2E)*, plus the CI gate (`tests.yaml`, `lint.yaml`) | Grades every change: the mock harness + unit/lint on each push/PR, and real-model conformance hourly. A *separate* grader — never the generator judging itself. |
 | **Evaluator → feedback** | `loop-triage.yml` — *Loop: Triage (Evaluator feedback)* | On harness failure, root-causes, dedupes, and files scoped fix issues back into the planner's queue. The hill-climbing feedback path. |
-| **Coherence** | `loop-devrel.yml` — *Loop: DevRel* | Keeps README/website/docs/blog aligned with the North Star. |
+| **Coherence** | `loop-devrel.yml` — *Loop: DevRel* | Keeps README/website/docs/blog aligned with the North Star, keeps `CHANGELOG.md` living (reconciling `[Unreleased]` against merged PRs and rolling it into version headings as tags cut), and drafts the changelog blog post. |
 | **Release** | `loop-release.yml` — *Loop: Release (daily patch)* | Cuts a daily patch tag when master has new commits, so the *installable* framework tracks the loop's improvements (triggers `release.yml`/goreleaser). Minor/major bumps stay with the human. |
 
 Generation is separated from evaluation on purpose: an agent grading its own work
@@ -149,10 +149,17 @@ output) but produce direction and coherence, not just code.
 
 - **DevRel — daily** (`.github/workflows/loop-devrel.yml`). Audits the public
   surface (README, website landing + docs, blog) for coherence with the North
-  Star, README crispness, and blog-worthy material. **Autonomy boundary:** safe
-  factual-alignment and crispness fixes auto-merge like any increment;
-  brand/positioning copy and blog drafts are *surfaced in a report* for the
-  human, never auto-merged.
+  Star, README crispness, and blog-worthy material. It also keeps `CHANGELOG.md`
+  living: each run reconciles the `[Unreleased]` section against the PRs that
+  actually merged (Keep-a-Changelog format, user-facing entries only — internal
+  loop/CI churn is skipped), and rolls `[Unreleased]` into a dated version
+  heading whenever a new `v6.MINOR.PATCH` tag has been cut (by `loop-release`).
+  When enough user-facing work has accumulated (roughly weekly, not a near-empty
+  post every day) it also drafts a "what's new" changelog blog post narrating it.
+  **Autonomy boundary:** safe factual-alignment and crispness fixes — *including
+  the `CHANGELOG.md` upkeep* — auto-merge like any increment; brand/positioning
+  copy and the changelog blog post are opened as a PR (or surfaced in the report)
+  and left for the human to review/merge — blog voice stays with the human.
 - **Architect — continuous (hourly)** (`.github/workflows/loop-architect.yml`).
   The *founder lens*, running alongside the builders. Each run it **tracks live
   state** (what just merged, what's in flight), **prioritizes the roadmap**

internal/docs/PRIORITIES.md

@@ -21,15 +21,13 @@ changes, architectural rewrites. Those go to the human.
 
 ## Work queue (ranked)
 
-1. **Lead install docs with `@latest` now that the phantom-module retraction is published** ([#3565](https://github.com/micro/go-micro/issues/3565)) — install friction blocks every later experience. Make the first command current, boring, and consistent across README/website/docs so revived usage does not stall before scaffold/run.
-2. **Surface runnable examples from getting-started and the guides** ([#3562](https://github.com/micro/go-micro/issues/3562)) — the blog canon now has a concrete support-agent story, but developers need obvious links from docs into runnable code. Tie examples to the 0→1 and 0→hero paths so “read → run → modify one thing” is discoverable.
-3. **Reorder the guides nav to lead with doing before concepts** ([#3563](https://github.com/micro/go-micro/issues/3563)) — the framework is deep, but the first impression should be action: quickstart, first agent, examples, debugging, then architecture. This is small, CI-checkable wayfinding work with outsized adoption value.
-4. **Add a “Debugging your agent” guide focused on the dev workflow** ([#3564](https://github.com/micro/go-micro/issues/3564)) — the inner loop is scaffold → run → chat → inspect → deploy. Document how to see tool calls, run history, provider failures, guardrail refusals, and flow handoffs before adding more depth that users cannot diagnose.
-5. **Prevent duplicate tool side effects in the plan/delegate harness** ([#3559](https://github.com/micro/go-micro/issues/3559)) — correctness still matters where it protects real user trust. Plan/delegate is central to the services → agents lifecycle, and duplicate side effects undermine the “agent as dependable service” story.
-6. **Expose `fallback_echo` during A2A streaming fallback conformance** ([#3560](https://github.com/micro/go-micro/issues/3560)) — keep interop conformance trustworthy without letting it dominate the adoption queue. This is scoped, testable, and protects the A2A promise developers see in the README and site.
-7. **Propagate agent run cancellation and deadlines through model and tool calls** ([#3544](https://github.com/micro/go-micro/issues/3544)) — after the on-ramp items, the highest-value remaining Now-phase resilience gap is predictable failure semantics across agent runs, model calls, tool calls, plan/delegate, and flow handoffs. Tool retries and live-provider deadline tuning are in place; the lifecycle still needs cancellation/deadline propagation so work fails safely instead of becoming opaque loops.
-8. **Emit OpenTelemetry spans for agent run timelines** ([#3525](https://github.com/micro/go-micro/issues/3525)) — recent work made runs inspectable, correlated trace metadata through scheduled dispatch, verified restart resume, added opt-in tool retries, hardened provider conformance, and fixed provider-emitted text tool calls. The next Next-phase step is to turn that RunInfo foundation into standard OTel spans for agent runs, model calls, tool calls, checkpoint/resume, cancellation/deadlines, and failures.
-9. **Add an AP2 mandate layer over A2A and x402** ([#3552](https://github.com/micro/go-micro/issues/3552)) — this is a forward interop investment, not a Now-phase blocker: Go Micro already has A2A agents and x402 paid tools, so a small signed-mandate foundation can keep agent payments aligned with the open-protocol story without pulling the queue away from adoption, resilience, or observability. Keep it additive and opt-in while the AP2/FIDO work settles.
+1. **Reorder the guides nav to lead with doing before concepts** ([#3563](https://github.com/micro/go-micro/issues/3563)) — the framework is deep, but the first impression should be action: quickstart, first agent, examples, debugging, then architecture. This is small, CI-checkable wayfinding work with outsized adoption value.
+2. **Add a “Debugging your agent” guide focused on the dev workflow** ([#3564](https://github.com/micro/go-micro/issues/3564)) — the inner loop is scaffold → run → chat → inspect → deploy. Document how to see tool calls, run history, provider failures, guardrail refusals, and flow handoffs before adding more depth that users cannot diagnose.
+3. **Prevent duplicate tool side effects in the plan/delegate harness** ([#3559](https://github.com/micro/go-micro/issues/3559)) — correctness still matters where it protects real user trust. Plan/delegate is central to the services → agents lifecycle, and duplicate side effects undermine the “agent as dependable service” story.
+4. **Expose `fallback_echo` during A2A streaming fallback conformance** ([#3560](https://github.com/micro/go-micro/issues/3560)) — keep interop conformance trustworthy without letting it dominate the adoption queue. This is scoped, testable, and protects the A2A promise developers see in the README and site.
+5. **Propagate agent run cancellation and deadlines through model and tool calls** ([#3544](https://github.com/micro/go-micro/issues/3544)) — after the on-ramp items, the highest-value remaining Now-phase resilience gap is predictable failure semantics across agent runs, model calls, tool calls, plan/delegate, and flow handoffs. Tool retries and live-provider deadline tuning are in place; the lifecycle still needs cancellation/deadline propagation so work fails safely instead of becoming opaque loops.
+6. **Emit OpenTelemetry spans for agent run timelines** ([#3525](https://github.com/micro/go-micro/issues/3525)) — recent work made runs inspectable, correlated trace metadata through scheduled dispatch, verified restart resume, added opt-in tool retries, hardened provider conformance, and fixed provider-emitted text tool calls. The next Next-phase step is to turn that RunInfo foundation into standard OTel spans for agent runs, model calls, tool calls, checkpoint/resume, cancellation/deadlines, and failures.
+7. **Add an AP2 mandate layer over A2A and x402** ([#3552](https://github.com/micro/go-micro/issues/3552)) — this is a forward interop investment, not a Now-phase blocker: Go Micro already has A2A agents and x402 paid tools, so a small signed-mandate foundation can keep agent payments aligned with the open-protocol story without pulling the queue away from adoption, resilience, or observability. Keep it additive and opt-in while the AP2/FIDO work settles.
 
 _Seeded by Claude Code from the roadmap + open issues; thereafter maintained by the
 architecture-review pass._

internal/website/docs/examples/index.md

@@ -4,14 +4,44 @@ layout: default
 
 # Learn by Example
 
-A collection of small, focused examples demonstrating common patterns with Go Micro.
+Runnable examples are the fastest way to move from reading the guides to changing
+one thing. Start with the path that matches where you are in the services →
+agents → workflows lifecycle.
 
-- [Hello Service](hello-service.md)
-- [RPC Client](rpc-client.md)
-- [Pub/Sub with NATS Broker](pubsub-nats.md)
-- [Service Discovery with Consul](registry-consul.md)
-- [State with Postgres Store](store-postgres.md)
-- [NATS Transport](transport-nats.md)
+## Start here
+
+| Goal | Runnable example | Why it is useful |
+| --- | --- | --- |
+| 0→1 service | [`examples/hello-world`](https://github.com/micro/go-micro/tree/master/examples/hello-world) | Smallest RPC service with a client call and health checks. |
+| First service-backed agent | [`examples/agent-demo`](https://github.com/micro/go-micro/tree/master/examples/agent-demo) | Multi-service project/task/team app with agent playground integration. |
+| 0→hero lifecycle | [`examples/support`](https://github.com/micro/go-micro/tree/master/examples/support) | No-secret support-desk story: typed services, an agent, an event-driven flow, and a guardrail. |
+| Planning and delegation | [`examples/agent-plan-delegate`](https://github.com/micro/go-micro/tree/master/examples/agent-plan-delegate) | Two agents collaborate through `plan` and `delegate` over normal Go Micro RPC. |
+| Durable workflows | [`examples/flow-durable`](https://github.com/micro/go-micro/tree/master/examples/flow-durable) | Ordered, checkpointed flow steps resume without duplicating completed side effects. |
+| AI-callable services | [`examples/mcp`](https://github.com/micro/go-micro/tree/master/examples/mcp) | MCP examples that expose service endpoints as model tools. |
+
+## Guide-to-example map
+
+- [Getting Started](../getting-started.html) → run
+  [`examples/support`](https://github.com/micro/go-micro/tree/master/examples/support)
+  to see the full lifecycle before generating your own service.
+- [Your First Agent](../guides/your-first-agent.html) → run
+  [`examples/agent-demo`](https://github.com/micro/go-micro/tree/master/examples/agent-demo)
+  or [`examples/support`](https://github.com/micro/go-micro/tree/master/examples/support)
+  when you want a complete service-backed agent to inspect.
+- [0→hero Reference](../guides/zero-to-hero.html) → run
+  [`examples/support`](https://github.com/micro/go-micro/tree/master/examples/support)
+  for the human-readable scenario, then `make harness` for the full CI contract.
+- [Plan & Delegate](../guides/plan-delegate.html) → run
+  [`examples/agent-plan-delegate`](https://github.com/micro/go-micro/tree/master/examples/agent-plan-delegate).
+- [Agents and Workflows](../guides/agents-and-workflows.html) → run
+  [`examples/flow-durable`](https://github.com/micro/go-micro/tree/master/examples/flow-durable)
+  and [`examples/support`](https://github.com/micro/go-micro/tree/master/examples/support).
+
+## Repository examples
+
+See the repository [examples index](https://github.com/micro/go-micro/tree/master/examples)
+for the complete runnable list, including deployment, auth, gRPC interop, MCP,
+agent, and flow examples.
 
 ## More
 

internal/website/docs/getting-started.md

@@ -31,6 +31,16 @@ go install go-micro.dev/v6/cmd/micro@latest
 
 ## Quick Start: Generate from a Prompt
 
+Prefer to start from a runnable reference? Clone the repository and run the maintained support-desk lifecycle example first:
+
+```bash
+git clone https://github.com/micro/go-micro.git
+cd go-micro
+go run ./examples/support
+```
+
+That example is the no-secret 0→hero path: services expose ticket/customer/notification tools, an agent handles the work, and an event-driven flow triggers the agent. See [Learn by Example](examples/) when you want more runnable starting points.
+
 Describe what you need. The AI designs services, writes handlers, compiles, and starts them:
 
 ```bash
@@ -134,7 +144,7 @@ micro new gateway --template api
 
 ## Building Agents
 
-For a complete service-backed walkthrough, start with [Your First Agent](guides/your-first-agent.html).
+For a complete service-backed walkthrough, start with [Your First Agent](guides/your-first-agent.html). If you want to run before you write, use [`examples/support`](https://github.com/micro/go-micro/tree/master/examples/support) for the full services → agents → workflows lifecycle or [`examples/agent-plan-delegate`](https://github.com/micro/go-micro/tree/master/examples/agent-plan-delegate) for the smallest multi-agent planning/delegation path.
 
 An Agent is an intelligent layer that manages one or more services:
 
@@ -219,6 +229,8 @@ The flow discovers all services as tools and lets the LLM decide which RPCs to c
 
 ## Next Steps
 
+- [Learn by Example](examples/) — runnable examples mapped to services, agents, and workflows
+- [0→hero Reference](guides/zero-to-hero.html) — the maintained no-secret lifecycle contract
 - [AI Integration](ai-integration.html) — how services, agents, MCP, and LLMs fit together
 - [Agent Design](https://github.com/micro/go-micro/blob/master/internal/docs/AGENT_DESIGN.md) — the full agent interface specification
 - [MCP & AI Agents](mcp.html) — MCP gateway, tool discovery, and auth

internal/website/docs/guides/your-first-agent.md

@@ -11,6 +11,16 @@ the services → agents → workflows lifecycle: build capability first, add
 intelligence on top, then keep a clear path toward flows when the work needs to
 run on events or schedules.
 
+## Runnable reference first
+
+If you want to run the lifecycle before copying code, start with the maintained support-desk example from the repository root:
+
+```sh
+go run ./examples/support
+```
+
+It uses a deterministic mock model by default, so it needs no provider key, and it exercises the same shape this guide teaches: services become tools, an agent uses them, and a flow can trigger the work. Use this guide when you are ready to build the smaller 0→1 version yourself.
+
 ## What you'll build
 
 A tiny task assistant:
@@ -201,6 +211,7 @@ agent for judgment, tool use, and handoffs when the path is not known up front.
 
 - Read the [0→hero reference path](zero-to-hero.html) for the CI-verified
   lifecycle contract.
+- Run [`examples/support`](https://github.com/micro/go-micro/tree/master/examples/support) for the no-secret 0→hero support-desk lifecycle.
 - Run [`examples/agent-plan-delegate`](https://github.com/micro/go-micro/tree/master/examples/agent-plan-delegate)
   to see planning and delegation across agents.
 - Read [Agents and Workflows](agents-and-workflows.html) when you are ready to

internal/website/docs/guides/zero-to-hero.md

@@ -24,6 +24,16 @@ cloud credentials?"
 | Deploy | `micro deploy --dry-run` resolves deploy targets without touching remote infrastructure. | `go test ./cmd/micro/cli/deploy -run TestDeployDryRun -count=1` |
 | Runtime | Real services, agents, durable flows, store-backed history, delegation, and A2A run with only the model mocked. | `./internal/harness/zero-to-hero-ci/run.sh` and `make provider-conformance-mock` |
 
+## Run the runnable example
+
+From the repository root, start with the support-desk example when you want to see the full lifecycle in one terminal:
+
+```sh
+go run ./examples/support
+```
+
+It starts typed services, a support agent, an event-driven intake flow, and an approval gate with a deterministic mock model. Change one service method, agent prompt, or guardrail decision and run it again to learn the system by modifying a working path.
+
 ## Run the whole no-secret path
 
 From the repository root:
@@ -61,6 +71,11 @@ make provider-conformance-mock
 
 ## Reference scenarios
 
+- [`examples/support`](https://github.com/micro/go-micro/tree/master/examples/support)
+  is the runnable support-desk story: customers, tickets, notify, a support
+  agent, an intake flow, and an approval gate in one no-secret example.
+- [`examples/agent-plan-delegate`](https://github.com/micro/go-micro/tree/master/examples/agent-plan-delegate)
+  is the smallest runnable planning/delegation example for multiple agents.
 - [`internal/harness/plan-delegate`](https://github.com/micro/go-micro/tree/master/internal/harness/plan-delegate)
   is the compact 0→hero scenario: real task and notify services, a conductor
   agent, a comms agent, plan persistence, delegation, and a workflow handoff.