AI-Native Enterprise Architecture Needs a Constitution

There’s a post making the rounds from Sergey Sergeyev, a chief enterprise architect, that names something the EA world has been circling for years: the framework wars were the wrong argument. TOGAF, Zachman, FEAF, Gartner — pick your favorite, it doesn’t matter. The real disruption isn’t that TOGAF got outdated. It’s that AI-native enterprises evolve faster than any static framework can describe them.

That’s correct, and it took some nerve to say in a profession that sells certifications in the thing being buried.

Where I want to push is the next line. The conclusion offered is that the future of enterprise architecture is “architecting adaptive intelligence.” I’ve read that sentence four times and I still can’t build anything from it. It’s a diagnosis wearing a prescription’s clothes.

So let me try to say the buildable version, because I’ve spent the last several months doing exactly this in a real repository, and the answer turned out to be narrower and more boring than a new framework.

What actually expired

The frameworks didn’t fail on rigor. TOGAF is rigorous. Zachman is genuinely clever. They failed on tense.

A framework produces description. A blueprint is a claim about the system that is true at the moment of writing and decays from that moment forward. That was survivable when the system changed quarterly. It is not survivable when the system redesigns itself on Tuesday and again on Thursday, and when a portion of the redesigning is being done by agents that don’t read your Confluence space.

Under those conditions, description has a half-life of about a week. You’re no longer maintaining an architecture. You’re maintaining a fiction about the architecture, and paying an architect’s salary to keep the fiction plausible.

And the cost isn’t the drift. Drift is cosmetic. The cost is that people keep making real decisions out of the fiction — sizing a project, approving a dependency, promising a regulator — while the actual system quietly stopped matching it.

Blueprints describe. Constitutions refuse.

Here’s the move: stop trying to describe the system and start constraining it.

A constitution is not a longer blueprint. It’s a much shorter one with teeth. It doesn’t attempt to say what the system is. It says the handful of things the system may never do — in a form the system itself can check, on every change, without a human remembering to.

The distinction is not philosophical. It’s mechanical:

• A description is read by humans, and decays silently.
• A constraint is executed by machinery, and either holds or fails loudly.

Every governance artifact you own is one or the other. Most orgs have hundreds of the first and almost none of the second, then wonder why governance feels like theater. It feels like theater because it is — a document that cannot refuse anything is a performance of control, not control.

The obvious objection

Someone is already typing it: you just spent a thousand words burying frameworks, and you run a methodology.

Fair. SQUEIL is built on one — SPEED, subtitled How to Think, and Deliver, in the Spec-Driven, Agent-Orchestrated Era. There’s a body of knowledge. It has chapters. I am not pretending otherwise.

But read what it actually claims. SPEED is deliberately framework-neutral, tool-neutral, and domain-neutral. It applies to any delivery context in which specifications are authoritative, quality is validated mechanically, and multiple cooperating roles — human, automated, or both — coordinate through explicit information boundaries.

Now read that with the argument above in mind. Specifications are authoritative. Quality is validated mechanically. That is not a description of an enterprise. It is a commitment about how an enterprise’s work is permitted to move.

That’s the distinction the framework wars talked straight past. TOGAF and Zachman describe what the enterprise is — and a snapshot of a thing that redesigns itself on Tuesday is obsolete by Thursday. A delivery methodology governs how change is allowed to happen, which doesn’t decay, because it was never a snapshot in the first place.

And the sharpest thing I can say about our own: SPEED always prescribed evidence. What changed is that the tooling now demands it. Prescribing evidence gets you a document that asks nicely. Demanding it gets you a build that fails. Same principle either way — only the second one has ever stopped anything.

So the claim isn’t no frameworks. It’s narrower and, I think, harder to argue with: the part of your framework that describes will rot, and the part that refuses will hold. Most EA practice invested almost entirely in the first.

What that looks like in an actual repository

I run a system called SQUEIL. Its operations layer — the thing that governs the platform, squeil-ops — is where I’ve been testing whether any of this survives contact with a working build. Some of what’s there:

Decisions are records, not slides. Every governance decision is an append-only file in a registry that projects into a running governance log inside the app. Not a deck, not a wiki page, not a Slack thread that scrolled away. If you can’t point at the record, the decision didn’t happen.

Every proposed decision ships four artifacts. The decision record itself; a screenshot from a running environment proving the thing exists; the implementation, already built and working, carried as a draft pull request; and current specs.

If you don’t live in a codebase: a pull request is a proposed change to the software, parked in the open where anyone can read it, run it, and argue with it — and which cannot take effect until someone with the authority to approve it does. A draft pull request isn’t even eligible for that yet. So the implementation exists, in full, in a form that cannot ship — not because a rule forbids it, but because a draft is mechanically ineligible to be merged at all. The evidence and the safety are the same object, which is the whole trick.

A scanner reads the artifact block and treats an absent or incomplete one as drift — non-zero exit. You can write N/A with a reason. You cannot write nothing. Silence fails the build.

Some constraints are architectural, not policy. The strongest rule in the system says no hosted component may hold a credential capable of writing to the ops repo or database. Not shouldn’t — the credential is not present on the hosted surface. Cloud runners can read; they are structurally incapable of writing. That’s the difference between a locked door and a sign that says “please don’t.”

Merges pass a gate that returns a verdict. Before a proposed change can be folded into the live codebase, a script evaluates the pull request and returns eligible or it doesn’t. And the load-bearing clause is the negative one: if the gate can’t run, don’t merge. Guards that fail open are the most expensive kind, because they read as protection right up until the audit.

Agents propose. A human ratifies. Automated runs execute freely inside decisions that are already ratified, and nothing outside them. When a run discovers it needs a decision that doesn’t exist yet, that’s a stop condition — not an obstacle to route around. It halts that thread, drafts the proposal with full evidence, and keeps working on everything the missing decision doesn’t block.

That last one compresses to five words that I think are the whole answer to Sergey’s post:

An honest note, since this piece is otherwise in danger of sounding like a victory lap: squeil-ops is not deployed anywhere. It runs on one machine, on purpose, under a standing block that clearing the preconditions does not lift — only an explicit ruling does. I’ve had the boxes ticked for a while now and the block still stands, because “the conditions are met” and “we decided” are different events and collapsing them is how systems get quietly widened. That constraint costs me convenience most weeks. That’s roughly how I know it’s real.

Adaptive is not the same as ungoverned

Here’s my worry about “architecting adaptive intelligence” going mainstream as a phrase.

The organization most eager to hear that frameworks are dead is very often the one that never enjoyed being told no. “We’re AI-native, we move differently” is about nine months from becoming the highest-status way to say we skipped the review.

So the correction has to be stated plainly: adaptive systems need more invariants, not fewer. What they need far less of is description. The ratio flips.

You genuinely cannot build a rulebook for an organization that is redesigning itself every day. You can build a small set of refusals it has to redesign itself around. That’s not a lesser version of architecture. In an AI-native shop it’s the only version that stays true between Monday and Friday.

I made the same argument from a different angle a few weeks back in Capability Was Never the Hard Part — the industry is racing on how smart the model is, when the binding constraint is how much of that intelligence you can prove is safe to switch on. And if you want the ground-level version of what a governance sprint actually feels like, that’s in Two Days, One Charter.

The part nobody is staffing

Now the awkward implication, which is really why I’m writing this.

If enterprise architecture stops being drawing and starts being governing, the scarce skill changes completely. The question is no longer “can you produce the layer diagram.” It’s:

Can you take a policy stated in one English sentence, turn it into a rule a machine enforces on every change, and then demonstrate that the rule actually fires when violated?

That’s a third kind of person. It isn’t the framework-certified architect, who can describe a system beautifully and has never once caused a build to fail. And it isn’t the prompt-fluent developer shipping five features a day who can’t tell you what, in the entire pipeline, would have stopped a bad one.

It’s someone who can read the canon, write the constraint, produce the evidence, and — the step almost everyone skips — deliberately break the rule to prove the guard can catch it. A control you’ve never seen fail is not a control you’ve verified. It’s a control you’re hoping about.

The genuinely good news, and the reason I’m not gloomy about the profession: this is trainable. It is not a four-year computer science degree. It’s a craft, with a small number of teachable moves, and the people who turn out to be best at it are frequently not the people with the pedigree. They’re the ones with the temperament — the ones who read a green checkmark and instinctively ask what it would take to make it red.

DevForge Academy

That’s the whole thesis behind DevForge Academy, which is the training side of what I’m building.

The premise is that a platform letting small operators run sovereign, AI-augmented businesses is worth nothing if there’s nobody who can implement it properly. So the academy exists to produce implementors who can run a governed AI-native build: people who know a canon from a wiki, a constraint from a preference, and a rule that reads like protection from one that can actually refuse.

That isn’t a curriculum I invented to have something to sell. SPEED already names three career tracks — Implementor, Practitioner, Architect — because a methodology that takes mechanical validation seriously has to say who is accountable for the machinery. DevForge Academy is the Implementor track with a door on it.

Dignity through competence — that’s the part of this project I’m proudest of. The fastest way to change somebody’s situation isn’t a benefit. It’s a skill, a peer group, and a path to paying work. And the skill I’ve just described happens to be one the market is about to need badly and has almost no pipeline for.

Where it honestly stands: the curriculum is being built, the first cohort is forming, and the commercial shape is not settled. I’d rather say that than imply a finished product.

If that’s the kind of work you want to be doing — or you’re hiring for someone who can do it — the academy is at devforgeacademy.com.

Where I’d leave it

Sergey is right that the profession’s most sacred assumptions are quietly expiring, and right that it should feel uncomfortable. My only amendment is to the remedy.

Adaptive intelligence doesn’t get architected by describing it faster. Nothing describes fast enough anymore. It gets architected by deciding — in advance, in executable form, in a place the machinery reads on every single change — what the system is not permitted to do, and then letting it move as fast as it possibly can inside that.

The blueprint was never the valuable artifact. The refusal was.

We just used to write our refusals in documents that couldn’t enforce them, and call the document architecture.

---

Patrick Roden is the CIO/CEO of On Top Home Services LLC, the exterior cleaning company serving as SQUEIL’s founding proof-of-concept tenant, and is implementing the SQUEIL project. He writes about platform architecture, governance, and the practical seam between AI tooling and operational discipline.