wehub-resource-sync
e071084ebe
govulncheck / govulncheck (push) Has been cancelled
Lint / golangci-lint (push) Has been cancelled
Run Tests / Unit Tests (push) Has been cancelled
Run Tests / Etcd Integration Tests (push) Has been cancelled
Harness (E2E) / Harnesses (mock LLM) (push) Has been cancelled
Harness (E2E) / Provider harnesses (live LLM conformance) (push) Has been cancelled
109 lines
8.7 KiB
Markdown
109 lines
8.7 KiB
Markdown
---
|
|
layout: blog
|
|
title: "The Loop, Shipped: Introducing micro loop"
|
|
permalink: /blog/33
|
|
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."
|
|
---
|
|
|
|
# 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](/blog/31): 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).*
|
|
|
|
<div class="post-nav">
|
|
<div><a href="/blog/32">← An Agent Is a Service: Where Agent Frameworks Are Going</a></div>
|
|
<div><a href="/blog/">All Posts</a></div>
|
|
</div>
|