As code gets cheaper to generate, I think the scarce thing is governed intent rather than the code itself. Here is the first concrete case of what I mean: 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.
A canvas can't tell you if your organization is legally coherent
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 constraint rules are where it gets useful
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.
Every agent function needs a legal person behind it
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.
If an agent in your system makes a bad call tomorrow, can you write down today which person or legal entity carries the liability for it, without first calling a meeting to figure it out?
Top comments (0)