The Loop, Shipped: Introducing micro loop

July 2, 2026 • By the Go Micro Team

A few weeks ago we wrote How Go Micro Builds Itself: 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):

This is the planner / generator / evaluator 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

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:

micro loop init

Go Micro is an open source agent harness and service framework for Go. Star us on GitHub.