---
title: "The Loop, Shipped: Introducing micro loop"
linkTitle: "The Loop, Shipped"
date: 2026-07-02
description: "The autonomous loop that builds Go Micro is now a command. micro loop init drops a planner, builder, triage, coherence, and release pipeline into any repository — GitHub Actions as the runtime, editable prompt files as the policy. And Go Micro now runs on it."
category:
- release
tags:
- AI
- agents
- CI-CD
aliases:
  - /blog/33
---
A few weeks ago we wrote [How Go Micro Builds Itself](/blog/2026/06/25/how-go-micro-builds-itself.html): a loop of two AI agents — Codex writing scoped increments, Claude Code orchestrating and reviewing, a human setting direction — kept honest by CI. It was our own thesis, *an agent operating a system*, pointed at the repository that defines the thesis.

People asked the obvious question: **can I run that on my repo?**

Now you can. `micro loop init` drops the whole pipeline into any repository, and — the part that makes it real rather than aspirational — Go Micro itself now runs on it. The workflows that maintain this project are generated by the same command we're shipping to you.

## It's not a binary. It's CI plus prompts.

The first thing to understand is what the loop *is*, physically, because it's not what people expect. There is almost no program here. The loop is a handful of GitHub Actions workflows and a few Markdown files. **GitHub Actions is the runtime.** Nothing compiled sits in a server "running the loop."

So `micro loop` the command is not the loop. It's a scaffolder. `micro loop init` writes the workflows and the prompts into your repo and exits. From then on, GitHub runs everything on a schedule.

That reframing is the whole design:

- **The workflows are the *mechanism*** — open a fresh tracking issue, summon an agent, let it open a PR, merge on green CI. This is generic. It's the same for every repo.
- **The prompt files are the *policy*** — what the agent is actually told to do. These live in `.github/loop/prompts/<role>.md`, and they're yours to edit.

Separating the two is what lets a tool be both general and specific. The mechanics never change; the instructions are entirely under your control. You steer the loop by editing prose, not YAML.

## The five roles

A full loop has five roles, each a workflow that dispatches an agent (or, for release, just cuts a tag):

| Role | What it does |
|------|--------------|
| **planner** | Reads your direction, scans what merged and what's open, and maintains a ranked queue in `.github/loop/PRIORITIES.md`. Decides *what*. |
| **builder** | Takes the top open item from the queue, implements it as a single-concern PR, and enables auto-merge so it lands the moment CI is green. Does the work. |
| **triage** | When CI fails on a branch, root-causes the failure and files scoped fix issues back into the queue. The feedback path. |
| **coherence** | Keeps README, docs, and `CHANGELOG.md` aligned with your North Star; drafts release notes. Optional. |
| **release** | Cuts the next patch tag when the branch has new commits, so the installable artifact tracks the loop. Optional. |

This is the [planner / generator / evaluator](https://www.anthropic.com/engineering/harness-design-long-running-apps) shape of a long-running agent harness, distributed across GitHub Actions instead of subagents. Generation is deliberately separated from evaluation: an agent grading its own work reliably over-rates it, so **CI — not the builder — is the gate.**

## Quickstart

```bash
micro loop init            # planner, builder, triage
micro loop init --roles all # add coherence + release
micro loop verify          # check the wiring
```

`init` writes the workflows, a `NORTH_STAR.md` (your direction) and `PRIORITIES.md` (your queue), and the per-role prompt files. Then there are exactly two things the CLI can't do for you — and `micro loop verify` reminds you of both:

1. **Add a token secret.** The agent ignores `@mentions` from the `github-actions` bot, so dispatch has to post as a real user via a personal access token stored as a repo secret. Until it's set, the workflows deliberately no-op.
2. **Set branch protection.** Require your CI checks with **zero** approving reviews, so the builder's auto-merge lands PRs the instant CI is green. That green-CI gate is the loop's only safety mechanism — which means it's worth saying plainly: **the loop is only as good as your tests.**

Edit `.github/loop/NORTH_STAR.md` to point it, tune the prompts if you like, commit, and it's running.

## The decisions that matter (and the things that broke)

Building this taught us that the hard part of an autonomous loop isn't the agent — it's the wiring around it. A few decisions are load-bearing, and we learned most of them by getting them wrong first.

**Agent-agnostic by `@mention`.** The dispatch summons an agent by mentioning it on an issue (`@codex` by default; `--agent` to change it). Any coding agent that responds to an issue mention and can run `gh` fits. The mechanics don't care which one.

**A fresh issue every run.** Agents derive their PR branch name from the triggering issue. Reuse one tracker issue and every run collapses onto a single branch name — the first PR opens, the rest silently collide and never appear. A unique issue per run gives each increment a clean branch. We found this the way you'd expect: a loop that looked healthy but quietly stopped producing PRs.

**Bots can't summon bots.** Codex ignores comments authored by `github-actions[bot]`, so the dispatch has to post as a user. That's the whole reason the token secret exists, and why the loop no-ops without it rather than pile up ignored comments.

**Don't let checkout clobber your token.** Our nightly release action once failed to push a tag with a permission error — despite having a valid token — because `actions/checkout` persists the default `GITHUB_TOKEN` as a git credential that overrode the personal token on the push. The generated release workflow ships with that fix baked in (`persist-credentials: false`), so it can't bite you.

None of these are exotic. They're exactly the papercuts you'd hit assembling this yourself over a week, and they're the reason a scaffolder earns its place: the defaults encode the lessons.

## Go Micro runs on it

Here's the part we care about most. This repository's loop is no longer hand-written. We ran `micro loop init --roles all` on Go Micro itself, moved our queue and direction into `.github/loop/`, and preserved our own richer instructions — the architect's founder-lens prompt, the adoption steer, the harness-failure triage, the changelog pass — as the editable prompt files. Behavior is identical; only the mechanism is now generated.

We proved it end to end before writing this. The planner fired, opened a fresh tracking issue as the token user, and posted its full instruction to Codex — clean, correctly addressed, picked up within seconds. The loop that will help maintain the post you're reading is the loop this post is about.

That's the honesty test for a dogfooded tool: if we wouldn't run it on our own main branch, we shouldn't ask you to run it on yours.

## What it is not

It would be easy to oversell this, so let's be clear about the edges.

- **It is not a replacement for judgment.** The generated prompts keep an explicit off-limits list — breaking public APIs, positioning and brand copy, new dependencies, architectural rewrites. Those get surfaced to a human, never auto-merged. Taste stays with you.
- **It is only as good as your gate.** Point it at a repo with weak CI and it will happily merge weak work. The evaluator *is* the safety model. Invest there first.
- **It spends tokens and pushes commits.** This is real automation with real effects. Start with the three-role default, watch it, and add `coherence` and `release` once you trust it.
- **It's early.** The mechanics are solid and battle-tested on this repo, but this is version one. The next steps are more agent adapters and, eventually, a standalone home so the workflows can be reused directly.

## The shape of the thing

Go Micro's premise is that when an agent has to operate inside a real system, it *is* a distributed system — services, state, retries, observability — and the simplest place to build it is the runtime where your services already live. `micro loop` is that premise turned back on the repository: an agent, operating a system, where the system is the codebase itself.

You've read about how Go Micro builds itself. Now you can point the same loop at your own repo:

```bash
micro loop init
```

---

*Go Micro is an open source agent harness and service framework for Go. [Star us on GitHub](https://github.com/micro/go-micro).*

