Turning \"What Even Is a Legitimate Organization\" Into Something You Can Validate

Originally published on LinkedIn on August 14, 2026.

Last time I wrote about why I think the scarce thing, as code gets cheaper, is governed intent rather than the code itself. This is the first concrete case: a schema I built for organizational design, and what it actually forces you to confront once you try to make it checkable instead of just persuasive.

Most org design advice is a business-model canvas: fill in some boxes, get a diagram, move on. The diagram doesn't tell you if your organization is legally coherent. It doesn't catch the moment where you've quietly promised two incompatible things to two different people.

So I built something closer to a type system. Eight parameters: purpose, who has a claim on surplus, who controls decisions, how resources flow in, how surplus gets allocated, the legal shell, the lifecycle, and who does the work (a parameter I added specifically because of AI, since the answer used to default to "everyone" and now it doesn't). Every organization is an assignment of values to those eight parameters.

The parameters are simple. The eleven constraint rules on top of them are where it gets useful, because they define which combinations are actually legally or logically possible, checked by a validator against the schema definition itself. A couple of examples: pick a foundation as your legal shell, and the rules require "no residual claimant, surplus must be reinvested." Not a best practice I decided on, just what the underlying legal structure is. Try to design an organization where autonomous agents hold real decision authority, and one rule forces the question every "AI-run company" pitch quietly skips past: agents have no legal personhood, so someone, a human or a legal entity, still has to be the one who can sign, be held liable, and be sued. You can't check that box without answering it first.

Eight parameters — one assignment per organization

PurposeResidual claimantDecision controlResource inflowSurplus allocationLegal shellLifecycleWho does the work

Eleven constraint rules

Which assignments are legally or logically possible, checked by a validator against the schema definition

• Legal shell = foundation → no residual claimant; surplus must be reinvested.
• C9 · Autonomous agents hold decision authority → agents have no legal personhood, so a named human or legal entity must still be able to sign, be held liable, and be sued.

Result

A design is not finished until every constraint resolves — including the one that names who carries the liability.

That last constraint is the one I think matters most for anyone building agentic systems right now, not just anyone designing a company. The instinct is to describe what the agent does. The constraint requires you to also state, explicitly, who's accountable when it does the wrong thing, and that answer has to resolve to an actual legal person, every time.

I used my own company as the first real test case, working through the constraints by hand against my actual design. It surfaced a tension a canvas never would have: a place where I wanted to claim "agents execute this function," and the C9 rule made me write down, in plain terms, who actually carries the liability for that function before I was allowed to call the design finished. That's the value of a checkable structure over a persuasive one. It doesn't let you skip the uncomfortable part.

Being an AI architect, I think, has to mean being willing to formalize the parts of a design that are usually left as vibes, specifically so an agent-heavy plan has to survive the same scrutiny a human-run one would.

Next up: the governance runtime I built for coding agents, and what happened when I tried to actually measure the difference between running a task governed versus not.