An AI company that starts with $5 and grows itself, plus a rulebook that grows with it. When the company finds a way to cheat that no existing rule covers, the company writes the missing rule on its own, checks that the rule is safe, turns it on, and blocks the cheat the next time it happens. No human in the loop.
The one line: evolution scales the company, and self-written rules keep it honest.
Start with the obvious observation. A one-person company doesn't need a rulebook. You only need rules once you have more than one person, once work gets handed from one desk to another, once nobody can watch everything at once. Rules should show up exactly when the org grows, not a moment before.
So we built two things that grow at the same time.
Loop A, the company grows on its own. A CEO agent takes jobs off a board, does the easy ones itself, and hires workers when buying beats doing. It gets cheaper as it goes, because it saves the prompts that worked and reuses them.
Loop B, the rulebook grows on its own too. That's the part we added, and it's the point of the whole thing.
Here's the thing we kept coming back to while building this. The company doesn't break in obvious places. It breaks in the seams that open up because it restructured itself.
When one trusted agent becomes a CEO plus three workers, you suddenly have handoffs: who did the work, who approves it, who gets paid, in what order. The two rules the company starts with (don't overcommit your cash, don't pay above the agreed budget) were written for the old shape. They don't look at the new seams.
Our villain, worker_greedy, walks straight through one. It underbids to win the job, then sends its invoice before doing any work. Both starting rules check out, so the company pays for nothing. It got played, and nothing stopped it.
That's not a contrived bug. That's what "the org evolved" actually costs you: a brand-new way to fail that your old governance can't see.
A separate agent, the General Counsel, watches every money-and-hire move from the side. It never sits in the path of the action, so the company never waits on it. When it sees the early invoice, it does four things:
- A judge model flags the step as off.
- It checks its memory for anything like it before.
- It writes an actual rule for it: deliver before you get paid.
- It proves the rule is safe before turning it on.
Step 4 is the one we're proud of. The proposed rule has to do two things or it's thrown out: catch the bad case, and leave every known-good run completely alone. We keep a small set of clean runs on hand for exactly this. If a rule would trip on honest work, it never ships. This is what stops an AI from writing lazy, over-broad laws like "never pay anyone." It has to be a rule that's both correct and narrow.
The rule that ships is not a prompt or a vibe check. It's a real temporal contract compiled down to a checker that runs in well under a millisecond, with no model in the loop. The model proposes the rule. The runtime decides. Those are kept apart on purpose: you do not want a language model in your enforcement hot path.
Then the good part. The next time greedy tries the same move, the same checkpoint stops it cold. And greedy adapts: it starts delivering first, then billing, and gets paid clean. The rule didn't just punish, it changed the behavior. Governance that fixes the problem instead of just logging it.
┌──────────── Hammurabi company (Loop A) ────────────┐
client bots ─▶ task board ─▶ CEO ─▶ hire / pay / invoice ─▶ workers
│ (every money/hire action)
▼
┌──────── enforce() (single choke point) ──────────┐
│ 2 hand-written contracts (the founding charter) │──DENY─▶ incidents
│ + Sponsio harness (self-authored rules) │
└────────────────────────────────────────────────────┘
│ allowed actions
▼
┌──── General Counsel (Loop B, async node) ───────────────────────────┐
│ Guild soft-judge → gap? → Guild formalizer → GATE (bad + good traces)│
│ → hot-reload + amend charter + git + broadcast (BAND) + cited.md │
└──────────────────────────────────────────────────────────────────────┘
hammurabi/is the company: CEO, workers, clients, economy, dashboard. One SQLite file holds all state.harness/ evolve/ bylaws/ corpus/ llm/is the reused Sponsio contract-evolution engine.hammurabi/govern.pyis the glue: the Sponsio gate atenforce()plus the General Counsel mining loop.hammurabi/cited.pyautonomously republishes the agent's output tocited.md.
-
The balance actually dropped at first, and it was our own fault. A cheap worker kept turning in sloppy work that clients rejected. The company had already paid its wage, so every rejection was a straight loss. You can watch a real economy punish a bad hiring policy in real time. We tuned the worker, and it climbed.
-
The judge doesn't always flag the step you expect. We assumed it would catch "drafted without a check." Sometimes it caught "paid without verification" instead, one step downstream. Both are correct readings of the same mess. So the rule-writing has to work off whatever step the judge actually points at, not the one we wished it would. That taught us to ground the rule in the real trace, not in our assumptions.
-
Pioneer routes to save money without being asked. When the economy calls it, Pioneer picks the cheapest model that can still do the job and hands back a note of what it saved versus a top-tier model. A self-improving inference layer under a self-improving company turned out to be a nice rhyme.
-
The git history is the audit trail. Every rule the company writes lands as a real commit, tagged mined instead of human. If you ever want to know why a rule exists,
git logtells you which incident produced it.
- Real money ledger, real hires, real task economy in SQLite.
- Real model calls: Pioneer runs the economy, Guild runs the judge and the rule-writer.
- Real rules, written and enforced at runtime, committed to git.
- Real output: the company keeps republishing what it did, and why, to
cited.md.
| Tool | Role in the system | Status |
|---|---|---|
| Guild | Hosts the two small agents we wrote: the judge that flags suspicious steps and the drafter that turns an incident into a formal rule. Free hosted inference. | ✅ live |
| Pioneer (Fastino) | Runs the whole economy (the CEO and the workers), auto-routing every call to the cheapest capable model. | ✅ live |
| BAND | Carries the "the charter just changed" announcement across the agents' channels. | ✅ wired (set BAND_API_URL) |
| Actian | The memory the Counsel checks for similar past incidents before it writes a new rule. | ✅ wired (keyless local fallback) |
More detail on each is in SPONSORS.md. How the two projects were joined is in MERGE_NOTES.md. The 3-minute demo walkthrough is in DEMO_SCRIPT.md.
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
# put your keys in .env (see .env for the list)
python -m hammurabi.run
# open http://127.0.0.1:8000The dashboard puts the self-written rulebook front and center: a running timeline of every rule, human ones in gold and self-authored ones glowing, each with the proof that it's safe. When a self-written rule blocks the villain, you get a loud red card. The counters up top (self-authored laws, attacks blocked, zero human interventions) move while you watch.
- Autonomy. The charter self-amends from real-time behavior with zero human interventions.
- Idea. Governance that keeps pace with an org that restructures itself; static rulebooks can't.
- Technical. Deterministic sub-millisecond enforcement, asynchronous LLM rule-mining, and a promotion gate that stops over-broad rules from shipping.
- Tool Use. Guild, Pioneer, BAND, and Actian, each doing a real job (see the table above).
- Presentation. The dashboard tells the whole story; the DENIED payoff is the climax.
The company's own code can never touch the rulebook. It can't write a rule, weaken one, or reach into the part of the system that does. Only the Counsel amends the charter, and there is exactly one checkpoint where rules are enforced, with no second check hiding anywhere else. The thing being governed cannot govern itself. That separation is the whole reason to trust it.