What a 20th Century Architect Can Teach Us About Building AI Systems
Contextual Architecture - Part 6: Design Patterns for the AI Age
Design Patterns for the AI Age
What a 20th Century Architect Can Teach Us About Building AI Systems
The best AI system your company will ever build won’t be designed by an engineer.
That’s not a knock on engineers. It’s a recognition that engineering and design are different disciplines — and that most enterprise AI projects have plenty of the first and almost none of the second. The result is systems that are technically impressive, institutionally brittle, and quietly frustrating to everyone who has to live with them.
There’s a better framework. It comes from an unlikely source: a mid-century architect who spent his career studying what makes buildings feel alive.
The Design Deficit in AI
Most AI systems are built the way bridges are built: with rigorous attention to load-bearing requirements and almost no attention to whether anyone would want to walk across them.
Engineers solve engineering problems. That’s exactly what they should do. But when a system is designed only by engineers solving engineering problems, you get a specific failure mode: technically powerful, institutionally brittle. The system does what it was designed to do. It doesn’t do what the organization needs — which is a different thing, and one that changes over time.
The symptoms are familiar:
- Systems that don’t compose. You have an AI tool for customer service, another for research, another for drafting. They don’t talk to each other. Every handoff is manual.
- Systems that don’t adapt. The vendor updates the model; your carefully tuned prompts break. You had no architecture to absorb the change.
- Systems that don’t develop character. After two years of use, the system is no smarter about your business than it was on day one. It processes data. It doesn’t accumulate wisdom.
The missing ingredient isn’t more engineering. It’s design thinking applied at the system level.
A building designed entirely by structural engineers would be safe. It would not be livable. Great buildings have both: the engineering and the design. They’re structurally sound and humanly inhabitable. Your AI systems need both too — and right now, most of them only have one.
Christopher Alexander’s Unlikely Relevance
Christopher Alexander was a mathematician-turned-architect who spent decades asking a deceptively simple question: what makes some environments feel alive, while others feel dead?
Not aesthetically pleasing. Not architecturally fashionable. Alive — in the sense that they support human activity, evolve gracefully over time, and feel right in ways that are difficult to articulate but impossible to ignore.
His answer, developed across decades of research and four dense volumes published between 1977 and 2005, was this: living environments emerge from a specific set of structural properties — properties that appear consistently in everything from medieval town squares to biological cells to well-designed software.
That last one is not a stretch. Alexander’s ideas were so resonant with software developers that they became foundational to the entire field of software design patterns. The Gang of Four’s Design Patterns (1994) — arguably the most influential software engineering book of the past thirty years — explicitly credits Alexander’s work. The concept of a “pattern language” is his.
But most AI builders today have never encountered Alexander’s ideas. They’re building systems with the vocabulary of engineering and none of the vocabulary of design. That’s a gap worth closing.
Centers and Wholeness: The Core Insight
Alexander’s most fundamental contribution was the concept of centers.
A center is any coherent, identifiable element within a larger whole — a doorway, a room, a courtyard, a neighborhood. Centers exist at every scale. And the quality of a design — its aliveness — comes not from the quality of any individual center, but from how centers support each other.
A great room isn’t great because of its dimensions. It’s great because the windows frame the light in a way that makes the furniture arrangement feel natural, which makes the conversations that happen there feel easy, which makes the room feel like a place people want to return to. Each element makes the others stronger. The whole is genuinely greater than the sum of its parts.
Now apply this to AI architecture.
Contextual Architecture is built on four layers: context, reasoning, governance, and orchestration. In engineering terms, these are services with defined interfaces. In design terms, they are centers — and the architecture works because each one makes the others more powerful:
- Context makes reasoning possible. Without relevant knowledge, reasoning is just pattern-matching against training data.
- Reasoning makes governance meaningful. Without traceable logic, governance is just blocking — there’s nothing to evaluate.
- Governance makes orchestration trustworthy. Without accountability, orchestration is just automation — fast, but unaccountable.
- Orchestration makes context actionable. Without workflow execution, context is just a library — valuable but inert.
Remove any one layer and the system doesn’t just lose that capability. It becomes less coherent everywhere. The centers depend on each other for their strength. That’s not an engineering observation. It’s a design one.
Five Properties That Matter for CEOs
Alexander identified fifteen structural properties that appear in every living system. Not all fifteen are equally relevant to AI architecture — some are more about visual harmony, others about spatial organization. But five of them map so directly to the challenges CEOs face when evaluating AI systems that they function as a practical diagnostic framework.
Think of this as a checklist you can take into your next AI vendor evaluation.
1. Levels of Scale
Living systems have meaningful structure at every level — from the city block to the building to the room to the doorknob. Each level is coherent on its own and connects to the levels above and below it.
Most AI deployments are single-level: operational. They answer questions, generate text, summarize documents. That’s one level — and a useful one. But it’s not a system. It’s a tool.
A system has structure at multiple levels:
- Strategic — how AI supports institutional goals and long-term decision-making
- Tactical — how AI-assisted processes are governed and improved over time
- Operational — how individual AI calls are executed, monitored, and audited
Contextual Architecture operates at all three levels. Most point solutions operate at one.
CEO diagnostic: Can you describe how your AI investments operate at the strategic, tactical, and operational level? Or do you have a collection of operational tools with no connective tissue above them?
2. Strong Centers
Each component of a living system should be independently valuable — with a clear purpose and clean boundaries. You should be able to describe what it does in one sentence.
Weak centers are components that only make sense in the context of other components. They’re not independently valuable; they’re just pieces of a machine. Systems built from weak centers are hard to understand, hard to change, and impossible to improve incrementally.
Strong centers in AI architecture look like: a context layer that works without a specific reasoning system. A governance framework that can be applied to different orchestration engines. A workflow template that produces value whether it runs on this vendor’s infrastructure or that one’s.
CEO diagnostic: Can you describe what each piece of your AI architecture does in one sentence? If a new executive joined your company tomorrow, could you explain your AI system in terms of coherent components — or would the explanation devolve into “it’s complicated”?
3. Boundaries
The edges between components matter as much as the components themselves. Clear boundaries enable independence — and independence enables evolution.
This is the architectural principle behind clean APIs, service contracts, and interface definitions. When the boundary between two components is explicit and well-defined, either component can be replaced or upgraded without rebuilding the whole system. When the boundary is implicit — when components are tightly coupled in ways nobody fully documented — changing anything becomes dangerous.
In AI systems, boundary failures look like: a workflow that only works with one specific model. A reasoning system that can’t be audited because its logic is buried inside a vendor’s proprietary black box. A governance layer that’s so entangled with the orchestration layer that you can’t update one without breaking the other.
CEO diagnostic: If your primary AI vendor went out of business tomorrow, how much of your system would you have to rebuild? The answer tells you how well your boundaries are defined.
4. Not-Separateness
Here’s the paradox: while boundaries should be clear, components shouldn’t be isolated. They should flow into each other — connected by shared protocols, common vocabularies, and mutual awareness.
Alexander called this “not-separateness” — the quality of belonging to a larger whole while remaining distinct. A great room has clear walls (boundaries) but opens naturally to adjacent spaces (not-separateness). It knows where it ends and where the hallway begins, but the transition feels intentional, not abrupt.
In AI systems, not-separateness means your tools talk to each other. Context flows into reasoning. Reasoning informs governance. Governance feeds back into orchestration. The system is connected — not through manual integration work, but through shared protocols designed from the start.
The opposite is what most companies actually have: AI islands. A research tool that doesn’t know about the customer data tool. A drafting assistant that doesn’t know about the governance framework. Each island works fine on its own; together, they require a human to carry information between them.
CEO diagnostic: How much manual bridging does your team do between AI tools? Every manual handoff is a boundary that should be a connection.
5. Roughness
This one surprises people. Alexander observed that the most enduring, livable environments are not perfectly polished. They have intentional imperfection — room to adapt, to accommodate the unexpected, to absorb change without breaking.
Over-polished systems are brittle. They work beautifully within their design parameters and fail catastrophically outside them. The more precisely a system is tuned to expected inputs, the more vulnerable it is to unexpected ones.
AI systems with “roughness” handle novelty gracefully. They don’t encode rigid assumptions about what inputs will look like. They have fallback paths, escalation routes, and graceful degradation modes. When they encounter something unexpected, they adapt — or at minimum, they fail in ways that humans can understand and correct.
AI systems without roughness break at the edges. They hallucinate confidently when they should say “I don’t know.” They apply the wrong template to an edge case because no one designed a path for “this doesn’t fit any template.” They produce outputs that are technically within spec but obviously wrong to anyone paying attention.
CEO diagnostic: What happens when your AI system encounters something it wasn’t designed for? Does it degrade gracefully, escalate appropriately, and flag uncertainty — or does it confidently produce a wrong answer?
The Fundamental Differentiating Process
Beyond the fifteen properties, Alexander’s most practically useful contribution was a decision-making method he called the Fundamental Differentiating Process.
The question is simple: does this change make the whole more alive, or less?
Not: is this feature useful? Not: does this vendor have good reviews? Not: is this cheaper than the alternative? Those questions have their place. But they’re incomplete. They evaluate the part without evaluating the effect on the whole.
The Fundamental Differentiating Process asks the harder question: what does this do to the system as a system? Does adding this capability make everything more coherent, or more complex? Does this vendor’s architecture compose with ours, or create a dependency we can’t escape? Does scaling this function strengthen the whole, or create an imbalance that pulls the system out of alignment?
This maps directly to how great investors think about business decisions. Warren Buffett’s “moat” analysis doesn’t just ask whether a business is profitable — it asks whether each decision deepens the moat. Does this acquisition make the whole business stronger? Does this product extension reinforce the core competitive advantage, or dilute it?
The Fundamental Differentiating Process is the design equivalent of moat analysis. Before any AI investment decision, ask: does this make the whole more alive?
- Adding a feature: Does it make the overall system more coherent, or more complex?
- Choosing a vendor: Does their architecture compose with yours, or create a lock-in dependency?
- Scaling a capability: Does it strengthen the whole system, or create an imbalance?
- Retiring a component: Does removing it simplify the system, or break connections that were doing quiet work?
This is a framework CEOs can apply immediately — in the next vendor meeting, the next architecture review, the next AI investment discussion.
Pattern Languages: Reusable Solutions to Recurring Problems
Alexander’s most famous contribution to software isn’t the fifteen properties or the Fundamental Differentiating Process. It’s the idea of a pattern language.
A pattern is a named, reusable solution to a commonly occurring problem in a specific context. It’s not a recipe to follow blindly — it’s a proven approach that captures the judgment of people who’ve solved this problem before, in a form that others can apply to their own situation.
Software engineers have been building pattern libraries for thirty years: Factory, Observer, Strangler Fig, Two-Phase Commit. These names mean something. When an engineer says “we should use the Strangler Fig pattern here,” every other engineer in the room immediately understands the approach, the tradeoffs, and the implementation considerations. The pattern is a shared vocabulary that accelerates every conversation.
AI operations are developing their own patterns. They don’t have widely agreed names yet — the field is too young. But the recurring problems are already visible, and the solutions are emerging:
- Context Bundle — assemble all relevant institutional knowledge before initiating reasoning. Don’t let the AI reason in a vacuum.
- Multi-Perspective Review — have multiple AI agents evaluate a decision from different angles before committing. Disagreement between agents is a signal, not a problem.
- Escalation Threshold — define in advance the conditions under which AI decisions require human or committee review. Don’t let the system decide when to escalate.
- Citation Trail — every AI claim links to source evidence. No assertion without a receipt.
- Template Evolution — workflows improve through versioned iteration. Each version is an experiment; each outcome is data.
Building a pattern library for your organization is one of the highest-leverage investments you can make in AI operations. It’s the difference between a team that has to rediscover good solutions every time they face a recurring problem, and a team that can say “we use the Context Bundle pattern here” and move on.
Every consulting firm has best-practices playbooks. Every functional department has standard operating procedures. Your AI operations need a pattern library. The organizations building theirs now will have a vocabulary — and a head start — that’s very difficult to replicate.
Living Systems vs. Dead Systems
Alexander’s ultimate distinction is the one that matters most for long-term AI strategy: some systems become more alive over time. Others become more rigid and eventually fail.
The difference isn’t about technology. It’s about architecture.
An AI system is alive when:
- It accumulates institutional knowledge — not just processes data, but retains and applies what it’s learned about your business
- Its governance evolves based on experience — past decisions inform future guardrails
- Its workflows improve through use — each iteration is better than the last because outcomes feed back into templates
- New needs can be addressed by composing existing capabilities — you build on the system, not around it
An AI system is dead when:
- It’s locked to a vendor’s update cycle — the system changes when the vendor decides, not when your needs do
- It can’t learn from its own decisions — every query starts from scratch, with no accumulated context
- Adding a new capability requires a new system — your AI estate grows by addition, not by composition
- It doesn’t get better as the organization uses it — two years in, it’s the same system you deployed on day one
Most enterprise AI deployments today are dead systems. That’s not a criticism of the technology — it’s a criticism of the architecture. The technology is capable of living behavior. Most deployments don’t unlock it, because they weren’t designed with that goal.
The medieval towns Alexander studied — the ones that felt most alive — weren’t designed by a single master planner. They were built incrementally, by many hands, following shared patterns. Each addition respected the whole. Each builder understood the language. Over centuries, the result was environments of extraordinary coherence and vitality.
The same principle applies to AI architecture. Composable, pattern-driven systems — built on shared protocols and clear design principles — produce more coherent, more adaptable, more enduring results than monolithic platforms designed by a single vendor.
LEGO or Playmobil? LEGO gives you a system of composable elements that can build anything. Playmobil gives you a beautiful, fixed scenario. Both have their place. But only one grows with you.
The CEO question to ask about every AI investment: Is this building a living system that grows with my company — or a dead system I’ll be replacing in three years?
Design Is Not Optional
The companies that will win with AI aren’t the ones with the most tools. They’re the ones with the best-designed systems.
Engineering gets you to working. Design gets you to enduring. The principles Alexander identified — strong centers, clear boundaries, appropriate roughness, not-separateness, structure at every scale — aren’t abstract philosophy. They’re a diagnostic framework you can apply to any AI system or investment decision, starting today.
Ask whether your AI systems have meaningful structure at multiple levels. Ask whether each component has a clear, independent purpose. Ask whether your tools are connected or isolated. Ask whether your system handles the unexpected gracefully. Ask whether each new decision makes the whole more alive.
These questions don’t require a technical background to answer. They require the same judgment you apply to every other strategic decision: does this make the whole stronger?
That’s the design lens. And it’s the one most AI builders are missing.
Design principles tell you what good looks like. But how do all these layers — context, reasoning, governance, orchestration — actually come together in practice? How do you take a business problem from “we should use AI for this” to a fully functioning, governed, auditable AI operation? That’s the orchestration story — not of workflows, but of the entire architecture. Continue to Part 7: The Operating System for Institutional Intelligence.
Austin Fatheree
AI-STRATEGY
contextual-architecture ai-governance enterprise-ai caio thought-leadership