I Put a Graph Engineering Layer on AutoMaintainer — With GLM-5.2 as the Architect
AutoMaintainer already works. It spawns agent teams, they write code, verify it, and open PRs. That part is solved. But here's what nobody talks about: what happens when the AI can't merge a PR?
A 500-line feature PR. A security-sensitive change. A conflict it can't auto-resolve. The fleet hits a wall, and then... it just waits. For you. The human. The CEO who has to look at it and say "approve" or "split" or "deny."
That used to mean opening GitHub, reading the diff, making a decision, and typing a command. Every time. For every blocked PR. It was the one crack in the autonomy.
So I fixed it. And the honest truth is: I didn't architect it alone. I used GLM-5.2 — the model behind this very session — as my engineering layer. And it worked out nicely.
The Problem: Autonomy Has a Ceiling
Here's what the fleet looked like before:
- AutoMaintainer spawns agents → they write code → PRs open
- A deterministic merger (shell script, 15min timer) merges small safe PRs automatically
- When it can't merge — too big, wrong type, conflicting — it delegates to an "AI merger" that was... not running
- Result: PRs pile up. Nothing escalates. You come back to 7 blocked PRs and no idea what to do with them.
The merger script had three bugs I didn't know about. A pipefail race that crashed it after the first repo. A regex that rejected conventional commit scopes (fix(#726): wasn't recognized as a safe type). A size limit so conservative it blocked 90% of the fleet's output.
One PR merged in 24 hours. That was the state.
The Fix: A Graph Engineering Layer
I didn't just patch the script. I built a layer on top — three components that form a closed loop:
1. mago — Human-in-the-Loop, GitHub-Native
When the merger can't resolve a PR after 8 passes (~14 hours), it escalates. Not to a Slack channel. Not to an email. To a GitHub issue in a dedicated repo (javimosch/am-fleet) with a structured question:
🙋 javimosch/automaintainer#783 needs CEO decision
Repo: javimosch/automaintainer
PR: #783 — feat(#234): add platform repo presets subcommand tree
Size: 558L (XL), 4 files changed
Reply with one of:
- CEO: approve — merge as-is
- CEO: split into <description> — break into smaller PRs
- CEO: deny — close the PR
- CEO: <custom instructions> — any other guidance
I get a GitHub email. I reply on the issue — "CEO: approve" — and a 5-minute timer on rbm21 detects my reply, applies the decision to the PR, and closes the loop. No terminal needed. No dashboard to check. Just GitHub, which I'm already on.
2. The Deterministic Merger — Fixed
The three bugs were found and fixed in one session:
{ set +o pipefail; tac | python3; }— the race that crashed after the first repo^(fix|docs|test|chore|refactor)(\(.+\))?:— the regex that now accepts scopesMAX_LINES=200— bumped from 100, because a 130-line test PR is not a risk
Result: 16 PRs merged in 24 hours. Same fleet. Same agents. Just a merger that doesn't crash.
3. Live Dashboards — See What the Fleet Is Doing
Two dashboards, auto-updated every 15-30 minutes, published to hart (my self-hosted artifact host):
- Shipped — what the fleet merged (24h/7d stats, per-repo breakdown, recent merges with size labels)
- HITL queue — what needs your decision right now
When the HITL queue is empty, the dashboard says "No pending HITL — fleet is autonomous." When it's not, it shows the PR, the size, the files, and a link to reply.
GLM-5.2 as the Architect
Here's the honest part. I didn't design this layer in a vacuum. I used GLM-5.2 — the model powering this session — as my engineering partner. And I want to be straight about what that means.
GLM-5.2 didn't "help me write a blog post." It architected a production system. It:
- Debugged the merger script by running it with
bash -x, reading the trace, and identifying thepipefailrace - Wrote the escalator and resume scripts — bash + Python, with idempotency checks, GitHub API calls, and structured error handling
- Designed the HITL protocol — the structured question format, the reply parsing (approve/split/deny/custom), the label-based state machine
- Created the systemd timers with
Nice=19andCPUWeight=10because I mentioned the server has a weak power supply and intensive load could crash it - Built the live dashboards — HTML/CSS/JS, self-contained, published to hart via curl API
- Caught its own bug: the
gh issue close --remove-labelflag doesn't exist, fixed it to usegh issue editfirst
And when I said "gentler" — because pve2 has a weak PSU and intensive load could power off the server — it built the mago binary locally and just scp'd the 8.5MB static binary to rbm21. No compilation on the server. No load spike. That's not a model regurgitating Stack Overflow. That's an engineer reading the room.
Does It Actually Work?
Yes. Here's the proof:
- Before: 1 PR merged in 24h. 7 blocked. No escalation. No visibility.
- After: 16 PRs merged in 24h. 0 pending HITL. Live dashboards. Closed loop.
The first HITL issue was raised for PR #783 (a 558-line feature). I replied "CEO: approve" on GitHub. Five minutes later, the resume timer detected it, added the human-approved label, and the PR was merged. The HITL issue closed automatically. The dashboard updated to "fleet is autonomous."
That's the whole loop. From blocked PR to merged PR, with one GitHub comment from my phone.
What This Means for AutoMaintainer
AutoMaintainer was already the only platform that closes the gap from idea to merged PR. Now it also closes the gap from blocked PR to merged PR — without you opening a terminal.
The fleet runs. The merger merges what it can. When it can't, it asks you a structured question on GitHub. You answer. It resumes. The dashboards show you what shipped and what's waiting. All of it on your infrastructure, your keys, your schedule.
And the layer that makes it work — the graph engineering, the HITL protocol, the deterministic merger fixes — was built in one session with GLM-5.2. Not as a demo. As production code running on a Proxmox container right now.
If you want to run AutoMaintainer on your repos — head to automaintainer.intrane.fr.
Next in this series: How the fleet's agent teams decide what to work on — the explore mode, issue scout, and the priority queue that keeps them on what matters.