Your architecture may not be dead but remember AI just introduced a new orchestrator
TL;DR: AI doesn't replace MVVM or anything compliant to it.
It introduces a new orchestration layer. ViewModels still excel at managing UI state, but when your app needs to reason, plan, use tools, and maintain context, an Agent becomes a natural addition to your architecture.
The Shift We Didn't See Coming
For over a decade, mobile architecture has focused on making UI code predictable and maintainable. Whether you follow MVC, MVP, VIPER, Clean Architecture, MVVM, or The Composable Architecture, the core idea has remained the same:
- Separate concerns.
- Keep business logic out of views.
- Make data flow predictable.
- Keep the UI reactive.
A typical modern iOS application looks something like this:
SwiftUI View
│
▼
ViewModel
│
▼
Repository
│
▼
API / Database
The ViewModel receives user intent. The Repository fetches data. The View updates. Everything is deterministic, a button tap follows a predefined execution path.
This architecture has served us incredibly well. But AI-powered experiences are fundamentally different.
Traditional Apps Execute
Traditional applications execute instructions. For example, a user taps:
Search "Blue Jacket"
The flow is straightforward:
View → ViewModel → Repository → Search API → Products
Every component knows exactly what to do. There is almost no ambiguity.
AI Applications Need to Think Before They Act
Now consider a modern shopping experience. Instead of typing keywords, the user says:
"Find me a blue waterproof jacket under ₹5,000 that's suitable for a rainy trip to Scotland next week."
Notice something interesting: the app cannot immediately call an API. It first needs to understand what the user actually means. It must infer:
- Waterproof
- Suitable for cold weather
- Budget constraint
- Destination
- Travel dates
- Product availability
- Ranking preferences
Before any API is called, reasoning has already begun.
One Request Can Become Multiple Tasks
Internally, that single sentence may become:
Understand intent
↓
Break problem into tasks
↓
Search products
↓
Check weather
↓
Understand destination climate
↓
Filter inventory
↓
Rank recommendations
↓
Generate explanation
That isn't something a traditional ViewModel was designed to orchestrate.
The ViewModel's Responsibility Hasn't Changed
Many developers immediately ask:
"Isn't an Agent just another ViewModel?"
It's a fair question. The answer is not quite.
A ViewModel's primary responsibility is still:
- Manage screen state
- Transform models into UI
- Handle user interactions
- Coordinate presentation logic
Those responsibilities remain exactly the same even in AI-powered applications. What changes is who coordinates reasoning.
Enter the Agent
Think of an Agent as an orchestration layer. Instead of simply forwarding requests, it decides how a request should be solved.
User Request
↓
Agent
↓
Reason
↓
Plan
↓
Choose tools
↓
Execute tools
↓
Combine results
↓
Return response
The Agent isn't replacing your networking layer. It isn't replacing repositories. It isn't replacing MVVM. It is coordinating them.
A Better Mental Model
Instead of thinking:
ViewModel → Repository
Think:
View → ViewModel → Agent → Tools → Repositories → Backend → LLM
The ViewModel still owns UI state. The Agent owns intelligence.
What Exactly Does an Agent Do?
1. Understand Intent
The user's words are rarely explicit. Example:
"Something comfortable for office meetings."
The Agent converts vague language into structured requirements.
2. Planning
Complex requests are broken into multiple smaller tasks. Instead of:
Call API
It becomes:
Search products → Compare options → Remove unavailable items → Rank → Summarize
3. Tool Calling
Modern LLMs don't perform every action themselves instead, they invoke tools. Examples:
- Product Search
- Weather API
- Calendar
- Maps
- Payment
- Database
- Inventory Service
- Recommendation Engine
The Agent decides which tools should be executed and in what order.
4. Memory
Traditional apps remember UI state. Agents remember conversations. Example:
"Show me another one."
Another what? The Agent knows, because it remembers previous context.
5. Reasoning
Instead of returning raw API results:
Product A
Product B
Product C
It may produce:
"Product B is slightly more expensive, but it offers significantly better waterproofing, making it more suitable for your upcoming trip to Scotland."
That's reasoning.
Comparing Responsibilities
| Traditional MVVM | AI-Native Architecture |
|---|---|
| ViewModel manages UI | ViewModel still manages UI |
| Repository fetches data | Repositories still fetch data |
| Business logic | Business logic still exists |
| API calls | APIs still exist |
| Static flow | Agent orchestrates dynamic workflows |
| Screen state | Conversation state |
| UI events | User intent |
| Deterministic execution | Planning and reasoning |
Notice how almost everything remains. We're simply introducing another orchestration layer.
Where Should the Agent Live?
This is probably the most interesting architectural discussion. One possible design looks like this:
SwiftUI View
↓
ViewModel
↓
Agent
├── Memory
├── Planner
├── Tool Registry
├── Prompt Builder
└── LLM Client
↓
Repositories
↓
Backend APIs
This keeps concerns well separated. The ViewModel doesn't suddenly become responsible for prompts, memory, or tool execution.
What About Clean Architecture?
If you're using Clean Architecture, the Agent naturally belongs in the domain layer; think of it as another domain service. Your ViewModel simply delegates complex AI tasks:
ViewModel → AgentService → Repositories → Tools → LLM
Repositories continue to own data access. The Agent owns orchestration.
Why This Matters
As AI features become more common, we're moving beyond simple request-response interactions. Applications are beginning to:
- Think
- Plan
- Reason
- Remember
- Decide
- Explain
That introduces responsibilities that traditional UI architectures were never intended to handle. Trying to push all of that into a ViewModel eventually leads to massive classes with mixed responsibilities. Adding an Agent layer keeps each component focused on what it does best.
A Practical Example
Imagine building an AI-powered travel assistant. The user asks:
"Plan my weekend trip to Coorg with good vegetarian restaurants, pleasant weather, and hotels under ₹6,000."
An Agent might:
- Understand the destination.
- Fetch weather forecasts.
- Search hotels.
- Search restaurants.
- Rank options.
- Remove unavailable hotels.
- Generate an itinerary.
- Explain why each recommendation was chosen.
Your ViewModel doesn't need to know how those eight steps happen. It simply receives a structured response and updates the UI. That's a much cleaner separation of responsibilities.
Looking Ahead
Just as networking logic gradually moved out of ViewControllers and into repositories and services, AI orchestration deserves its own home.
- The ViewModel remains responsible for presentation.
- The Repository remains responsible for data.
- The Backend remains responsible for persistence.
- The LLM remains responsible for reasoning.
- The Agent becomes responsible for coordinating the entire workflow.
Final Thoughts
I don't believe MVVM is becoming obsolete. In fact, it's still one of the best ways to manage presentation logic in SwiftUI.
What is changing isn't the UI architecture, it's the layer above it.
The future of intelligent applications isn't about replacing ViewModels. It's about introducing an orchestration layer capable of understanding intent, planning workflows, invoking tools, maintaining context, and delivering intelligent experiences.
The apps we build tomorrow won't just respond to user actions. They'll collaborate with users to accomplish goals. And that requires more than another ViewModel -> it requires an Agent.
What do you think?
If you were designing an AI-first iOS application today:
- Would you extend your existing ViewModel?
- Would you introduce a dedicated Agent layer?
- Or do you see another architectural pattern emerging?
I'd love to hear how you're approaching AI-native application architecture.
Top comments (0)