Constraint Court

Every CTO who has tried this has a list. The codebase is too old. Security will never sign off. The seniors won't touch it. The board wants proof first. Say the list out loud in a leadership meeting and the room nods, because every item on it sounds responsible.

That is exactly the problem. A constraint that sounds responsible never gets checked. It sits in the plan as a fact, borrows the authority of whoever said it first, and a year later the company is where it started, with a better-documented reason.

Constraint Court is where the list gets checked. You state a constraint. It gets a hearing and one of three verdicts: real, negotiable or false. Half of the ten on the books are false. The rest have a price, and somebody has to pay it.

State a constraint, get a ruling

You bring the constraint to the Court in your own words, or through the tinycto MCP server from whatever client you already work in. If it matches a constraint the Court has already ruled on, you get that ruling. If it doesn't, the model rules on it, grounded in the rulings below and in the same operating beliefs that run through this whole guide, and it answers with the same four parts. The Court also hears one kind of claim people forget is a claim: taking a workflow off a function's core list. The rung-5 bar on the ladder is strict on purpose, and "that workflow doesn't count" gets a hearing like everything else.

The pushback is always blunt. There is no tone setting, and there won't be one.

That is a design decision, not a personality. You already negotiate with yourself every time the work slips another month. You have plenty of voices that understand your position. What you lack is one that doesn't. A softened ruling is just another round of that negotiation, and the constraint wins it, because it was comfortable, and comfort is what kept it alive in the first place.

The three verdicts are three different jobs. A real constraint gets designed around. A negotiable one gets a price and an owner. A false one gets a date to stop believing it. That date matters more than the verdict. A false constraint does not die when someone tells you it's false. It dies on the day after which nobody in your leadership team is allowed to say it again.

How a hearing runs

Owner first. Not a team. "Security" is not an owner, and neither is "legal" or "the platform people". A name, and where that name is written down. If nobody can produce one, the constraint is treated as false until someone proves otherwise.

That sounds harsh until you ask what an unowned constraint actually is. Nobody can remove it, because nobody is responsible for it. Nobody can say what it would take, because nobody has been asked. It can't be negotiated, because there is no one on the other side of the table. It is friction somebody felt once and repeated, and it has been costing you ever since. I made the same argument about review steps in the gatekeeping reflex: a control exists to catch something, and if nobody can name what it catches, there is no gate. Just a feeling.

A constraint nobody owns is a feeling, not a fact.

What would have to be true. This question turns a wall into a list of conditions. "Security won't approve it" is a wall. "Scoped credentials, isolated execution, zero-retention terms and a named reviewer" is a list, and lists get worked through, one item at a time.

What removing it costs, in time, money and political capital. CTOs fill in the first two and leave the third blank. It is usually the biggest. Removing "our seniors won't adopt it" costs no money at all. It costs you saying something uncomfortable, in public, to people you respect. Price that honestly or you will keep choosing the cheaper-looking option of doing nothing.

Ruling and first move. The first move is one thing the owner can do this week. Never "explore". Never "consider". If the first move needs a meeting to plan the meeting, it isn't a first move.

The ten constraints so far

1. “Our codebase is too legacy for agents”

   False

   Reading old code nobody remembers is where agents pay off fastest. Legacy is the reason to start.

   What would have to be true: Agents can build and run the tests locally. Where there are no tests, adding them is the first agent task.

2. “We need to pay down tech debt first”

   False

   This gets the order backwards. Agents are how the debt gets paid down. Waiting means paying it by hand.

   What would have to be true: Name the debt that blocks agents specifically, such as no tests or no local build, and fix only that.

3. “Our seniors won't adopt it”

   False

   That's a leadership problem, not a constraint. Agents amplify what's already there, including a culture that treats not adopting as optional.

   What would have to be true: Leaders use it themselves, in the open, and the agent path is easier than the manual one.

4. “We need to hire AI engineers first”

   False

   The people who know your systems and your customers are the ones who can write the intent. New hires can't.

   What would have to be true: One owner per function who can write a real intent document.

5. “Let's wait for the models to get better”

   False

   The ceiling is how you work, not the model. Waiting keeps the interpreter in the loop.

   What would have to be true: Nothing. Start now.

6. “Security won't approve it”

   Negotiable

   Usually means nobody has asked with a specific proposal. Bring scope, sandboxing and data terms, not a vibe.

   What would have to be true: Scoped credentials, isolated execution, zero-retention vendor terms, and a named security reviewer.

7. “We can't prove the ROI”

   Negotiable

   Pick one workflow and measure how much hands-on time it takes today versus next month. Don't wait for a company-wide business case.

   What would have to be true: One baseline measured before the change starts.

8. “The platform team has to build it first”

   Negotiable

   Some shared plumbing is real, but it shouldn't block the first function. Buy first, build later.

   What would have to be true: A buy-versus-build call on agent infrastructure, with a deadline.

9. “Customer contracts forbid sending their data to a model”

   Real

   Read the actual clause. It often limits which data and which vendor, not all AI.

   What would have to be true: Legal reads the clause and names what's allowed.

10. “We're regulated (SOX, HIPAA, data residency)”

    Real

    It shapes how you do this, not whether. Regulated work still gets drafted by machines, with humans signing off.

    What would have to be true: Controls are mapped to the ladder. The audit trail comes from the pipeline, not from people.

The table gives you each ruling. What it doesn't show is that the ten collapse into three kinds, and once you see the kinds you can rule on most new constraints before you finish typing them.

Five of them are about waiting

Legacy code, tech debt, reluctant seniors, hiring AI engineers, better models. Read them again and they all say the same thing: something else has to happen first. And in every case, the thing that has to happen first is work the agents would do, or a decision only you can make.

Legacy is the clearest. The old service nobody wants to touch is the one where nobody remembers what "correct" means, and pinning that down with characterization tests is bounded, mechanical, checkable work. That is the order I'd run a legacy migration in, and it starts with the agent, not after it. Tech debt is the same argument from a different angle. You don't pay the debt down so agents can start. Agents are how it gets paid. The only debt that genuinely blocks them is the debt that stops them checking their own work: no tests, no local build. Fix that. Leave the rest on the list and hand it over.

"Our seniors won't adopt it" is a leadership problem wearing a constraint's clothes. The 2025 DORA report's central finding is that AI "amplifies what's already there", which cuts both ways. A culture where adopting is optional gets amplified too. The fix isn't a mandate memo. It is you, on a real ticket, with an agent, where people can see it. Leaders stay hands on now, or they stop being able to tell a two-month estimate from a three-day one.

Hiring AI engineers first gets the scarce skill wrong. The hard part is writing intent: the outcome, the trade-offs already decided, what would trigger a revisit. The people who can write that are the ones who already know your systems and your customers. A new hire spends months learning what your support lead knows today.

And waiting for better models is the purest form of the pattern. The model isn't your ceiling. How you work is. Anthropic's analysis of roughly 400,000 Claude Code sessions found verified success rates of about 15% for novice sessions against 28 to 33% for intermediate and expert ones. Same models, different people. A better model next year does not make your team intermediate. Practice does, and practice starts when you stop waiting.

Three of them have a price

Security, ROI and the platform team are negotiable. None of them is fake. All of them are usually unpriced.

"Security won't approve it" almost always means nobody has asked with a specific proposal. Security teams say no to vibes. They are much better at saying yes to controls. So bring controls. Meta's Agents Rule of Two, covered in Phase 1, gives you a scoping rule a CISO will recognise. The OWASP Top 10 for Agentic Applications is the checklist your reviewer can hold you to. On data terms, know what you are buying: Anthropic, for example, covers Claude Code under its BAA only when Zero Data Retention is active on a qualifying account, and terms change, so check them with each vendor before you rely on them. And take the lesson from the Replit incident, where an agent deleted a production database during a declared code freeze: "don't touch prod" is an instruction, not a control. Permissions are controls. Blast radius is a design decision you make before the first run, and a security team that sees you made it will sign.

"We can't prove the ROI" is negotiable because the proof is cheap if you collect it in the right order. One workflow, hands-on time measured before anything changes, measured again after. Do not substitute how people feel about it. Self-reported speed is not evidence. A baseline with a date on it is.

"The platform team has to build it first" is half right. Some shared plumbing is real. None of it should block the first function. The harness is a commodity now and the wiring is where your advantage lives, so buy for the first function and let the platform team build what the second and third turn out to need.

Two of them are real

Customer contracts and regulation are real. Real does not mean stop. It means the constraint gets designed around, and it changes how you do this, never whether.

For contracts, the first move is embarrassingly simple: read the actual clause. Not the summary someone gave in a meeting two years ago. The clause. It usually limits which data and which vendors, under which terms. That is a design input, not a veto.

For regulation, the pattern holds across SOX, HIPAA and data residency. Machines still draft the regulated work. Humans still sign it off. The difference an AI-native setup makes is where the audit trail comes from. Today it comes from people remembering what they did and writing it down afterwards. Built properly, it comes from the pipeline, which records every run whether anyone remembers or not. Map your controls to the ladder once, show the auditors once, and let the pipeline produce the evidence from then on.

Notice something about the two real ones. They already arrive with owners. Legal owns the contract. Compliance owns the control. They are written down, they have names on them, and that is why they are the easiest constraints on the list to work with. The false ones are the ones nobody ever wrote down.

Accept it or appeal it

Every ruling ends with a choice, and both choices go on your record.

Accept it and you set a date. For a false constraint, that is the date you stop believing it. For a negotiable one, it is when the owner pays the price. The ruling, the owner and the date go into your profile, show up in your check-ins until they are done, and land in the Court transcript you can hand to your exec team from your takeaways. A ruling you accepted and then ignored will be waiting for you.

Appeal it and you need new evidence. Not a louder version of the same claim. Not the seniority of the person who said it, how long it has been true, or how many people in the room agree. New evidence looks like an owner named where there was none (that alone gets you a fresh hearing), a clause Legal has actually read, a baseline you actually measured, or a written no from a security reviewer to a specific proposal. Bring one of those and the Court rules again, and the ruling can change.

An appeal needs new evidence. The same claim, louder, is still the same claim.

When you appeal, the call goes in your trust log: what the Court ruled, what you argued, and how the appeal came out. Both rulings stay on the record. Nothing gets quietly overwritten.

The trust log is the part most readers skip, and it is the part that teaches you the most. Over time it becomes a record of your own instincts about your own organisation. Appeal five times and lose five times, and that tells you something about how much weight your gut is carrying. Win, and that tells you something about the Court. Either way, you stop guessing when to push harder and start knowing.