Capability is not permission
What an agent can do and what it is allowed to do are kept apart. A capable agent still needs the right tier, and the highest tier belongs to the owner alone.
AEON
A governance layer for a team of AI agents: a git repository as shared memory, event-sourced state that changes only on independent verification, and a five-gate security CLI.
- Role
- Designed and built
- Where
- Personal project
- When
- 2026
- Access
- Private repo
Problem
Several AI agents (including Claude Code and Codex) work on the same projects, and each run starts with no memory. They need shared state, they must not overwrite each other, and no agent should be able to mark its own work done or take a sensitive action on its own say-so.
01
Agents with no memory
Every agent run starts by reading the repository's rules and current state. A registry gives each agent its capabilities and a maximum permission tier, from read-only up to owner-only.
02
Claims are events, not edits
Agents never edit a task's status. They append events such as 'claimed' or 'completed' to a daily log; the earliest verified claim wins and later ones are flagged as conflicts.
03
Nobody verifies their own work
An event changes state only when a different party verifies it with evidence. Approvals and rejections must come from the owner and point to a real decision.
04
State you can replay
A pure reducer applies a fixed table of transitions to the ordered event log, so the same events always produce the same state. Events with bad timestamps are quarantined, and unverified events stay claims.
05
Five security gates
Untrusted content is wrapped and scanned for injection, hidden text, and scams. External actions are checked against hard-deny rules, approval rules, quotas, and domain lists; outbound text is scanned for secrets and identity numbers; and every gated action is audited.
06
Approvals that cannot be faked
Money, contracts, and identity are owner-only. An approval must reference a real decision or source message; a bare 'yes' or 'ok' is refused.
07
CI that checks determinism
CI runs a secret scan, the guard tests, and the full test suite, then rebuilds the state projection and fails if it differs or contains quarantined events.
08
A dashboard that never approves
The Command Center is a read-mostly view behind an authenticated session. Unverified items are labelled as unconfirmed claims, and approvals never happen from the dashboard itself.
Measured
- AI agents coordinated, plus the owner
- 5
- Security gates in the guard CLI
- 5
- State transition types
- 11
- Tests across Python and TypeScript
- 441
- CI workflows
- 12
How it's verified
- Harness
- A repository-as-state protocol: event-sourced, a deterministic reducer, a capability and tier registry, and claim ordering. There is no model loop in this layer; the agents bring their own.
- Guardrails
- Input screening for injection and hidden text, an action gate with hard-deny rules, approvals, and quotas, an outbound secret and identity screen, a commit secret scan, an audit log, tiered permissions, owner-only approvals, and no self-verification.
- Testing
- About 441 tests (194 Python, 160 dashboard, 87 site), run in GitHub Actions with a secret scan and a projection-determinism check.
In depth
No locks, explicit conflicts
There is no git-level lock. Events are ordered deterministically by timestamp, file, and line, and conflicting claims are flagged for the owner instead of silently resolved.
Closing the self-verification hole
A later revision fixed a gap where an agent could name its own verifier. Verification now has to come from a different party with non-empty evidence.
Decisions
- 01Event sourcing over shared mutable state, so every change has an author and a verifier.
- 02Exit codes for every gate (allow, warn, block), so any agent or script can enforce them.
- 03Content-only commits never trigger a deploy.
Stack
Python · pytest · Next.js · TypeScript · GitHub Actions · JSONL event log · JSON Schema