For the last 26 years, I have worked on enterprise platforms and applications across healthcare, life sciences, insurance and finance domains.
Like many architects of my generation, I grew up designing systems around a handful of familiar layers — Presentation, Service, Domain, Persistence, and Infrastructure Services. Around them sat the cross-cutting concerns we never shipped without: Security, Logging, Caching, Exception Handling, Configuration Management, and Integration Services.
If you have built .NET systems for any length of time, you have probably opened the same Microsoft Learn page I have kept bookmarked for years — Common Web Application Architectures. The N-Layer diagram. UI → BLL → DAL. Then Clean Architecture, the onion, dependency inversion pointing inward to the domain. That page was a quiet anchor for a whole generation of us. It encoded a worldview.
This architecture served us remarkably well.
Whether we were building a policy management platform, a claims engine, a healthcare portal, or an ERP system, one assumption never moved:
The system is deterministic. Given the same input, it should always produce the same output.
Today, that assumption is being challenged - AI changes the very nature of the software inside the boxes.
The Deterministic World We Built
Let me ground this in something every architect has built at least once.
Suppose you need a dynamic form.
Historically, we solved this through database-driven metadata, XML configuration, JSON configuration, or a rules engine. The form could change but only within boundaries a developer had defined in advance.
The application stayed deterministic. The architecture was still controlling every possible outcome. Even our "dynamic" systems were, honestly, predefined systems wearing a flexible coat. The space of behaviour was finite, enumerated, and testable. We could write an assertion for every path because we had authored every path.
That was the whole game. We were master recipe writers. Our systems were a thali factory every plate identical, to the gram, because we had specified every step.
Enter the Non-Deterministic World
Now imagine an AI-powered onboarding application.
A user says:
"I am a 52-year-old diabetic patient seeking a second opinion for a heart condition."
Instead of loading a predefined form, the system can generate a completely new interaction flow different questions, different validations, different recommendations, different document requirements, different follow-up actions.
Another user, with a different context, receives an entirely different experience.
No configuration file contains all the possible paths. No developer anticipated every scenario. The system reasons from context.
This is the chef walking into the thali factory. Ask the same question twice and you may get two excellent but different plates. We have moved from:
Applications that execute rules → Applications that generate behaviour.
For an architect, that single sentence rewrites the job. We used to design the finite set of things the system can do. Now we design the conditions under which the system decides what to do. Determinism is no longer the default property of the platform. It has become a design choice we deliberately impose where we need it and deliberately relax where reasoning is the point.
Why Traditional Layered Architecture Is No Longer Enough
In most enterprise systems today, the architecture still looks like the Microsoft diagram:
UI → Services → Domain → Database.
And AI usually gets bolted on as one more service a call out to a model, a sentiment score, a summary. That is treating AI as a feature.
It works, for a while. But in many of the systems we will build next, AI is not a service the application calls. AI becomes the orchestration layer itself. The thing that decides what happens.
Instead of: User → Application → Database
we increasingly see: User → AI Agent → Tools → Knowledge → Systems
The application is no longer merely processing a request. It is reasoning about it. And the moment reasoning moves to the centre, a four-box layered diagram can no longer hold the design. The centre of gravity has shifted.
The New Building Blocks of AI-Native Architecture
Over the last two years of building with this, I have become convinced that architects need to think in terms of several new layers. Not buzzwords layers, with the same seriousness we once gave to the DAL.
1. Context Layer : context becomes the new database. Traditional applications store data. AI-native applications manage context: user profile, session and conversation history, organisational knowledge, business state, external signals. The chef is brilliant but knows nothing about your kitchen so what you hand him before each dish decides the dish. In my experience, the quality of the context, more than the cleverness of the model, determines the quality of the outcome.
2. Knowledge Layer : databases answer questions; LLMs need knowledge. This is where RAG, vector databases, enterprise documents, content repositories, and knowledge graphs stop being implementation details and become first-class architectural components. The hard problem is no longer storing information. It is making information discoverable and meaningful to a model at the moment of reasoning.
3. Reasoning Layer : rules give way to reasoning. LLMs, prompt orchestration, agent frameworks, planning engines, decision chains. We used to design how transactions happen. Now we must also design how reasoning happens — and how to keep it bounded.
4. Tool Layer : a model alone cannot run a business. It needs hands: CRM access, ERP access, payment systems, document generation, search, workflow engines. This is where MCP (Model Context Protocol) matters. MCP is emerging as a standard way for AI systems to discover and safely invoke enterprise capabilities. Think of it as the kitchen's standardised supply dock and, for our world, as the API gateway of the AI era. The same contract instinct we applied to REST and OpenAPI, now pointed at a model as the consumer.
5. Trust and Governance Layer : this may become the most important layer of all. We always worried about security, authentication, authorisation. We must now also worry about hallucinations, prompt injection, data leakage, model drift, explainability, and auditability. Prompt injection is the new SQL injection — there is even an OWASP Top 10 for LLM applications now. The inspector at the pass who tastes every plate before it leaves is no longer optional. The governance surface is significantly larger than anything we faced in traditional systems.
The Future Architecture May Look Like This
Instead of the classic stack — Presentation → Business Services → Domain → Persistence —
future systems may increasingly resemble: Experience Layer → Agent Orchestration → Reasoning → Context → Knowledge → Enterprise Tools & Systems → Data Platforms.
Notice the most uncomfortable change for people like me.
The database is no longer the centre of the architecture. For 26 years, the data model was where we started and the schema was sacred. In the new shape, Context and Knowledge become first-class architectural concerns, and the database becomes one well-governed tool among several that the reasoning layer reaches through. The crown moved.
What This Means for Architects
I do not believe we need to abandon what we know. If anything, our instincts become the moat.
Many principles remain absolutely timeless, separation of concerns, buy Vs. build, security, scalability, reliability, observability, domain modelling. The AI stack does not retire a single one. It needs them more, precisely because it has dropped a probabilistic component into the middle of a deterministic enterprise.
But we must expand our thinking. Tomorrow's architects will need genuine fluency in LLMs and SLMs, RAG, knowledge graphs, agentic systems, MCP, prompt engineering, AI governance, and context management the way we once had to learn ORMs, message buses, and the dependency inversion principle.
And a few hard-won guardrails I would put on every AI-native design:
The model proposes; your validated, coded systems dispose. Never let a probabilistic component be the last line of defence on money, identity, or compliance.
Keep the deterministic rules in code, as guardrails around the model and not inside a prompt. The chef improvises the dish; the chef does not get to override the food-safety law.
Treat the model as a swappable dependency behind an interface. You would never marry a single database vendor; do not marry a single model.
Testing becomes evaluation. You cannot a distribution. Regression suites grow eval sets and acceptance thresholds beside them.
The role is evolving from designing software structures to designing intelligence systems. We are not being replaced; we are being promoted into a harder, more interesting job. We did not stop being architects. We hired a chef and our work is still to design the kitchen he cannot burn down.
That is a profound shift. Perhaps the biggest architectural transition I have witnessed since I started my career in 1999-2000.
And I believe we are only at the beginning.
One question for the architects here: in your current system, where would you let the model reason freely and where would you keep the recipe absolutely locked? That single boundary is the most important line you will draw this year. I would genuinely like to read your answer in the comments.
First published on LinkedIn.