The End of the Era of "Heavy Software". Part 1 of 2: a computer that assembles itself around intent

Half a century ago, the computer demanded that a human learn its language. First — commands, then — programming languages. Graphical interfaces hid the command line, but brought their own complexity in return: windows, menus, panels, settings, and dozens of programs, each of which you had to know by sight.

Today nobody writes code to fix a piece of text. Yet we are still forced to remember which application to open, where the right button lives, and in what order to click the mouse. GUI did not kill the programming of interaction — it made it visual.

The next step is now taking shape: the machine is told not a sequence of operations, but an intent.

"Collect the data from these documents, find the contradictions, check the calculations and prepare a final report."

"Compare the images, restore the damaged areas and prepare print-ready variants."

"Analyze the project, find the bottlenecks and propose optimizations."

The system itself decides which models, data, tools and computations will be needed. This is the foundation of Intent-Based Computing — computation that unfolds around intent rather than around a pre-written program.

1. From app to intent

The traditional software model looks familiar:

User
     ↓
Graphical interface
     ↓
Application
     ↓
Operating system
     ↓
Computer

Here the application is king and god. To write text you need Word. To process a photo — Photoshop. To calculate — Excel. To program — an IDE. The user must know which program is responsible for which job.

Intent-Based Computing breaks this bond. The human says what should happen. The system determines how to achieve it. This is a shift of abstraction: previously the computer executed a program prepared by a human in advance; now it is capable of synthesizing a program for a specific intent.

Intent
   ↓
Interpretation
   ↓
Planning
   ↓
Computation Graph
   ↓
Execution
   ↓
Result

The computation graph can live exactly as long as the task lives. When the work is done, it disappears.

2. The end of heavy software is not the end of complex programs

It is easy to imagine that the "end of heavy software" buries Word, Photoshop, CAD and other heavyweights. That would be too simplistic an interpretation. Complexity does not go away — it leaves the surface of the system.

Today, to work in Photoshop you need to know Photoshop. Tomorrow a person will simply say: "Remove the background, restore the damaged area, preserve the natural texture and prepare the image for printing." Inside, the same algorithms, color spaces, rendering and computing infrastructure will remain. But the user will no longer have to stand at the helm of this machine.

Where GUI remains king

Nevertheless, intent does not win everywhere. There are tasks in which direct manipulation of an object is more effective than any description. Drawing, video editing, music, 3D modeling, working in CAD — all of this lives in the short loop "saw → changed → saw → adjusted". Here it is easier for a human to pick up a stylus and draw a line than to explain to a model the geometry of every movement.

That is why Intent-Based Computing flourishes where a task can be formulated unambiguously, decomposed into operations, and its result objectively verified. Where most of the work is procedural rather than demanding continuous manual editing. GUI is not going anywhere — it will simply become one of the ways to express intent.

3. Data becomes the language between human and machine

The first sign of the new architecture is already visible — in document work. A traditional .docx file stores far more than the meaning of the text: styles, markup, tables, images, metadata, the internal plumbing of the format. For a human it is a way to present content; for a machine it is a data structure.

DOCX / PDF / HTML
        ↓
Semantic Representation
        ↓
Markdown / Structured Data
        ↓
Agent Processing
        ↓
Verification
        ↓
DOCX / PDF / HTML

This is round-trip processing: the editor ceases to be the only place of work and becomes one of the possible shells of the result. A broader principle grows out of this:

Markdown, JSON, structured schemas and other machine-readable representations are interesting not for their simplicity, but because they make it possible to separate meaning from interface.

But this process carries a deeper consequence: when data goes directly into an intelligent system, the boundary between data and instructions blurs again. And here a new security problem is born.

4. Intent Compiler: when data becomes code again

Classical programming built an important wall: code ≠ data. SQL injection, buffer overflows and other classes of vulnerabilities vividly demonstrated what happens when data gains the right to be interpreted as instructions.

In an agentic architecture this wall becomes shaky. A letter can contain an instruction. A PDF — an instruction. A web page — an instruction. A document that the agent is only supposed to analyze can try to change the behavior of the agent itself. This is one of the forms of indirect prompt injection.

That is why Intent-Based Computing requires a separate layer — let us conditionally call it the Intent Compiler. Its task is not just to translate natural language into a plan, but also to separate:

Trusted Intent
       │
       ↓
  User Objective
       │
       ├──────────────┐
       ↓              ↓
  Trusted Rules   Untrusted Data
       │              │
       └───────┬──────┘
               ↓
       Computation Graph

When the compiler must say "I don't know"

The Intent Compiler is not obliged to always produce a ready graph. If the intent is vague, it is more honest to return a question:

Intent
  ↓
Interpretation
  ↓
Confidence?
 ↙       ↘
YES       NO
 ↓         ↓
Graph    Question

Here the clarifying dialogue is not an interface decoration but a part of the architecture. It is the analogue of a compiler warning: "I can continue, but there is an ambiguity that should be resolved."

5. Intelligence, policy and the right to act are different things

The most dangerous illusion of agentic architecture is the belief that a smart model automatically gains the right to do everything it deems right. These notions are incompatible.

The model answers the question: what should probably be done? The Policy Engine decides: what is allowed to be done? The capability system determines: which resources does the agent physically have access to?

MODEL
"What should be done?"
        ↓
POLICY
"What is allowed to be done?"
        ↓
CAPABILITY
"Which resources are physically accessible?"

Agent Identity

From here another layer grows — agent identity. In 2026 Microsoft is rolling out Microsoft Entra Agent ID for Copilot Studio: new agents automatically get a separate account that can be managed through Entra — with audit, lifecycle management, and connector and API permissions at the level of the agent itself.

What is interesting here is not Microsoft's specific solution but the direction of travel. If an agent acts autonomously, the system must know who exactly performed the action: not just "user Ivanov", but "agent X, belonging to organization Y, with such-and-such permissions". Over time this will become the analogue of identity for a server process.

Microkernel and capabilities

The lower level is responsible not for meaning but for physically available permissions. Instead of "you are root, so you can do anything", the system says: "you may read these files for five minutes" or "you may call this API but not reach other network resources". It is here that microkernel architectures and capability-based security find a new life in the agentic world.

6. The local guard and the physical architecture of the AI computer

The Policy Engine does not have to be a large language model at all. For critical decisions it is wiser to keep a compact local loop on the device — a Guard Model. It can check:

• the type of intent;
• the level of risk;
• the requested permissions;
• the sensitivity of the data;
• whether confirmation is required;
• whether sending the task to the cloud is acceptable.

Hardware-wise, such a guard naturally lives on the NPU. But keeping the model running idle is irrational, so the local loop must work event-driven:

Normal State
     ↓
Minimal Power
     ↓
New Intent / Permission Request
     ↓
Wake-on-Intent
     ↓
Local Guard
     ↓
Decision
     ↓
Sleep

This is nothing like an ever-awake local assistant. The system wakes up only when a new intent, a sensitive action, or a permission request appears. Unified memory further reduces transport costs between CPU, GPU and NPU, letting the local loop work with a shared context without constantly shuttling large volumes of data.

Next comes the dynamic choice of execution location:

                 INTENT
                    ↓
              Local Guard
                    ↓
          ┌─────────┴─────────┐
          ↓                   ↓
       LOCAL                CLOUD
          │                   │
     privacy              power
     latency              cost
     autonomy             scale

7. Ephemeral Software: the application becomes temporary

When the Intent Compiler can assemble a computation graph, a new type of program comes into being. Ephemeral Software is a computational shell created for a specific task and capable of disappearing immediately after completion.

Today the user's path looks like this:

Install the app
        ↓
Open the app
        ↓
Select a feature
        ↓
Do the work

In the new model:

Intent
  ↓
Select Capabilities
  ↓
Build Graph
  ↓
Execute
  ↓
Destroy / Reuse

A specific program may live for only a few minutes. It gains access to the data it needs, calls models and tools, creates a temporary interface, performs the task, writes the changes into State — and disappears.

But that does not mean the project itself disappears.

8. State becomes permanent, and the interface — temporary

If applications come and go, the main question is: where does the state live? The answer: in the new architecture the state must become independent of the application. A document, a project, a database, a workflow exist on their own — without regard to which interface is currently accessing them.

                    STATE
                      │
        ┌─────────────┼─────────────┐
        ↓             ↓             ↓
      Agent          GUI           API
        │             │             │
        └─────────────┼─────────────┘
                      ↓
                  Same State

Event Sourcing and CRDT

Long-lived projects will need models in which state and history are separated from the interface. Event sourcing preserves the chain of changes. Git-like models preserve versions. CRDT and related mechanisms let several participants work with the same object simultaneously.

In an agentic environment this is especially important: several agents may become concurrent writers of a single State. Transactionality, collision resolution, priority rules and mechanisms that determine which changes can be accepted automatically will be required.

Provenance becomes part of State

In the agentic world, a history of changes alone is not enough. Every significant change must carry provenance:

State Change
     │
     ├── Agent Identity
     ├── Human / Sponsor
     ├── Intent
     ├── Capabilities
     ├── Model
     ├── Timestamp
     ├── Tool
     └── Verification

Now the system answers not only "what changed?" but also "who changed it?", "which agent acted?", "under what intent?", "with what permissions?". Agent identity turns from a security function into part of the data model.

A new vendor lock-in

But a new danger opens up right here. If the application disappears and State becomes the main object, a proprietary State format becomes a new level of dependency. Today: "I cannot open this file without the application." Tomorrow: "I cannot open this project without an agentic platform."

That is why open State, portable history, standard provenance and independent access to data are not mere conveniences but architectural prerequisites. Otherwise lock-in will simply move from the application level to the data level.

9. Generative UI: the interface lives as long as the task lives

If the computation graph is born dynamically, the interface can become dynamic too. The user says:

"Compare the sales over five years, find the anomalies and show the regions that need attention."

The system creates a table, a chart, a map, filters, explanations, elements for further analysis. When the task is complete, the interface disappears.

But this does not cancel Human-in-the-Loop. On the contrary, a need for a new form of verification arises.

Verification instead of knowing the mechanism

A human no longer has to know exactly how the system arrived at the result. But they must be able to verify that the result can be trusted. This can be achieved in three ways.

First — independent verification. A critical calculation is repeated by another method, another model, or against other sources.

Second — confirmation of irreversible actions. Transferring money, deleting data, publishing a document, or changing a production system require explicit consent.

Third — a readable structure of the computation. A visual representation shows which data, operations, models and checks took part in producing the result.

Human-in-the-Loop does not disappear. It changes level: instead of "I know which button to press" comes "I understand what the system is about to do and can assess the consequences".

Interim summary: two permanent objects and one temporary one

Let us assemble Part 1 into a single picture. The new architecture introduces two permanent objects and one temporary one.

Intent — what a human wants to achieve. State — what already exists and what has been done, together with history and provenance. Between them lies a temporary layer — Software: it receives the task, picks models and tools, gets limited permissions, creates an interface, performs the computation, writes the changes into the state — and may disappear.

At this level, the computer after applications is visible in full: the Intent Compiler, separating trusted intent from untrusted data; policy and capabilities, separating intelligence from the right to act; the local guard on the NPU; ephemeral software; permanent State; a generative interface with a new form of verification.

But as soon as a program ceases to be a pre-installed object, the next question arises by itself — about the fate of source code, repositories, libraries and the professions that grew up around them. What happens to GitHub when an agent needs not a library but a capability? Does programming disappear, or does it simply rise to another level of abstraction?

That is the topic of Part 2: "The End of the Era of Heavy Software. Part 2: after source code" →