Agent Applications as the Next Application Substrate: Intelligence Diffusion, Knowledge Aggregation

I. Overview: From a Technical Substrate to a Two-Way Loop

I have to say that Agentic AI is one of the most joyful fields to be in right now. Sometimes it even gives me an almost postwar-technological-boom feeling. Every so often, foundation models and Agent products suddenly deliver a cluster of interesting capabilities. We have practically reached the point where every few days is another big day.

The pace of Agent product iteration in 2026 has been extraordinary. Early discussions of ChatGPT were mostly about whether it could answer questions. Then the question became whether it could complete a task: create slides, process a document, or analyze a dataset. Now product design is moving beyond completing a task to accumulating experience—and even proactively identifying work that should become a Skill, Memory, or Automation.

Since March, thinking about the next generation of digital applications with Agents at the center has increasingly led me to one conclusion: Agent applications may become a technical substrate, not merely another category of software.

First, though, a piece of news I particularly enjoyed while writing this article in August.

Moderna and Merck announced positive Phase 3 topline results for the individualized mRNA neoantigen therapy intismeran autogene combined with pembrolizumab in high-risk melanoma following surgery. It remains investigational; full results, overall-survival data, and regulatory conclusions still need to be followed. It should not yet be described as a validated universal cancer-treatment platform. Moderna’s official explanation

What attracts me to this approach is its structure. mRNA provides a programmable technical substrate, while the characteristics of each patient’s tumor inform a personalized configuration. The underlying platform is general; the treatment is tailored. As design, manufacturing, treatment, and follow-up become digitized, experience across cases may improve our understanding of both disease and the platform.

I am not suggesting that Agents and cancer therapies are technically equivalent. What interests me is the shared structure:

A general technical substrate enters many personalized settings. Those settings produce new experience, which can be organized and used to improve the substrate.

Previously, I would have expressed this as:

Foundation models ↔ Digital knowledge center ↔ General Agent applications ↔ Customized software

Now I think we can make the two directions clearer.

One direction takes models, Skills, Harnesses, tools, and workflows from a digital knowledge center into applications and real-world work. I call this:

Intelligence Diffusion.

The other direction brings tasks, trajectories, outcomes, failures, corrections, and boundaries back from the real world, turning them into knowledge that future Agents can reuse. I call this:

Knowledge Aggregation.

The relationship looks roughly like this:

Digital knowledge center                 Real-world settings
Models                   — diffusion →   Agentic Software
Skills / Harnesses                       Persistent Agents
Evals / Contracts        ← aggregation — Tasks / Outcomes
Policies                                 Evidence / Failure

A digital knowledge center sits on one side, frontline settings on the other. Agent applications, Agent Runtimes, and Agentic Software connect them.

This two-way loop is the central idea of this article.

II. Intelligence Diffusion: Bringing Agentic Software into Every Loop

The Agent Product Race

One of the liveliest things happening now is the race among Agent products.

The competition is no longer only about model scores. It is about how Agents enter real workflows and reduce the cost of sustained human–Agent collaboration.

Claude Code’s Artifacts turn work in progress inside a Session into a continuously updated visual page that can be shared and collaborated on. This is not simply a prettier answer: it makes an Agent’s intermediate state and working process something a team can understand together. Claude Code Artifacts

Anthropic also introduced Claude Tag. In Slack, users can tag Claude like a colleague, let it access authorized channels, tools, and repositories, and have it work asynchronously or follow up on unresolved questions. Different Claude identities can have memory and permissions scoped to different channels. Claude Tag

Codex introduced Record & Replay. A user demonstrates a workflow, and Codex organizes its goal, inputs, steps, and verification into a reusable Skill. What I find interesting is that teaching an Agent shifts from writing an abstract specification to first showing it how the work is done. Record & Replay

Computer History takes another step. After users explicitly enable it and choose data sources, it organizes cross-application activity into a timeline and local memory, helps recover earlier work, and suggests Skills or Automations when it notices repeated patterns. It is not simply continuously recorded video: it is a long-term work-context system built around interaction events, summaries, permissions, and user control. Computer History

Cursor’s /automate lets users describe an automation goal in natural language and have an Agent configure triggers, instructions, and tools. It also supports always-on Agents triggered by events from services such as GitHub and Slack. Cursor Automations

Kimi Work brings local files, browsers, scheduled tasks, professional databases, and long-running execution into a desktop Agent environment. It can organize an Agent Swarm according to task complexity. At the time of writing, its documentation described up to 300 sub-agents and long tasks spanning tens of hours and thousands of tool calls. Kimi Work

My favorite part of Kimi Work was slightly funny: it could connect to professional financial data. I recommended it to friends who trade stocks, so they could ask an Agent to write quantitative backtests. Their feedback was good—although it certainly had an appetite for tokens, haha.

Taken together, these products reveal a clear progression:

Answer questions
→ Complete tasks
→ Produce shareable Artifacts
→ Externalize workflows as Skills
→ Build cross-task Memory
→ Become persistent Agents
→ Proactively discover and improve workflows

I call this a race not because everyone is building the same chat product, but because Coding Agents have compressed the journey from an idea to a feature. A good feature can be followed quickly, pushing competition further outward: who understands users better, works persistently, accumulates experience, and safely brings Agents into more real systems?

Why Agent Applications Could Become an Application Substrate

A natural question follows: are these simply product features, or general-purpose platform capabilities?

My answer is the latter.

When building a Web application, we usually do not reimplement windowing, font rendering, networking, local storage, sandboxing, and cross-platform adaptation. We build on the browser. The browser does not understand our business, but it provides a sufficiently general Runtime that lets us concentrate on our product.

Mature Agent applications are developing a similar structure. Foundation models provide probabilistic understanding and reasoning; the Agent Harness handles context, tools, state, permissions, approvals, execution, verification, recovery, and long-term memory.

I sometimes compare a foundation model to an NLPU, and its Harness to a Runtime and Control Plane. This does not mean natural language is equivalent to CPU instructions. It means the model is becoming a probabilistic computational resource that needs scheduling, constraints, and verification. Natural language is useful for expressing goals, but whenever an action can become code, a query, a test, or a structured tool call, the system should return to a more deterministic and verifiable execution path.

OpenAI has described Codex as an open Agent Harness that can be embedded into other products. It manages the Agent Loop, state, tools, sandboxing, and approvals, while the host retains its UI, business rules, data, permissions, and ultimate control. Codex as a platform

In research, AIOS also explores scheduling, context, memory, storage, and access control as services of an Agent Operating System. AIOS

This is what I mean by Agent applications becoming the next application substrate.

It does not mean every application becomes a chat box. Good fixed interfaces remain important. For frequent, deterministic actions, clicking, dragging, filtering, and comparing are often faster, cheaper, and more predictable than describing the goal again.

The change is that software need not rebuild general Agent capabilities. It can keep the interface and data model appropriate to its business, while delegating intent interpretation, context assembly, tool use, exception handling, and long-term learning to an underlying Agent Runtime.

Release Is Only the Beginning: Users as Co-Builders

When an Agent Runtime enters ordinary software, the software itself can change.

Traditionally, developers define the product. Users can adjust settings, but rarely alter the product safely and cheaply. Yet users are closest to the actual work.

Half the fields in a company-wide expense system might be constant for one sales team. Security, product, and engineering teams may care about very different aspects of the same operational data. A central team cannot cheaply build a separate version for every local need.

Agents may make this economically feasible.

There is already a direct precedent. Geoffrey Litt’s 2023 essay on Malleable Software proposed that ordinary users could modify their software with an LLM acting as a local developer. He emphasized that the future need not consist only of chat boxes: an inner loop of direct software use can coexist with an outer loop in which an LLM helps modify the software. Malleable Software in the Age of LLMs

I think Agentic Software can continue in this direction:

A public product core + a private Agent Overlay.

The public core owns the data model, core capabilities, security invariants, compatibility, and shared Verifiers. The private Overlay owns the user’s workflows, automations, interface organization, and expression.

Users do not need to copy a repository or first become conventional programmers. They can keep developing the software they use—within controlled boundaries—by expressing intent, demonstrating workflows, correcting mistakes, and accepting results.

Consider an expense system that requires downloading invoices, filling a dozen fields, selecting an approval chain, and filing receipts. An Agent can learn a sales team’s process and create a private Overlay that extracts project, region, and amount from invoices and calendars, pre-fills a fixed cost center, and sends only exceptions for confirmation.

The public expense system remains. The Agent folds away complexity the team should not have to handle repeatedly.

Of course, this cannot mean letting AI change anything it likes. A reliable local adaptation must specify:

• Which interfaces, logic, and resources may be changed.
• Which security and business invariants must hold.
• Which actions require user approval.
• How changes are previewed and verified.
• Whether an Overlay remains valid after an upgrade.
• How to roll back to the public default.

Local modification raises another problem: will software fragment into countless private forks that cannot be tested, upgraded, or maintained?

Effective local adaptations therefore need a path back into the public product.

My proposed Knowledge-based Pull Request contributes not primarily unfamiliar code that a project must merge, but product knowledge sufficient for the project to reconstruct the change: what the user wants, where the need applies, what counts as completion, which examples and counterexamples define its boundary, what must not break, and how real use has corrected and verified the proposal. Knowledge-Based Pull Requests paper

The project’s own Agent then implements the change using its code, architecture, Policies, and tests. Maintainers first review the problem, evidence, and boundaries, then the implementation, rather than starting with a large volume of code generated by an external Agent in an unfamiliar context.

GitHub has already discussed the growth of Agent PRs and pressure on review bandwidth. Agent pull requests are everywhere

KPR remains a product and research proposal requiring validation. If it does not reduce time to an initial decision, clarification rounds, rework, or post-merge defects, it is merely a more complicated issue template. That boundary matters.

But if it works, a local adaptation is no longer merely private convenience. Verified needs from real settings can help evolve shared software.

Developers as Distributors of Intelligence

There is also a rather mundane but unavoidable question: where does the money come from?

Developers integrating foundation models initially become token consumers. Greater usage brings higher inference bills. If they only bear costs without sharing the additional value, many will lack the incentive to deploy Agents into every small setting.

So I want to retain a slightly provocative description:

Software developers may become token distributors for foundation-model companies and Agent platforms.

This has precedents. Poe allows bot creators to price dynamically according to input length, output length, and computational complexity, earning revenue from usage. Poe Bot Monetization API

Strictly speaking, however, tokens measure cost; they should not be the final unit of value. Revenue tied directly to token consumption can reward verbosity, inefficiency, or deliberately excessive calls.

The more precise long-term concept is:

Software developers become distribution nodes for Agent capabilities and value.

They may charge for tokens or messages, but also for subscriptions, tool calls, transactions, professional data, successful outcomes, or time saved.

Model companies supply general intelligence; Agent platforms supply Harnesses and Runtimes; developers supply domain data, workflows, interfaces, customer relationships, and last-mile delivery. Together they accomplish intelligence diffusion and share the value it creates in real settings.

When this economic chain works, developers have a reason to deploy Agents into situations previously too small to automate.

And the more settings there are, the more important the reverse path becomes.

III. Knowledge Aggregation: How Real Settings Improve Agents

As Agentic Software enters more settings, it naturally produces many interaction trajectories.

A trajectory includes more than what the model said:

• The task the user actually wanted to complete.
• The environment the Agent observed.
• The tools it called.
• Where execution failed.
• Where the user corrected it.
• Whether the final result was accepted.
• Which security or business constraints blocked an action.
• Whether completing the task had a real effect.

Such data may help train better Agents. But “more settings and more trajectories automatically produce stronger models” is a dangerous simplification.

Trajectories are not knowledge, and volume is not training value.

An Agent choosing the wrong tool differs from a product failing to supply the right tool. Misunderstanding a user differs from the user never expressing the goal clearly. If every failure is labeled “the model is not smart enough,” additional trajectories simply create additional noise.

A single task also produces knowledge with two different ownership structures.

One kind concerns the system: unstable tools, missing context, escalation conditions, or stopping rules that end work prematurely. With authorization and de-identification, this can improve the Harness, Evals, Model Driver, and model.

The other concerns the user: naming conventions, expression, risk boundaries, workflows, and acceptance criteria. It can become a private Skill or Preference, but should not enter general training by default under the banner of improving the product.

The first makes the Agent system more reliable; the second helps this Agent understand this user. They can originate in the same task without sharing ownership.

From Raw Trajectories to Trusted Knowledge

A digital knowledge center cannot simply be a large trajectory database.

A useful center should record at least:

1. Task: What was to be accomplished?
2. Context: What environment and constraints applied?
3. Trajectory: What did the Agent and human do?
4. Outcome: What ultimately happened?
5. Evidence: Why is the result considered successful or unsuccessful?
6. Provenance: Who supplied the information, and how was it changed?
7. Permission: What uses are authorized?
8. Verifier: How can the conclusion be checked again?
9. Scope: Where does the knowledge apply—and where not?

Technically, I therefore prefer the term:

Trusted Knowledge Aggregation.

“Trusted” does not mean trusting a central platform. It means contributions can be traced, inspected, withdrawn, and reverified.

Raw private data need not even leave the local environment. What is aggregated may be user-approved Claims, de-identified failure types, reproducible tasks, Verifiers, Skills, parameter updates, or scoped product knowledge.

This gives KPR another role: not just a software collaboration protocol, but a trusted boundary for transferring knowledge from private settings to a shared knowledge center.

Three Layers of Knowledge Feedback

Knowledge feeding back into Agents has at least three distinct layers.

The first is Memory and Skill feedback.

It does not change model weights. It preserves user preferences, environmental knowledge, and verified workflows for the current Agent. This is the cheapest, fastest layer and the easiest one in which to retain user ownership.

The second is Harness and Eval feedback.

Failure trajectories can reveal missing context, poorly designed tools, inappropriate permissions, premature stopping conditions, or insufficient Verifiers. Teams can then change the Runtime, tool schemas, prompts, workflows, and tests.

Only the third is model post-training feedback.

Once a task has been reconstructed in a reproducible environment, its outcome is verifiable, failures are attributable, and data use is authorized, it may enter SFT, Verifier training, preference learning, or Agentic RL and actually change model weights.

Research already supports the idea that high-quality, diverse, verifiable scenario data can improve Agent capabilities.

Agent-FLAN argues for more careful treatment of formatting, reasoning, tool use, and negative examples in Agent training data. In its evaluation setting, this design improved Llama2-7B over earlier methods by 3.5%, while negative examples mitigated some hallucinations. Agent-FLAN

SWE-Gym assembled 2,438 software-engineering tasks with real repositories, executable environments, and unit tests, reporting absolute gains of up to 19 percentage points. The value lies not only in realistic tasks but in executable, verifiable ones. SWE-Gym

ATLAS supplies an important counterexample to “more is better”: imitating complete expert trajectories is not necessarily optimal. In its experiments, training on roughly 30% of critical planning and decision steps outperformed training on full trajectories. ATLAS

APIGen-MT likewise emphasizes multi-turn, varied, verifiable data rather than volume alone. APIGen-MT

Together, these studies suggest:

The valuable resource is not more raw trajectories, but more authorized, verifiable, attributable experience across different settings.

As a rough intuition, I would write:

Knowledge value
≈ Scenario coverage
× Verifiability
× Attributability
× Authorization for use

If any factor approaches zero, the trajectory’s value for shared training may be very low.

Models and Harnesses Evolving Together

A Harness influences not only what an Agent does today, but also what training data the system can collect.

Without tool results, failure causes, and user corrections, a model team sees only a vague conversation. With structured state, Verifier results, permission blocks, and alternative candidates, the next round can obtain clearer examples of success, failure, recovery, and preference.

Two 2026 preprints directly explore this relationship.

Recursive Harness Self-Improvement treats a Harness as both an execution mechanism and a producer of future training trajectories, and explores improving it from historical performance. Its experiments primarily use synthetic machine-learning research tasks, leaving a substantial gap to general real-world self-improvement. RHI

HELIX proposes a Build–Update–Rebuild loop: build a Harness, update the model using verified trajectories, then rebuild the Harness for the updated model. Models and Harnesses jointly shape behavior and generate data for the next generation. Its current evidence, however, covers one evolution round in code repair. HELIX

This closely matches the two-way loop in this article:

Digital knowledge center
→ Models, Harnesses, Skills
→ Agentic Software
→ Real-world settings
→ Tasks, trajectories, outcomes, evidence
→ Digital knowledge center

Intelligence diffuses through Agentic Software. Experience returns through trusted aggregation as new Memory, Skills, Evals, Harnesses, and training data. Improved systems then enter more settings.

Intelligence diffusion and knowledge aggregation now form one large Loop.

IV. XYZ to RSI: From Human Loops to Agents Improving Agent-Producing Loops

Break modern work down and we find ourselves living in countless Loops:

Observe the environment
→ Understand the problem
→ Make a judgment
→ Act
→ Check the result
→ Adjust the next action from feedback

Historically, the intelligence in these Loops has usually come from people. Software records, communicates, and executes predefined rules. Ambiguity, changing goals, and exceptions bring humans back into the Loop.

Agents change the share of that work performed by humans.

But this is not only about replacing a few steps in existing work.

Human intelligence is expensive, scarce, and difficult to replicate in parallel. Only sufficiently important problems justify someone continuously observing, judging, and responding. Many small, infrequent, persistent problems never receive a complete intelligent Loop.

Agents can maintain many such Loops: observing a software project, following experiments, maintaining a personal knowledge space, checking business anomalies, or resuming work when an external event occurs.

The change is therefore not only:

Agents take a growing share of existing Loops.

It is also:

We can create many more intelligent Loops at the same time.

This is how I understand AgenticXYZ.

X: Crossing

X is Crossing: People with Agents, corresponding to Human in the Loop.

Agents enter human workflows and work alongside people. Humans usually supply goals, context, important judgments, and final acceptance. Agents perform some of the search, organization, generation, execution, and verification.

X is not merely about humans rescuing AI after mistakes. It is about people and Agents jointly establishing Loops that could not previously be automated.

This is where most Agent products sit today. They can perform complex work, but humans usually trigger tasks and maintain long-term goals. Identity, responsibilities, and resources across time remain insufficiently stable.

Y: Yours

Y is Yours: Agents for People, expressed here as Agents in Every Loop.

In Y, an Agent is no longer a temporary tool inside a Session. It becomes a Persistent Agent with a continuing identity, state, responsibilities, and resource budget.

Persistent operation does not require occupying a GPU around the clock. An Agent may sleep most of the time and resume when a schedule, message, data change, or external event triggers it. What matters is that identity and state survive Sessions and that the Agent remains responsible for ongoing work.

Y is not merely about everyone having an Agent.

I want to give it a more explicit—and more memorable—target:

Y reaches its population threshold when persistent Agents with real responsibilities outnumber biological humans.

To prevent this metric from being gamed, an Agent must retain identity and state, carry an ongoing rather than one-off responsibility, respond to time or real events, have explicit permissions and a resource budget, and continue to produce inspectable outcomes.

Billions of empty instances without responsibility, state, or results do not count.

We are still far from Y. Most Agents remain task executors that humans initiate temporarily, run briefly, and cease to have a responsibility relationship with afterward. Agents that persist reliably, manage permissions, and remain responsible across settings are still far from population scale.

Y matters because widespread Persistent Agents would fundamentally change the scale of intelligence diffusion. More Agents can enter more Loops; previously uneconomic problems can gain intelligent feedback processes; real settings can supply richer tasks, failures, and verification signals.

Z: Zero

Z is Zero: Agents by Agents, corresponding here to Human beyond the Execution Loop.

But Agents outnumbering humans is not RSI.

It is a threshold of quantity and coverage.

The classical idea of Recursive Self-Improvement is that a system uses its current capabilities to improve the mechanism producing future capabilities. I. J. Good’s 1965 discussion centered on machines participating in the design of better machines. Gödel Machines later considered systems rewriting their own code when they can prove a change beneficial. I. J. Good, Gödel Machines

Three levels should be distinguished:

An Agent completes a Loop automatically
= Agentic Automation

An Agent improves how it completes that Loop
= Self-Improvement

An Agent improves the mechanism producing the next improvement
= Recursive Self-Improvement

Z means Agents begin improving more than external task execution:

• Their own Memory and Skills.
• Context management and tool selection.
• Agent Harnesses and workflows.
• Verifiers and evaluation tasks.
• Training-data generation and selection.
• Research processes for the next Agent or foundation model.

The recursion closes only when the improved system re-enters the process and becomes better at producing the next improvement.

Anthropic describes a similar progression: people initially conduct AI research; chat models assist parts of it; Coding Agents execute code, delegate work, and run experiments. The RSI loop would close if Agents could autonomously design, train, and validate their successors. Anthropic also states that this point has not been reached and that RSI is not inevitable. When AI builds itself

Lilian Weng’s Harness Engineering essay suggests that a more realistic near-term form of self-improvement may occur first in the Harness, rather than through models directly rewriting their weights. Agents can improve context, tools, Memory, workflows, permissions, and evaluations, then use the resulting verified trajectories for subsequent models. Harness Engineering for Self-Improvement

AgenticXYZ therefore contains two kinds of growth.

One is growth in reach: more Agents, more settings, more Loops.

The other is growth in capability: knowledge aggregation improves each Agent’s Skills, Harness, Evals, and model.

X puts Agents into human Loops. Y gives Agents persistent responsibilities in more Loops. Z brings Agents into improving the Loops that produce better Agents.

Thus:

Agents outnumbering humans is Y’s population threshold.

Agents improving the mechanism that produces the next generation of Agents is Z’s recursive threshold.

One boundary is especially important.

Human beyond the Execution Loop does not mean Human beyond the Governance Loop.

People may leave many execution processes in Z, but goals, values, rights, immutable rules, resource limits, stopping conditions, and ultimate responsibility do not disappear as Agent numbers grow.

A reliable Z system should not let Agents modify everything. It needs sandboxes, versions, independent Verifiers, held-out evaluations, permission boundaries, audit logs, and rollback. Some immutable governance rules must remain outside the recursive loop.

Z is not unconstrained self-rewriting. It is the gradual improvement of how Agents work and how future Agents are produced, under verifiable and reversible conditions.

V. Conclusion: The Application Substrate Is Only the Beginning

Will Agent applications become the next application substrate?

My answer remains yes.

Not because chat boxes will replace all software, but because mature Agent products are packaging context, tools, state, permissions, approvals, long-term memory, task execution, recovery, and verification into a new Runtime.

Developers can retain their interfaces, data, business logic, and user relationships while reusing a mature platform’s general intelligence capabilities. Just as browsers absorbed much cross-platform complexity into a shared substrate, Agent Runtimes may absorb the complexity of bringing probabilistic intelligence into real software.

Agentic Software built on this foundation is not simply a finished product that users passively consume. With Agents, users can create private Overlays and keep adapting software to frontline work. Knowledge with genuine public value can return to the public core through KPRs, Verifiers, and human approval.

Developers may also move from token consumers to distribution nodes for intelligence and value, creating a new economic loop among model companies, Agent platforms, developers, and users.

More deployment digitizes real tasks, failures, and corrections. But these become trusted knowledge only after authorization, provenance tracking, attribution, verification, and scoping.

The loop cannot therefore be reduced to:

Deploy more Agents, collect more data, train stronger models.

A better description is:

Intelligence diffuses through Agentic Software into real settings. Verified experience aggregates into new Memory, Skills, Evals, Harnesses, and training data. Improved Agents then enter more settings.

The digital knowledge center sits on one side; frontline settings sit on the other. Intelligence diffuses outward, and knowledge aggregates back.

AgenticXYZ describes the growing role of Agents in this larger loop:

X: Agents enter human Loops.
Y: Persistent Agents spread into Loops everywhere.
Z: Agents improve the Loops that produce better Agents.

We are still far from Y, let alone Z. That does not stop us from building the required Harnesses, Persistent Memory, Skills, Agentic Software, Knowledge-based Pull Requests, Verifiers, and digital knowledge centers today.

Genuine RSI will not simply materialize from a model.

It is more likely to emerge through countless real Loops: intelligence enters a setting, knowledge comes back; Agents establish more Loops, and better Loops produce better Agents. The process accelerates until Agents do not merely participate in work, but improve the mechanisms producing the next generation of intelligence.

If I had to compress the article into a few final lines:

X puts Agents into human Loops.

Y begins when persistent Agents with real responsibilities outnumber humans.

Z begins when Agents improve the Loops that produce better Agents.

Intelligence diffuses into the real world. Knowledge aggregates back. That is the path from Agentic Software to RSI.

Intelligence will diffuse into real settings. Knowledge will aggregate back into digital knowledge centers.

Release is only the beginning. So is the application substrate.