The First Four Pillars Were About Structure. The Next Four Are About Behavior.
A few weeks ago, I argued that four architectural pillars have survived more than two decades of software evolution: Contract, Discovery, Isolation, Composition. I still believe they’re fundamental. But after publishing that article, one question kept bothering me.
Those four pillars describe how software components connect safely — how systems discover capabilities, agree on interfaces, isolate failures, and compose independent parts into larger solutions. What they quietly assume is that the thing being composed has fixed behavior. AI-native systems break that assumption. And once behavior is no longer fixed, the original pillars don’t become wrong — they become incomplete.
The layer traditional architecture doesn’t describe
Classical software is deterministic: developers write the behavior, and the architecture simply delivers it. AI-native systems are different. Their behavior is emergent rather than explicitly programmed, probabilistic (identical inputs may produce different outputs), and it changes over time as models, prompts, knowledge, and the surrounding world evolve.
That creates an entirely new architectural concern. The original four pillars govern structure; they say very little about behavior. You can build a system with perfect interfaces, elegant composition, and flawless isolation — and still end up with an AI that is confidently wrong. Every connection correct, every boundary secure, yet the behavior inside those boundaries slowly drifting away from what you intended. The question isn’t whether the structural pillars still matter. They absolutely do. The question is: what governs behavior?
Evaluation — the new Contract
In traditional software, contracts are written. In AI systems, contracts are measured. Reading the source code won’t tell you how an AI behaves — only continuous evaluation can. Your evaluation suite becomes the real specification; behavioral telemetry becomes the real operational evidence. Every behavior that matters must be measured continuously, because if you’re not measuring it, you’re not governing it. And if you can’t measure it, you don’t really have a contract. You have hope.
Steerability — the new Discovery
Discovery used to mean finding capabilities. Steerability means guiding them. Instead of asking “Can this system perform the task?” we increasingly ask “Can we keep it performing the task correctly as everything around it changes?” That’s a profound shift. Traditional software is built; AI-native systems are cultivated. They require observation, feedback, calibration, prompt refinement, retrieval improvements — continuous adjustment. The architect’s role becomes less like building a machine and more like tending a living ecosystem.
Provenance — the new Composition
Traditional software makes accountability relatively straightforward: when something fails, you inspect the execution path. With AI, that path becomes much harder to follow. Models call tools, agents invoke other agents, outputs become inputs, reasoning chains emerge dynamically — the wiring no longer tells the whole story. Provenance restores accountability: every significant decision should be traceable. What information was used? Which model participated? Which tools were invoked? What authority permitted the action? These questions shouldn’t only be answerable after an incident — they should be answerable at any time. In AI-native systems, “we’re not sure why it happened” is no longer an acceptable answer.
Containment — isolation raised one level
Isolation used to protect software from failures. Containment protects organizations from agency. The architectural question changes from “What can this code break?” to “What is this AI allowed to decide?” Containment means limiting authority — not merely limiting access. It means human approval for irreversible actions, least-privilege agency, treating every input and output as untrusted, and keeping authority intentionally smaller than capability. One sentence captures the entire shift: we used to contain code; now we contain agency.
Reversibility — the foundation beneath everything
Everything above rests on one unavoidable truth: AI systems will be wrong. Not occasionally, not exceptionally — regularly. That’s not a flaw; it’s the operating model of probabilistic systems. The goal isn’t to eliminate mistakes — it’s to make them inexpensive. Design for rollback. Design for recovery. Design for uncertainty. Design systems that know when to stop and ask for help instead of confidently guessing. Human oversight isn’t a feature; it’s part of the architecture. Without reversibility, every other behavioral pillar is standing on unstable ground.
The verbs tell the story
Something interesting happens when you look at these five pillars together: each naturally maps to a different responsibility. You design with Evaluation, deploy behind Containment, cultivate through Steerability, govern with Provenance, and manage through Reversibility and continuous evaluation. Those verbs describe the lifecycle of AI-native systems. Unlike traditional software, the system you launch today won’t be exactly the system you’re operating a year from now — even if you never deploy another line of code.
Two final thoughts
First, this isn’t an established architectural doctrine. The original structural pillars have decades of industry consensus behind them; these behavioral pillars are simply my attempt to describe a pattern I keep seeing across AI-native systems. Treat them as a framework to challenge your thinking, not a checklist to memorize. Second — and perhaps more importantly — don’t let the excitement around AI convince you that everything has changed. It hasn’t. Contract, discovery, isolation, composition remain just as essential as they were twenty years ago. They simply no longer describe the whole architecture.
AI-native systems require two complementary layers: the structural layer ensures software connects safely; the behavioral layer ensures it remains trustworthy as it evolves. One makes systems work. The other makes people continue trusting them. In the years ahead, I suspect successful AI architectures won’t be defined by how intelligent they become — they’ll be defined by how well they govern that intelligence.
If you’re building AI-native systems today, which of these behavioral pillars are truly operational in your organization — and which exist only in architecture diagrams? In my experience, the gap between those two lists is exactly where the next production incident is waiting.