The model was built for humans. Here is what changes — and what doesn’t — when the actors are autonomous.
A while ago I wrote a blog post outlining a 5 layer architecture to move from strategic theater to a scalable growth engine. Feedback from readers and parallel work on agentic architectures triggered this adapted version of the original North Star Architecture article.
The North Star Architecture was designed for a specific world.
A world where humans initiate actions.
Where software responds to requests.
Where integrations follow contracts.
Where data is queried, not reasoned over.
That world is not disappearing.
But a new one is arriving alongside it. Or in fact, already arrived.
A world where software agents initiate actions without being asked.
Where AI reasons over data instead of querying it.
Where workflows are not orchestrated by humans — they are orchestrated by other AI systems.
Where the boundary between “tool” and “actor” dissolves entirely.
This is the age of agentic AI.
And it raises a legitimate question for anyone who has invested in platform architecture.
Does the five-layer model still hold?
The answer is yes — but not without confronting where it bends, where it breaks, and where it needs to grow.
What Makes Agentic AI Architecturally Different
Before mapping the layers, it is worth being precise about what agentic AI actually changes.
Traditional software is reactive.
A user clicks. A system responds.
The flow is synchronous, deterministic, and human-initiated.
Agentic AI is proactive and autonomous.
An agent perceives a state. It decides an action. It executes — often without human initiation.
The flow is asynchronous, probabilistic, and self-directed.
This creates four architectural tensions that the original model was not designed to absorb.
The actor problem.
The five layers were designed assuming the actor — the entity initiating requests — is a human.
Agentic systems introduce a new actor: the AI agent itself.
Agents don’t just consume the platform. They navigate it, invoke capabilities, generate new data, and trigger downstream workflows.
The architecture has to serve two fundamentally different kinds of actors simultaneously.
The orchestration problem.
Traditional integration assumes predictable, contract-based flows.
Agent A calls API B. API B returns a result. Done.
Agentic workflows don’t work that way.
An agent might invoke five capabilities in parallel, evaluate the results, spawn sub-agents, revise its plan, and retry — all without human involvement.
The integration fabric was not designed for choreography at this level of complexity.
The trust problem.
In traditional systems, trust is structural.
A service is authorized or it isn’t. An API key is valid or it isn’t.
Agents introduce probabilistic, context-dependent behavior.
The same agent, given the same task, might take different actions.
Trust can no longer be purely structural. It must be behavioral and monitored continuously.
The memory problem.
Traditional applications maintain state in databases.
Agents need a fundamentally different kind of memory — context that persists across interactions, that retrieves the right information at the right moment, and that allows the agent to reason effectively without losing coherence.
This is not what data platforms were built to provide.
With these tensions in mind, the five layers look different.
Layer 1 — Experience Layer
The interface now has two kinds of users
The Experience Layer was designed for humans.
Composable interfaces. Feature flags. Experimentation. Design systems.
All of that still matters.
But in an agentic world, the Experience Layer acquires a second class of user.
The agent.
Agents don’t use interfaces the way humans do.
They don’t click buttons. They don’t navigate menus.
They invoke capabilities, read outputs, and decide next steps — programmatically.
This means the Experience Layer must now serve two fundamentally different interaction models.
Human-facing surfaces — the apps, portals, and workflows customers and employees use.
Agent-facing surfaces — structured, machine-readable interfaces that agents can navigate without ambiguity. These include conversational interfaces that accept natural language instructions, tool manifests that describe what an agent can do and how, and action surfaces that expose human workflows as agent-invokable operations.
The implications for architecture are real.
A composable UI designed only for humans will not translate into a reliable agent interface.
An agent interface designed without human oversight capabilities will not be trustworthy.
The most forward-looking organizations are designing both from the start — not retrofitting one onto the other.
They are also introducing a new pattern into the Experience Layer:
Human-in-the-loop surfaces.
Not every agentic action should be autonomous.
Some decisions require human confirmation — an approval step, a review gate, an exception escalation.
These surfaces don’t exist in traditional experience design.
In agentic architectures, they become critical.
Layer 2 — Product Capability Layer
This is where agents live
If the Experience Layer gains a new kind of user, the Product Capability Layer gains an entirely new kind of resident.
In the original model, this layer contained domain services, workflow engines, analytics capabilities, and AI services.
In an agentic architecture, agents themselves become capabilities in this layer.
This is the most structurally significant shift in the entire model.
An agent is no longer just a consumer of the platform.
It is a published, composable, reusable capability — just like an authentication service or a reporting engine.
This has a name in agentic platform design: the agent registry.
The agent registry is the catalog of available agents — their purpose, their inputs and outputs, their trust level, their operational constraints.
Just as the product capability layer makes human-built services available to stream-aligned teams, the agent registry makes agent capabilities available to orchestrating systems, to other agents, and to human product builders.
This enables a pattern that fundamentally changes how products are built.
Agent composition.
Instead of building a workflow from API calls, a product team assembles a workflow from agents — each one specialized, each one accountable for a specific type of reasoning or action.
A research agent that retrieves and synthesizes information.
A planning agent that breaks a goal into subtasks.
A validation agent that checks outputs before they propagate.
An execution agent that takes actions in external systems.
These are not science fiction. They are the building blocks of a mature agentic Product Capability Layer.
The architectural principle from the original model still holds perfectly here:
Build capabilities once. Reuse them across products, markets, and use cases.
It now applies to agents.
Layer 3 — Integration Fabric
The nervous system needs to handle choreography, not just messaging
The Integration Fabric was built for predictable integration.
Standardized APIs. Event-driven communication. Identity federation.
Agentic workflows stress every one of these assumptions.
When an agent executes a complex task, it does not follow a predefined flow.
It plans dynamically, fans out across multiple capabilities, evaluates results, revises its approach, and propagates outcomes — often triggering further agents in the process.
This is not a request-response pattern.
It is dynamic orchestration — and the integration fabric must support it.
In practice, this means several things change.
API contracts must become richer.
Agents need to understand not just what an API does, but when to use it, what its failure modes are, and what alternatives exist if it is unavailable.
This requires a new kind of API specification — one designed for agent consumption, not just developer consumption.
The emerging standard for this is the Model Context Protocol (MCP) — an open protocol that allows agents to discover, understand, and invoke tools and services in a standardized way.
Just as REST APIs standardized how humans and systems communicate over the web, MCP is emerging as the protocol layer that standardizes how agents interact with capabilities.
Event streams must become agent-legible.
Events in traditional systems are structured for consumption by services.
Agents need to consume events too — and reason over them.
The integration fabric must enrich events with enough context that agents can make meaningful decisions from them, not just route them.
Identity must extend to agents.
Traditional identity federation handles humans and services.
In an agentic system, agents are actors too — and they must have identities, permissions, and audit trails.
An agent that can impersonate any user, or invoke any capability without restriction, is not just an architectural problem.
It is a security and compliance failure.
Orchestration must be observable.
When a human-initiated workflow fails, there is usually a clear place to look.
When an agent-initiated workflow fails — having spawned sub-agents, invoked multiple capabilities, and revised its plan three times — the failure can be deeply buried.
The integration fabric must make agent orchestration patterns as observable as traditional service calls.
The underlying principle from the original model holds:
Make integration a strength — not a bottleneck.
But in an agentic world, integration includes the ability to safely orchestrate autonomous actors at scale.
Layer 4 — Data Platform
Memory, context, and grounding become first-class architecture concerns
The original Data Platform layer was designed to transform data from a byproduct into a strategic asset.
Governed ingestion. Unified storage. Cross-product telemetry. ML-ready datasets.
All of that remains foundational.
But agentic AI introduces three new requirements that sit on top of — and interact with — everything the data platform already provides.
Vector storage and semantic retrieval.
Traditional databases answer the question: what record matches these parameters?
Agents need to answer a different question: what information is most relevant to this context?
This requires vector databases — storage systems that represent information as embeddings and retrieve it by semantic similarity rather than exact match.
Without this capability, agents cannot do meaningful retrieval-augmented reasoning.
They either hallucinate — confabulating information that isn’t there — or they ignore vast amounts of relevant knowledge that exists in the platform.
Agent memory architecture.
Agents operate across time. They may handle a task today that depends on context established weeks ago.
This requires a layered memory model:
Short-term working memory — the context an agent holds during a single task.
Session memory — context that persists across a multi-step interaction.
Long-term organizational memory — knowledge that accumulates across all agent activity and is retrievable by any agent that needs it.
The data platform is the home of long-term memory. Without it, every agent starts from scratch. With it, intelligence compounds.
Grounding and knowledge management.
Agents that reason over unverified information will eventually reason their way to the wrong answer.
The data platform must provide not just data, but grounded, governed knowledge — information that has been validated, versioned, and made reliable enough for an agent to act on.
This is a new discipline: knowledge engineering for agentic systems.
It requires rigor that most data platforms have not yet applied to their content.
The original insight from this layer becomes even more consequential in an agentic world:
AI is not something you add later.
It emerges naturally once a strong data foundation exists.
In an agentic architecture, the inverse is also true:
Agents are only as good as the data foundation beneath them.
A strong Data Platform produces capable, reliable agents.
A weak one produces agents that confidently do the wrong thing.
Layer 5 — Speed Infrastructure
A new runtime enters the picture
The Speed Infrastructure layer was about compressing time-to-market.
Elastic compute. CI/CD automation. Developer self-service. Observability tooling.
All of that still matters.
But agentic systems introduce a new class of infrastructure requirement that doesn’t exist in traditional application architectures.
The agent runtime.
An agent is not a traditional application.
It doesn’t run once and exit. It plans, acts, observes, and replans — in a loop.
It may spawn other agents. It may run for seconds or for hours.
It needs access to tools — APIs, code execution environments, browsers, databases.
And it needs to do all of this safely — without causing unintended harm in production systems.
The agent runtime is the infrastructure layer that makes this possible.
It includes:
Sandboxed tool execution environments.
Agents that can run arbitrary code need environments where that code cannot cause unintended damage.
The runtime provides isolated, constrained execution contexts.
Cost and token governance.
Agentic workflows can consume significant compute and LLM tokens — especially when agents spawn sub-agents or retry reasoning loops.
Without governance, costs become unpredictable.
The runtime must provide visibility, limits, and alerting — at the agent level, not just the infrastructure level.
Safety and constraint enforcement.
Agents must operate within defined boundaries.
What systems can they access? What actions are irreversible? What decisions require human confirmation?
These constraints cannot live in the agent’s prompt alone. They must be enforced at the runtime level — structurally, not just instructionally.
Agent observability.
Debugging a traditional application means reading logs.
Debugging an agent means understanding its reasoning — why it made a particular decision, what information it retrieved, which tool it called and with what parameters.
The observability infrastructure must capture agent reasoning traces, not just execution logs.
Latency and throughput management.
Agentic workflows have different latency profiles than traditional applications.
Some tasks are fine to run over minutes. Others — especially those in customer-facing flows — require near-real-time responses.
The infrastructure must handle both, and route appropriately.
The original principle of this layer holds perfectly:
Infrastructure should disappear into the background so teams can focus on building capabilities instead of running systems.
In an agentic world, this principle extends to the agent runtime.
Teams should be able to deploy, monitor, and govern agents without building bespoke infrastructure for each one.
Does the Architecture Need a Sixth Layer?
This is the question worth asking directly.
Some practitioners argue that agentic systems require an entirely new layer — an orchestration and trust layer that sits above everything else and governs how agents plan, act, and interact.
The argument has merit.
But the more precise answer is this:
Agentic orchestration and trust are not a new layer. They are a new concern distributed across all five existing layers — but concentrated most heavily in two of them.
The Product Capability Layer is where agents are defined, published, and composed. This is where agent governance lives architecturally — what agents exist, what they can do, how they are discovered.
The Speed Infrastructure Layer is where agents execute. This is where runtime safety, cost governance, and behavioral observability live.
The integration fabric handles agent communication. The data platform handles agent memory and grounding. The experience layer handles agent-human interaction surfaces.
What this means practically is not that you need a new layer.
It means you need to revisit every existing layer through an agentic lens — and deliberately extend each one to support autonomous actors alongside human ones.
The organizations that treat agentic AI as a feature to be added on top of their existing platform will struggle.
The organizations that treat agentic AI as a new set of actors that the entire platform must be designed to support will compound.
The Architecture Is Now a Platform for Both Humans and Agents
There is a reframe that ties all of this together.
The North Star Architecture, in its original form, was a platform for human-built software serving human users.
In the age of agentic AI, it must become something larger.
A platform for both humans and agents — where each can build, compose, and act — safely, at scale, and in ways that compound over time.
The five layers hold. But each one now serves two classes of actor.
The experience layer serves humans and agents simultaneously.
The product capability layer contains human-built services and agent capabilities.
The integration fabric handles service calls and agent orchestration.
The data platform stores records and provides agent memory and grounding.
The speed infrastructure runs applications and agent runtimes.
The architectural principle that underpins the entire model remains unchanged:
Every capability built into the platform should be usable by any actor — human or agent — that needs it.
This is what separates organizations that deploy AI features from organizations that become AI-native.
Feature deployments add AI on top.
Platform-native AI embeds agents as first-class actors throughout the architecture — composing capabilities, reasoning over data, orchestrating workflows, and surfacing insights at the speed of computation rather than the speed of human decision-making.
The Compounding Effect — Amplified
In the original model, the compounding effect was described this way.
Each new product becomes easier to build than the last.
Capabilities plug together.
Data accumulates value.
Innovation accelerates.
In an agentic architecture, this compounding effect amplifies significantly.
Because agents don’t just consume the platform.
They improve it.
An agent that handles customer support learns which knowledge base articles are most effective.
An agent that manages deployments learns which patterns correlate with production incidents.
An agent that synthesizes research learns which sources are most reliable for which question types.
Over time, this learning — if captured properly in the data platform — makes every subsequent agent better.
The platform doesn’t just accumulate capabilities.
It accumulates intelligence.
And intelligence, unlike infrastructure, compounds without limit.
The North Star — Extended
The goal of the architecture remains the same.
A platform where innovation compounds over time.
But the definition of innovation has expanded.
It is no longer just about how fast human teams can ship products.
It is about how effectively human and agent collaboration accelerates the pace at which the organization turns ideas into customer value.
The Scalable Growth Engine — in the age of agentic AI — is one where:
Humans set direction.
Agents execute, learn, and surface insight.
The platform makes both faster over time.
That is the architecture worth building toward.
Not because AI is the latest trend.
But because the organizations that build platforms capable of hosting autonomous agents alongside human teams will compound their capabilities in ways that purely human-operated platforms simply cannot match.
The five layers hold.
They just need to be built for two kinds of actor now.