GitHub - Chong169/a-constitution-for-one: Seven months governing a personal AI agent fleet under a written constitution. Zero incidents. · GitHub

/" data-turbo-transient="true" />

Skip to content

Search/

Sign in<br>Sign upAppearance settings

You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.

Dismiss alert

{{ message }}

Chong169

a-constitution-for-one

Public

Notifications<br>You must be signed in to change notification settings

Fork

Star

main

BranchesTags

Go to file

CodeOpen more actions menu

Latest commit

History<br>1 Commit<br>1 Commit

Folders and files<br>NameNameLast commit message<br>Last commit date<br>README.md

README.md

View all files

Repository files navigation

A Constitution for One: Seven Months Governing a Personal AI Agent Fleet

Seven months ago I did something that felt slightly absurd: before letting my AI agents touch anything real, I wrote them a constitution.

Not a prompt. Not a system message. A written document — what the system may do, what it must never do, who audits whom, and what happens when code is found violating a ruling. Then I built the fleet to enforce it.

Seven months of continuous operation later: zero incidents. Not zero attempts — zero incidents. The difference between those two words is what this post is about.

Why a constitution and not guardrails

Everyone building agents eventually learns the same lesson: the most useful capability is the most dangerous one. An agent that can deploy code can deploy the wrong code. An agent that can send messages can send them to the wrong person. The industry's default answer is guardrails — patches added after each scare.

I run everything alone: an always-on cloud bot handling daily intelligence briefings and monitoring, execution agents doing builds and deployments, an AI strategy layer for planning. One person, no security team, no compliance department, bus factor of exactly one. For me, "add a guardrail after the incident" isn't a strategy — a single bad incident could end the whole operation.

So I inverted the order: constitution before code. Guardrails are retrofitted; a constitution is architecture. Every component that came later had to grow up inside rules that already existed.

The method: observe first, legislate second

The constitution didn't come from theory. It came from a deliberate sequence I'd recommend to anyone building in this space:

Observe before you automate. Before giving agents any real authority, I spent weeks just watching how failures actually happened — in my own manual workflows, in public incident reports, in other people's postmortems. Not "what could go wrong" in the abstract, but what actually goes wrong, in what order, through which door.

Derive rules from observed failure shapes, not imagined ones. Every article of the constitution traces back to a failure mode I had either witnessed or found documented. Rules invented from imagination tend to guard the wrong doors; rules derived from observation guard the doors failures actually use.

Then run the rules against reality — and let reality amend them. The constitution shipped as a hypothesis, not a scripture. Seven months of operation falsified some clauses, hardened others, and wrote several I could never have imagined at the start. The case files below are that process, visible.

This ordering — observe, derive, deploy, amend — is the actual contribution here. The specific rules matter less than the loop that produced them.

The four load-bearing walls

The full document is long. Four principles carry most of the weight:

1. Fail-safe by default: not explicitly declared = not production.<br>Every risky capability ships disabled. My lead-scanning module went live with its master switch defaulting to OFF and a hard daily budget cap — turning it on requires an explicit environment flag and manually activating each channel. Nothing becomes "live" by accident, forgetfulness, or a bad merge. If the declaration is missing, the system assumes the answer is no.

2. Human gates on everything irreversible.<br>Funds, deployments, deletions, anything public-facing: the agent prepares, the human fires. This isn't distrust of the agents — it's an honest map of which errors can be rolled back and which can't. In seven months, no exception has been granted. The gate is boring. Boring is the point.

3. Equal-strength checks on every execution path.<br>A recent 116-page paper on stealing reasoning traces from LLM APIs confirmed something I'd designed around months earlier: attackers don't beat your strongest defense, they walk through your weakest path. So there is no "trusted internal shortcut" anywhere in my system. Every path to a consequential action passes the same checks. The moment you create a faster lane for convenience, you've defined your real security boundary — and it's the...