Home / Articles / 中文版

ATM Governance · Visual Guide

Understanding ATM Governance for AI Agents in Nine Diagrams

Once AI becomes a team of agents changing the same repository, the hard question is no longer only "can it write code?" It becomes: can it deliver stable, verifiable, recoverable engineering work?

by Eagl Huang·June 30, 2026·10 min read

ATM is not about making humans memorize more commands. It is about letting an AI agent enter a repository, learn the local ATM skill, understand task intent, obtain a boundary, validate the result, leave evidence, and hand the work to the next human or agent. These eight diagrams form a map of that governance chain: entry routing, health checks, locks, hooks, git-head evidence, closeout, and batch checkpointing.

9 governance diagramsA readable path through ATM's main operational surfaces.
1 engineering chainIntent, scope, validation, evidence, handoff, and closure stop living only in chat.
Multi-agent coordinationParallel work gets a boundary before it becomes mutation.

The short version: ATM governs AI engineering behavior

Most AI coding discussions focus on model capability: which model is smarter, which prompt is sharper, which agent can touch more files. Long-running projects change the shape of the problem. You start asking different questions: did the agent understand the task boundary? Did it claim the right scope? Did validation run? If something fails, can we locate the cause? Can the next agent continue without reconstructing chat history?

ATM turns AI work into an engineering production chain: route first, inspect repository health, acquire a lock or claim, let hooks block invalid mutation, then close through evidence. That is how it reduces hallucinated scope drift.

For humans

You describe the outcome, such as "fix a small login validation bug and leave reviewable evidence." The intended first touch is the AI using the local ATM skill, not the human learning the CLI first.

For agents

An agent should not edit immediately. It should read the local entry guidance, route through ATM next, then follow the returned playbook, scope, and validator expectations.

1. Start with the map: ATM Governance Atlas

Figure 02

ATM governance atlas

ATM governance atlas showing the major governance surfaces from entry routing to evidence and closure.
This is the map for the whole article. It frames ATM as a governance layer inside the repository: not one command, but a set of skills, rules, checks, and evidence lanes that help agents work reliably.

If you remember only one thing, remember this: ATM does not try to replace Git, CI, or human review. It sits between AI agents and the repository. An agent wants to act, so it routes first. It wants to edit, so it needs scope. It wants to close, so it needs evidence. It wants to cooperate, so it needs to know which work can happen in parallel.

2. Governance cards batch 1: put the high-frequency surfaces on one board

Figure 03

governance cards batch 1

ATM governance cards batch 1 showing next, doctor, lock claim, and hook as a grouped operational board.
This is not a single path diagram. It is an operational board that places next, doctor, lock / claim, and hook side by side so a human or agent can quickly see which governance card should open first.

For a first-time reader, the full atlas can be too broad while a single flowchart can be too narrow. This card board sits in the middle. It behaves like a governance dashboard home screen and tells you that the most common problem is not "which command exists?" but "which governance surface is relevant right now?"

For example, suppose the request is "fix the landing page and check whether GitHub also needs the same update." A mature agent should not edit immediately. It should first decide whether to route through next, whether the repo needs a doctor pass, whether the scope needs a lock, and what the hook will later enforce. This board puts those four questions in one place.

3. next is the entry: decide how this request should move

Figure 04

next entry decision

ATM next entry decision diagram showing how a request is routed before editing.
next is the agent's first governance entry. It does not merely answer "what is next?" It converts the user's request into a route, playbook, risk signal, and prerequisites.

In a CLI-first world, humans must remember the correct command order. In a skill-first ATM workflow, the agent should absorb that habit. The human states the outcome, the agent enters next through the repo-local skill, and the returned playbook keeps it from inventing its own lifecycle.

Take a request like "update the paper landing page and see whether GitHub needs matching changes." next should not return only "start editing." It should separate the work into website copy, repo documentation, and possibly publishing follow-up, then indicate which repository should be touched first. That is how the agent avoids treating a cross-repo job like a trivial single-page edit.

4. doctor is the health check: can this repo safely accept work?

Figure 05

doctor health check

ATM doctor health check diagram showing repository readiness checks.
doctor asks whether the repository is ready for governed agent work. Entry files, integrations, runner state, evidence, policy, and Git state can all become early warning signals.

The most expensive AI failures are the ones discovered late. Doctor pushes those failures earlier. Before the agent mutates files, it can learn whether the repository is healthy enough to proceed. For a multi-agent team, this is the traffic system before the intersection.

A concrete example is a missing repo-local ATM integration, a stale runner build, or a dirty Git tree that already contains someone else's uncommitted work. Those should not wait until pre-commit. Doctor tells the agent whether it must repair entry files, rebuild the runner, or resolve tree state before governed work really begins.

5. lock / claim is the boundary: shrink the agent to the task

Figure 06

lock and claim boundary

ATM lock and claim boundary diagram showing scoped work admission before mutation.
Locks and claims are not paperwork. They make the agent admit, before mutation, which part of the repository it is responsible for.

Without a boundary, an agent can easily turn a small fix into a broad cleanup or a bug fix into a speculative refactor. ATM first places the work inside a bounded frame so mutation, validation, and evidence all describe the same thing.

Imagine you asked for a rewrite of [README.md](C:/Users/User/AI-Atomic-Framework/README.md) to improve the 60-second beginner entry. A drifting agent may casually rewrite CLI docs, package metadata, and side documents along the way. Lock / claim says: not this time. This task touches the README and the paired publishing surface, not the whole framework.

6. hooks are live gates: block invalid work before commit

Figure 07

hook pre-commit gate

ATM hook pre-commit gate diagram showing checks before git commit.
The pre-commit gate turns governance from a reminder into an interception point. Missing lock, missing evidence, out-of-scope files, or invalid state can be blocked before the commit lands.

This is where ATM becomes practical engineering rather than advice. It does not depend on agents remembering every rule. It embeds the rule at the moment where the repository is about to change.

For instance, the page may already look finished, but the staged set still includes an out-of-scope file, a missing validator, or evidence that no longer matches the working tree. Without hooks, the agent is tempted to report success. With hooks, the repository can answer back: no, this delivery is not yet governable.

7. git-head evidence: prove which tree the evidence describes

Figure 01

git-head evidence flowchart

ATM git-head evidence flowchart showing how evidence is bound to current git head.
Git-head evidence answers a concrete question: does this evidence describe the current HEAD? If the evidence and the commit range do not match, the closure should not be trusted.

Evidence freshness is easy to overlook. A test that passed yesterday does not prove today's tree. By binding evidence back to Git head, ATM makes every closeout answer the same question: exactly which code did this evidence validate?

Picture agent A running validation in the morning, then editing two more files in the afternoon while still carrying the old "passed" result. Without git-head evidence, stale proof can quietly leak into a new delivery. Once evidence is tied to HEAD, the system can ask the right question: does this proof belong to this exact tree? If not, rerun it.

8. taskflow close: don't just say done, prove done

Figure 09

taskflow close flowchart

ATM taskflow close flowchart showing evidence-backed task closure.
taskflow close turns "I'm done" into a governed closure transition. It checks scope, delivery, evidence, git-head freshness, and closeout readiness instead of accepting a chat summary.

This is the step that turns implementation into something another human, another agent, or an audit can actually trust. The important shift is that "done" is no longer a conversational claim. It becomes a closure event backed by declared evidence.

A practical example is an agent finishing a landing page update and claiming success because the page visually looks correct. ATM still asks harder questions: were the intended files the ones actually delivered, do the validators map to this delivery, and is the git-head evidence fresh enough to close? If those answers are incomplete, close should stop rather than silently bless the task.

9. batch checkpoint: large queues move one stable head at a time

Figure 08

batch checkpoint flowchart

ATM batch checkpoint flowchart showing queue-head delivery and checkpointing.
Batch checkpointing is for multi-card or multi-fix work. ATM does not encourage an agent to mix everything into one giant delivery. The queue head must be delivered, validated, and checkpointed first.

Parallel work still needs rhythm. Batch checkpointing gives large work a cadence and reduces the classic failure mode: many things changed, but nobody knows which unit is actually done.

Suppose you are revising multiple articles, rewriting the README, and syncing a landing page at the same time. If all of that lands as one giant commit, it becomes hard to answer which unit is actually stable. Batch checkpointing says: finish the queue head, leave evidence, make it handoff-safe, then advance. It is slower, but much safer for a multi-agent team.

Put the nine diagrams back into one governance view

  1. Atlas: the governance atlas gives the global coordinate system.
  2. Board: cards batch 1 groups the high-frequency governance cards into one dashboard.
  3. Route: next translates natural language into a governed path.
  4. Inspect: doctor checks runner, integration, policy, evidence, and Git readiness.
  5. Bound: lock / claim gives the agent a declared scope.
  6. Gate: hooks block invalid state before commit.
  7. Bind proof: git-head evidence proves which code the validation describes.
  8. Close formally: taskflow close turns delivery plus evidence into governed closure.
  9. Advance deliberately: batch checkpoint keeps multi-task work resumable.

This is how ATM governs AI: it does not assume the model is always right or the prompt is always perfect. It places agent work inside a bounded, validated, recoverable chain. That is the foundation that lets multi-agent collaboration become an engineering practice rather than a pile of impressive but fragile edits.