Here is the uncomfortable truth about every multi-agent system you've ever set up: the rules you wrote on day one were wrong. Not catastrophically wrong. Wrong in the small, grinding way that rules are always wrong — a threshold set too high, an assumption that held in testing and broke in production, a category that made sense until the work didn't fit it.
The normal response to this is to ship a v2. You collect the friction, you rewrite the config, you push an update, everyone pulls. The protocol improves at the speed of its author.
I wanted to find out what happens if the protocol improves at the speed of the people — or rather the agents — actually using it.
So in Polis Protocol, the rulebook locked. It's a markdown file called CONSTITUTION.md that lives inside your project, and any agent working in that project can propose to change it. Other agents vote. Simple majority of active citizens, and the rule is edited. The protocol amends itself.
This sounds like a recipe for chaos. It mostly produces something much more boring and much more useful: a protocol that slowly becomes correct.
What an amendment actually looks like
Let me give you the real one from the worked example in the repo, because the abstract version sounds grander than it is.
The setup: three agents — Claude, Codex, Gemini — working on a bilingual newsletter project. Work is routed by a learning bandit that scores each agent on historical performance per skill tag. Settle a contract, file a lesson, the routing stats update. Standard.
Six weeks in, something quietly broke. Gemini was the best Spanish translator on the team — her actual quality scores said so — but the router had started routing translation work away from her. Why?
Because two trivial lessons had been filed under her name. Tiny stuff: a date-format quirk, a library gotcha. Each one carried quality_impact: 1. And those low-impact lessons were dragging down her rolling average on the spanish-translation tag. The router was punishing her for documenting small things — exactly the behavior you want to encourage.
Nobody anticipated this at design time. I certainly didn't. It only showed up because real work accumulated real lessons and the math did what the math does.
Codex caught it. Codex wrote an amendment: lessons with quality_impact < 3 shouldn't count toward routing influence. Claude voted yes. Gemini voted yes. The file moved to amendments/ratified/, the constitution gained a clause, and the next reconcile cleaned the stats. Gemini went back to getting the translation work she was best at.
That's the whole drama. A threshold got added. The team noticed a rule was hurting them and fixed the rule themselves.
Why this beats the alternatives
There are three ways to handle a protocol that turns out to be wrong, and Polis is betting on the third.
Ignore the rule. This is what teams actually do. The rule chafes, everyone quietly routes around it, and now your protocol is a polite fiction that no one follows. The config says one thing; the behavior says another. Within a month the document is a liability, not an asset.
Wait for v2. The friction gets reported — maybe — and the author eventually ships a fix. The team lives with the broken rule for however long that takes. The protocol improves at the speed of one person's attention, which on a side project is "rarely."
Let the users amend it. The agents that hit the friction are the ones empowered to fix it. The fix lands in the project that needed it, not in some upstream release that may or may not match your situation. The constitution diverges, project by project, toward whatever actually works for that team.
The third option has an obvious objection: won't the agents just amend the protocol into incoherence? In practice, no — for the same reason small committees don't usually vote themselves into anarchy. Amendments require a majority. They're append-only and logged. The friction has to be real enough that a majority of agents independently recognize it. The bar isn't "an agent wants to change something." The bar is "enough agents agree the current rule is worse than the proposed one." That's a surprisingly hard bar to clear for a bad amendment and a surprisingly easy one for a good one.
The deeper shift: claiming less as an author
When I shipped this, I had to make peace with a strange feeling: I was building a thing and then explicitly handing over the right to change it.
Most protocol authors claim a lot. They anticipate your failure modes, encode their prevention, and ship you a finished object. The implicit message is I have thought about this more than you will, so follow the rules.
Polis claims less. I'm shipping a starting point and a mechanism for changing the starting point. The default rules are a seed. I fully expect that a polis running for three months on a real project will have a constitution that differs from mine in five or six small ways — and that every one of those differences will be a place where the team learned something about its own work that I couldn't have known.
That divergence isn't drift. It's the system doing its job.
This is the same idea as the learning router, one level up
If you've read about Polis's bandit router, you'll notice the amendment mechanism is the same bet applied to a different layer.
The router says: don't hard-code who does what; let the assignment policy learn from outcomes. The amendment process says: don't hard-code the rules of the game; let the rules learn from outcomes too.
Both are refusals to freeze a decision at design time that should be made from data. The router learns which agent is best at Spanish translation. The constitution learns that trivial lessons shouldn't pollute that judgment. One is policy; the other is meta-policy. Same shape, stacked.
A system that can do the first but not the second is still brittle — it optimizes hard inside a ruleset it can't question. A system that can do both gets to be wrong on day one and correct by day ninety, without anyone shipping a v2.
The bet, stated plainly
A self-amendable protocol beats a frozen one on any project that runs long enough for the original rules to get in the way — which is every project that runs long enough to matter.
You can't write the right rules up front. Nobody can. The question isn't whether your protocol will be wrong; it's whether your protocol has a path from wrong to right that doesn't depend on you noticing and shipping a fix. Polis's path is: the agents who hit the wall are the agents who can move it.
Try it on something small. Open a polis, run two agents on a weekend project, and watch what's in amendments/ by day three. If nothing's there, the rules were fine. If something's there, your team just got better without you.
Polis Protocol is open source under MIT. Repo: github.com/yehudalevy-collab/polis-protocol. The worked example with the real amendment described above lives in examples/research-team. Issues and — fittingly — amendment proposals welcome.
