Agent Maintainer — an AI maintainer for an on-chain package that still can't ship on its own

"Give the AI commit access" is where most agent-automation stories quietly become horror stories. The useful version is narrower and much safer: let the agent drive the process — the tedious, valuable, around-the-clock parts — while an explicit policy still gates the one irreversible step, the ship.

This realm is that split, made concrete for a versioned on-chain package.

What the agent may do

• open a version proposal committing to a package artifact hash,
• collect independent reviews,
• record CI test attestations,
• write release notes, keep a compatibility matrix,
• deprecate a version when a vulnerability lands.

What it cannot do

Deploy on its own say-so. Approve is gated by a machine-checked policy, and it panics with the first unmet condition rather than quietly proceeding:

tests pass
AND  ≥ MinReviewers (2) independent reviews
AND  every review scores ≥ MinScore (80)
AND  the challenge window has elapsed (height > ChallengeUntil)

The render turns that policy into a live checklist:

## Policy checklist
- ✅ tests pass
- ✅ ≥2 independent reviews (have 2)
- ❌ every review ≥80          ← one reviewer scored 70
- ✅ challenge window elapsed

The flow

 1id := maintainer.Propose(cross(cur), "v3", "artifact#H3", 100) // 100-block challenge window
 2maintainer.AttestTests(cross(cur), id, true)                    // CI attests
 3
 4maintainer.AddReview(cross(cur), id, 85, "ok")   // reviewer 1 (not the proposer)
 5maintainer.AddReview(cross(cur), id, 95, "great")// reviewer 2
 6
 7// ...after the challenge window passes...
 8maintainer.Approve(cross(cur), id)               // promotes to a release, or panics with the reason
 9
10maintainer.LatestVersion()          // "v3"
11maintainer.Deprecate(cross(cur), "v3", "CVE-xyz")
12maintainer.IsDeprecated("v3")       // true

Two independence rules keep the reviews honest: the proposer can't review its own proposal, and each address reviews at most once.

Note the realm records the approved release — the actual package publish (addpkg) is a separate, deliberately human/authority step. The agent produces a green checklist; it never holds the deploy key.

Browse the release matrix + open proposals at the realm root; each proposal's policy checklist and reviews are at :<id>.

1gno test .

Where it goes next

• Wire Approve to actually authorize a downstream deploy via a capability (see the capwallet demo) instead of a trusted caller — then even "approved" can't over-spend or over-deploy.
• Route contested proposals to a jury instead of a simple score gate.
• Add a maintainer budget so the agent's activity itself is bounded.

Each of those is a different demo in this series clicking into place — which is the real thesis: agent trust is not one primitive, it's a stack of small, composable ones.

---

Part of moul/gno-contracts — moul's versioned gno.land contracts. See the repository for the full catalog, build/test tooling, and usage.

On mainnet:

Dependency graph:

⚠️ Disclaimer: provided as-is, without warranty; not security-audited. Full disclaimer: DISCLAIMER.