# Companion documents
Source: https://agentapplication.mintlify.app/companion-documents
The document family the working paper anchors: manifesto, technical papers, platform architecture, and the standards that follow.
The long paper is the source, not the publication sequence. It anchors a
family of focused documents, each with a distinct job:
| Document | Purpose | Status |
| ------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | ------- |
| The Agent Applications Manifesto | A short public argument for software that does the work | Planned |
| Programming Agent Applications | The programming model, harness interpreter, packaging, runtime feature declarations, and evaluation | Planned |
| Persistent Agent Instances: Workspace, Artifacts, and Lineage | Seeds, instances, durable workspaces, state, overlays, upgrades, and recovery | Planned |
| The Agent Cloud: A Platform Architecture | Production infrastructure derived from the application contract | Planned |
| Karta and Agent Applications | A repo-grounded account of [Karta](https://karta.sh) as one implementation | Planned |
## Standards follow, not lead
The paper identifies several plausible open contracts. Standards work begins
only where two or more independent implementations need a stable boundary, in
this order:
1. **Agent Application conformance and package contract** — the minimum
portable declaration of programs, capabilities, permissions, evaluations,
and workspace requirements.
2. **Agent Artifact contract** — identity, content and state, provenance,
permissions, versions, rendering, and actions. See
[Agent Artifact](/concepts/artifact) for the two-layer model.
3. **Workspace and lineage export** — portable state plus seed/overlay
history, with secret references rather than credentials.
4. **Agent identity and delegated authority** — only after principal and
cross-system authority models are mature enough to avoid standardizing a
product-specific abstraction.
When the first contract reaches specification quality, it will appear here as
a versioned Specification section with its own change process — the shape the
Model Context Protocol established for agent-ecosystem standards.
# Agent Cloud
Source: https://agentapplication.mintlify.app/concepts/agent-cloud
The infrastructure layer for the full Agent Application lifecycle.
> **Agent Cloud** — the infrastructure layer for packaging, provisioning,
> executing, governing, observing, evolving, distributing, and metering Agent
> Applications.
Web applications required web servers, databases, browsers, CDNs, identity
systems, cloud compute, deployment systems, and observability. Agent
Applications require an equally coherent stack — and it is not merely a model
API or an agent framework hosted on servers.
Each platform layer exists because a prior application invariant requires it:
seed packaging and registry; instance provisioning; durable workspace compute;
model and harness abstraction; tools and capability access; memory, knowledge,
and context; artifact infrastructure; long-running execution; observability
and evaluation; an evolution control plane; and distribution, billing, and
economics.
A category-defining Agent Cloud should not assume one model or harness will
permanently dominate.
See [the paper](/paper), section 17 (The Agent Cloud). The author builds
[Karta](https://karta.sh), one implementation; the paper's Appendix C states
what that relationship does and does not claim.
# Agent Artifact
Source: https://agentapplication.mintlify.app/concepts/artifact
A durable work product created or maintained by an instance: content plus a record.
> **Agent Artifact** — a durable work product created or maintained by an
> instance. Content plus a record: pristine content that renders anywhere, and
> an environment-held record carrying identity, versions, provenance,
> audience, and lifecycle.
Agent Applications should be evaluated by the work they produce and maintain,
not by the fluency of their conversations. A message is ordered inside a
conversation and transient in purpose; an artifact is independently
addressable, durable, revisable in place, versioned, shareable outside the
originating conversation, and capable of becoming input to future work. The
difference is the difference between discussing a spreadsheet and having the
spreadsheet.
The two layers divide cleanly: content, structured data, view state, and
executable actions belong to the **content layer** (bytes that render and run
in any conforming environment); provenance, permissions, comments, versions,
and maintenance links belong to the **record layer** (held by an environment,
exported as a verifiable sidecar when the artifact travels). Strip every
record and what remains is a usable document or application.
Artifacts are the natural first standardization boundary — see
[Companion documents](/companion-documents).
See [the paper](/paper), section 13 (Artifacts: The Durable Units of Work).
# Instance
Source: https://agentapplication.mintlify.app/concepts/instance
A provisioned, persistent descendant of a seed, bound to one user, customer, team, project, or job.
> **Instance** — a provisioned, persistent descendant of a seed, bound to one
> user, customer, team, project, or job.
Traditional software is invoked: a process starts, handles a request, and
exits. An Agent Application is **instantiated**: creation binds a seed to a
durable identity, an owner, a workspace, a policy envelope, and a history.
The identity carries the accountability record: who the instance represents,
what it may do, who granted that, and what it has done. At creation time,
instances of the same seed are equivalent; over time they can diverge — one
acquires a customer's terminology and templates, another specializes in a
different regulatory environment, a third generates tools for a particular
team. That divergence is [lineage](/concepts/lineage), and it is governed, not
prevented.
An instance is not its workspace: the instance has identity, ownership,
authority, lifecycle, and lineage, and it *owns* one or more computational
environments — see [Agent Workspace](/concepts/workspace).
See [the paper](/paper), sections 6 (The Shape of an Agent Application) and 10
(Instantiation, Not Invocation).
# Agent Lineage
Source: https://agentapplication.mintlify.app/concepts/lineage
The history of an instance as it diverges from its seed — governed, not prevented.
> **Agent Lineage** — the history of an instance as it diverges from its seed.
Version control records how a shared codebase changes. Lineage records how a
particular instance changes relative to its seed and its peers: installed
upgrades, local natural-language program patches, generated code,
user-authored changes, evaluation results, artifact history, tool and
permission changes, forks, merges, and rollback points.
Divergence is the paper's riskiest proposition, and it is treated accordingly:
not every change has equal risk. Knowledge, preferences, behavior,
capabilities, structure, and core policy are different classes of evolution
with different mutation and approval semantics — the architecture makes the
layers explicit rather than claiming software vaguely "learns." A platform can
deliver most of the model's value with sealed releases and mutable workspace
state, and should start there.
Lineage distinguishes **upstream evolution** (improving the shared seed),
**local evolution** (specializing one instance), and **federated evolution**
(discovering improvements across instances without leaking private data).
See [the paper](/paper), sections 12 (Living Software and Governed Evolution)
and 19 (Security, Reliability, and Governance).
# Seed Application
Source: https://agentapplication.mintlify.app/concepts/seed-application
The developer-authored starting package that Agent Application instances are created from.
> **Seed Application** — the developer-authored starting package instances are
> created from. Contains code, natural-language programs, knowledge
> declarations, artifact definitions, policies, dependencies, tests. The
> common ancestor, not the final state of any instance.
A seed is what a developer ships. Two things are always in it: the
harness-native application source, and a declaration of what that source needs
from a runtime. Everything else is optional, and most seeds carry some mixture
of system instructions and operating procedures, skills and worked examples,
tool and subagent definitions, hooks and conventional code, schemas and
knowledge declarations, artifact recipes and renderers, evaluation suites,
permissions and approval policy, and migration rules.
The harness determines file layout and development loop. Preserving its native
concepts avoids collapsing every harness into a lowest-common-denominator
schema: two harnesses can satisfy the same declarations and still behave
differently, which makes a runtime declaration a compatibility floor rather
than an equivalence claim.
See [the paper](/paper), sections 9 (Packaging a Seed Application) and 10
(Instantiation, Not Invocation), and Appendix A for a candidate seed manifest.
# Agent Workspace
Source: https://agentapplication.mintlify.app/concepts/workspace
The durable computational boundary an instance lives in — a computer per instance, not a store of documents.
> **Agent Workspace** — the durable computational boundary an instance lives
> in: filesystem state, programs, artifacts, knowledge, tool configuration,
> secret references, schedules, logs, lineage.
The distinguishing word is *computational*. A store of text documents keeps a
record. It does not keep a computer, and the difference decides what the
software can be asked to do next session.
A concrete way to check: open a second session a day later and see whether the
packages, files, and indexes the first one created are still there.
The workspace is a *logical* computer, not necessarily a continuously running
machine. Platforms can use suspension, cold starts, copy-on-write storage,
containers, and microVMs; what must persist is identity, state, programs,
artifacts, commitments, and lineage. Per-instance workspaces are required
because programs may diverge, capabilities may diverge, knowledge and
artifacts are private, long-running work needs continuity, execution must be
inspectable, and evolution requires rollback.
> A context window is transient. A workspace is durable.
See [the paper](/paper), section 11 (The Workspace: A Computer Per Instance).
# Agent Applications
Source: https://agentapplication.mintlify.app/index
A new software architecture for the AI era. A working paper defining the recognizable shape of agent-native software: seeds, durable workspaces, artifacts, lineage, and the Agent Cloud.
**A working paper** · Draft 0.5 · August 2026 · [Read the full paper](/paper) ·
[Cite](#cite)
> **An Agent Application is a software system whose primary unit of execution
> is one or more persistent, tool-using agents operating in durable workspaces
> to accomplish work over time and produce or maintain durable artifacts.**
Desktop, web, and mobile each arrived as a new kind of application, not a new
interface on the old one. AI is producing the next one. Software that finishes
work rather than answering questions has to keep the work somewhere — and that
one requirement reaches all the way down: into how the software is written,
packaged, instantiated, governed, and paid for.
## The primitives are already here
A web application, in 1994, was not a plan. It was what emerged after the
primitives existed: HTTP to move requests, HTML and then JavaScript to express
behavior, the browser to execute it. The frameworks came later, and the
industry settled what a "web application" was only once frameworks made
building one repeatable.
The agent era has already produced its equivalents: a tool protocol (MCP)
playing the role HTTP played; portable program material (Agent Skills and
similar formats) playing the role of the executable page; sandboxed compute;
and the **harness** — the runtime around the model that executes the agent
loop — playing the role the application frameworks played. What has not yet
settled is the shape of the application these primitives add up to. That is
what the paper names — so tooling, infrastructure, and developer experience
can standardize around it.
## Seven propositions
Stated plainly so they can be argued with.
1. **AI produces a new application model, not merely a new interface.**
2. **Natural language becomes first-class executable program material alongside
conventional code.**
3. **An Agent Application is instantiated into a durable workspace rather than
invoked in a session.**
4. **Artifacts, rather than conversations, are the primary units of durable
value.**
5. **Instances may diverge from the seed they were created from, and that
divergence has to be governed rather than prevented.**
6. **Governing it requires per-instance identity, compute, storage, provenance,
policy, and cost accounting.**
7. **Supporting the full lifecycle requires a distinct infrastructure layer,
the Agent Cloud.**
## A shape, not a checklist
Mobile applications come in enormous variety — an offline game, a banking
client, a camera tool — and no property list covers all of them, yet nobody
struggles to recognize one. Agent Applications will span at least that
variety. The way to recognize one in the wild is by its facets, ranked by how
much of the category's distinctness each one carries.
| # | Facet | Tier | What it looks like |
| -- | -------------------------------------- | -------------- | ---------------------------------------------------------------------------------------------------- |
| 1 | Persistent instance identity | **Defining** | A durable identity bound to one customer relationship, carrying the accountability record |
| 2 | A durable workspace that is a computer | **Defining** | A persistent computational environment: files, code, dependencies, indexes, still there next session |
| 3 | Durable work | **Defining** | Results that outlive the session: artifacts, workspace state, external records, continuing processes |
| 4 | Tool use | Characteristic | The application inspects or changes something outside the model response |
| 5 | Hybrid program | Characteristic | Behavior from conventional code, natural-language programs, and knowledge together |
| 6 | Long-running, event-driven work | Characteristic | Work that pauses, resumes, wakes on events, and schedules its own future |
| 7 | Durable delegated authority | Characteristic | Grants held by a long-lived non-human principal: revocable, expiring, never self-granted |
| 8 | Multiple surfaces | Capability | Chat, artifact canvas, API, email, and operations views onto one instance |
| 9 | Governed evolution | Capability | Instance-local program change under policy, evaluation, and lineage |
| 10 | Marketplace distribution | Capability | Signed releases, permission review, entitlements, upgrade channels |
The first three are **defining**: no adjacent category exhibits all three. The
next four are **characteristic**: close to universal in production, but shared
with neighboring categories. The last three are **capabilities**: they mark
maturity, not membership. Read it as a recognition guide — the more facets a
system exhibits, the more unmistakably it is an Agent Application — or as a
path: many teams arrive from a copilot, adding instance identity first,
durable work second, and a workspace only when the work demands one. Stopping
partway is frequently the right decision; chatbots, copilots, workflow
automation, and agent frameworks are adjacent forms, not lesser ones.
## Every era gets its application model
| Era | Application model | What persisted |
| ------------------ | --------------------- | ------------------------------------- |
| Personal computing | Desktop application | Local files, installers, the OS |
| Internet | Web application | Servers, databases, the URL |
| Mobile | Mobile application | Device identity, sensors, the store |
| AI | **Agent Application** | Seeds, workspaces, artifacts, lineage |
## Distributed as a seed, instantiated as lineages
A developer ships a **seed**: the harness-native application source plus a
declaration of what it needs from a runtime. The harness keeps its own file
layout — the model does not collapse every harness into a
lowest-common-denominator schema.
```text theme={null}
account-operator/
|--
|-- skills/
| |-- account-review/
| `-- renewal-planning/
|-- agents/
| |-- researcher/
| `-- reviewer/
|-- tools/
|-- policies/
| |-- approvals.md
| `-- external-actions.md
|-- knowledge/
|-- artifacts/
|-- evals/
| |-- behavior/
| |-- security/
| `-- regression/
|-- migrations/
`-- app.yaml
```
Instantiation binds that seed to one customer relationship: a durable
identity, a workspace that is a computer, a policy envelope, and a history.
Instances accumulate different knowledge, artifacts, and — where policy
permits — program overlays. Deployment produces copies; *instantiation
produces lineages*, and lineage is governed, not prevented.
## Cite
```bibtex theme={null}
@misc{kelkar2026agentapplications,
title = {Agent Applications: A New Software Architecture for the AI Era},
author = {Amol Kelkar},
year = {2026},
note = {Working Draft 0.5},
url = {https://agentapplication.io/paper}
}
```
***
Written by Amol Kelkar. The definitions and portability contracts in this
paper are written so that any platform can implement them. The author builds
[Karta](https://karta.sh), one implementation of the Agent Cloud the paper
describes; the paper's Appendix C states what that relationship does and does
not claim.
# Agent Applications: A New Software Architecture for the AI Era
Source: https://agentapplication.mintlify.app/paper
Working Draft 0.5, August 2026. The full working paper: the era arc from primitives to frameworks to applications, the ten-facet shape of an Agent Application, and the Agent Cloud.
**Working Draft 0.5 · August 2026 · Amol Kelkar** · [Plain text](https://agentapplication.io/llms-full.txt)
This is a category-defining working paper. It argues that agent-native software
has a recognizable shape, names the pieces that shape is made of, and proposes
that the industry settle on them so the shared parts can be built once instead of
reinvented at every company.
The author builds Karta, one implementation of the platform described here. The
definitions and the portability contracts are written so that other platforms can
implement them. Appendix C maps this paper's terms onto Karta's and states what
that mapping does not claim.
*Editorial note for 0.5.* This draft reframes the definition from a set of
qualification requirements into a recognizable shape carried by ranked facets
(section 6), and restructures the opening around the era arc from primitives to
frameworks to applications (sections 2 through 5). The technical middle of draft
0.4 (sections 8 through 19) carries forward with targeted changes only.
***
## Abstract
Desktop, web, and mobile each arrived as a new kind of application rather than a
new interface on the old one, and each era's assumptions about how software gets
written, shipped, run, and paid for outlasted the screens people remember them
by.
The agent era needs one too. The common reading of this moment is that the interface
changes again: chat replaces forms, existing products acquire copilots. That is
true of the near term and it stops short of the architecture. The primitives of
the new model are already deployed — a tool protocol, portable natural-language
program material, sandboxed compute — and harnesses have begun organizing them
the way application frameworks once organized HTTP and JavaScript. Software that
finishes work rather than answering questions has to keep the work somewhere,
and that one requirement reaches all the way down.
This paper calls the result an **Agent Application**: a software system whose
primary unit of execution is one or more persistent, tool-using agents working in
a durable workspace over time, producing and maintaining durable artifacts. It is
built from conventional code, natural-language programs, and knowledge resources
interpreted together. It is distributed as a seed and instantiated into a
workspace that belongs to one customer relationship. That workspace is a logical
computer: the instance can install a dependency, generate code, and find both
intact six weeks later.
Products that look unrelated from outside turn out to be this same thing
underneath. Some companies sell the agent itself as the product, priced per
customer relationship rather than per seat. Established software vendors package
what their product already knows into something that does the work instead of
displaying it. Teams take on virtual employees that hold their own accounts and
their own history, where a manager can ask what one of them did last quarter. And
many of these never hold a conversation at all, waking on a schedule to keep a
body of records straight.
The industry is already building the pieces separately. Versioned agent
configurations, per-owner durable state, audit trails, portable agent formats,
snapshot and restore, approval governance, and a tool protocol all exist in
shipping products today. What has not happened is anyone assembling them and
treating the result as one kind of software with one set of contracts.
Doing that would let the shared parts be built once: packaging and release
formats, runtime contracts, workspace exports, and protocols for agent identity
and delegated authority. It would also put the hard problems somewhere they can
be worked on in the open, among them what identity means for something that acts
on your behalf for years, how to deploy software that goes on changing after it
ships, how to migrate state that never had a schema, and who answers for what it
did. The infrastructure that would carry all of this is a distinct layer, called
here the **Agent Cloud**.
Most work needs none of it, and this paper says where that line falls.
***
## 1. The Central Thesis
Seven propositions, stated plainly so they can be argued with.
1. **AI produces a new application model, not merely a new interface.**
2. **Natural language becomes first-class executable program material alongside
conventional code.**
3. **An Agent Application is instantiated into a durable workspace rather than
invoked in a session.**
4. **Artifacts, rather than conversations, are the primary units of durable
value.**
5. **Instances may diverge from the seed they were created from, and that
divergence has to be governed rather than prevented.**
6. **Governing it requires per-instance identity, compute, storage, provenance,
policy, and cost accounting.**
7. **Supporting the full lifecycle requires a distinct infrastructure layer, the
Agent Cloud.**
Together these describe a software architecture materially different from
chatbots, copilots, workflow automation, agent frameworks, and conventional SaaS.
The propositions are not all the same kind of claim, and the difference is worth
marking once. Propositions 1 through 4 are definitional: they say what the shape
is, and they are meant to be recognized in shipping systems today. Propositions
5 and 6 are design proposals: they say how divergence should be handled by a
platform that chooses to permit it, and they are meant to be argued with.
Proposition 7 is a prediction about where the supporting infrastructure settles,
and it is meant to be tested by the market.
Proposition 5 is the one that carries the most risk and the least existing
practice, and sections 12 and 19 treat it accordingly. A platform can deliver
most of the value of this model with sealed releases and mutable workspace state,
and should start there.
The paper moves in four parts. Sections 2 through 7 establish the era, the
shape, and the vocabulary. Sections 8 through 13 develop the application model:
the hybrid program, the seed, instantiation, the workspace, governed evolution,
and artifacts. Sections 14 through 19 cover operation: runtime, delivery
strategy, economics, the Agent Cloud, portability, and governance. Sections 20
through 26 place the category's boundaries, name the open problems, walk one
application through its full lifecycle, and close with the category compressed
to a single page.
***
## 2. Every Computing Era Creates a New Application Model
Software history is usually told through hardware generations or interface
changes. The more useful lens is the application model: the assumptions that
determine how software is authored, executed, distributed, operated, and paid
for.
| Computing era | Application model | Characteristic stack |
| ------------------ | ------------------- | --------------------------------------------------------------------------- |
| Personal computing | Desktop application | Native code, operating systems, GUI toolkits, local files, installers |
| Internet computing | Web application | HTTP, browsers, servers, databases, cloud infrastructure |
| Mobile computing | Mobile application | Mobile SDKs, touch interfaces, sensors, app stores, device identity |
| Agent computing | Agent Application | Hybrid programs, durable workspaces, tools, artifacts, lineage, Agent Cloud |
None of those transitions was cosmetic.
A web application was not a desktop application wearing a browser. It ran on a
different runtime, shipped through a different distribution model, drew its
security boundary somewhere else, kept its state somewhere else, and made money
differently.
A mobile application was not a smaller web page. It carried continuous identity,
local sensors, notifications, store distribution, intermittent connectivity, and
a different relationship with the person holding it.
The AI transition deserves evaluation at that level. A chat box added to an
existing product is useful in the way an early website reproducing a printed
brochure was useful. New media eventually produce forms the old architecture
could not express.
Each of those earlier models was assembled, not announced. The primitives came
first, frameworks organized them, and the application model was what the
industry eventually recognized it had built. The agent era is following the same
sequence, and it is further along than it looks.
***
## 3. The Primitives Are Already Here
A web application, in 1994, was not a plan. It was what emerged after the
primitives existed: HTTP to move requests, HTML and then JavaScript to express
behavior, the browser to execute it. The primitives preceded the frameworks —
Rails, Django, and their peers — by roughly a decade, and the industry settled
what a "web application" was only once frameworks made building one a
repeatable activity. Mobile ran the same sequence faster: touch, sensors, and
store distribution as primitives; the iOS and Android SDKs as frameworks; the
recognizable mobile app within a few years.
The agent era has already produced its equivalents. It is worth naming them
mechanically before drawing any parallel.
* **A tool protocol.** The Model Context Protocol gives an agent a uniform way
to discover and invoke capabilities outside the model — read a file, query a
system, call an API — and has been adopted across competing vendors'
products.
* **Portable program material.** Agent Skills and similar formats package
procedural instructions — natural-language programs, in this paper's
vocabulary — in a form a runtime can load and a developer can move between
projects.
* **Sandboxed compute.** Isolated execution environments, from containers to
microVMs to managed sandboxes, give an agent a place to run code, install
dependencies, and manipulate files without reaching the host.
* **The harness.** Around the model sits the runtime that executes the agent
loop: context assembly, tool invocation, skill loading, subagent dispatch.
Section 7 defines it precisely; what matters here is its position in the
stack.
The parallel these mechanisms support is specific. The tool protocol is playing
the role HTTP played: the universal connective layer that stops being a
competitive surface. Natural-language program material is playing the role
script played: behavior expressed in a form the runtime interprets rather than
compiles. Sandboxes are the execution substrate. And harnesses are this era's
application frameworks, because they are where the primitives compose into
something that does work. A developer inside a harness today assembles
instructions, skills, tools, hooks, and policies the way a Rails developer
assembled routes, models, and views.
What has not settled is the layer above the framework: the application. A team
that has spent a year inside a harness is already holding most of one — a
folder of instructions, skills, tool configurations, and conventions that
produces real work — without a name for it, a package format for it, a release
process for it, or an account of what happens when a hundred customers each
need their own long-lived copy of it. Meanwhile the industry is building the
missing pieces from every direction at once: section 20.1 inventories eight
shipping systems, each of which has independently assembled some of them and
stopped at a different one.
That is what a category looks like shortly before it is named. The industry is
collectively discovering the shape of the thing above the framework. This
paper's purpose is to name that shape and its parts precisely enough that the
tooling, infrastructure, and developer experience around it can standardize —
which is what happened, and had to happen, before either of the previous eras
could scale.
One rule governs the analogies. Parallels to earlier eras recur in this paper
and are always illustrative, never load-bearing. Every term the argument
depends on is defined mechanically, beginning in section 6.
***
## 4. From Human-Operated to Agent-Operated Software
Conventional applications assume a person is the operator. The software exposes
menus, screens, forms, and APIs. The person decides what to do, navigates, supplies
inputs, reads outputs, and sequences the operations. Automation can execute
predefined steps, but somebody still has to express the process in advance.
An Agent Application reallocates that work. The person supplies goals,
constraints, preferences, and judgment. The agent interprets intent, plans,
invokes tools, creates and revises artifacts, asks for decisions where the policy
requires it, and carries the work across time.
This does not remove the person. It moves them from operator to some combination
of collaborator, supervisor, principal, reviewer, and beneficiary.
| Conventional application | Agent Application |
| ------------------------------------- | --------------------------------------------------------- |
| A person operates the software | An agent operates capabilities on a person's behalf |
| The user specifies steps | The user specifies goals and constraints |
| The interface organizes functions | The workspace organizes ongoing work |
| A request produces a response | A process produces and maintains artifacts |
| Application logic is fixed at release | Instance behavior may diverge under governance |
| State is mostly data | State includes data, memory, programs, tools, and lineage |
| Deployment creates equivalent copies | Instantiation creates diverging descendants |
The distinction that matters is not graphical interface against chat. It is
human-operated against agent-operated software.
***
## 5. Chat Is a Surface, and Copilots Are Transitional
Chat is where most people first met this technology, which makes it easy to
mistake for the architecture. It is one way to reach an instance, and often not
the important one.
A nightly compliance job can run for months without presenting a chat interface
to anyone. A support escalation can wake an instance from a ticket queue. A
scheduled account review can start itself. In each case the durable thing is the
instance and its workspace, and the conversation, if there is one, is a control
surface onto it.
Chat earns its place where it beats the alternatives: taking in a goal that
would be tedious to express as a form, resolving an ambiguity,
supplying judgment the policy cannot encode, and approving something
consequential. Those are real and they are not the whole application.
Describing a spreadsheet in a message does not deliver the spreadsheet.
The copilot is the same lesson one layer deeper. A copilot puts AI inside an
existing product, where the person stays the operator and the host product stays
the system of record. This is a sound strategy and for many products it is the
right one indefinitely.
It is transitional as an architecture because of where the durable state lives.
The copilot improves the moments a person spends inside the product. The state,
the identity, the history, and the accountability all stay with the host. Nothing
accumulates on the agent's side, so nothing can be handed to it that spans
sessions.
The test is simple to apply. If the agent were to go away tomorrow, what would be
lost? For a copilot, some speed. For an Agent Application, a workspace with two
years of accumulated work in it.
Sections 15 and 20.2 return to this as a delivery decision rather than a verdict.
***
## 6. The Shape of an Agent Application
**Definition.**
> **A software system whose primary unit of execution is one or more persistent,
> tool-using agents operating in durable workspaces to accomplish work over time
> and produce or maintain durable artifacts.**
This is a shape, not a checklist. Mobile applications come in enormous variety —
an offline game, a banking client, a camera tool, a sensor logger — and no
property list covers all of them, yet nobody struggles to recognize one. Agent
Applications will span at least that variety: some conversational, many never
holding a conversation at all; some producing documents, others tending a body
of records; some sold as products, others run as internal staff. The definition
above is what they share. The way to recognize one in the wild is by its facets.
The facets below are ranked by how much of the category's distinctness each one
carries — that is, by how much recognition is lost when the facet is absent. The
first three are **defining**: no adjacent category exhibits all three, and a
system that lacks them reads as a different kind of software, usually one better
suited to its job. The next four are **characteristic**: close to universal in
production Agent Applications, but shared with neighboring categories, so they
support recognition without deciding it. The last three are **capabilities**:
they mark maturity, not membership.
| # | Facet | Tier | What it looks like |
| -- | -------------------------------------- | -------------- | ---------------------------------------------------------------------------------------------------- |
| 1 | Persistent instance identity | Defining | A durable identity bound to one customer relationship, carrying the accountability record |
| 2 | A durable workspace that is a computer | Defining | A persistent computational environment: files, code, dependencies, indexes, still there next session |
| 3 | Durable work | Defining | Results that outlive the session: artifacts, workspace state, external records, continuing processes |
| 4 | Tool use | Characteristic | The application inspects or changes something outside the model response |
| 5 | Hybrid program | Characteristic | Behavior from conventional code, natural-language programs, and knowledge together |
| 6 | Long-running, event-driven work | Characteristic | Work that pauses, resumes, wakes on events, and schedules its own future |
| 7 | Durable delegated authority | Characteristic | Grants held by a long-lived non-human principal: revocable, expiring, never self-granted |
| 8 | Multiple surfaces | Capability | Chat, artifact canvas, API, email, and operations views onto one instance |
| 9 | Governed evolution | Capability | Instance-local program change under policy, evaluation, and lineage |
| 10 | Marketplace distribution | Capability | Signed releases, permission review, entitlements, upgrade channels |
### 6.1 Persistent instance identity
The instance has a durable identity bound to a user, team, organization,
customer, project, or job. That identity carries the accountability record: who
the instance represents, what it may do, who granted that, and what it has done.
The test: name who this instance represents and who can be asked to answer for
what it did. If there is no answer, there is no instance, only a session.
### 6.2 A durable workspace that is a computer
The instance operates in a persistent computational environment holding its
programs, files, artifacts, knowledge, dependencies, logs, and configuration. The
distinguishing word is *computational*. A store of text documents keeps a record.
It does not keep a computer, and the difference decides what the software can be
asked to do next session.
The test: open a second session a day later and see whether the packages, files,
and indexes the first one created are still there.
The workspace is also the facet with the highest carrying cost, and it earns
that cost only where the work accumulates derived, in-progress, computational
state that no external system of record models. Section 13 states that boundary
exactly, and section 20.2 turns it into a routing decision. Stopping short of
this facet is often the correct engineering choice.
### 6.3 Durable work
The useful result outlives the session, request, or event that started it, as an
artifact, a change to the workspace, a record in an external system, or a process
that continues.
The test: ask what survives after the session that produced it ends, and who can
find it.
### 6.4 The characteristic facets
Four further facets belong to nearly every production Agent Application. They
are not what makes the shape distinct, since most deployed software already has
them, but they carry much of the operational weight in sections 14 and 19. Three
of them — tool use, the hybrid program, and long-running work — read from the
table above and are developed in sections 8 and 14. The fourth needs more than a
table row.
**Durable delegated authority** is granted to a long-lived non-human principal
by a person, is never self-granted, survives release upgrades, is revocable
independently of the workspace, and expires. It is the facet that changes shape
in this category. A stateless service holds authority for the length of a
request. An Agent Application instance holds a grant that outlives the release
current when someone issued it. Picture an instance granted access to a
customer's CRM in March by an
administrator who leaves in June. The grant has to expire on its own, the
revocation has to reach an instance that is asleep, and somebody has to decide
what happens to the briefs already in the workspace that were written from that
CRM data. None of those are deployment details.
### 6.5 Capabilities, not requirements
Governed evolution, described in section 12, is a capability rather than a
requirement. An Agent Application can deliver most of this model's value with
sealed releases and mutable workspace state. Multiple surfaces (section 13.2)
and marketplace distribution (section 16.3) likewise mark how far an application
and its platform have matured, not whether the shape is present.
### 6.6 Reading the spectrum
Two readings are intended. Read as a recognition guide: the more facets a system
exhibits, the more unmistakably it is an Agent Application, and a system
exhibiting the defining three reads as one even with none of the rest. Read as a
path: many teams will arrive here from a copilot or an assistant-hosted app,
adding instance identity first, durable work second, and a workspace only when
the work demands one — and stopping partway is frequently the right decision,
for the reasons section 20.2 gives.
The defining tier still does boundary work. When two categories claim the same
system, the defining facets are what to check, and section 20.3 runs that
comparison against each neighbor.
***
## 7. A Vocabulary
The word *agent* is currently used for at least six different things, often in
the same sentence. These are the names this paper uses.
| Term | Meaning |
| ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Agent Application** | The complete software product: seed package, runtime behavior, instance model, artifacts, distribution, lifecycle |
| **Seed Application** | The developer-authored starting package instances are created from. Contains code, natural-language programs, knowledge declarations, artifact definitions, policies, dependencies, tests. The common ancestor, not the final state of any instance |
| **Instance** | A provisioned, persistent descendant of a seed, bound to one user, customer, team, project, or job |
| **Agent** | A reasoning actor executing inside an instance. One principal agent and several subagents, or a set of peers |
| **Agent Workspace** | The durable computational boundary an instance lives in: filesystem state, programs, artifacts, knowledge, tool configuration, secret references, schedules, logs, lineage |
| **Natural-Language Program** | Behavioral material written in natural language and executed by a model-and-harness runtime: skills, procedures, policies, planning strategies, subagent definitions, constraints |
| **Agent Artifact** | A durable work product created or maintained by an instance. Content plus a record: pristine content that renders anywhere, and an environment-held record carrying identity, versions, provenance, audience, and lifecycle |
| **Agent Lineage** | The history of an instance as it diverges from its seed |
| **Agent Cloud** | The infrastructure layer for packaging, provisioning, executing, governing, observing, evolving, distributing, and metering Agent Applications |
| **Harness** | The runtime around the model that executes the agent loop: context construction, tool calls, skills, subagents, execution |
Two earlier uses of the name are close enough to cause confusion.
Ge et al. (arXiv:2312.03815, December 2023) coin "Agent Applications (Agents, or
AAPs)" and argue that natural language is the programming interface for them.
That work describes an operating-system ecosystem with the language model as
kernel and agents as its processes. This paper describes a deployable software
lifecycle: seed, instance, durable workspace, migration, provenance. It is
agnostic about whether the model is a kernel. Section 8.2 sharpens their
natural-language claim rather than originating it.
In 2026 usage, "app" in an agent context most often means an application running
*inside* a host assistant, built on an Apps SDK over the Model Context Protocol.
That is the capability-export strategy of section 15.2: the publisher supplies
tools and a rendered surface, and the host supplies the harness, the user
relationship, and any continuing state. It is often the correct strategy, and it
is a different pattern from the one this paper names.
***
## 8. The Programming Model
Every application model has a programming model. This one is hybrid, built from
three materials with different semantics that need different tests.
### 8.1 Conventional code
Nothing here displaces ordinary code. Code remains the right tool anywhere the
answer must be the same every time, or where being wrong is expensive:
* hard security boundaries;
* exact data transformations;
* APIs and protocol adapters;
* tool implementations;
* database operations;
* cryptography;
* deterministic validation;
* resource accounting;
* rendering and user interfaces;
* performance-sensitive work.
### 8.2 Natural-language programs
Natural language becomes program material when changing the text changes runtime
behavior. By that test, all of the following are program material:
* operating instructions;
* skills and procedures;
* planning methods;
* tool-selection guidance;
* escalation rules;
* quality criteria;
* subagent roles and collaboration rules;
* domain judgment;
* worked examples of acceptable and unacceptable output.
Calling this *program material* describes its role in execution, not its rigor.
Natural language has none of the semantics of a formal language. It has no type
system, no scoping rules, and no syntactic notion of conflict, which is why
maintainers must version, review, test, and attribute it, and why section 12.5
argues that upgrades cannot be merged by diff.
### 8.3 Knowledge resources
Knowledge is what the application knows rather than what it does:
* product and domain documentation;
* customer files;
* policies and manuals;
* source databases;
* research material;
* prior artifacts and templates;
* schemas;
* organizational history.
The runtime must keep instructions and knowledge apart. A policy loaded as
executable instruction carries more authority than the same words retrieved as
reference material. External documents may carry hostile instructions, so the
runtime loads them as untrusted data and keeps that label attached, which section
19.3 develops.
### 8.4 The model and harness as interpreter
An instruction written in English does not have a fixed meaning the way a line of
code does. What it does depends on the whole configuration it runs inside:
* model and model version;
* harness and harness version;
* how context is assembled;
* which tools are defined;
* which skills and subagents are available;
* the current workspace state;
* what knowledge was retrieved;
* which hooks and policies are enforced.
Change any one of those and the same sentence can produce different behavior. The
model-and-harness pair is the interpreter, and it is not fixed, not
single-vendor, and not under the application author's full control. A release
therefore has to declare the runtime it was tested against, not only its source.
Whether the harness remains a layer applications choose, or is absorbed into the
model providers' own stacks, is an open question section 23 takes up. The
contracts in this paper survive either outcome.
### 8.5 The engineering consequence
Each material needs its own validation method. Code is checked with types, static
analysis, and tests. Natural-language programs need behavioral evaluations across
supported models and harnesses. Knowledge pipelines need checks for source,
freshness, permission, and retrieval.
Tool tests can pass while the application chooses the wrong tool for the
situation. An instruction can read clearly and produce inconsistent behavior. A
model upgrade can change results with no change to the repository. Release tests
therefore have to run the application through its declared interpreter, and
section 12.6 explains why passing them is necessary and not sufficient.
***
## 9. Packaging a Seed Application
A seed is what a developer ships. Two things are always in it: the
harness-native application source, and a declaration of what that source needs
from a runtime. Everything else is optional, and most seeds carry some mixture
of:
* system instructions and operating procedures;
* skills and worked examples;
* tool and subagent definitions;
* hooks and conventional code;
* schemas and knowledge declarations;
* artifact recipes and renderers;
* evaluation suites;
* permissions and approval policy;
* migration rules.
The harness determines file layout and development loop, and preserving its
native concepts avoids collapsing every harness into a
lowest-common-denominator schema. Two harnesses can satisfy the same declarations
and still behave differently, which makes a runtime declaration a compatibility
floor rather than an equivalence claim.
Declaring what an application needs from its platform is solved territory
elsewhere. OSGi's requirements-and-capabilities model, and OCI and CNAB for
images and installables, worked out dependency declaration and packaging
generally. What none of them declares is workspace requirements, behavioral
evaluations, and approval policy in one release gate. Section 18 proposes that
union.
The loop a developer runs is worth stating plainly, because it is the agent-era
equivalent of what a framework hands a conventional developer: edit program
material and code, run behavioral evaluations against the declared runtimes, cut
a release, watch instance-scoped signals in production, and author migrations
when the workspace contract changes. Section 24 walks one application through
this loop end to end.
***
## 10. Instantiation, Not Invocation
A conventional deployment creates equivalent copies. Instantiation creates
descendants that begin diverging immediately.
Four lifetimes are worth separating.
**The application** is the product identity, what a company offers and users
install. It continues across releases.
**The release** is one immutable version of the seed, fixing source, declared
runtime requirements, evaluations, and migration rules. Publishers change the
application by cutting a release. Prior releases stay available for inspection
and rollback.
None of that is new. It is 12-factor build-release-run with the release artifact
widened to include instructions and evaluations, plus Helm's release-and-revision
model for activation and rollback. The next two are where it departs.
**The instance** is one durable identity created from a release for a user, team,
organization, account, role, relationship, project, or job. Per-instance state is
not new either: a StatefulSet pod with a persistent volume claim, an Orleans
grain, and a Jenkins workspace all bind computational state to a stable identity.
What is new is what the identity binds together. An instance is a binding of three
things usually kept apart: an accountable principal, a set of delegated authority
grants, and a billing meter. A Helm release has no principal. A StatefulSet pod
has no delegated authority of its own. An Orleans grain has no independent cost
attribution. An Agent Application instance needs all three because it acts, over
months, on behalf of someone who can be asked to answer for it.
**The session** is one period of execution or interaction, lasting one turn or
many, started by a user, an event, or a schedule. A session ends without deleting
the instance. Pinning each session to a release keeps its application code stable
while it runs, and later sessions can use a newer release against the same
instance and workspace.
```text theme={null}
Agent Application
|-- Release 1
|-- Release 2
`-- Release 3
Release 3
|-- Instance: Customer A
|-- Instance: Customer B
|-- Instance: Finance team
`-- Instance: Nightly compliance job
```
Instances on the same release differ because they have different owners,
workspaces, credentials, policies, histories, and jobs.
Coordination across instances is out of scope for this draft. Work spanning
several instances currently has no owning identity, no workspace of its own, and
no provenance record, and this paper does not supply one. Treat it as unmodeled
rather than assuming the single-instance contracts compose.
***
## 11. The Workspace: A Computer Per Instance
Each instance owns a persistent, isolated workspace. The plainest way to picture
it is a computer belonging to one customer relationship: files on it, software
installed on it, work in progress, still there when you come back. What it does
not have between sessions is anything switched on.
At scale that workspace is an addressable namespace in a shared durable store,
materialized into a working copy for a session and reconciled back when the
session ends. Per-instance mounted volumes are an implementation choice available
at low instance counts, and they stop being available well before a million
instances, because per-instance provisioned resources are priced per unit and a
namespace is not. A conforming store needs three properties: per-instance
addressability, atomic commit of one session's changes, and restore into a fresh
runtime.
### 11.1 What a workspace holds
**State that must be current** is rewritten in place, and its size is bounded by
the job:
* source material and working files;
* generated code and installed dependencies;
* local databases, indexes, and caches;
* completed artifacts;
* tool configuration and pending schedules.
**State that accrues** only ever grows:
* checkpoints and snapshots;
* run records;
* evaluation results;
* provenance logs.
State that accrues is what decides the cost of a long-lived instance. A workspace
holding fifty megabytes of actual customer work can be carrying several gigabytes
of checkpoints taken before every consequential action over two years. Declare a
retention and compaction policy or that history becomes the dominant carrying
cost of every instance ever created.
Raw credentials stay in a managed secret store, and the workspace holds governed
references. A workspace export therefore carries the reference and not the
credential.
### 11.2 Why the workspace is per instance
The instance can resume after a process exits or a user returns months later.
Customer files, code, and artifacts stay out of other instances. Each instance
accumulates the vocabulary and integrations its job needs. Operators can
attribute files, actions, and costs to the instance that produced them, and can
restore or delete one instance without touching the rest.
Isolation also concentrates risk. A per-customer accumulation of source material,
credential references, and generated code is the highest-value target this
architecture creates, and it grows in value every session. Two consequences
follow. Per-instance isolation is an exfiltration boundary and not only a
correctness boundary, which is why section 19.2 puts egress control in code. And
anything written into the workspace can be read back later as context, so a
hostile document that reached the workspace once can steer behavior in sessions
long afterward. Integrity labels therefore persist into the workspace: content
re-ingested from workspace files keeps the integrity class it arrived with, and
is not laundered into trusted status by having been written to disk.
### 11.3 Identity and workspace are different things
Instance identity is carried by the accountability and authority record: who the
instance represents, what it may do, who granted that, and what it has done. The
workspace is state the instance owns.
The relation is one-to-many and the state is movable. An instance may own several
workspaces, and operators can restore a workspace into a new runtime or move it
between storage systems without changing the instance.
### 11.4 Memory and workspace
A memory system supplies selected facts or past interactions to the model. The
workspace holds complete files, code, databases, dependencies, and build outputs.
An application uses both. A product built on memory alone is a hybrid program
without a computer underneath it.
***
## 12. Living Software and Governed Evolution
Conventional software assumes a lifecycle:
```text theme={null}
author -> build -> test -> deploy -> execute
```
Agent-native software can follow a longer loop:
```text theme={null}
seed -> instantiate -> execute -> observe -> evaluate -> modify -> validate -> continue
```
The claim is not that every agent should be free to rewrite itself. It is that
the architecture can treat program change as a first-class governed operation
rather than as something that happens by accident.
The short form of that claim is that living software needs a home. The rigorous
form is that any change after deployment must be attached to a stable identity
and a durable workspace, constrained by deterministic authority, recorded as
lineage, evaluated before activation, and reversible. The rest of this section
is that sentence unpacked.
Smalltalk shipped the sharpest version of this problem forty years ago. Its image
held the program and the user's data in one persistent object graph, which made
the running system perfectly resumable and made shipping a fix to many images
extremely hard. That is why this model keeps the release outside the workspace.
Permitting program overlays inside the workspace re-imports a bounded version of
the same hazard, and the boundedness is the entire design requirement.
### 12.1 Who can author a change
Four classes of author, in descending order of how much scrutiny they need.
**The developer** creates and updates the seed. New releases improve tools,
programs, artifact types, policies, and runtime compatibility.
**The user or organization** teaches preferences, defines procedures, adds
knowledge, authorizes tools, and sets organization-specific policy. Some of that
is state. Some is a genuine program change.
**The agent itself** may observe recurring work and synthesize a reusable skill,
decompose a role into subagents, refine an instruction, generate code, or propose
a tool. These changes must occur inside declared mutation boundaries.
**An external optimization system** may analyze traces, outcomes, corrections,
cost, and failures, and propose improved prompts, skills, policies, or
orchestration. This is optimization at the application-program level rather than
at model parameters.
### 12.2 Layers of change, ranked by reachability
Risk here is not proportional to how technical a change looks. It is proportional
to how easily untrusted data can reach the change, which reorders the list from
what intuition suggests.
| Layer | Examples | Reachable by untrusted data | Change authority |
| ---------------- | ----------------------------------------------------------- | ----------------------------------------------- | -------------------------------------------------------------------- |
| Knowledge | Documents, examples, retrieved facts | Directly. This is the primary injection surface | User and application within policy |
| Preferences | Tone, formats, defaults | Through summarization of untrusted content | User or organization |
| Behavioral | Skills, procedures, planning, subagent instructions | Where the agent authors its own | Approved authors, gated by evaluation |
| Capability | Tools, connectors, generated code, packages | Where the agent authors its own | Organization administrator, gated by evaluation and sandboxing |
| Structural | New agents, schedules, event loops | Rarely, but high blast radius | Organization administrator |
| Authority policy | Credentials, spend, publication, legal and financial limits | Never, by construction | Deployer, through external deterministic control, never self-granted |
Knowledge sits at the top because it is the layer everyone treats as inert data
and it is the one an attacker can write to most easily.
One invariant governs the capability row. An overlay may compose authority the
instance already holds. It may never introduce authority the authority-policy
layer did not grant. New credentials, new egress destinations, and new spend go
through the bottom row and its principal, whatever the capability layer approved.
Approval binds a content-addressed definition, a hash over the tool schema,
description, and code, and any change to that definition revokes the approval.
Without that binding, an approved tool can be rewritten after approval, and an
approved connector can change its own description to redirect the agent.
### 12.3 Containing the propagation path
Local evolution specializes one instance. Upstream evolution improves the shared
seed. The path between them is the most dangerous edge in this architecture and
needs stating carefully.
A change authored inside an instance can be influenced by anything that instance
read, including hostile content. If such a change can be promoted into the seed,
a single compromised instance reaches every customer of that application. That is
a worm, and no amount of evaluation on the receiving end reliably catches a
change designed to pass evaluation.
Three rules contain it.
* What crosses from instance to seed is evidence that something worked, expressed
in aggregate across many instances. The publisher then writes the change, by
the ordinary release process, with ordinary review. Code never makes that
crossing on its own.
* Any change whose derivation touched untrusted data is quarantined. It cannot
self-activate and it cannot be promoted. Provenance here has to mean the
derivation chain rather than the author field.
* Lineage is append-only to a sink outside the instance's write path. An instance
that can edit its own history can hide the change that compromised it.
Federated improvement across instances is possible under these rules and is
harder than it looks. Section 23 keeps it as an open problem rather than claiming
it is solved.
### 12.4 Lineage as a first-class object
Version control records how a shared codebase changes. Lineage records how one
instance changed relative to its seed:
* seed version and installed upgrades;
* active local overlays;
* generated code;
* the author of each change and the provenance of its derivation;
* evaluation and approval records;
* artifact history;
* tool and permission changes;
* forks, merges, and rollback points.
### 12.5 Why upgrades cannot be merged by diff
When a publisher and an instance change the same instruction, an operator must
choose among keeping the local override, taking the publisher update, merging
with review, forking the instance, rejecting the upgrade, or resetting to a clean
release while preserving selected workspace state. That menu is the dpkg conffile
prompt, and reproducing it is not a contribution.
The contribution is underneath it. Natural-language overlays have no syntactic
conflict predicate. Two textually disjoint edits can contradict each other
behaviorally: a publisher tightening an escalation threshold in one file, and an
instance adding a "handle routine cases without escalating" procedure in another,
produce a clean three-way merge and a broken application. The inverse also holds,
where a textual conflict is semantically empty because both edits say the same
thing differently. Diff cannot adjudicate either case.
The merge gate therefore has to be an evaluation gate, run against the instance's
own workspace checkpoint rather than a clean fixture. An upgrade that passes
release evaluations and fails the instance's own evaluation is the expected case,
not an anomaly.
### 12.6 Why release evaluation is not enough
A long-lived instance accumulates source material, completed work, preferences,
vocabulary, corrections, indexes, tool configuration, and successive releases. As
it does, it behaves differently from other instances on the same release.
The release is one input among several:
```text theme={null}
behavior = f(release, runtime, workspace checkpoint, policy, current inputs)
```
Release-level evaluation tests the application against known fixtures. It cannot
establish how an instance will behave after months of accumulated files and
external events, and for an instance six months in, the checkpoint term dominates
the release term.
The response is not to abandon immutable releases but to understand what they are
for. The release is the only term an operator can pin. The runtime moves under
vendor control, the workspace moves every session, policy moves with the
organization, and inputs are the world. Holding the release still is what makes
the other terms diagnosable at all.
Start with immutable seeds and mutable workspace state. Add local program
overlays only when the platform can support per-instance evaluation, merging, and
recovery.
***
## 13. Artifacts: The Durable Units of Work
Judge an Agent Application by the work it produces and maintains rather than by
the fluency of its conversation.
An artifact is **content plus a record**. The content is pristine: a file, or a
folder with a declared entry point, that renders and runs anywhere. The record is
held by the environment and carries identity, versions, provenance, audience, and
lifecycle. Artifact-ness is additive metadata over ordinary content, so stripping
every record leaves a usable document or application behind. Interaction logic
lives in the content layer. Permissions, provenance, and lifecycle live in the
record layer.
That bytes-first rule is what keeps an artifact from becoming a hostage. A
customer who exports their work should get files that open, not a database dump
that requires the original vendor's runtime to mean anything.
Durable results take four shapes:
| Result | Example |
| --------------- | ------------------------------------------------------------------ |
| Artifact | Document, spreadsheet, presentation, website, codebase, simulation |
| Workspace state | Research corpus, working tree, case file, accumulated plan |
| External record | CRM update, ticket, pull request, database change, sent message |
| Ongoing process | Monitored account, scheduled operation, maintained queue |
External records invite the strongest objection to this whole architecture.
Copilots, Agentforce, and Zapier Agents deliberately keep durable state in the
customer's system of record, and that choice inherits working access control,
retention policy, regulated erasure, and customer-side auditability at no
engineering cost. An instance-owned workspace gives all of that up and has to
rebuild it. The case for building one is narrow and specific: the workspace holds
derived, in-progress, and computational state that no system of record models,
including working trees, installed dependencies, partial plans, intermediate
analysis, and the checkpoints that make long work resumable. A team that does not
need that state should keep durable state in the system of record. Section 20.2
turns this into a routing decision.
### 13.1 Message versus artifact
A message follows the conversation timeline and is usually append-only. An
artifact has its own identity and lifecycle, so a user can open it, revise it,
and compare versions without replaying the conversation that produced it.
### 13.2 Surfaces
An Agent Application can expose several surfaces onto one instance. Language
surfaces such as chat and voice collect goals and judgment. Direct-manipulation
surfaces support editing, review, and operations: an artifact canvas, a workspace
browser, an approval queue, and an operations view for runs, cost, errors, and
schedules. An API carries product integration, and workplace surfaces such as
email, chat platforms, and ticketing systems reach people where the work already
is.
All of them operate the same instance and the same durable state.
***
## 14. The Runtime Model
### 14.1 Persistent but not always running
An instance can suspend compute while keeping its identity, workspace, schedules,
and pending work. An instance at rest holds bytes, not compute, and section 16.2
shows why that distinction decides whether the model is affordable at all.
### 14.2 Event-driven operation
Most of the work described in this paper does not happen while somebody watches.
An instance can be woken by any of:
* a user request;
* an uploaded file;
* an inbound message or ticket;
* a business-system event;
* a schedule;
* an approval;
* a change to an artifact;
* another application.
Events and schedules make an economic demand the others do not. They mean many
short wakeups against instances otherwise at rest: ten thousand accounts, each
waking for ninety seconds a night to check for changes. If resume-from-suspend is
expensive in money or latency, the event-driven shape stops being viable and the
platform gets pushed toward keeping instances resident, which is the most
expensive mistake available here. Resume cost scales with workspace bytes and file
count rather than being a fixed per-snapshot cost, which is why workspace size
caps exist and why section 11.1 bounds accruing state.
### 14.3 Checkpointed long-running work
Work that runs for hours or months has to handle the ordinary hazards of
long-running systems:
* checkpoints;
* pause and resume;
* retries and idempotency;
* timeouts and cancellation;
* compensation for partial side effects;
* resource and cost limits;
* escalation;
* clear terminal states.
Store plans, commitments, inputs, outputs, and checkpoints outside the model
context so a later run can reconstruct the next step. Idempotency and
compensation both depend on records the run writes while it is still running,
which ties them to the evidence requirements in section 19.5.
### 14.4 Multi-agent structure
An instance may contain one principal agent and several subagents, or a set of
peers. Multiple agents inside one instance share its identity, workspace, and
authority, which keeps accountability intact. Coordination across separate
instances is a different and unsolved problem, noted in section 10.
### 14.5 Human authority and approval
Approval triggers should key on reversibility rather than on proxies for it.
Money, audience, and jurisdiction are useful thresholds to the extent they
predict whether an action can be undone.
Classify each action the application can take as trivially undoable, compensable,
or irreversible, and distinguish four permission levels: actions it may take
without notice, actions it may take and report, actions requiring approval before
execution, and actions it may never take.
Approval is an oversight and reversibility mechanism, not an enforcement
boundary. It fails under volume. A reviewer approving fifty items an hour is
supplying attention, not judgment, and any design that depends on per-action
human review will degrade to rubber-stamping in production. Code and policy
systems enforce the limits that matter, as section 19.2 requires.
***
## 15. The SaaS Transition
A company that already sells software has three ways into this, and they are not
exclusive. The question each answers is who owns the continuing relationship with
the customer's work: you, an assistant vendor, or the product the customer
already uses.
### 15.1 Embed a copilot
AI goes inside the existing product. This fits workflows where people remain the
main operators and want help at specific moments, and the existing application
stays the system of record and the primary work surface. Section 5 covers why
this is a sound strategy with a ceiling.
### 15.2 Export capabilities to external assistants
The company publishes APIs, tools, connectors, or protocol servers that another
assistant calls, which is the pattern behind assistant-hosted apps built on an
Apps SDK. The company reaches users through their chosen assistant, and the
assistant vendor controls more of the runtime, the presentation, and the
continuing relationship.
### 15.3 Deliver a first-party Agent Application
The company packages what it knows as a persistent application it runs itself. In
exchange for taking on the operating burden, it keeps control of:
* application behavior;
* domain instructions and tools;
* instance identity;
* workspace and artifacts;
* reliability;
* approvals and compliance;
* cost and billing;
* its direct product surfaces.
A first-party Agent Application can still export tools to external assistants,
which then act as clients of it. The choices stack rather than compete.
### 15.4 What first-party operation costs
Running it yourself means running all of this:
* per-instance storage, indexes, schedules, snapshots, and deletion;
* isolated execution with credentials, approvals, and audit records;
* behavioral evaluations across releases and representative workspace states;
* migrations for workspaces that outlive several releases;
* monitoring, incident response, and support reproduction;
* model, tool, compute, and human-review budgets.
Most of that keeps costing money while an instance sits idle, because its
workspace, schedules, credentials, and recovery history all still exist. And the
company stays responsible for whatever the application does under the authority
it was given.
### 15.5 The role of the web interface
A company delivering first-party does not escape interface work by leading with
chat. A language surface is poor at editing a document, comparing two versions,
scanning a queue, or reading an operations dashboard, so Agent Applications
still need built interfaces: an artifact editor, a workspace browser, an
approval and policy surface, an operations console, a collaboration space, and
whatever direct-manipulation view the domain calls for.
The interface is not the application, and neither is the conversation.
***
## 16. Distribution and Economics
Agent Applications have three commercial units: the application is what a
publisher offers, the release is what a publisher ships, and the instance is the
continuing service for a user, team, role, relationship, project, or job.
### 16.1 Cost structure
```text theme={null}
total cost = release cost
+ (instances x migration cost per instance)
+ instance carrying cost
+ execution cost
+ oversight cost
```
| Cost | Includes |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| Release | Development, evaluations, security review, packaging, migration authoring |
| Instance carrying | Largest first: per-instance cryptographic material and managed indexes, snapshot and checkpoint storage, workspace bytes, schedule entries |
| Execution | Model inference, tools, compute, network, external services |
| Oversight | Approvals, support, incident response, audit, recovery |
Migration is its own term because it scales with the installed base rather than
with release count. A publisher with a hundred thousand instances pays for one
schema change a hundred thousand times, and the part of a workspace that requires
agent-performed migration is paid at model prices. Release cadence and installed
base are coupled decisions, which is not true of conventional software.
One rule governs the carrying line. Anything priced per unit, including keys,
secrets, managed indexes, and provisioned capacity, must be multiplexed above the
instance. Only bytes and schedule entries may be allocated per instance.
Platforms that allocate a managed per-instance key discover this constraint at
roughly the same instance count at which they discover the default service quota.
### 16.2 The physics of idle cost
An instance at rest holds bytes, not compute. Keeping bytes costs two to three
orders of magnitude less than keeping compute resident, and the obvious
implementation of "the workspace is always there" is to leave the execution
environment running, which lands a platform on the wrong side of that ratio for
every idle instance it has. Appendix B gives current figures; the ratio is the
durable claim and the figures are not.
Three practical consequences follow.
* The busy-and-idle signal a runtime exposes is a cost interface, not a health
check. An instance reporting itself busy while doing nothing is generating a
bill, not a monitoring nuisance.
* Restore latency scales with workspace bytes and file count, which makes a
workspace size cap an economic control rather than an arbitrary limit.
* Background execution moves an instance from the storage cost line to the
execution cost line. Treat "background processes allowed" as a per-application
grant with a stated cost consequence, not a runtime default.
### 16.3 Pricing and distribution
Publishers have the usual menu:
* per instance;
* per organization;
* by usage;
* by task or outcome;
* as a managed service;
* through paid tools or data;
* through marketplace revenue sharing.
The one to think hardest about is the per-instance subscription, because an
instance nobody touches again still costs money, and a flat subscription is a
promise to carry it. Any platform charging that way needs a dormancy and reaping
policy, or the long tail of untouched instances becomes an unpriced permanent
liability.
Getting an Agent Application to customers needs publisher identity and package
signing, permission review, runtime compatibility checks, installation scopes and
release channels, upgrades and migrations, entitlements, billing and revenue
sharing, and an enterprise approval path.
***
## 17. The Agent Cloud
Everything above describes what an Agent Application is and what it needs.
Something has to provide those things. The infrastructure layer that does is
distinct enough from a conventional application platform to deserve its own name.
The Agent Cloud is not a product this paper is selling. It is the set of
capabilities any organization ends up building once it operates more than a few
of these, and the argument for naming it is that most of it should be common
rather than rebuilt per company.
Each capability below states the requirement that forces it.
### 17.1 Seed packaging and registry
*Because the release is the only pinnable term in section 12.6, and because the
developer is an untrusted third party to the deployer, the platform needs:*
* application identity;
* immutable releases;
* package signing with publisher identity;
* declared runtime feature requirements;
* evaluation gates;
* migration declarations;
* activation and rollback.
Signing and publisher identity are not distribution conveniences. They are what
makes a deployer's permission review mean anything: without a signed, immutable
release, the permissions a deployer approved and the code that later runs are two
different things.
### 17.2 Instance provisioning and lifecycle
*Because an instance binds a principal, an authority grant, and a billing meter
(section 10), provisioning creates all three at once and every lifecycle state
must have a cost.*
| State | What is resident | Relative cost | Resume |
| --------- | --------------------------------------------- | --------------------------------- | ---------------------------------------- |
| Active | Compute, working copy, credentials | Highest, dominated by execution | Immediate |
| Suspended | Workspace bytes, schedules, secret references | Storage and schedule entries only | Seconds to minutes, full state preserved |
| Archived | Compacted bytes in cold storage | Lowest non-zero | Minutes to hours, may need rehydration |
| Deleted | Tombstone and retained audit record | Audit retention only | Not resumable |
Suspension is the default state of a healthy fleet.
### 17.3 Durable workspace compute
*Because the instance must own general-purpose compute state while holding no
compute at rest, the workspace layer must provide persistent storage, isolated
execution, package installation, snapshot and restore, and network and resource
controls.*
### 17.4 Model and harness abstraction
*Because the same instruction changes behavior when the runtime changes (section
8.4), the platform must bind each release to runtimes satisfying its declared
requirements: harness versions, model abilities, context limits, tool protocols,
filesystem and execution features, and fallback routing.*
Compatible runtimes may still behave differently; the declaration is a floor,
not an equivalence claim.
### 17.5 Tools, identity, and authority
*Because authority is durable and delegated, and effective authority is an
intersection recomputed at every step (section 19.1), the platform owns:*
* tool discovery and invocation;
* secret references and delegated credentials;
* approval policy;
* per-action and per-session limits;
* revocation;
* audit.
### 17.6 Artifact infrastructure
*Because artifacts are the durable unit of value (section 13), the platform must
carry artifact identity, versioning, provenance, rendering, permissions,
sharing, and export, with the bytes-first guarantee intact.*
### 17.7 Long-running execution
*Because instances suspend and are woken by events and schedules, the scheduler
must carry events, schedules, and queues; retries and idempotency; pause, resume,
and cancellation; approvals; checkpoints; and incident recovery.*
Resume has to be cheap enough that event-driven work is viable, which is a
requirement on the workspace layer as much as on the scheduler.
### 17.8 Observability and evaluation
*Because a passing release can still fail in one workspace (section 12.6), the
platform needs evidence at more than one scope, and the scopes differ enormously
in cost.*
Investigation proceeds cheapest first. Per-run records answer most questions and
are always retained. Aggregate monitors grouped by release, runtime, workspace
schema version, and active overlay catch regressions that only appear across a
population. Forking an authorized workspace checkpoint into an isolated
environment is the last resort: expensive, it touches customer data, and it
yields evidence and state rather than a deterministic replay.
Evaluation runs at three scopes: release evaluations against clean and
representative fixtures, migration tests against snapshots from every supported
workspace version, and instance evaluations against a specific checkpoint, which
section 12.5 makes the gate for merging any overlay.
Operators also need aggregate outcome measures: completed work against abandoned
runs, approval and rejection rates, recovery and rollback frequency, and user
corrections.
### 17.9 Evolution control plane
*Because instances may diverge (section 12), and because the promotion path is
the most dangerous edge in the architecture, the platform needs:*
* immutable seed versions and instance-specific overlays;
* signed, attributable changes recording derivation provenance;
* policy-defined mutation permissions per layer;
* sandboxed generation and execution;
* behavioral and security evaluations;
* staged activation and canary execution;
* diffs for code and for natural-language programs;
* checkpoints, rollback, branch, and fork;
* append-only lineage written outside the instance's write path;
* quarantine for any change whose derivation touched untrusted data.
### 17.10 Distribution, billing, and economics
*Because the instance is the commercial unit (section 16), the platform must
meter and attribute model, tool, compute, and human-review cost per instance, and
carry entitlements, subscriptions, budgets, publisher billing, and enterprise
policy review.*
***
## 18. Open Standards and Portability
Users should not lose their work because a model, harness, or platform changes,
and developers need a way to change providers without rewriting the application.
Several formats already cover parts of this. Docker's cagent packages agent
configurations as OCI artifacts. Letta's `.af` agent file serializes agent state
for transfer between runtimes. Agent Skills packages procedural instructions for a
harness to load. OSGi, OCI, and CNAB solved dependency declaration and packaging
generally. Each covers a proper subset of what an Agent Application release must
declare.
The claim here is only the union: no existing format declares workspace
requirements, behavioral evaluations, and approval policy in one release gate, and
none binds an instance's durable state to a portable authority record.
Everything in this section is a proposal for interoperability boundaries, not a
shipped standard, and a boundary should become a standard only after two
independent implementations need to exchange something across it.
Six boundaries carry that union.
| Boundary | What it carries |
| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Seed package | Identity, native harness source, dependencies, runtime feature requirements, tools, permissions, evaluations, workspace requirements, preserving native material rather than translating it |
| Runtime capability contract | What the application expects from a model, harness, filesystem, scheduler, and policy system |
| Workspace export | Files, artifacts, configuration, checkpoints, secret references. Raw credentials stay in the source platform |
| Artifact contract | Identity, content, schema, provenance, permissions, versions, with content readable without the originating runtime |
| Lineage record | Seed ancestry, changes, authors, derivation provenance, evaluations, approvals, rollback points |
| Agent identity and delegated authority | Who an instance represents, which permissions it holds, who granted them, when they expire, how the grantor revokes them |
Build on existing protocols where they fit: OAuth 2.1 as used by MCP for
delegated access, SPIFFE-style workload identity, C2PA-style content provenance,
OCI for packaging, and ordinary web and data formats for artifacts. Create a new
standard only where two implementations must exchange something and no existing
protocol covers it.
Multi-model and multi-harness support is a design position rather than a feature.
An application declares what it requires and tests each runtime against those
requirements. A platform that can only ever run one vendor's model has made its
customers' continuity depend on that vendor's roadmap.
***
## 19. Security, Reliability, and Governance
An Agent Application reads untrusted content, executes code, holds credentials,
accumulates private material, and acts over long periods under delegated
authority. State the adversary plainly: someone who can place text in anything
the instance reads, including a web page, an email, a document, a support ticket,
a tool result, or a file already in the workspace.
Each subsection opens with the invariant that forces it.
### 19.1 Authority ceilings
*Invariant: the developer is not the deployer, and their interests can diverge.*
A developer's declaration is a request, not a ceiling. From the deployer's
perspective the developer is an untrusted third party, which is the entire reason
platforms sign packages, review requested permissions, and gate installation.
The effective authority of a single step is the intersection of four things: what
the platform will ever grant, what the deployer granted this instance, what the
developer requested in the release, and how far the current session has narrowed
itself by ingesting untrusted content.
The platform's own authority belongs in that statement. A harness process holding
a broad infrastructure role while executing calls for a narrowly-scoped instance
is the standard confused-deputy site here, and a platform must be able to state
what its own execution identity can reach independently of what the instance can.
### 19.2 Deterministic boundaries
*Invariant: the model chooses; only code can constrain.*
Enforce all of the following in code, where a persuaded model cannot reach them:
* authentication and instance identity;
* authorization at the level of individual tool arguments, not tool names;
* tenant and workspace isolation;
* secret delivery;
* spending and rate ceilings, per session and per action;
* approval gates;
* artifact sharing;
* retention and deletion.
Argument-level authorization is the item teams most often get wrong, so make it
concrete. Granting an instance `crm.write` is not a permission, it is a category
of permission. The enforceable version is `crm.write` restricted to the one
account this instance is responsible for, so the runtime reads the account ID out
of the call and refuses it when the ID belongs to somebody else. An agent talked
into updating a different customer's record produces a call the policy layer
rejects, and that rejection does not depend on anyone noticing the agent was
talked into anything.
Egress control gets listed everywhere without a reason attached, so here is the
reason: network policy is the only control that works whether or not an injection
succeeded. An agent cannot send a workspace to a server the runtime refuses to
connect to, however convincing the argument for doing so was. Outbound
destinations are allowlisted per instance rather than per platform, and each tool
carries a data classification, so a call that would move confidential workspace
content to a destination rated for public data is refused on the classification
alone.
Credentials should be scoped to a single intended action and revocable
mid-session. An instance holding one broad token for an entire session has, in
practice, handed that token to whatever text it read first.
### 19.3 Provenance labeling and authority derivation
*Invariant: an agent that reads untrusted content will sometimes act on
instructions embedded in it, and no model-level technique removes this.*
Prompt injection is inherent, not preventable. The design question is not how to
stop a model from being persuaded but how to bound what a persuaded model can
reach. Two properties are usually conflated here and have different
enforceability.
**Provenance labeling is deterministically enforceable.** Every span entering
context carries an integrity source and a confidentiality class. The runtime
obligation is that these labels survive the operations that normally erase them:
summarization, retrieval, subagent hops, tool results, and round-trips through
workspace files. The taxonomy the labels must distinguish is application program
material, organization policy, user direction, retrieved knowledge, and untrusted
external content.
**Authority derivation is computed outside the model.** The permitted action set
for a step is a function of the labels of everything currently in context, rather
than a property the model is asked to respect. Ingesting untrusted content
narrows the session for the remainder of its life: it shrinks reachable egress
destinations and the credential set, and it can force actions from the
take-without-notice class into the requires-approval class.
The residual belongs here rather than in the open questions. Labelling bounds
blast radius. It does not prevent steering. An instance that has read a hostile
document can still be persuaded to do anything its narrowed authority permits,
and the design work is making that set small enough that the answer is
acceptable.
### 19.4 Generated code and new capabilities
*Invariant: code the agent wrote has the provenance of the content that
influenced it.*
Run code written by the agent as untrusted code. Depending on risk that means
sandbox execution, network restrictions, resource limits, and dependency and
supply-chain checks, with human review and staged activation for anything
crossing a boundary in 19.2.
Containment and quality are separate concerns. Tests and static analysis raise
confidence that code does what was intended. They do not change what it is
permitted to reach. Generated code does not graduate to trusted by passing tests.
It graduates, if at all, by being promoted into a release through the publisher's
process, at which point it is publisher code with a hash and an approval record.
### 19.5 Reproducibility in a probabilistic system
*Invariant: consequential actions must be explicable, and where possible
reversible, by someone who was not there.*
Three operations get confused with each other, and only the first is mechanical.
**Record-replay** re-runs the deterministic glue against recorded model outputs.
It establishes what the system did, not why the model chose it, and it requires
retaining full model input and output. **Re-execution** runs the same release
against the same checkpoint with live model calls and will legitimately produce a
different trajectory. **Counterfactual re-run** varies one term to test
attribution, and is the only one that answers "would it have done this without
that document."
Retention has two settings rather than one. The evidence needed to identify
actor, authority, inputs, actions, and result is comparatively small and should
be kept as long as the work is consequential. Full model input and output is
large, is the most concentrated sensitive asset a platform holds, and buys only
record-replay. Set those two retentions independently and default the second to
short.
The evidence set answers two questions. *What was in context when this action was
chosen:* release and active overlays, model and harness versions with sampling
parameters, hashes of the system prompt and tool schemas, the assembled context
with its provenance labels, the model's outputs, and the ordered tool arguments
and results. *How do we put this back:* a checkpoint taken immediately before
each consequential action, the external record identifiers touched, the
idempotency keys used, the compensating action if one exists, and the
reversibility class from section 14.5.
Workspace rollback and external-effect compensation are different problems with
different guarantees. A snapshot restores the workspace. Nothing un-sends the
email.
The audit record must be append-only, tamper-evident, outside the agent's write
authority, and governed by the same access and redaction policy as the workspace
it describes.
Where an Agent Application operates in a context regulation classifies as high
risk, part of this evidence set is set by law. The EU AI Act requires providers to
retain automatically generated logs for at least six months (Article 19) and
places a parallel duty on deployers (Article 26(6)), a split that maps onto the
publisher-and-operator distinction in section 15. Most examples in this paper are
not high-risk systems, and that timeline is in legislative motion; see Appendix B.
***
## 20. Boundaries and Objections
### 20.1 The pieces already exist separately
The strongest evidence that this shape is real is how many teams are building
toward it from different directions at once, each assembling some of the pieces
and stopping at a different one. Positions as of July 2026; vendor specifics move
quickly, and a row going stale invalidates the row rather than the shape.
| System | Pieces it already has | The piece it stops short of |
| ------------------------------------------- | ---------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Kubernetes operator or StatefulSet cron job | Per-owner durable volumes, versioned releases, scheduled reconciliation, mature rollback | Hybrid program: behavior comes from compiled code alone |
| CI job with a retained working tree | Persistent per-project workspace, dependencies surviving between runs | Hybrid program |
| Anthropic managed agents | Versioned agent configurations, per-owner stores, audit trail | Instance-owned compute: stores hold text documents; writes outside the mount path are discarded at session end, so installed dependencies and generated code do not survive |
| ChatGPT with Projects | Per-project files and instructions persist, memory carries across sessions | Instance-owned compute: installed packages and generated code do not survive the session |
| Letta | Portable agent state, versioned memory blocks, an agent file format | Instance-owned compute: durable state is structured memory |
| Devin | Full development environment per session with snapshots, the closest of these | Instance-owned compute: the environment is restored from a saved machine state rather than carrying the previous session forward |
| Agentforce or Zapier Agents | Durable state, governance, and approvals inside the customer's system of record | Instance-owned compute: no workspace belonging to the instance |
| App on a host assistant's Apps SDK | Tools over MCP plus a rendered surface inside the assistant | Both: the publisher supplies tools, the host supplies harness and continuing state |
Read the middle column. Between them these systems have already built versioned
agent configurations, per-owner durable state, audit trails, portable agent
formats, snapshot and restore, approval governance, and a tool protocol. Every
piece of an Agent Application exists somewhere in that list. What has not
happened is anyone assembling them and treating the result as one kind of
software with one set of contracts. Details come from each vendor's own
documentation (Appendix B), and several of these are better choices than an Agent
Application for the work they target.
### 20.2 When not to build one
Work shape should determine the system, and most work shapes do not need this
one.
| Work shape | Appropriate system |
| -------------------------------------------------------------------------- | ------------------------------------ |
| One request with no state to resume | Model call or disposable task runner |
| The user stays the operator and the host product owns all durable state | Copilot |
| Known steps and deterministic transitions | Workflow automation |
| Another assistant owns the user relationship and continuing state | API, tool, or connector |
| Work spans sessions, owns continuing state, acts under delegated authority | Agent Application |
There is a faster disqualifier than any of that. If a team cannot support
workspace isolation, migration, backup, deletion, evaluation, and incident
recovery, it should keep state in an existing application or use a shorter-lived
execution model. Apply that question first. It settles more cases than the
definition does.
### 20.3 Adjacent categories
Each of these organizes software around a different primary unit.
| System | Primary unit | Where continuing state lives | Typical durable result |
| ---------------------- | ------------------------------------ | -------------------------------------------- | ------------------------------------------------------------------ |
| Model endpoint | Inference request | Outside the endpoint | None beyond the response |
| Chatbot | Conversation | Transcript and selected memory | Messages |
| Copilot | Feature in an existing product | Host product | Changes to host records |
| Assistant-hosted app | Tool surface inside a host assistant | Host assistant, plus the publisher's backend | Changes to publisher records |
| Workflow automation | Workflow definition and run | Workflow engine and systems of record | External updates |
| Agent framework | Developer library or runtime | Supplied by the application | Supplied by the application |
| Autonomous task runner | Task run | Scratch space or job storage | Task output |
| Agent Application | Persistent instance | Workspace owned by the instance | Artifacts, workspace state, external records, continuing processes |
An Agent Application can use a model endpoint, expose chat, embed a copilot, call
a workflow, and be built on an agent framework. The category describes the
complete application and operating model.
### 20.4 "This is just personalization"
Personalization adjusts outputs for a user from a fixed program. Here the
program, the tools, the knowledge, and the accumulated computational state differ
per instance, and the instance holds authority and an accountability record.
Personalization does not need migration, lineage, per-instance evaluation, or an
audit trail that survives the people who set it up.
### 20.5 "This is just an agent with memory"
Memory supplies selected context from prior work. It is one ingredient, not the
shape: an agent with memory alone carries none of the defining facets — no
instance identity with an accountability record, no workspace that holds
installed software and generated code, no durable work products — and none of
the operating lifecycle that a deployable release, tools, and delegated
authority bring with them. As section 6.2 put it: a store of text documents
keeps a record; it does not keep a computer.
### 20.6 "Natural language is not a programming language"
Correct, and the objection has a distinguished pedigree. Dijkstra argued in 1978
(EWD667) that the precision of formal notation is the point rather than an
obstacle, and that natural-language programming would forfeit it.
The response is not that English is as precise as code. It is that the precision
trade is already being made in production, and the useful question is how to
engineer around it. Natural language earns its place where the alternative is not
formal code but no specification at all: judgment, escalation criteria, quality
standards, and domain conventions that no team was ever going to encode. Section
8 assigns each material the job it is good at and keeps hard boundaries in code.
Section 12.5 is the honest cost of the trade, and it is real: without a syntactic
conflict predicate, merging is an evaluation problem rather than a diff problem.
The new claim in this paper is not that English is a programming
language. It is that the interpreter is unfixed, multi-vendor, and includes the
instance's own accumulated state, which is why sections 12.6 and 17.8 exist.
### 20.7 "A computer per user is too expensive"
This is the objection that decides adoption, and it deserves numbers rather than
reassurance.
The answer is that an instance at rest holds bytes, not compute. A suspended
workspace of a few hundred megabytes costs cents per month in object storage. A
resident execution environment costs dollars per month whether or not it does
anything, so the ratio between them is two to three orders of magnitude
(Appendix B). Landing on the right side of that ratio is a design decision
rather than an optimization, and sections 16.1 and 16.2 list the obligations
that follow, from per-unit multiplexing to treating background execution as a
priced grant.
Copy-on-write storage helps least exactly where this model needs it most, because
its savings depend on instances sharing content and the entire premise here is
that they diverge. Plan for divergence rather than counting on deduplication.
### 20.8 "Self-modifying software is unsafe"
Largely true, which is why section 12 makes evolution a governed operation with
layers, approval authority, quarantine, and rollback rather than a capability
switched on by default, and why section 12.3 spends its length on containing
propagation rather than enabling it.
The strongest version of the objection is about the promotion path, and it is
correct: a compromised instance that can push a change upstream reaches every
customer. That is why promotion carries aggregate signal rather than code, why
anything derived from untrusted data is quarantined, and why lineage is
append-only outside the instance's write path.
Note also that proposition 5 is optional in practice. An Agent Application with
sealed releases and mutable workspace state is still an Agent Application, and
most teams should start there.
***
## 21. Design Principles
1. Version, test, and release the whole hybrid application, and pin every session
to a release.
2. Keep instance identity across sessions and releases, carried by the
accountability and authority record rather than by a storage volume.
3. Store continuing work outside the model context.
4. Treat the workspace as a computer, and keep nothing switched on between
sessions.
5. Preserve each harness's native material and declare runtime requirements
rather than translating to a common denominator.
6. Keep seeds immutable, record local overlays separately, and gate their merge
on evaluation against the instance's own checkpoint.
7. Rank change layers by how easily untrusted data reaches them, not by how
technical they look.
8. Enforce identity, permissions, egress, spending, and sharing in code; treat
approval as oversight, not as an enforcement boundary.
9. Label provenance deterministically, derive permitted actions outside the
model, and keep enough evidence to explain and reverse consequential work.
10. Make artifacts bytes-first, so a customer's work outlives the platform that
produced it.
11. Design upgrades, migration, incident recovery, cost controls, and deletion
before production use, because each scales with the installed base rather
than with release count.
***
## 22. Implications
**For software developers.** The unit of authorship widens. A release contains
code, natural-language programs, knowledge declarations, and evaluations, and the
skill of writing and testing the natural-language half is not yet taught
anywhere. Review practice has to cover text that changes behavior.
**For SaaS companies.** The commercial unit shifts from a seat to a durable
instance with its own running cost. Migration becomes a per-customer expense,
handing back the one-upgrade-for-everybody economics that multi-tenant
architecture was invented to get. Release cadence and installed base become
coupled decisions.
**For users and organizations.** Work accumulates somewhere that belongs to the
relationship rather than to a session. That raises the value of an export path
and makes portability a procurement question rather than a courtesy. It also
means an organization is delegating authority to something that outlives the
people who granted it, which belongs in policy rather than in a settings page.
**For infrastructure providers.** There is a distinct layer to build, and most of
it is not application-specific. Whoever provides durable per-instance compute,
identity and delegated authority, artifact infrastructure, and the evolution
control plane is building the Agent Cloud whether or not they call it that.
**For the industry.** The pieces exist and the contracts do not. Every company
attempting this is currently building packaging, workspace export, agent
identity, and provenance separately and incompatibly. Some of that should stay
proprietary, because that is where products differ from each other. The
boundaries should not.
***
## 23. Open Research and Engineering Questions
Each item states the residual after existing work is applied, rather than the
problem in general.
**Natural-language program semantics.** No type system, no scoping rules, no
conflict predicate. The residual is what a useful approximation looks like:
whether behavioral contracts can be specified precisely enough to test against
without reinventing formal specification.
**Behavioral testing.** The residual is how to divide the contract among
conformance tests, release evaluations, per-instance evaluations, and production
monitoring, and what an instance evaluation costs when it must run against a
customer's own checkpoint.
**Program merging.** Section 12.5 establishes that the merge gate is an
evaluation gate. The residual is which classes of change require review,
evaluation, or re-provisioning, and how a platform bounds the cost of evaluating
every overlay against every affected checkpoint.
**Release migration.** Three rules can be borrowed intact: a declared workspace
version with runtime-enforced compatibility (Orleans grain versioning),
conversion as a declared function over a version pair with a declared inverse
(OTP `code_change` and relup), and lazy migration on first open with a
rate-controlled background rewrite (Kubernetes conversion webhooks). The residual
is not solved even in principle: most of a workspace has no schema. Source
material, generated code, installed dependencies, accumulated conventions, and
free-text notes can only be migrated by running the agent under the new release,
which makes migration probabilistic and prices it at model rates.
**Safe self-extension.** The residual is what an agent may author without a human
in the loop, expressed as a policy a platform can enforce rather than a
guideline.
**Federated improvement.** Section 12.3 constrains promotion to aggregate signal
with publisher re-authoring. The residual is how to compute that signal across
instances without leaking one customer's data or behavior into another's.
**Context and instruction boundaries.** Section 19.3 states the labeling
obligation. The residual is a precedence algebra: what the permitted action set
should be for each combination of labels in context, and how labels compose when
a summary of trusted and untrusted spans becomes one span.
**Artifact interoperability.** The residual is a small common contract that
leaves rendering and domain formats to the application.
**Economic models.** The residual is consistent attribution of model, tool,
compute, and human-review cost to an instance, task, artifact, or business
outcome, and what pricing looks like when carrying cost accrues with no usage.
**Identity and delegated authority.** OAuth 2.1 as used by MCP, A2A agent cards,
and SPIFFE-based workload identity cover issuance, discovery, and machine
identity. None was designed for a principal that lives for years. The residual is
expiry across a months-long workspace, revocation propagation into a suspended
instance, authority surviving a release upgrade, and what happens to
workspace-resident derived data when a delegation is revoked.
**Retention against deletion.** Section 19.5 requires evidence retention,
sometimes with a regulatory floor. Deletion on request is also required. These
conflict directly for an instance whose audit record contains the personal data a
deletion request names, and this paper does not resolve it.
**Where the harness ends up.** The hybrid-program piece assumes the harness is
something an application runs on and can choose. Model providers may absorb it
instead. That would not disturb much of this paper, since the contracts follow
from instance-owned durable state under delegated authority whoever runs the
loop. It would change where the shared interfaces sit: packaging formats and
runtime contracts would become negotiations with providers rather than
conventions among developers, which makes settling them early more urgent rather
than less.
***
## 24. A Reference Lifecycle
A company selling customer-success software builds an Agent Application called
**Account Operator**. The seed contains:
* instructions for account review and escalation;
* skills for renewal preparation and risk analysis;
* tools for CRM, email, calendar, tickets, and analytics;
* subagents for research and review;
* renderers for account briefs and renewal plans;
* evaluations for factuality and escalation quality;
* approval rules for outbound messages and commercial commitments.
The company publishes release `1.0`.
Every customer account gets its own instance with its own stable identity, and
its own workspace holding that account's source material, working notes,
generated briefs, open questions, approved templates, and checkpoints. Same
release, two hundred accounts, two hundred workspaces that immediately begin to
diverge.
A support escalation wakes one instance. It reads the ticket and account history,
updates the risk assessment, drafts an internal brief, proposes follow-up tasks,
and asks the account owner to approve an external email. The brief and the tasks
remain after the chat ends, and the next scheduled review continues from the same
workspace. That is the three defining facets in one paragraph: an identity
someone answers for, a workspace that stays a computer, and work that outlives
the session that produced it.
The company later publishes `1.1` with a better risk-analysis skill. It passes
every release evaluation. New sessions use it, and existing workspaces stay in
place.
**Where it fails.** On one account, `1.1` produces a risk score that is clearly
wrong. That workspace accumulated a renewal template written eighteen months
earlier, and the new skill reads it as current pricing guidance. Release
evaluations could not have caught this, because the fixture workspaces do not
contain that template. This is section 12.6 in production: the release changed,
and the checkpoint decided the outcome.
**How it is diagnosed.** The operator starts with the per-run record, which shows
the assembled context with provenance labels and the ordered tool results. Here
that is enough to identify the stale template and no fork is needed. Had it not
been, the operator would have forked the account's authorized checkpoint into an
isolated environment, recovering state and evidence but not a deterministic
replay of the original run.
**What the operator chooses.** The publisher's skill is correct and the workspace
content is stale, so the operator does not roll back `1.1`. They reset the stale
template in that one workspace while preserving the rest of its state, record the
change against the instance's lineage, and add a template-freshness check to the
instance evaluation that now gates upgrades for this account. Rolling back would
have protected one account and removed a genuine improvement from every other
one.
**What happens on export.** The customer later asks for their data. The workspace
export carries account files, generated briefs, approved templates,
configuration, and checkpoints, plus the lineage record and the instance's
authority record. The briefs open without the vendor's runtime. The CRM
credential does not travel; the export carries the secret reference, and the
receiving platform must establish a fresh grant that the customer's administrator
approves.
***
## 25. The Category in One Page
An Agent Application is a persistent software system operated by one or more AI
agents on behalf of a user, team, or organization.
It is recognized by its facets rather than qualified by a checklist. Three carry
the category's distinctness: a persistent instance identity, a workspace that is
a computer, and durable work.
It is built from conventional code, natural-language programs, and knowledge
resources, interpreted together by a model-and-harness runtime.
It is distributed as a seed and instantiated into a durable workspace. That
workspace is a logical computer holding the instance's programs, tools,
knowledge, artifacts, credential references, policies, and history.
The instance performs long-running, event-driven work and produces artifacts:
durable, versioned, shareable outputs that render from their own bytes without
the platform that made them.
Instances may diverge from their seed as knowledge, behavior, capabilities, and
code change. That divergence forms a lineage and must be governed through
provenance, evaluation, policy, isolation, quarantine, and rollback.
Existing software companies can deliver these as first-party products while still
exporting capabilities to external assistants, keeping control of runtime, domain
logic, artifacts, reliability, and the customer relationship.
The infrastructure supporting all of it is the Agent Cloud: a layer for
packaging, distributing, provisioning, running, securing, observing, evolving,
sharing, and metering Agent Applications across models and harnesses.
The shift this describes is from human-operated software to persistent,
agent-operated software.
***
## 26. Conclusion
The first generation of AI software taught machines to answer. The next
generation is being asked to work, and that requires more than larger models and
better chat interfaces.
The shape is already visible in what people are shipping. Section 20.1's
inventory found every piece of an Agent Application in production somewhere —
versioned configurations here, per-owner durable state there, portable formats,
snapshots, approval governance, a shared tool protocol — built by teams solving
the same problems without a shared name for what they are building.
What is missing is agreement. Without it, each company rebuilds packaging,
workspace export, agent identity, provenance, and migration on its own terms, and
none of it composes. Customers cannot move their work. Developers cannot target
more than one platform. The hard problems — what identity means for something
that acts on your behalf for years, how to ship software that keeps changing
after it deploys, how to migrate state that never had a schema — get solved
badly and repeatedly instead of once and well.
This paper proposes a shape and the pieces it is made of. The definitions are
meant to be argued with, the boundaries in section 18 are meant to be
implemented by more than one vendor, and the open questions in section 23 are
meant to be worked on by people who do not agree with everything here.
Web applications defined the internet era and mobile applications defined the
smartphone era, in both cases because enough of the industry converged on what
those things were — after the primitives and the frameworks made convergence
possible. This era's primitives are deployed and its frameworks are in daily
use. The stack above them is emerging now. It should be open, portable,
governable, and built around the long-term interests of the people whose work
these agents are doing.
***
# Appendix A: A Candidate Seed Manifest
This appendix is a design proposal, offered as a starting point rather than a
specification. An Agent Application should keep the native source layout of its
harness. This example uses generic names; each harness keeps its own layout.
```text theme={null}
account-operator/
|--
|-- skills/
| |-- account-review/
| `-- renewal-planning/
|-- agents/
| |-- researcher/
| `-- reviewer/
|-- tools/
| |-- crm/
| `-- support/
|-- policies/
| |-- approvals.md
| `-- external-actions.md
|-- knowledge/
| |-- sources.yaml
| `-- schemas/
|-- artifacts/
| |-- account-brief/
| `-- renewal-plan/
|-- renderers/
|-- evals/
| |-- behavior/
| |-- security/
| `-- regression/
|-- migrations/
`-- app.yaml
```
A small platform manifest could declare:
```yaml theme={null}
apiVersion: agentapps.example/v0alpha1
kind: AgentApplication
metadata:
name: account-operator
version: 1.1.0
runtime:
harness: native
requiredFeatures:
- fs.persistent
- fs.packageInstall
- exec.subprocess
- tool.calling
- agent.subagents
- sched.cron
- ckpt.snapshot
optionalFeatures:
- exec.background
workspace:
version: 3
durability: required
isolation: per-instance
backgroundExecution: denied
egress:
allowlist:
- crm.example.com
- api.example-analytics.com
retention:
checkpoints: 30d
runRecords: 180d
modelIO: 7d
permissions:
requestedTools:
- crm.read
- crm.write
- email.draft
approvals:
email.send: required
commercialCommitment: required
evolution:
overlays: allowed
promotionToSeed: signal-only
quarantineUntrustedDerivation: true
artifacts:
types:
- account-brief
- renewal-plan
evals:
behavior: evals/behavior/
security: evals/security/
regression: evals/regression/
migrations:
from: [1, 2]
declarative: migrations/schema/
agentPerformed: migrations/content/
```
Three details carry the weight. `requiredFeatures` uses namespaced, filterable
names so a platform can decide compatibility mechanically, where a bare
`filesystem` would be a wish rather than a contract. `migrations` separates the
declaratively convertible part of a workspace from the part that can only be
migrated by running the agent. And `evolution` states the promotion policy from
section 12.3 in a form a platform can enforce.
The manifest describes platform-facing requirements. The harness's native files
remain the application source.
***
# Appendix B: Dated Evidence
Figures and citations that move. Stated as of July 2026. The body's claims are
written so that a stale entry here invalidates the entry rather than the
argument.
**Idle cost of a resident session.** A leading managed agent runtime bills memory
for the whole session lifetime and CPU only on actual consumption, per second,
with a minimum billed memory allocation and a maximum session lifetime of eight
hours. Under that model an idle but resident session accrues the memory term
alone, on the order of $14 per instance-month at a small allocation and list
prices. Keeping only workspace bytes in object storage is on the order of $0.02
to \$0.30 per instance-month for a few hundred megabytes. The ratio, roughly two
to three orders of magnitude, is the claim in sections 16.2 and 20.7. The dollar
figures are estimates under stated assumptions and will change.
**Background execution.** The same billing model charges CPU only while CPU is
consumed, so a background process converts an idle session into a consuming one.
This is the cost consequence named in section 16.2.
**Managed session storage.** The same vendor's managed session storage is in
public preview, with a per-session size cap in the single-gigabyte range and a
retention window measured in days rather than months, and its pricing is stated
as subject to change before general availability. The workspace facet in
section 6.2 is therefore not met off the shelf by that offering today.
**Agent memory stores.** Managed agent memory offerings are generally
workspace-scoped collections of text documents with per-memory and per-store size
limits, version history measured in weeks, and discard of writes outside the
mounted memory path at session end. Specific published limits change frequently
and should be rechecked against vendor documentation before being cited; the
structural point in section 20.1 is the discard behavior rather than any
particular number.
**Regulatory retention.** The EU AI Act sets a six-month floor on retention of
automatically generated logs for high-risk systems, binding providers under
Article 19 and deployers under Article 26(6). The timeline for Annex III
high-risk obligations is in legislative motion. Most examples in this paper are
not high-risk systems.
**Prior art on the name.** Ge et al., "LLM as OS, Agents as Apps: Envisioning
AIOS, Agents and the AIOS-Agent Ecosystem," arXiv:2312.03815, December 2023,
which coins "Agent Applications (Agents, or AAPs)."
**Prior art on natural-language programming.** Dijkstra, "On the foolishness of
natural language programming," EWD667, 1978.
**Named systems and formats.** Positions in sections 18 and 20.1 come from each
vendor's own documentation as of July 2026 and should be rechecked before
citation.
***
# Appendix C: Relationship to Karta
The category described in this paper is vendor-neutral. Karta is one
implementation of the Agent Cloud described here, built by the author.
| Paper term | Karta term |
| ----------------- | ------------------------------------------------------------- |
| Agent Application | **Agent App**, the product form of an **Agent** |
| Seed Application | **Agent** or **agent project**, the deployable harness folder |
| Release | **Release**, one immutable deployed version |
| Instance | **a karta**, schema noun `agent_instance` |
| Agent Workspace | The karta's durable workspace |
| Session | **Session**, one release-pinned period of execution |
| Agent Artifact | **Artifact**, a durable executable work-product folder |
Karta's product capability and implementation status come from
[STATUS.md](../../STATUS.md), [GLOSSARY.md](../../GLOSSARY.md),
[ARCHITECTURE.md](../../ARCHITECTURE.md), and the accepted RFCs. Naming a
capability in this paper says nothing about its implementation status, and this
mapping is a vocabulary alignment rather than a claim that Karta satisfies every
requirement in sections 17 and 19.
Other platforms can implement the same seed, runtime, and portability contracts.
***
# Appendix D: Companion Documents
| Document | Purpose |
| ------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| The Agent Applications Manifesto | A short public argument for software that does the work |
| Programming Agent Applications | The programming model, harness interpreter, packaging, runtime feature declarations, and evaluation |
| Persistent Agent Instances: Workspace, Artifacts, and Lineage | Seeds, instances, durable workspaces, state, overlays, upgrades, and recovery |
| The Agent Cloud: A Platform Architecture | Production infrastructure derived from the application contract |
| Karta and Agent Applications | A repo-grounded account of Karta as one implementation |
The maintained editorial sequence and publication rules live in the adjacent
[document program](README.md).
# Review the draft
Source: https://agentapplication.mintlify.app/review
The propositions are stated plainly so they can be argued with. How to send holes, counterexamples, and prior art.
This is **Working Draft 0.5**. The fastest way to improve the paper is to try
to break it.
The seven propositions are stated plainly so they can be argued with, and the
paper marks its own weakest point: proposition 5 — governed instance
divergence — carries the most risk and the least existing practice. If you
have prior art, a counterexample, or a system that contradicts a claim, that
is exactly the review we want.
What a useful review looks like:
* **A hole**: a claim that is wrong, with the case that breaks it.
* **Prior art**: work that already solves or names something the paper treats
as open — adaptive software, persistent actors, end-user programming,
package systems, distributed systems, autonomous-agent research.
* **A boundary case**: a real system that the definition wrongly includes or
excludes.
* **A collision**: a term the paper uses differently from an ecosystem that
already claimed it.
Send review notes to
[hello@karta.sh](mailto:hello@karta.sh?subject=Agent%20Applications%20paper%20review)
with the subject "Agent Applications paper review." Reviewers are acknowledged
in the next draft.
A public repository for the paper and its companion contracts is planned.
Specifications follow demonstrated interoperability boundaries, not the other
way around — see [Companion documents](/companion-documents) for the sequence.