The AI industry is still talking about models.
Bigger models.
Faster models.
Cheaper models.
More capable models.
But something more important is happening underneath the headlines.
The AI stack is becoming an enterprise stack.
And the strategic question is changing from:
“How powerful is the AI?”
to:
“How does AI capability become enterprise capability?”
That question sits at the center of several developments appearing almost simultaneously across the AI ecosystem.
The journey starts with infrastructure
Alibaba’s latest AI announcements provide a striking example.
On September 22, Alibaba announced plans for a future model in the 5–10 trillion-parameter range, introduced its Zhenwu V900 AI chip, expected to enter mass production in early 2027, and said Alibaba Cloud aims to exceed 20 GW of data-center capacity by 2032. Alibaba’s CEO described the strategy as building across the full AI technology stack, including models, semiconductors and data centers.
The interesting point is not only the scale.
It is the architecture:
Chips → Infrastructure → Models → Cloud → Agents → Applications
This tells us something fundamental.
AI capability is increasingly becoming an ecosystem capability.
But that does not mean every enterprise should own every layer.
A hyperscaler may own infrastructure.
A bank may consume it.
A retailer may own part of the stack and partner for the rest.
A manufacturer may use multiple providers.
So the strategic question is not:
“Do we own the infrastructure?”
It is:
“What dependencies does our enterprise create across the infrastructure stack?”
That distinction matters.
A strategic architecture needs to distinguish between:
Own → Consume → Partner
while maintaining visibility into the dependency created by each choice.
Then intelligence becomes available almost everywhere
Once infrastructure becomes increasingly accessible, the differentiation moves upward.
The enterprise can obtain:
Foundation Models
Specialized Models
Reasoning
Multimodal Intelligence
Agentic Capabilities
But intelligence alone still does not create enterprise value.
A model can reason.
It does not automatically understand your customers.
It does not automatically know your policies.
It does not automatically understand your capabilities.
It does not automatically know who has decision authority.
And it certainly does not automatically know what it is allowed to do.
So another layer appears.
Enterprise context becomes strategic
This is where the AI conversation becomes much more interesting for Business Architecture.
The enterprise needs to provide:
Data
Semantics
Business Meaning
Knowledge
Rules
Relationships
Context
This is the difference between having access to information and understanding how the enterprise actually works.
The chain becomes:
Enterprise Context → Business Meaning → Capabilities → Processes → Rules → Decision Rights
Only then can an AI agent begin to move from generic intelligence toward enterprise-specific execution.
And that creates an important strategic distinction:
AI intelligence is not the same as enterprise understanding.
That has become one of the recurring themes in our Grounded Strategy™ work.
Then the agent enters the picture
The next layer is agency.
AI no longer simply answers a question.
It can:
Reason → Plan → Decide → Act
This creates enormous potential.
But it also creates something that enterprises have historically been very good at controlling:
authority.
The question is no longer simply:
“Can the AI do this?”
It becomes:
“Should the AI be allowed to do this?”
That is a fundamentally different question.
AI control is moving into the runtime
Fastly’s September 21 launch of AI Runtime Control, AI Firewall and new API Security capabilities is a useful example of this architectural shift.
Fastly describes a control plane that can manage model routing, provider credentials, limits, usage and inspection, while its API Security capabilities can control how agents access enterprise APIs.
This means the architecture increasingly looks like:
User / System
↓
AI Application
↓
Model
↓
Agent
↓
Enterprise API
↓
Business Action
And control needs to exist inside the execution path.
- Identity.
- Permissions.
- Policy.
- Routing.
- Security.
- Observability.
- Cost.
- Audit.
These are no longer purely governance documents.
They are becoming part of the AI operating environment.
That is a major transition.
Then AI agents collide with enterprise boundaries
The next issue becomes even more interesting.
What happens when the AI agent is not owned by the enterprise?
Meta’s Muse illustrates the new situation.
A customer may ask an AI assistant to:
Search → Compare → Decide → Purchase
The customer sees one experience.
But from the enterprise’s perspective, an external AI agent is now attempting to interact with its systems, customer accounts, products and transactions.
That creates a new relationship:
Human Customer ↔ AI Agent ↔ Enterprise
Your source frames this as a major Customer Journey Architecture shift: customer journeys are beginning to include non-human actors.
That creates questions that did not exist in quite the same form before:
- Does the agent have an identity?
- How is it authenticated?
- Whose authority is it using?
- What can it access?
- What can it purchase?
- Can it negotiate?
- Can it personalize?
- What transaction limits apply?
- Who is accountable if the agent makes a mistake?
Suddenly, the customer journey is no longer just:
Customer → Enterprise
It becomes:
Customer → Agent → Enterprise
That is a Business Architecture problem.
Capability without boundaries creates risk
The ZCode case makes the same point from another direction.
According to the case in your briefing, Z.ai disabled parts of its coding-agent functionality after reports that a codebase-indexing feature could upload local repository information to external cloud infrastructure without user consent. The response included disabling functionality, patching the issue and establishing a continuing product-security response process.
The architectural lesson is broader than the incident itself.
A coding agent may be technically able to:
Read code → Understand code → Modify code → Execute code
But each capability creates a different risk boundary.
Therefore:
Capability ≠ Authority
A technically capable action is not automatically an authorized business action.
The enterprise needs:
Context → Permission → Action → Confirmation → Execution → Audit
That is exactly where governance and Business Architecture begin to converge.
The market is moving from experimentation toward enterprise scale
The fifth signal is quieter but equally important.
Dresner’s current research agenda includes dedicated work on AI and Agentic AI, Enterprise AI Platforms, AI Development Platforms and ModelOps, with the AI Development Platforms and ModelOps studies released on September 21.
That reflects a broader transition.
The question is moving from:
“Should we experiment with AI?”
toward:
“How do we build an enterprise capability around AI?”
And that changes everything.
Because building an enterprise capability requires more than a model.
It requires architecture.
The Enterprise AI Transformation Stack
Put these signals together and a remarkably coherent structure appears.
- Infrastructure
Chips → Cloud → Compute
Technology provides the foundation.
- Intelligence
Foundation Models → Specialized Models
The enterprise gains reasoning capability.
- Enterprise Context
Data → Semantics → Business Meaning → Knowledge
AI begins to understand the organization.
- AI Agents
Reason → Plan → Decide → Act
AI begins participating in work.
- Control & Authority
Identity → Permissions → Security → Observability → Governance
AI receives boundaries.
- Business Architecture
Capabilities → Processes → Value Streams → Decision Rights → Customer Journeys
AI becomes connected to how the enterprise actually works.
- Operating Model
People + AI + Systems + Governance
Work itself begins to change.
- Business Outcomes
Customer Value → Productivity → Growth → Resilience → Competitive Advantage
Only now does technology become enterprise value.
The strategic transition
This gives us four major layers of enterprise transformation:
Technology Stack
↓
Enterprise Intelligence
↓
Enterprise Execution
↓
Business Value
That is the real story.
The technology stack creates potential.
Enterprise intelligence creates understanding.
Enterprise execution creates action.
Business outcomes create value.
And value creates the reason for the entire architecture to exist.
Where does AI capability become enterprise capability?
That is the question I find most important.
Because a company can buy compute.
It can access a frontier model.
It can deploy an agent.
It can purchase an AI governance platform.
It can connect an API.
And still fail to create meaningful business value.
Why?
Because the layers are disconnected.
AI has to become grounded in the enterprise.
The agent has to understand the context.
The action has to be authorized.
The process has to support it.
The capability has to absorb it.
The operating model has to accommodate it.
And the outcome has to be measurable.
This is where Grounded Strategy™ enters the architecture.
The Grounded Strategy™ perspective
The pattern can be expressed as:
Enterprise Context
↓
Business Meaning
↓
Capability
↓
Process
↓
Rule
↓
Decision Right
↓
AI Action
↓
Business Outcome
↓
Learning & Capability Evolution
Now place that above the technology foundation:
Infrastructure
↓
Intelligence
↓
Understanding
↓
Agency
↓
Authority
↓
Execution
↓
Outcome
The result is no longer merely an AI stack.
It becomes an:
Enterprise AI Transformation Stack
And this is why I would not describe AI transformation simply as “implementing AI.”
The deeper transformation is:
AI capability becomes enterprise capability.
That means connecting technology to:
Context
Meaning
Capabilities
Processes
Decision Rights
Customer Journeys
Governance
Operating Model
and ultimately:
Business Outcomes
One more important point: not every enterprise needs to own the stack
This is where strategy matters.
The infrastructure layer should not be interpreted as a mandatory ownership model.
Different enterprises will make different choices.
Own where strategic differentiation or control justifies it.
Consume where scale and specialization make external providers more efficient.
Partner where combining capabilities creates greater strategic value.
But whichever model is chosen:
Understand the dependency.
That may become one of the most important disciplines of enterprise AI strategy.
Because dependencies create:
Cost exposure.
Resilience exposure.
Security exposure.
Vendor concentration.
Strategic constraints.
Architecture therefore becomes the mechanism for making those dependencies visible.
The real destination
I do not think the destination is:
More AI.
I think the destination is:
A more capable enterprise.
AI is the accelerator.
Infrastructure creates the foundation.
Models create intelligence.
Context creates understanding.
Agents create agency.
Governance creates authority.
Business Architecture creates coherence.
The operating model creates execution.
And outcomes create value.
That produces the complete flow:
Infrastructure → Intelligence → Enterprise Understanding → AI Agency → Control & Authority → Business Architecture → Operating Model → Business Outcome
And then one final arrow matters:
Business Outcome → Learning → Capability Evolution
Because once an enterprise can learn from outcomes and continuously evolve its capabilities, AI transformation stops looking like a technology programme.
It becomes a mechanism for continuous enterprise redesign.
That is where AI strategy becomes Business Architecture.
And that is where I believe Grounded Strategy™ has something important to contribute.
From Infrastructure to Intelligence.
From Intelligence to Action.
From Action to Business Outcome.
The real strategic question is no longer:
“How powerful is our AI?”
It is:
“How effectively can our enterprise turn AI capability into business capability — and business capability into measurable outcome?”
That is the transformation worth designing.
Grounded Strategy™
From enterprise reality to AI-enabled action.
