After the App: MCP Apps, Generative UI and the Architecture of the Next User Interface

Signal Summary

For decades, software has required humans to learn its structure.

Open the application.

Find the correct section.

Navigate through menus.

Locate the function.

Enter the information.

Confirm the action.

Artificial intelligence introduces the possibility of reversing that relationship.

Instead of the human navigating toward the function, the system can interpret the desired outcome, locate the required capability and construct an appropriate interface around the task.

This does not necessarily mean that graphical interfaces disappear.

Evidence emerging across the AI and operating-system ecosystems points toward something more subtle:

the interface may stop being permanently attached to the application.

A chart can appear when a chart is useful.

A form can materialize when structured input is required.

A map can appear when location becomes relevant.

A confirmation panel can emerge before an irreversible action.

A small persistent widget can remain visible while an agent continues working.

Then the interface can disappear.

Several technologies that appeared independently between 2025 and 2026 are beginning to converge around this architecture:

• Model Context Protocol — MCP
• MCP Apps
• MCP-UI
• OpenAI Apps SDK
• Google’s A2UI
• AG-UI
• Agent2Agent — A2A
• Apple App Intents and App Schemas
• Android AppFunctions
• agent-oriented component libraries and Generative UI frameworks

None of these individually defines the future of interfaces.

Together, however, they expose a detectable pattern.

Software is beginning to separate capability from application, and interface from capability.

The chat box is probably not the final interface

The first widespread interface for generative AI was extraordinarily simple:

┌──────────────────────────────┐
│ Ask anything...              │
└──────────────────────────────┘

This simplicity was strategically useful.

Natural language eliminated the need to understand the internal organization of a system.

Instead of locating a command, the user could describe an objective.

But conversation has significant limitations as a user interface.

Consider booking a hotel entirely through text.

The model can perform the interaction.

But the interface is inefficient.

A conventional visual system can represent the same state more effectively:

LISBON
12–15 OCTOBER

Price        €120 ───────── €250
Pool         ☑
Breakfast    ☑
Distance     < 3 km

┌──────────────┐
│ Hotel A      │
│ €184         │
│ ★★★★         │
└──────────────┘

┌──────────────┐
│ Hotel B      │
│ €206         │
│ ★★★★         │
└──────────────┘

Natural language is highly efficient for expressing intent.

Graphical interfaces remain highly efficient for:

• comparison
• manipulation
• spatial information
• reviewing structured information
• choosing between alternatives
• adjusting parameters
• visualizing state
• confirming actions

The emerging architecture therefore does not appear to be:

It increasingly resembles:

The conversation becomes the orchestration layer.

The graphical interface becomes situational.

The important distinction: MCP is not a UI protocol

Much of the current terminology creates confusion.

The Model Context Protocol itself was designed primarily to standardize how AI applications connect to external capabilities, resources and tools.

Conceptually:

This solved an important integration problem.

An agent could discover that a system exposes something such as:

search_customers()
create_invoice()
check_inventory()
send_message()

without requiring a bespoke integration architecture for every model and every application.

But knowing that a function exists does not solve the user-interface problem.

Suppose the agent calls:

search_products()

and receives 40 products.

Text is technically capable of representing the result.

It is not necessarily the correct interface.

That missing layer produced another development.

MCP Apps: tools can now carry interfaces

On January 26, 2026, MCP maintainers announced MCP Apps as the first official MCP extension.

It allows MCP tools to provide interactive user interfaces that can be rendered directly inside compatible hosts. Examples explicitly covered by the specification include dashboards, forms, data visualizations, media viewers and multi-step workflows.

The basic architecture is:

              MCP
AGENT ─────────────────► SERVER
                          │
                          ├── TOOL
                          │
                          └── UI RESOURCE
                                  │
                                  ▼
                              HOST
                                  │
                                  ▼
                            INTERACTIVE UI

A tool declares that it has an associated interface using metadata pointing to a ui:// resource.

The host retrieves that resource and renders it inside a sandboxed iframe.

The interface and the host then communicate using JSON-RPC over postMessage.

This appears technical.

Its implications are architectural.

The backend capability and the frontend experience can now travel together.

From MCP-UI to MCP Apps

The distinction between MCP-UI and MCP Apps is worth recording because both names still appear throughout developer discussions.

MCP-UI was an early community project exploring interactive interfaces returned by MCP tools.

Its experiments included:

• HTML interfaces delivered by MCP
• sandboxed rendering
• communication between the embedded interface and host
• interactive tool results

Those concepts subsequently influenced the formal MCP Apps extension.

The MCP-UI project now recommends MCP Apps for new applications and its current SDK implements the official MCP Apps specification.

The progression can therefore be simplified as:

MCP
│
├── tools
├── resources
└── prompts

        ↓ community experimentation

MCP-UI

        ↓ standardization

MCP Apps

This matters because UI-over-MCP is no longer merely an experimental pattern.

It has entered the formal MCP ecosystem.

An MCP tool can now contain an application

The MCP Apps model is essentially:

MCP APP = TOOL + UI RESOURCE

Suppose an organization exposes:

get_sales_report()

Previously the response might have been JSON:

{
  "revenue": 184932,
  "orders": 1847,
  "conversion": 3.8
}

The agent could translate that into prose.

With MCP Apps, the same capability can declare:

ui://sales/dashboard

and the host can display something closer to:

┌──────────────────────────────────────┐
│ SALES                                │
│                                      │
│ Revenue              €184,932        │
│ Orders                   1,847       │
│ Conversion                 3.8%      │
│                                      │
│       ▁▂▃▃▄▅▅▇▆█                    │
│                                      │
│ [Last 7 days ▼] [Region ▼]           │
└──────────────────────────────────────┘

The user can interact with the dashboard.

The interface can then call other MCP tools.

The application effectively exists inside the AI host.

The interface is bidirectional

This is where MCP Apps becomes more important than merely displaying rich output.

The embedded interface can communicate back to the host.

According to the current specification, an MCP App can perform operations including:

• calling server tools
• reading server resources
• sending messages into the conversation
• updating model-visible context
• requesting external links
• reacting to host environment changes

Consider an inventory interface.

The agent initially displays:

The human clicks:

The UI can update the model context:

User selected Item B.
Current stock: 12.

The conversation now knows what the user is inspecting without requiring:

“I mean the second item.”

The UI becomes part of the context loop.

This is a significant change.

The model is no longer merely generating the interface.

The interface itself can become a sensor for user intent.

Widgets may become the atomic unit of AI software

Traditional applications are built around destinations.

Agentic systems begin from a different assumption:

The application becomes secondary to the objective.

This creates an environment in which a complete application may often be unnecessary.

A small contextual interface may be enough.

Examples:

MCP Apps formally defines three display modes:

inline

Embedded directly inside the conversational flow.

fullscreen

Suitable for editors, dashboards and more complex applications.

picture-in-picture

A persistent surface suitable for elements such as players or timers while the conversation continues.

This is notable.

The protocol is already acknowledging that agent interfaces will not have a single shape.

The widget existed before AI

Widgets are not new.

Mobile operating systems have been progressively separating application capabilities from full applications for years.

What AI changes is selection and composition.

Previously:

Potential agentic model:

This changes the role of the widget.

It stops being merely a miniature application.

It becomes a temporary interface primitive.

Apple is moving capabilities outside applications

Apple’s App Intents framework offers another important signal.

App Intents allow developers to expose application actions and entities to system-level experiences including Siri, Spotlight, Shortcuts and widgets.

At WWDC 2026, Apple expanded this direction around Siri AI and App Schemas.

Applications can describe:

Siri can then resolve natural-language requests into those actions.

Apple’s 2026 documentation describes scenarios where Siri can understand onscreen context and perform actions across applications using exposed entities and intents.

The architectural direction resembles MCP even though the implementation is different.

The system no longer needs to open the UI to access every capability.

Apple explicitly makes App Intents available across system surfaces including widgets, Spotlight, Shortcuts and Siri.

The application is becoming callable.

Android is moving even closer to the MCP model

Android’s direction is even more explicit.

Google currently describes AppFunctions as an experimental Android platform API designed to make applications expose capabilities to agents.

The Android documentation directly characterizes AppFunctions as the mobile equivalent of MCP tools.

Applications can contribute actions to an operating-system registry that agents or assistants can invoke.

Conceptually:

ANDROID APPLICATION
       │
       ├── Traditional UI
       │
       └── AppFunctions
              │
              ▼
        SYSTEM / AGENT

In July 2026, Android’s developer team described AppFunctions as a complementary entry point to traditional mobile UI, allowing a privileged on-device agent to access application functionality in the background.

The word complementary is important.

Google is not claiming that applications cease to exist.

Instead, applications gain another interface:

machine-callable functionality.

A2UI: instead of sending an app, send interface intent

MCP Apps provides considerable freedom.

A server can deliver HTML, CSS and JavaScript that the host renders inside a sandboxed iframe.

This enables sophisticated experiences.

But it creates another problem.

Suppose five different services insert five different applications into the same assistant.

Each may contain:

• different fonts
• different button styles
• different spacing
• different scroll behaviour
• different accessibility characteristics

The result can resemble five websites embedded inside another application.

Google’s Agent-to-User Interface — A2UI explores a different architecture.

Instead of transmitting executable UI code, the agent transmits a declarative description of the desired interface.

For example:

The host determines how those elements actually look.

Conceptually:

The agent specifies what should exist.

The client decides how it should render.

The component catalog may become extremely important

A2UI clients define trusted component catalogs.

For example:

An agent can compose these elements.

It cannot arbitrarily execute whatever UI code it chooses.

This has important security implications.

Google explicitly designed A2UI as declarative data rather than executable code. Agents request components from a predefined catalog controlled by the client.

This produces a fundamentally different model from dynamically generating HTML or JavaScript.

becomes:

That separation could become critical if generative interfaces operate in sensitive environments.

A2UI 0.9 makes the idea more concrete

Google released A2UI 0.9 in April 2026.

The release added or expanded:

• React rendering
• Flutter rendering
• Angular rendering
• Lit rendering
• dynamic component catalogs
• version negotiation
• streaming UI generation
• client-defined functions
• client/server state synchronization
• improved schema validation

Importantly, A2UI is not tied to a specific transport.

Google explicitly describes it as usable over mechanisms including:

This means A2UI is better understood as a language for interface intent, rather than another agent transport.

MCP Apps and A2UI are not necessarily competitors

This distinction becomes clearer from work published by the A2UI and MCP Apps teams in June 2026.

The two approaches can be combined.

An MCP server can return an A2UI payload instead of an HTML application.

For example:

Google demonstrated A2UI payloads transported through MCP using the MIME type:

application/a2ui+json

The architecture therefore gains two possible paths.

High-control custom experience

Native host experience

Neither is universally superior.

A specialized design application may require substantial custom code.

A simple booking form may be better represented using host-native controls.

Hybrid models are therefore likely.

AG-UI addresses another layer

A third project frequently appears alongside MCP and A2UI: AG-UI.

It solves a different problem.

AG-UI describes itself as a protocol for communication between agents and user-facing frontend applications.

The protocol addresses events such as:

• streaming responses
• agent state
• frontend tool calls
• tool execution
• UI intents
• human approval
• interruptions
• user steering
• generative UI events

A useful simplification is:

These boundaries are not absolute.

The technologies can overlap and integrate.

But viewing them as layers makes the emerging architecture easier to understand.

The agentic interface stack is becoming visible

A future application architecture could resemble this:

                       USER
                         │
                         ▼
                  AI HOST / OS
                         │
                 ┌───────┴────────┐
                 │                │
               AG-UI          UI RENDERER
                 │                │
                 │        ┌───────┴────────┐
                 │        │                │
                 │      A2UI          MCP APP
                 │        │                │
                 ▼        ▼                ▼
                      AGENT
                         │
              ┌──────────┴───────────┐
              │                      │
             MCP                    A2A
              │                      │
              ▼                      ▼
        TOOLS / SERVICES        OTHER AGENTS

No single standard currently owns this complete architecture.

The important observation is that the layers are separating.

A2A completes another part of the picture

Agent2Agent — A2A — addresses communication between independent agents.

Its current specification enables agents to advertise capabilities, discover other agents, exchange information and coordinate tasks without exposing their internal memory or implementation.

In August 2026, A2A joined the Agentic AI Foundation as a Growth Stage project. Its own documentation describes the relationship succinctly:

MCP provides vertical integration between agents and tools.

A2A provides horizontal integration between agents.

That gives us another potential structure:

             USER
               │
               ▼
             AGENT
        ┌──────┴───────┐
        │              │
       MCP            A2A
        │              │
        ▼              ▼
     TOOLS         AGENTS
        │
        ▼
       UI

The user might therefore interact with one visible assistant while multiple applications and remote agents operate underneath it.

The application may become a capability provider

This leads to a larger architectural possibility.

Today’s application is usually packaged like this:

The user enters through the UI.

The future structure could increasingly resemble:

Different consumers select different layers.

A human may use the complete application.

An agent may invoke a tool.

An operating system may invoke an App Intent.

Another agent may communicate through A2A.

An assistant may render only one MCP widget.

An A2UI client may construct a native interface.

The application therefore stops having a single entrance.

From application navigation to capability discovery

This creates a fundamental change in software discovery.

Today:

Agentic model:

Consider:

Find three hotels near the conference, below €200, compare cancellation policies and reserve the best option after I approve it.

Several capabilities may be involved:

A sufficiently integrated agent does not require the user to navigate six applications.

The user interacts with the task.

The task may replace the app as the primary UX object

This is currently a projection rather than an established industry outcome.

But it follows directly from the architectures now being implemented.

Traditional software organizes around:

Agentic interfaces can organize around:

That is a substantial inversion.

Imagine:

Organize my trip to Berlin.

The system could temporarily construct:

┌─────────────────────────────────────────────┐
│ BERLIN · 14–17 OCT                          │
│                                             │
│ ✈ FLIGHT                                    │
│ Iberia 08:20                     €184        │
│                                             │
│ 🏨 HOTEL                                     │
│ Motel One                         €161/night │
│                                             │
│ 📅 CALENDAR                                  │
│ Conference starts 14:00                     │
│                                             │
│ 💳 POLICY                                    │
│ Within company allowance                    │
│                                             │
│           [ Review booking ]                │
└─────────────────────────────────────────────┘

That interface may never have existed before the request.

It may never need to exist again.

The task generated the application surface.

This is different from AI generating frontend code

The distinction is important.

Much current experimentation involves asking models to generate React, HTML or entire applications.

That is useful for software development.

It is not necessarily how runtime generative interfaces will operate.

Allowing a model to continuously generate and execute arbitrary frontend code introduces obvious problems:

• security
• accessibility
• consistency
• performance
• unpredictable interaction
• difficult testing
• visual instability

The approaches now emerging from MCP Apps and A2UI point toward constrained generation.

This is closer to a UI grammar than unrestricted application generation.

Design systems could become machine-readable

If A2UI-style architectures grow, an organization’s design system gains another consumer.

Today:

Potential future:

                    DESIGNERS
                       │
DESIGN SYSTEM ─────────┼──── FRONTEND
                       │
                       └──── AI AGENTS

The design system may need to describe not only:

but semantic constraints:

The component catalog becomes something an agent can reason about.

Frontend architecture therefore becomes partially semantic.

Components may acquire capabilities, not just appearance

Current UI components primarily describe presentation.

<Button />
<Table />
<DatePicker />

Agentic systems may require something richer.

<PaymentApproval
  amount
  recipient
  policy
  authenticationRequired
/>

The difference is important.

The component represents a task contract, not merely pixels.

It knows:

• what data it needs
• what actions are available
• what permissions apply
• what state changes are possible

This could reduce the amount of arbitrary interface generation required.

A new division of responsibility

One possible future frontend architecture therefore becomes:

This separation is more controllable than giving an autonomous model unrestricted access to application code.

Security becomes part of interface architecture

Agent-generated interfaces create unusual security problems.

A malicious interface could attempt to:

• imitate trusted controls
• manipulate users into approvals
• exfiltrate information
• invoke unauthorized tools
• disguise external actions
• create misleading confirmation flows

The emerging standards therefore contain explicit security boundaries.

MCP Apps runs applications inside sandboxed iframes.

Those applications do not receive direct access to the host DOM, cookies or storage.

External network destinations are declared through Content Security Policy metadata, and communication passes through controlled host mechanisms.

A2UI chooses an even more restrictive model.

Remote agents send declarative data and can request only trusted components present in the client’s catalog.

These represent two different approaches:

versus:

Both may remain useful.

The host is becoming more powerful

There is another consequence.

If applications increasingly execute inside AI environments, the host gains importance.

Potential hosts include:

• ChatGPT
• Claude
• Microsoft Copilot
• operating-system assistants
• IDEs
• enterprise AI environments
• specialized agent applications

MCP Apps was announced with support across clients including ChatGPT, Claude, Goose and Visual Studio Code, with additional hosts expected.

Microsoft now also documents MCP-based interactive widgets inside Microsoft 365 Copilot.

Its UX guidance is revealing.

Microsoft explicitly recommends that MCP interfaces inside Copilot remain task-focused rather than attempting to reproduce complete applications inside the conversation.

That reinforces the emerging pattern:

small contextual surfaces rather than applications inside applications.

OpenAI is moving in the same direction

OpenAI introduced its Apps SDK in October 2025, enabling applications with interactive interfaces to operate directly inside ChatGPT.

The SDK uses MCP as its underlying integration mechanism and allows developers to define both application logic and UI.

Current OpenAI documentation now recommends using the open MCP Apps standard for new shared UI functionality and adding ChatGPT-specific extensions only where necessary.

The UI system supports concepts including:

• cards
• carousels
• embedded interfaces
• richer application views
• stateful widgets
• host-controlled modals
• file interaction
• tool calls from UI

Again, the conversation is evolving into a runtime for other interfaces.

Developer infrastructure is following

This pattern is not confined to the major AI platforms.

Vercel’s AI SDK has progressively expanded from model invocation and streaming into agent infrastructure and generative UI.

AI SDK 7, released in June 2026, added MCP Apps support alongside agent tooling, approval flows, durable agents and integrations with multiple agent harnesses.

Vercel’s AI Elements component library also provides components specifically designed around AI interaction patterns such as:

• streaming responses
• tool calls
• reasoning displays
• structured message parts

The frontend ecosystem is therefore beginning to build components for interactions that did not exist in traditional web applications.

The most important new UI element may be approval

Traditional software assumes:

Agentic software increasingly allows:

That produces a new critical interface:

Example:

┌─────────────────────────────────────────┐
│ PAYMENT READY                           │
│                                         │
│ Recipient     ACME Ltd                  │
│ Amount        €4,820                    │
│ Account       Operations                │
│                                         │
│ Agent reason                            │
│ Invoice INV-4827 matched purchase order │
│ PO-1821.                                │
│                                         │
│ [ Reject ]            [ Approve ]       │
└─────────────────────────────────────────┘

This is neither chat nor conventional navigation.

It is a moment where autonomous execution intersects with human authority.

As agents gain access to consequential tools, interfaces for:

• inspection
• approval
• correction
• interruption
• delegation
• rollback

may become increasingly important.

AG-UI already treats interrupts and human-in-the-loop interactions as explicit agent-interface concepts.

Interfaces could become confidence-sensitive

Another logical extension is dynamic UI based on model uncertainty.

This is a projection.

Consider:

confidence = 0.99

The agent could act automatically.

At:

confidence = 0.78

the system could display:

At:

confidence = 0.42

the system could present:

The UI therefore becomes conditional on uncertainty.

Instead of every workflow having the same interface, the amount of human interaction could adapt to how confidently the system understands the situation.

This could become one of the more significant differences between traditional and agentic software.

Interfaces could also become permission-sensitive

The same task might produce different UI depending on the user.

A generative interface does not need to mean unlimited generation.

It can mean selecting the correct permitted surface from a constrained system.

The interface may increasingly live outside the application

Apple exposes app actions into:

• Siri
• Spotlight
• widgets
• Shortcuts
• system controls

Android is building AppFunctions for agent access.

MCP exposes application capabilities to AI hosts.

A2UI allows remote agents to request host-native interfaces.

MCP Apps allows services to bring their own interactive surfaces.

These developments point toward a common architectural shift:

The full application remains one surface among several.

The app icon is unlikely to disappear soon

This requires a counterpoint.

There is currently no reliable evidence that conventional applications are about to disappear.

In fact, the platform vendors themselves describe these agent interfaces as complementary.

Android explicitly states that traditional mobile UIs remain effective for focused, hands-on tasks and positions AppFunctions as an additional entry point.

Complex software still benefits from stable spatial structure.

Examples include:

• video editors
• CAD applications
• development environments
• spreadsheets
• music production
• advanced analytics
• complex administration systems

Users build spatial memory around these interfaces.

Replacing everything with dynamically generated controls could reduce efficiency rather than improve it.

The likely transition is therefore not:

A more defensible projection is:

That is a significantly different claim.

The future application may have two audiences

Software has historically been designed primarily for humans.

Increasingly, applications will have another consumer:

agents.

Developers may therefore need to build two parallel interfaces.

and:

A strong application may require both.

This could change competitive advantage

This section is projection.

If agents increasingly choose tools for users, application discovery changes.

Traditional competition relies heavily on:

Agent-mediated software could introduce another factor:

An agent needs to determine:

• what a service can do
• what inputs it requires
• what it costs
• whether it is authorized
• what guarantees it provides
• how reliable it is

That creates incentives for highly structured capability metadata.

A service that agents can reliably understand and invoke may gain an advantage even if the user never directly navigates its interface.

The equivalent of optimization for human search could therefore gradually expand into optimization for agent selection.

It is too early to know what economic model will emerge around this.

The architectural prerequisite is already appearing.

Applications may become composable across vendors

Consider a future expense workflow.

One agent might interact with:

The resulting UI might combine:

No single participating service necessarily owns the final interface.

The orchestrator does.

This represents a significant departure from application-centric computing.

We may be approaching ephemeral software

This is one of the more speculative implications.

Traditional software assumes that an interface is designed before the user arrives.

Generative UI introduces:

The interface becomes an instance rather than a permanent artifact.

It exists because the current state requires it.

When the task ends, it may no longer be needed.

This could be described as ephemeral software:

software surfaces assembled temporarily around an objective.

The underlying services remain persistent.

The interface does not have to be.

The likely transition

Based on currently deployed and documented technologies, a reasonable progression can be constructed.

Phase 1 — Application-centric computing

Phase 2 — Conversational access

Phase 3 — Tool-using assistants

Phase 4 — Interactive agent interfaces

This phase is already emerging.

Phase 5 — Composed task interfaces

This remains a projection.

Phase 6 — Ambient capability layer

More speculative:

At this stage, applications continue to exist.

But users interact increasingly with capabilities rather than application boundaries.

What developers may need to build differently

If this direction continues, creating software may involve more than building screens and APIs.

A mature application could need:

The frontend is no longer the only representation of the product.

What designers may need to design differently

Designers could move from designing fixed screen sequences:

toward designing interaction primitives.

Those primitives can then appear in different contexts.

Design becomes partly about defining the grammar from which interfaces can be assembled.

What changes for humans

The most significant shift may ultimately concern cognitive load.

Traditional applications require users to maintain a mental model of software:

Agentic interfaces potentially transfer some of that organizational work to the system.

The human describes the desired state.

The system determines the operational path.

But this also creates a new requirement.

Humans need to understand:

The design challenge therefore shifts.

Navigation complexity decreases.

Delegation transparency increases.

The strongest signal is not chat

Chat attracted the initial attention because it provided the first universal interface to language models.

But the infrastructure now developing around AI points beyond chat.

MCP Apps allows tools to carry applications.

A2UI allows agents to describe interfaces.

AG-UI connects agents with frontends.

A2A connects agents with other agents.

Apple App Intents makes app capabilities accessible throughout the operating system.

Android AppFunctions exposes application functionality to agents.

AI SDKs are introducing components specifically for tool execution, agent state and generative UI.

The resulting architecture is no longer simply:

It is moving toward:

INTENT
  │
  ▼
ORCHESTRATION
  │
  ├──── CAPABILITY
  │
  ├──── CAPABILITY
  │
  ├──── AGENT
  │
  └──── DATA
          │
          ▼
    APPROPRIATE INTERFACE

Sometimes that interface will be text.

Sometimes voice.

Sometimes a button.

Sometimes a form.

Sometimes a map.

Sometimes a complete application.

And sometimes there may be no interface at all.

CORE01 Assessment

The application is not disappearing.

Its boundaries are weakening.

For most of the history of personal computing, functionality and interface have been distributed together.

The user selected an application because that application contained the required capability.

Agent architectures begin to separate those two concepts.

A capability can now be exposed independently.

An agent can discover it.

A protocol can transport it.

A host can render its interface.

The operating system can invoke it.

Another agent can delegate to it.

The interface can appear only when human judgment is required.

The most consequential transition may therefore not be from graphical interfaces to conversational interfaces.

It may be:

In that model, the user does not navigate software.

Software assembles itself around the user’s objective.

The standards required for that architecture are incomplete.

The implementations are still fragmented.

Security, permissions, business models, discovery and user trust remain unresolved.

But the underlying components are no longer theoretical.

They are being standardized now.

Pattern detected.

The interface is becoming dynamic.

The application is becoming callable.

The agent is becoming the orchestration layer.

Monitoring continues.