Skip to main content
Working Draft 0.9.1 · August 2026 · Plain text · Cite

​
Abstract

This paper proposes a vendor-neutral reference architecture for building and operating AI agent systems. It identifies the system’s main elements, assigns responsibilities to them, and describes how an Agent Project becomes a release, how releases create long-lived instances, and how those instances retain work across sessions. The architecture gives developers, framework authors, and platform operators a common model without requiring one implementation or project format. The architecture applies to products built around persistent, tool-using agents. A request, event, or schedule can start work. The agent chooses intermediate actions within application guardrails. After a run ends, the instance retains its workspace, credentials, artifacts, and unfinished work. This paper calls the complete product an Agent Application. Developers build these systems as hybrid programs of conventional code, natural-language instructions, declarations, and knowledge. A harness runs the agent loop. An Agent Application Framework is a harness that also supplies a coherent project structure, development tools, evaluations, packaging, deployment, and production runtime support. An Agent Application Platform turns a tested project into an immutable release, provisions and operates long-lived instances with durable workspaces, and provides identity management, security controls, governance, observability, evaluation, and fleet management. It attaches scoped credentials to each instance and enforces permissions, spending limits, network destinations, and approvals. Long-lived instances accumulate different facts, artifacts, generated code, and unfinished work. If they can also add or edit natural-language instructions, they diverge in program as well as state. Operators then manage and govern a fleet whose members no longer share one program: rollout, audit, and policy have to follow each instance’s local program and state, not only the shared release. They must preserve per-instance work, test a new release against existing instance state, and keep enough evidence to explain or recover consequential actions. Edited published instructions have to be merged semantically on upgrade: copy and line-based merge miss how one instruction changes another. The paper provides a layered system model, a capability model, lifecycle and security views, and a method for applying the architecture. It defines Agent Application Programming as the discipline of programming Agent Applications: designing, authoring, and evaluating a hybrid program of code, natural-language instructions, tools, agents, workflows, state, and policy. It also defines an Agent Application Store as a catalog and commerce service through which people find, acquire, and pay for Agent Applications. The architecture locates current standards such as the Model Context Protocol (MCP), Agent Skills, Agent Plugins, and Agent2Agent (A2A) at the boundaries they cover, and identifies where new standards are still needed. Teams can use the paper to reason about the complete system, decide who owns each responsibility, compare implementations, and see which boundaries need to interoperate.

​
Purpose and scope

Teams have built persistent, tool-using agents as product-specific systems. Core pieces are now becoming reusable components and standards: harnesses, MCP, Agent Skills, Agent Plugins, agent-to-agent protocols, and sandboxed execution. Products still use different names and divide responsibilities differently, which makes the recurring system shape hard to see and implementations hard to compare. This paper identifies that recurring shape. It covers the complete system in which an agent operates: projects, releases, instances, workspaces, authority, artifacts, user and machine interfaces, platforms, stores, and operations. It does not specify the model’s internal reasoning algorithm or require a particular agent loop. The architecture identifies the elements that commonly appear, the responsibilities they carry, and the boundaries between them. A product may combine several elements in one service or obtain them from different vendors. This paper is not a technical standard, a portable package format, or a reference implementation. A concrete system can use different names, source layouts, technologies, and deployment models. The useful questions are whether the system handles the responsibilities described here, who owns each one, and which boundaries need to interoperate.

​
Who should read this paper and why

​
Guided reading paths

This is a long paper because it covers application design, development, operation, security, and ecosystem roles. Readers can follow it in order or use one of these shorter paths. The architecture separates common responsibilities from implementation choices. Not every application needs every optional capability. A small agent may have one interface and no schedules, while a business application may need background work, several agents, approval gates, artifacts, and fleet operations. In either case, the design should state where durable state lives, where authority is enforced, and which component owns each capability.
Figure 1. System context. Agent Application system context showing build and publishing, optional distribution, platform operation, runtime dependencies, user interaction, and artifact sharing.

​
Part I: The shape of an Agent Application

​
1. What is an Agent Application?

ChatGPT and Claude use agent widgets. An OpenClaw agent may appear as a WhatsApp or Telegram contact. GitHub Copilot’s coding agent and Cursor Cloud Agents can start from an issue or pull request and return their work there. A Microsoft Copilot Studio autonomous agent can wake in response to a business event without presenting a conversational interface at all. What do these systems have in common? Each gives a tool-using agent a continuing scope of work. Later messages or events return to that work, and the results remain after a run ends. They have different interfaces and jobs, but the same underlying application shape. This paper calls it an Agent Application. An Agent Application uses one or more persistent, tool-using AI agents to produce or maintain durable results. A request, schedule, or outside event can start the work. The application sets the available tools, permissions, policies, and other guardrails. Within those limits, the agent inspects the current state and chooses what to do next. Its work can continue across sessions, and the results outlive the model call that produced them. Consider a Financial Advisor Agent that works with Maya. She uploads tax returns, account statements, and retirement plan documents, then authorizes read access to accounts at her financial institutions. The agent periodically retrieves new records, reconciles them with the material she uploaded, and alerts her when it finds a change worth reviewing. When Maya considers taking a year away from work, she asks how the change could affect her retirement plan. The agent draws on the financial history in her workspace, writes code to run cash-flow analyses and retirement simulations, records its assumptions, and presents the results. Months later, it can show which records, assumptions, and simulations informed its analysis. Doing this over years requires more than a model response or transcript. The application routes Maya’s messages, scheduled reviews, and retrieved records back to the same agent instance. Its workspace preserves uploaded documents, account snapshots, analysis code, assumptions, reports, and unfinished work. The harness / Agent Application framework runs the reasoning loop. Tools give the agent read-only access to financial institutions, and a sandbox executes its analysis code. Compute can stop when Maya’s instance is idle, but the instance and its work remain. Its scoped credentials permit read-only retrieval when a request or schedule wakes it. The application can analyze data, produce reports, and notify Maya, but it exposes no tools for changing accounts or moving money. An audit record preserves how it produced each report. New releases can improve the application without discarding the context it has accumulated with Maya. Its persistent instance, durable workspace, tool use, scheduled work, and lasting analyses make it an Agent Application.

​
2. From web and mobile applications to Agent Applications

Desktop, web, and mobile applications each gave developers a recognizable way to assemble a complete product. A desktop application joined native code, an operating system, local files, a graphical interface, and an installer. A web application joined browser code, application servers, databases, HTTP, and cloud infrastructure. A mobile application added a device runtime, sensors, notifications, identity, and an app store. Agent Applications change how control, context, and work are handled. A request, event, or schedule supplies a goal, and the agent chooses intermediate actions within authority, policy, cost, and approval boundaries. Its instance retains context and working state over a long horizon. The work also persists as artifacts, workspace changes, external records, or continuing processes. The web application architecture is a useful point of comparison. Both models separate application development from managed operation, and both give the developer a framework within which to build. Figure 2. Web and Agent Application lifecycles. Two parallel lifecycles compare web and Agent Applications across framework selection, programming, test and release, deployment, operation, and use. The Agent Application lifecycle adds persistent instance identity, durable work, model-directed control flow, and semantic upgrades. The agent runtime adds model-directed control flow to this familiar lifecycle. Its workspace may accumulate instructions, generated code, artifacts, and unfinished work along with data. The platform therefore needs an instance lifecycle, an authority model, and an upgrade process that can reconcile a new release with each instance’s local state.

​
3. Architectural drivers and design principles

The splits in section 4 exist because a persistent, tool-using agent has to keep work, act later, and do so under someone else’s authority. This section names the pressures. It uses three terms that later sections define more carefully. An instance is a long-lived copy of the application for one person, team, customer, or other privacy domain. Its workspace is the durable state that copy can reach. A release is a fixed version of the shared program.
  1. The complete application is the unit of development and evaluation. Behavior comes from conventional code, natural-language instructions, declarations, knowledge, and dependencies acting together. A tool can be correct while the agent calls it at the wrong time. Testing a prompt or a model call is not the same as testing the application.
  2. The agent should operate over a computer, with limits in policy code. General-purpose agents get their leverage from a filesystem, a shell, and a network: they read and write files, run scripts, install tools, and keep that environment across sessions. As models get better at reasoning and following instructions, that environment should stay general and the harness around it small. An ever-growing kit of special-purpose tools and prompt-level partitions is the weaker path. Credentials, permissions, spending limits, and network rules still have to be real. They belong in code the agent cannot change. They wrap the computer rather than replace it. Section 14 develops this design.
  3. The privacy boundary is the instance. The agent has access to its entire workspace. Natural-language instructions that tell it to keep one person’s data apart from another’s are not a privacy boundary. The model can be tricked into ignoring them. People, records, and work that must not mix belong in separate instances, even when compute is suspended.
  4. The shared program and the instance’s work have different owners. A publisher ships a release. Each instance then accumulates files, artifacts, local instructions, and unfinished work. A later release can improve the shared program. It must not silently discard that instance’s work.
  5. Test a release against the workspaces it will meet. If an instance edited a published natural-language instruction, merge that instruction semantically on upgrade. A release can pass every fixture and still fail on one customer’s history. Copy and line-based merge miss how one instruction changes another.
  6. Consequential actions need evidence and a way to recover. An agent can send a message, change a record, or spend money, then suspend for weeks. An operator should be able to explain what happened, resume interrupted work, and respond when an outside effect cannot be reversed.
  7. The work should survive a change of provider. Instances last. Export and migration need to carry artifacts, workspace state, lineage, and references to authority, without copying raw secrets.
Section 4 maps these drivers onto the layers of the system.

​
4. The Agent Application stack

An Agent Application spans seven layers, from model inference to the use case delivered to a person or organization. These layers implement the drivers in section 3. Figure 3. Seven-layer Agent Application stack. Seven-layer Agent Application stack, from models and agent compute through the Agent Application Framework, Agent Application Project, Agent Application Platform, optional Agent Application Store, and delivered use cases. The layers describe responsibilities, not seven products that a team must buy. One provider may combine several layers, and an application may assemble them from different systems. L3 is the Agent Application Framework: the harness, project conventions, development tools, evaluations, packaging, deployment model, and production runtime support. L4 is the framework-native Agent Application Project itself. L5 is the Agent Application Platform, which runs instances and exposes them through user and machine interfaces. L6 is the optional Agent Application Store, which handles acquisition, entitlements, billing, publisher payments, and monetization. An artifact can be shared outside its instance under its own access policy. That access does not open the workspace that produced it. Figure 4. Logical view of an Agent Application. Logical view showing how a developer uses an Agent Application Framework to build a project and immutable release, which an Agent Application Platform runs as an instance with a framework runtime, durable workspace, interfaces, artifacts, models, compute, tools, and external services. The diagram assigns logical responsibilities. One product may combine the framework and platform, while another runs a third-party framework on an independent platform. The early web produced many frameworks with different ideas about routes, templates, data access, configuration, and deployment. A smaller set grew into complete application frameworks. A Next.js application follows Next.js conventions; a Rails application follows Rails conventions. Both are first-class web application frameworks. Claude Code, Codex CLI, Goose, OpenCode, the OpenAI Agents SDK, and LangGraph all run or support the agent loop. They differ in how much of the development and operating lifecycle they handle. This paper uses Agent Application Framework for a harness that also provides a coherent way to structure, develop, debug, test, deploy, and operate the application. The harness / Agent Application framework choice shapes the application. Each carries opinions about models, context management, tools, permissions, delegation, checkpointing, and debugging. Those choices affect portability, reliability, and task cost. Directory conventions are part of the programming model. An Agent Application Platform can support several frameworks by running their native projects and standardizing the boundaries between layers. It does not need to force every application into one generic directory structure. Several boundaries in the stack already have working protocols or products. The boundaries between harnesses, frameworks, and platforms are still moving. Claude Code and Codex define project conventions and local development. Vercel Eve adds a prescribed layout, durable execution, sandboxes, approvals, evaluations, tracing, and delivery across several channels. Amazon Bedrock AgentCore provides parts of the production layer.

​
5. From human-operated to agent-operated software

Conventional applications treat a person or a predefined workflow as the operator. The software exposes menus, screens, forms, and APIs. A person chooses what to do and sequences the operations, or a developer encodes that sequence in advance. An Agent Application divides control differently. Developers and operators set the guardrails: available tools, permissions, budgets, policies, triggers, and approval rules. When a user request, schedule, or outside event starts a run, the agent reads the current state and chooses the next action. It can plan, define workflows, invoke tools, create and revise artifacts, delegate work, and continue until it reaches an outcome or a boundary that requires outside input. The definition does not require a person to approve every action. A Financial Advisor Agent may retrieve read-only account data and run scheduled analyses without asking each time. A backend operations agent may process a low-risk record without waiting for anyone. In both cases, code defines the allowed space and the agent chooses a path through it. An agent does not need a particular interface. The same agent may appear as a full-screen conversation, a copilot inside another product, a phone number, or a backend worker.

​
6. Recognizing an Agent Application

The definition in section 1 does not depend on the user interface. Four properties distinguish an Agent Application from adjacent systems: The Hello World Agent Application shows the smallest complete example: a notebook agent saves a note, suspends, and uses that note to update a briefing on a later run. Different products assign the instance and workspace to different privacy domains.

​
6.1 How to decide who gets an agent instance

An agent instance has access to its entire workspace. If a workspace holds information about several people, customers, or cases, the agent can combine that information in its reasoning, summaries, and artifacts. Those entities belong in the same instance only when that mixing is acceptable. The privacy boundary therefore decides who gets an instance. This boundary also limits prompt-injection damage. Teams sometimes keep mixed data in one workspace and tell the agent, in natural language, to keep one person’s material apart from another’s. Those instructions are not a privacy boundary. The model can be tricked into ignoring them and combining, quoting, or leaking the partitioned material. Separate instances keep that material outside the agent’s reachable state. The same boundary extends to data reachable through tools and retrieval systems. A user-initiated call should not return information that the authenticated user cannot access. The Financial Advisor Agent therefore gets one instance per person or household, depending on who is authorized to share financial records. A human resources (HR) helper that handles personal employee matters gets one instance per employee. A business-to-business (B2B) support agent can keep many tickets for one customer in the same workspace, so each customer gets an instance. A virtual employee acting as a marketing expert can have one instance shared by a whole team because the team itself is the privacy boundary. The application builder chooses the boundary and a stable instance identifier. A Financial Advisor Agent may use household_id, so every user in that household reaches the same instance and workspace.

​
6.2 A durable computational workspace

The workspace holds the state the agent needs in order to continue: instructions, files, memory, artifacts, code, configuration, and derived data. The runtime may keep that state in a database or object store. It may also give each session an ephemeral filesystem, then retain selected file changes and artifacts so later sessions can retrieve them. The underlying storage can vary. The usual design gives each instance an isolated persistent virtual computer: a filesystem, a shell, and network access. The agent uses ordinary file operations, scripts, and command-line tools on documents, code, local databases, installed packages, and work in progress. It does not need a schema or a custom API for every new kind of state. The platform can restore compute around that environment when the agent wakes, or keep it running when the application needs a long-lived process. Section 14 states this design more fully. A later task must be able to use and change the working state left by an earlier one. A transcript can remind an agent what it said. A workspace lets the agent continue the work itself. A durable workspace is useful when the work accumulates derived or in-progress computational state that an external system of record cannot represent. It can also be an expensive part of this model. Section 16 draws that boundary.

​
6.3 Durable work

Durable work may be an artifact the agent created, a workspace change, a record in an external system, or a continuing process. The work persists after the session that produced it ends. Later sessions and state-access APIs can use it.

​
6.4 What is not an Agent Application?

The boundary is fuzzy, as it is between a web page and a web application. Many jobs are served well without a full Agent Application, and some of those jobs can later become one. A chat interface does not make a system an Agent Application. A Q&A chatbot and a Financial Advisor Agent can share a conversational UI. The chatbot is not an Agent Application if it does not keep working state across sessions and does not produce durable work. Turning it into an Agent Application can add capabilities such as personalization from prior work. Several adjacent systems fall outside the category: A conventional n8n or Zapier flow remains workflow automation when its graph determines the next step. Dependabot is a boundary case: it monitors configured package ecosystems and opens pull requests according to schedules and update rules. The pull request is durable, but the configuration determines the control flow. A simple Q&A bot remains a chatbot when each conversation stands alone. An Agent Application may contain deterministic workflows and answer questions, but its continuing unit is a persistent agent that chooses actions from the current state and leaves durable work behind.

​
7. Where people encounter AI agents

Agent Applications reach people and software through interfaces suited to their work. The agent widget is the most common user interface. It may fill the product window or appear as a sidebar, panel, or popup. Here, widget means a reusable interface component; it may occupy any amount of screen space. The widget renders an event stream from the agent runtime, not just a message history. When a user returns to a session, the client must replay those events, restore the artifacts and interactive controls, and reconnect to any live run. It must also preserve the identity and permission context behind every approval and tool action. ChatKit, CopilotKit, and AI SDK Elements package parts of this surface. AG-UI defines a typed event connection between a frontend and an agent backend. MCP Apps lets an MCP tool return an interactive view that the host renders in isolation. Other surfaces connect the same persistent instance to existing software and background events. One agent can span several of these surfaces. A copilot can be backed by an Agent Application; a channel only determines where the person and agent interact.

​
8. Vocabulary

The word agent now refers to products, runtime processes, assistants, and packaged configurations, sometimes in the same discussion. This paper uses the following terms consistently. This paper uses app as the shortened form of application. Agent App and Agent Application are synonymous. The same applies to terms formed from these names: Agent App Programming, for example, is the shortened form of Agent Application Programming. The broad meanings are useful in ordinary discussion. A developer will say, “I am building an agent,” just as a web developer says, “I am building a web app.” When architecture or operations require precision, this paper names the agent project, release, instance, session, runtime agent, workspace, or interface directly.

​
Part II: Applying the architecture

​
9. A build-and-operate method

The architecture is useful when a team turns an idea into explicit design decisions. The following method is illustrative. Teams can use different documents, tools, and release processes while answering the same questions. Framework selection follows from the capability map. A team should compare harnesses on the needs of its workload, including tools, code execution, subagents, schedules, approvals, model choice, context use, evaluation, tracing, and faithful deployment of the native project. Section 12 provides the capability model and a sourced comparison of current harnesses. Evaluation should cover both clean fixtures and representative accumulated workspaces. A production failure that exposes a new behavior belongs in the regression suite. Platform staging should also exercise the hosted sandbox, credentials, network policy, event delivery, approvals, schedules, and artifact rendering because those conditions differ from a developer’s machine.

​
10. A reference lifecycle

The lifecycle connects development, release management, and long-lived operation. A release can create many instances. Each instance can run many sessions and retain one workspace across them. A later release changes the shared program but does not replace the instance’s accumulated work. Figure 5. Release and instance lifecycle. Release and instance lifecycle showing fixed releases, separate instances, sessions that share a durable workspace, a local adaptation, and a staged semantic upgrade that preserves the instance's accumulated state and local change. Consider the Financial Advisor Agent from section 1. Its project contains instructions for reviewing records, skills for account and retirement analysis, read-only financial connections, a code-execution environment, report renderers, evaluations, and policies that prohibit account changes. The company publishes release 1.0, and each customer receives a separate instance and workspace. Maya’s instance accumulates records, account snapshots, assumptions, analysis code, retirement plans, reports, and checkpoints. A request or schedule starts a session, but the workspace remains when the session ends. During one planning session, Maya tells the agent that she has committed to pay a family member’s tuition for the next four years. The default version 1 retirement-analysis skill does not handle this obligation consistently across scenarios. An approved local change teaches Maya’s instance how to include the commitment, creating a modified copy of the version 1 skill in her local program state. The company later publishes version 1.1 of the retirement-analysis skill with improvements for every instance. Replacing Maya’s skill with a fresh copy would discard her local treatment of the tuition commitment. Keeping her modified version 1 copy would omit the publisher’s improvements. The platform therefore integrates the version 1 to version 1.1 change into Maya’s modified skill by meaning, then evaluates the result against her workspace. The evaluations check the new shared behavior and the local commitment before the platform activates the upgrade. Releases and instances therefore need separate lineages. Release evaluation cannot cover every change accumulated by every instance. Staged rollout, instance-aware evaluation, semantic merging, and checkpoints support upgrades without erasing local program state. Maya may also share a live Agent Artifact, such as an interactive retirement plan. The artifact depends on current balances and source documents that cannot be embedded in a standalone file. Its record carries governed references to the exact data it needs. When Maya shares the artifact, she can give the recipient a revocable, artifact-scoped grant to those specific resources. If the artifact moves to another platform, that platform resolves the references and obtains fresh authorization for any grant that cannot transfer.

​
Part III: Building Agent Applications

​
11. A hybrid programming model

An Agent Application combines four kinds of material: conventional code, natural-language programs, declarations, and knowledge or assets. Developers package this material in the Agent Project. After deployment, an instance may also acquire code, instructions, knowledge, or assets as local state.

​
11.1 Conventional code

Conventional code remains the right tool for:
  • deterministic, repeatable processes;
  • 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.
Tools and MCP Tools connect this code to the model’s reasoning loop. In an LLM “tool call,” the model selects a tool and produces structured arguments. The harness validates the request, invokes the implementation, and returns the result to the model. The Model Context Protocol (MCP) standardizes how a server publishes a tool’s name, description, and input schema, and how a client discovers and calls it. A calendar API, database query, or payment action can then appear to the model through a common interface. The 2026-07-28 MCP specification is stateless at the protocol layer. Each request carries the protocol version, client metadata, and client capabilities needed to process it. There is no initialization handshake or MCP session ID. If a tool needs state to survive across calls, it returns an explicit handle that the client passes in later requests. That handle belongs to the tool or application, not to an MCP session. When an application reaches external systems through MCP, identity, authentication, and authorization become part of the tool boundary. Under the MCP authorization specification, a protected HTTP MCP server acts as an OAuth 2.1 resource server, while the MCP client calls it on behalf of a resource owner. The server publishes how to find its authorization server and which scopes are needed. The client obtains an access token issued for that MCP server and includes it in the Authorization header of every HTTP request. If the server requires another scope, the client can ask the user to authorize it and retry the request. The application still has to bind three identities correctly: the authenticated user, the agent instance, and the external account. For user-initiated work, the MCP client uses the user’s delegated grant rather than a shared platform credential. The MCP server validates the token and enforces permission for the exact tool and resource before returning data or taking action. If it calls an upstream API, it uses a separate upstream token; the MCP specification forbids passing the inbound MCP token through. These bindings matter when several users share one team agent or when the same user has instances with different authority. Tool calls also have a lifecycle. A timeout may leave the agent unsure whether a calendar event was created, and a blind retry could create it twice. Stable call IDs and idempotency keys let the tool recognize the same logical action. A long-running operation needs a durable job handle, progress, cancellation, and a way to collect the result after the agent reconnects; the MCP Tasks extension defines one such pattern. Parallel calls introduce ordering and concurrency problems. Conventional code enforces these guarantees and records each request, approval, retry, result, and error for audit. Runtime code execution An Agent Application may make scripts and executables available to the runtime agent. Some are packaged with the release; the agent may generate others while working. The agent can invoke this code through a shell, interpreter, or code-execution tool, and conventional compute runs it in the application’s execution environment. If the instance retains generated code for later execution, it becomes part of the workspace and local program state rather than the immutable release.

​
11.2 Natural-language programs

Natural language becomes program material when changing the text changes runtime behavior. Agent developers already write this material in several common forms:
  • Project instruction files such as AGENTS.md, Claude Code’s CLAUDE.md, Gemini CLI’s GEMINI.md, and harness-specific equivalents set operating rules for an agent working in a particular environment.
  • The Agent Skills specification packages a reusable procedure in a SKILL.md file, with optional scripts, references, and assets.
  • Subagent definitions describe specialist roles, the tools they may use, and the instructions they follow when the main agent delegates work to them.
The harness / Agent Application Framework can load instructions at runtime from a designated URL, a file on disk, an organization policy store, or a skill registry. The LLM interprets this text alongside the instructions packaged in the release. Dynamic loading allows an organization to add a procedure without rebuilding the application and lets the agent load specialized instructions for the task at hand. If the instance keeps them, they become local program state; the instance has diverged from its release, and its lineage records the change. Loaded instructions carry the authority to steer the agent. An attacker who can alter the source can change the agent’s behavior, and a prompt injection can have the same effect if the runtime mistakes untrusted content for instructions. The loading policy identifies which sources may supply instructions, how their contents are verified and versioned, and what authority they receive. A document loaded as knowledge remains untrusted reference material unless the release designates it as an instruction source. Section 19.4 develops these controls. These instructions can define a dynamic multi-step process. A procedure packaged with the release or adopted as local program state by an instance might direct the agent to inspect source material, draft a change, send it to a review subagent, run tests, and report the result. A research application can generate a larger graph in which subagents plan parts of a query, gather evidence, review each other’s findings, and assemble a report. The harness / Agent Application Framework loads the relevant instructions, while the model interprets them against current state and adjusts the process as work proceeds. Designing these dynamic workflow graphs, including their participants and transitions, is sometimes called graph engineering. Frontier models have become better at following detailed instructions and chaining tool calls, making longer natural-language procedures practical. The Agent Skills specification does not define execution guarantees. Its guidance uses evaluations to test behavior. A harness can improve reliability by adding structure, execution validation, and debugging. Those mechanisms make natural-language programs more inspectable and their execution easier to validate. Appendix B records the prior art and dated sources. Natural-language programs are versioned, reviewed, and evaluated with the rest of the application. Their behavior depends on the model, harness, tools, and runtime context, so behavioral tests establish whether the procedure works. Section 15.5 explains why text diffs alone cannot settle an upgrade when a published instruction was edited in the instance.

​
11.3 Project declarations

Project declarations are structured configuration that a framework or its tooling reads to assemble and run an Agent Project. They name entrypoints and components, select models and harness features, configure tools and triggers, declare package dependencies, and state requested permissions or runtime requirements. An Agent Plugin’s plugin.json and mcp.json files are declarations contributed by a project dependency. Some declarations describe deployment requirements and become part of the release. The platform resolves those requirements when it deploys the release. Secrets, granted authority, user data, and per-instance settings remain outside the project and release. Declarations change application behavior, but a processor does not execute them as ordinary code and a model does not interpret them as instructions. Version and review declarations with the source they configure. Validate them against a schema where one exists, then test the assembled application. A syntactically valid MCP declaration can expose the wrong server, and a valid dependency range can resolve to plugin content the application has never evaluated.

​
11.4 Knowledge resources

Knowledge supplies the material the application reasons over:
  • product and domain documentation;
  • customer files;
  • policies and manuals;
  • source code;
  • research material;
  • prior artifacts and templates;
  • schemas;
  • organizational context.
Knowledge may be packaged in the agent folder or kept in an external location the agent can access, such as a website, database, a document store, or behind an API. A release may therefore contain the material itself or the configuration and credentials needed to reach it. The source can remain raw. The agent browses, searches, opens, and reads the material as the work requires. For large collections, a retrieval service can ingest and index the material for retrieval-augmented generation (RAG), allowing the agent to find relevant passages before reading further. An application may use both approaches: direct access to complete and current sources, plus an index for finding material across a large collection. The runtime must preserve the boundary between instructions and knowledge. A policy loaded as executable instruction carries more authority than the same words retrieved as reference material. External documents may contain hostile instructions, so the runtime loads them as untrusted data and keeps that label attached. Section 19.4 develops the security consequences.

​
11.5 Two kinds of execution

An Agent Application uses two kinds of execution. A conventional computer executes deterministic code, tool implementations, filesystem operations, and resource limits. A large language model (LLM) interprets natural-language programs, reasons about the current state, and chooses actions. The agent harness coordinates both. It assembles the model’s context, exposes tools backed by conventional code, loads the application’s instructions and knowledge, and carries the reasoning loop forward. The same instruction can behave differently with another model, harness, tool set, or workspace state. A release therefore records the model and harness versions it was tested against, along with its conventional runtime dependencies. This does not guarantee identical answers. It tells an operator which combinations the developer has checked. Appendix D gives the fuller runtime contract.

​
11.6 Test the whole application

Each part of an Agent Application needs a different test. Developers test code with ordinary software tests. They test natural-language instructions by giving the agent representative jobs and judging its behavior. They validate declarations and dependency resolution, then check knowledge for source, freshness, and permission. A tool may work perfectly, yet the agent may choose it at the wrong time or supply an incorrect argument. Release testing therefore has to run the whole application, not just its code.

​
11.7 Agent Application Programming

Building an Agent Application requires more than writing prompts or connecting tools. Someone has to decide which work the model may judge, which behavior code must guarantee, how agents divide and hand off work, what state persists, and which outside components the application can trust, then author that program and evaluate the complete application. This work is Agent Application Programming. The discipline operates at two scales. At the local scale, a programmer decides whether a behavior belongs in agent instructions, a skill, a tool, a hook, a subagent, memory, or the agent loop itself. At the application scale, the programmer composes those primitives into a product. This includes:
  • separating a use case into model judgments and deterministic operations;
  • placing each behavior in the primary agent, reusable instructions, skills, tools, hooks, specialist agents, or runtime policy;
  • applying graph engineering to dynamic workflows and deciding which transitions conventional code determines and which the model chooses at runtime;
  • selecting external capabilities from plugins, MCP servers, libraries, APIs, and other dependencies;
  • assigning state to sessions, instances, workspaces, memory, and artifacts;
  • designing interfaces, triggers, permissions, evaluations, observability, and cost controls around the resulting system.
The placement of each behavior matters as much as its wording. A guarantee hidden in an instruction can be ignored. A task that needs judgment can become brittle when forced into a fixed graph. A subagent can protect the main agent’s context, but it also adds cost and another place for coordination to fail. A plugin can save months of work, but it also expands the application’s code, instructions, dependencies, and authority. Designing, authoring, and evaluating that hybrid program is what makes an Agent Application effective, efficient, and secure. AI coding agents are likely to become the main practitioners of this craft. They can inspect an entire project, propose a decomposition, write both code and natural-language programs, run evaluations, study execution traces and costs, and revise the design as models and application runtimes change. Humans will still set the goals, authority, risk limits, and acceptance criteria, and review consequential choices. Much of the day-to-day work, however, may be agents programming other agents. The planned Programming Agent Applications companion document will develop this discipline in detail: its design principles, decomposition methods, patterns, testing practices, security model, and relationship to harnesses / Agent Application frameworks. The capability model in the next section provides the common vocabulary for that work.

​
12. The agent project and capability model

An Agent Application is authored as a project for a particular harness / Agent Application framework. In a code-oriented framework, the project is usually a source directory. A managed or visual builder may store the same material in another form. This framework-native representation is the agent project. It contains the code, instructions, knowledge, configuration, and tests used to build and run the application. The project stays in the framework’s native form. This is similar to how Next.js and Rails both build web applications, but they use different route files, project conventions, and release bundles. They interoperate through the web platform and its protocols. Agent frameworks can likewise support common protocols while keeping their own project layouts and programming models. The choice of framework affects the finished application. Its conventions, defaults, and design philosophy about model support, context strategy, tool system, execution environment, state model, event stream, and debugging facilities all shape behavior and cost.

​
12.1 A capability model for Agent Applications

The table lists capabilities found across current Agent Applications. Each project uses the subset its job requires. A small application may need only an agent program, a few tools, an interface, and tests. A long-running business application may need every row. Framework authors can use the table to describe what their frameworks handle.

​
12.2 What a project may contain

A project can group its source material like this. The names describe parts of the project, not required filenames or a portable package format. Each framework maps them onto its own files. A small project omits unused parts. A platform may keep some operational settings outside the repository.
Natural-language instructions are the primary program material a harness loads: a root instruction file, skills, and subagent definitions. Computer-code tools are deterministic functions, hooks, and other in-repo code. System integrations declare MCP servers and other connectors. Evaluations test the assembled application. Package dependencies pin libraries and plugins. Platform configuration is what a platform reads to package a release and create instances. The capability model in section 12.1 still names runtime responsibilities such as workspace, interfaces, triggers, and policy. Those often live in the parts above, in the framework, or on the platform rather than as extra top-level folders. Appendix A shows one larger layout. Section 9 applies the model as part of the build-and-operate method.

​
12.3 Where existing standards fit

Standards help when independently built systems need to communicate. An internal interface controlled by one framework can follow that framework’s own design. These standards play roles similar to HTTP, HTML, and package formats in web applications. A framework can use several of them while keeping its own source layout, build process, and deployment model.

​
12.4 How current harnesses expose the capabilities

This comparison focuses on Goose, Claude Code, Deep Agents, OpenCode, and Vercel AI SDK. Each already covers much of the capability model and has a project or runtime boundary that could develop into an Agent Application framework. The table uses first-party documentation available on August 11, 2026. Each entry names the path the project documents. “Project code” means that the application assembles the capability from general APIs. “Platform service” means that a deployment or hosting layer supplies it. These terms describe ownership and packaging, not a pass/fail score. The table exposes fragmented support for the capability model. A capability may be a built-in feature in one harness, project code in another, and a platform service in a third. Similar features use different names, scopes, state models, and deployment paths. Developers must therefore reconstruct the application model for each harness. The boundary also differs. Goose, Claude Code, and OpenCode package a runnable host with user surfaces. Deep Agents combines a Python harness with a documented LangSmith deployment path. Vercel AI SDK offers TypeScript primitives and a durable Workflow runtime, leaving the project to supply more of the application structure. This paper makes those differences visible and gives the community a shared capability model. A harness moves toward becoming a first-class Agent Application framework when it presents these capabilities as a coherent system for structuring, developing, testing, deploying, and operating an application. Consistency means shared concepts, explicit ownership, and interoperable boundaries while each framework keeps its native preferences, defaults, and use-case optimizations.

​
12.5 Plugins contribute components

An Agent Plugin packages reusable components for an Agent Project. An application can incorporate plugin-supplied instructions, tools, hooks, and client extensions into its program. Its state model, authority rules, tests, and operating lifecycle govern how those components are used. Agent Plugins 1.0 defines a portable directory with a root plugin.json, Agent Skills under skills/, MCP server configuration in mcp.json, and reverse-domain client extensions. The specification stops at the package format. Frameworks and package managers can supply registries and dependency resolution, including project dependency files and transitive plugin dependencies. They can also define installation permissions and supply-chain verification without changing the plugin format.

​
Part IV: State, change, and results

​
13. Application, release, instance, and session

A running Agent Application has four related lifetimes. The product continues across releases. Each release can create many instances, and each instance can run many sessions. The application is the product identity that a company offers and customers use. It continues while the publisher ships new releases. A release is a fixed, deployable version of the native project. Each framework and platform has its own release format. A production release records the source revision and resolved dependencies, along with the framework, harness, and model versions. It also records active components, requested authority, runtime requirements, evaluations, and migration rules so an operator can inspect and reproduce the deployment. Operators keep prior releases for inspection and rollback. A release records content digests as well as version labels. Semantic versioning cannot establish behavioral compatibility for a package that changes natural-language instructions. A plugin update therefore requires evaluation even when its publisher labels it a minor or patch release. An instance is the long-lived unit created from a release for one privacy domain, such as a user, team, customer account, project, or job. Its workspace, authority grants, history, and billing accumulate independently of other instances. The user or organization it represents remains responsible even when the instance acts for months. An operator upgrades an instance by updating its project files to a new release. If the instance edited a published natural-language instruction, that instruction is merged semantically. A session is one period of execution or interaction within an instance. A user, event, or schedule starts it. The session may last one turn or many and need not have a formal finished state. It uses the release and active local changes attached to the instance when the session starts.

​
14. The durable workspace

Each instance has one persistent, isolated logical workspace. It includes every piece of durable state that the runtime agent can retrieve, even when the platform stores that state across several systems. A logical workspace need not be a single filesystem. A platform may keep structured state in a database and artifacts in object storage. It may also give each session an ephemeral filesystem, retain selected changes, and record which session produced them. Later sessions must be able to find, use, and update the retained state. The reference design gives each instance a persistent virtual computer: a filesystem, a shell, and network access, wrapped by the application’s policy code. Agents and their tools use ordinary file operations, scripts, and command-line programs on documents, code, local databases, installed packages, artifacts, and intermediate results. They can add new forms of state without a schema or a storage API for each kind of object. That environment is why a harness-based agent can do general work. A chat and a list of specialized tools can complete a narrow job. A loop that can read, write, and run code over a disk can take on work the application author did not enumerate in advance. As models get better at reasoning and following instructions, the harness should stay small: assemble context, call tools, load skills, and run the loop over that computer. The industry often adds more special-purpose tools and prompt-level partitions. Those can help a narrow product. They are a poor substitute for a computer when the job is open-ended. Manus Cloud Computer keeps a persistent filesystem, installed tools, and running processes. Grok Bot runs on a persistent cloud machine with a filesystem, terminal, and browser. Claude Managed Agents give Claude bash, file operations, and a persistent sandbox filesystem. Perplexity Computer is framed as a worker that uses a computer, including local files on Windows. These products differ in tenancy and product scope. They agree that the agent should operate over a computer rather than only a transcript and a tool list. The computer does not require a dedicated machine while the instance is idle. A platform can snapshot it, restore compute when work arrives, and suspend it afterward. At scale, the platform can store a shared base image and only the files each instance has changed. Appendix D describes the storage contract.

​
14.1 What a workspace holds

Current working state changes in place, so its size usually reflects the application’s current work rather than its full history. It may include:
  • source material and working files;
  • generated code and installed dependencies;
  • local databases, indexes, and caches;
  • created artifacts;
  • downloaded and locally cached files;
  • user-uploaded files;
  • tool configuration and pending schedules.
Historical state grows as the instance works and includes:
  • checkpoints and snapshots;
  • run records;
  • evaluation results;
  • source and change history.
For a long-lived instance, history may cost more to store than the current working state. A workspace holding fifty megabytes of customer work may also carry several gigabytes of checkpoints taken before consequential actions over two years. Retention and compaction policies can keep that history from dominating the workspace’s storage cost. Raw credentials stay in a managed secret store, while the workspace holds governed references. An export carries those references and leaves the credentials behind. The Agent Plugins specification defines two storage roots. PLUGIN_ROOT holds immutable release content for a plugin packaged with an application. PLUGIN_DATA holds writable state in the instance workspace. A platform scopes that data by application, instance, and plugin identity, then applies the workspace’s isolation, retention, export, checkpoint, and deletion rules. A team sharing one instance also shares its plugin data; separate instances never share it. Secrets stay in the managed secret store rather than either root. Plugin upgrades that change persistent data include migrations in the release plan.

​
14.2 The workspace is the privacy boundary

The runtime agent has access to the whole workspace. Files, memory, indexes, summaries, and artifacts may enter its context or affect later work. Folder names and file permissions within a shared workspace do not create separate privacy domains. The boundary covers the logical workspace rather than one filesystem volume. It includes database rows, objects, session-bound files, and external records whenever the instance can retrieve them. The platform enforces privacy between workspaces. It isolates their storage and compute, controls where their contents can be sent, and restores or deletes one without touching another. Section 6.1 gives examples of where applications draw that boundary; section 19 covers the controls that enforce it.

​
14.3 Instance identity and workspace state

The instance identifies the continuing agent: whom it represents, what it may do, and what it has done. The workspace holds the durable working state and computational environment that the agent uses. Separating them lets an operator access, move, or restore the workspace without changing the agent’s identity or permissions. It also keeps per-instance configuration outside the workspace and out of the runtime agent’s reach.

​
14.4 Memory and workspace

A memory system selects facts or past interactions for the model’s context. Persisted memory belongs to the logical workspace whenever the instance can retrieve it. The memory may live in files, a database, or another service.

​
15. How instances change after deployment

A shared application changes when its publisher ships a release. An instance can also change between releases. It may learn facts, accumulate files, adopt user preferences, or receive new instructions. Some applications let the runtime agent write a skill or generate code for later use. These local changes cause instances in the same fleet to diverge. If they add or edit natural-language instructions, they diverge in program as well as state. Operators then manage a fleet whose members no longer share one program: rollout, audit, and policy have to follow each instance’s local program and state, not only the shared release. The platform tracks the shared release separately from the changes made inside each instance. For every local change, it records the author, tests, approval rule, and rollback method.

​
15.1 Who can author a change

Authorship does not confer the right to activate a change. An agent may draft a skill that requires a person’s approval. The application may activate a low-risk change automatically after its tests pass, according to a policy set in advance.

​
15.2 Risk depends on the change

Adding a customer document changes what the agent knows. Editing a skill changes how it behaves. Installing a plugin can alter behavior, available capabilities, or program structure. Granting a credential expands what the installed components can access. The review process should reflect these differences. Installation, activation, and authorization remain separate decisions. A plugin cannot authorize itself, and installing it does not approve future updates. A behavioral diff must include instructions, descriptions, tool schemas, hooks, and other declarations as well as executable files. The source of a change also affects its risk. A support ticket or web page may contain instructions written by an attacker. If an agent turns that material into a skill or tool, reviewers must treat the resulting program as influenced by an untrusted source. An agent cannot grant itself more authority. Only the person or organization that controls a resource can approve a new credential, spending limit, or network destination. Appendix D classifies these changes in more detail.

​
15.3 Keep instance changes local

Changes created inside an instance stay with that instance. They cannot update the shared Agent Project or publisher release. An instance may report that a new procedure worked well. A developer can use that evidence to author and test a release through the publisher’s release process. The platform quarantines changes influenced by untrusted material until a trusted reviewer clears them. It also stores change history where the agent cannot edit it. This prevents a compromised instance from changing the rest of the fleet. If policy lets a runtime agent install a plugin, the platform treats the result as an instance-local change to the program. It records the package and activation in lineage and evaluates the change in isolation. Promotion to a publisher release still requires the release process and trusted review, especially when the plugin came from untrusted content.

​
15.4 Recording instance lineage

Version control records changes to the shared application. Instance lineage records local history after creation:
  • originating release and installed upgrades;
  • active local filesystem overlays;
  • generated code;
  • installed plugins, exact package digests, and active components;
  • the author and source of each change;
  • tests and approvals;
  • artifact history;
  • tool and permission changes;
  • forks, merges, and rollback points.

​
15.5 Merge edited published instructions semantically

Copy or a line-based three-way merge is enough for ordinary code, configuration, and files the instance did not edit. Natural-language instructions are different. One instruction can change the effect of another, including instructions in different files. A text merge finds edits to the same lines. It cannot tell whether two instructions agree. Semantic merge is required when the instance edited a published natural-language instruction. A later release of that instruction cannot be applied by replacing the file or by merging lines. The platform applies the publisher’s intended behavior, preserves unrelated local changes, and tests the result against the instance’s workspace. If the instance only added local instructions and left the published files alone, the platform can copy the new published files. It still has to evaluate the result. Local instructions can collide with the new published ones. Suppose a publisher raises the threshold for escalating a support case. One customer’s instance has also learned to “handle routine cases without escalating.” Copying the new published file succeeds as a text operation. The combined behavior can still be wrong. A three-way merge of an edited published instruction can likewise accept two sentences that contradict, or report a conflict between two paraphrases of the same rule. If an upgrade test fails, the platform blocks that instance’s upgrade and creates a review task for the fleet manager.

​
15.6 Evaluate releases against instance state

A shared release can pass every test and still fail for one instance whose workspace contains unusual history. The platform first tests the release on standard examples, then tests the upgrade against affected instances or representative checkpoints. Releases remain fixed and inspectable. When behavior changes, an operator can compare the release, runtime, policy, and workspace against a stable reference. Appendix D states this model more formally.

​
16. Artifacts and other durable results

An Agent Application may produce a report, a working codebase, an updated customer record, or a process that it continues to maintain. These results persist independently of the conversation that produced them. Durable results fall into four groups: An Agent Artifact is a portable, versioned, access-controlled work product. The platform records its creator, current version, source lineage, and access rules. An artifact may be:
  • a file, such as a document, spreadsheet, or Markdown file, that a user can open on their computer; or
  • a hosted work product, such as an interactive report, website, or Agent Application, that needs a suitable runtime.
A live Agent Artifact may depend on current data that cannot travel with its content. Its record carries governed references and an artifact-scoped grant for the exact resources it may read. Moving the artifact to another platform requires that platform to resolve the references and obtain fresh authorization for grants that cannot transfer.

​
16.1 Message versus artifact

A message belongs to the conversation timeline and is usually append-only. An artifact has a separate identity and lifecycle. A user can open it, revise it, and compare versions without replaying the conversation that produced it.

​
16.2 Surfaces

Interactive Agent Applications usually expose the agent widget described in section 7. It presents conversation, session history, artifacts, approvals, and generated UI in one interface for an instance. An application may also have a dedicated artifact editor, workspace browser, approval queue, or operations view for runs, cost, errors, and schedules. APIs connect the application to other products. Email, messaging, and ticketing systems deliver work through channels that people already use. Each surface operates on the same instance and durable state.

​
Part V: Operating Agent Applications

​
17. Instance execution

​
17.1 Persistence without resident compute

An instance can suspend compute while preserving its identity, workspace, schedules, and pending work. Suspension stores the instance’s state without keeping a process running. Section 18 describes the corresponding active and suspended instance states.

​
17.2 Event-driven operation

An instance often works without a user present. It can wake in response to:
  • 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.
GitHub Copilot automations run on repository events or a schedule, while Intercom Fin wakes when a customer sends a support message. Events and schedules create fleets with many short wakeups. Ten thousand accounts, for example, might each run for ninety seconds every night. If resume is slow or expensive, a platform may keep instances resident and lose the cost savings of suspension. Resume cost grows with the instance’s writable delta, retained checkpoints, and file count. Retention policies and workspace size caps limit these costs.

​
17.3 Checkpointed long-running work

Work that runs for hours or months must recover from interruptions, mistakes, and partial failure. It requires:
  • checkpoints;
  • pause and resume;
  • safe retries that do not repeat a charge, email, or database update;
  • timeouts and cancellation;
  • a way to repair or offset partially completed actions;
  • resource and cost limits;
  • escalation;
  • clear terminal states.
The application stores its plan, commitments, inputs, outputs, and checkpoints outside the model’s short-term context. On a later run, the agent reads that record to determine what has happened and what remains.

​
17.4 Multi-agent structure

An instance may contain one principal agent with several subagents, or a set of peers. Agents inside the same instance share its identity, workspace, and authority, so the instance remains the unit of accountability. A plugin can contribute a subagent definition, but the subagent runs under the application’s instance and delegated limits. An A2A peer is independently addressable and may have its own workspace, identity, and authority boundary. Section 22 identifies coordination across separate instances as an open problem.

​
17.5 Human authority and approval

Approval rules should reflect how hard an action is to undo. Editing a draft is reversible. Refunding a charge may require a second transaction. Sending a private document to the wrong person may be irreversible. For each action, the policy specifies whether the agent may act silently, act and report, ask first, or never act. An approval lets a reviewer stop irreversible work before it occurs. Manual review becomes less reliable at high volume because a reviewer handling fifty items an hour may start to rubber-stamp them. Code and policy systems must enforce hard limits, as section 19.3 describes.

​
18. The Agent Application Platform

An Agent Application Platform turns a tested Agent Project into an immutable release and operates long-lived instances with durable workspaces, identity management, security controls, governance, observability, evaluation, and fleet management. It provisions instances at the application’s privacy boundary, attaches scoped credentials, and runs their sessions. A store or publisher may provide distribution and commercial services separately. Ordinary cloud infrastructure supplies compute, storage, networking, and databases. An Agent Cloud adds infrastructure designed for persistent agents: durable workspaces, resumable execution, sandboxed tools, model access, event streams, checkpoints, and per-instance metering. An Agent Application Platform may build on that specialized infrastructure, provide it directly, or assemble the same capabilities from general cloud services. Above this infrastructure, the platform manages the application lifecycle and the services used by developers and publishers. An Agent Application Platform provides these shared lifecycle services: Amazon Bedrock AgentCore, Vercel Eve, and Pickaxe each cover part of this list in their public documentation: For a fleet, the platform keeps local changes separate from the shared release. It records each instance’s lineage, tests local changes, applies upgrades in stages, and supports rollback. An instance moves through four lifecycle states: Figure 6. Instance execution and lifecycle states. User requests, business events, schedules, and approvals start sessions for the same persistent instance. The instance moves among active, suspended, archived, and deleted states. Checkpoints support suspension, resume, and recovery. Most instances spend much of their time suspended. They keep their work and schedules while using storage instead of active compute. Appendix D expands the service boundaries for platform builders.

​
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. A malicious instruction can arrive through a web page, email, document, support ticket, tool result, or old workspace file. The controls below limit what compromised or mistaken behavior can affect. Figure 7. Trust and authority boundaries. Trust and authority boundaries showing untrusted inputs entering an isolated Agent Instance through identity routing and source labels. The runtime operates through sandboxed code execution and a durable workspace, while a separate policy plane controls tool access and preserves evidence and recovery records. The model can propose actions inside these boundaries. Identity, resource-level authorization, approval decisions, network policy, spending limits, and audit records remain outside program material the agent can modify.

​
19.1 The agent cannot choose its own authority

The developer declares the permissions the application may need. The user, organization, or resource owner decides what to grant. The agent can use that authority but cannot expand it. Permissions can expire or be revoked while the instance is suspended or running. The platform must also use a narrow execution identity so an agent cannot inherit broader platform access. Commerce policies grant search, negotiation, ordering, and payment authority separately. A commercial grant can limit the merchant, what may be bought, maximum price, time window, payment instrument, and confirmation rules. Commerce and payment protocols can carry intent, checkout state, authorization, payment requirements, and receipts. Policy code enforces the limits and handles revocation. Appendix D.4 lists the current protocols.

​
19.2 Review the complete plugin

A plugin affects executable software and model behavior. Review and approve its complete content digest: executable code, natural-language instructions, component descriptions, tool schemas, declarations, hooks, and client extensions. A skill can steer an existing tool in a new way even when the plugin adds no capability. Hooks require extra scrutiny because they can run at lifecycle points without model selection. A production release keeps a component inventory analogous to a software bill of materials. For each plugin it records the source, version, digest, exported components, executable files, requested capabilities, network destinations, and active host extensions. Credentials remain governed references scoped to an instance. Neither a plugin nor one of its components can grant itself access. An update shows behavioral and capability changes along with file changes. The platform reruns affected evaluations before activation and keeps the previous resolved graph available for rollback.

​
19.3 Put hard limits in code

Policy code the agent cannot change authorizes each action the model proposes. Keep these controls outside program material the agent can edit:
  • authentication and agent-instance identity;
  • permission checks on the exact record or resource being read or changed;
  • tenant and workspace isolation;
  • secret delivery;
  • spending and rate limits;
  • approval gates;
  • allowed network destinations;
  • artifact sharing;
  • retention and deletion.
A permission such as crm.write is too broad by itself. The system that controls the resource must also check which customer account the agent is changing. A record-level check prevents a compromised or misled agent from reaching another account or sending private files to an unapproved server. Reads need the same control. A database, document connector, search index, or RAG service must enforce access before returning data to the agent. When that connector is an MCP server, much of this enforcement belongs in its authentication and authorization path. For user-initiated work, the safe default is the intersection of the instance’s delegated authority and the authenticated user’s permissions. Loading a broad collection into the model’s context and asking the model to hide unauthorized records defeats this boundary. Credentials should be short-lived and limited to the current action whenever possible.

​
19.4 Preserve source labels

The runtime distinguishes developer instructions, organization policy, user directions, reference material, and outside content. It keeps those source labels when text is summarized, passed to a subagent, or saved and read later. Reading an untrusted document may narrow what the current run is allowed to do or trigger an approval requirement. Prompt injection remains possible, so policy uses source labels to limit what a misled agent can reach. Instance and workspace isolation provide the outer boundary. Users with different data rights need separate workspaces, and scoped tools limit what the agent can reach outside its workspace. Appendix D describes this mechanism in more detail.

​
19.5 Agent-generated code

During a run, the agent may write a script, execute it, inspect the output, and use the result to continue working. It may save that script at a known path in its workspace so later sessions can run or revise it. The runtime applies the instance’s network, resource, and permission limits to this code. Saving the script makes it part of the instance’s local program state. It does not change the shared application release. If the publisher wants every instance to receive the script, a developer reviews and tests it before adding it to a new release.

​
19.6 Evidence and recovery

An audit record identifies the agent, its authority, the sources it used, the tools it called, and what changed. It must be understandable to someone who was not present during the run. Keep this compact record for as long as the result matters. Store detailed model inputs and outputs for a shorter period unless the use case or law requires more; they are large and often contain sensitive data. Before a consequential action, keep a workspace checkpoint and record any outside systems the agent will change. A checkpoint can restore files but cannot recall an email or a disclosed secret. For each outside action, the application must record how it can be reversed, offset, or reported. Appendix D covers replay and recovery techniques; Appendix B records one current legal retention example.

​
20. Standards, contracts, and portability

Standards cover specific boundaries in the stack: tools, reusable instructions, component packages, agent events, communication between independent agents, and commerce. Section 12.3 and Appendix D.4 map these protocols in more detail. A standard is useful when independent implementations need to exchange information or commands. Frameworks can keep their own approaches to local development, evaluation, and deployment. Cloud platforms can likewise choose how they provide workspaces, identity, scheduling, fleet operations, and cost controls. Agent Projects and releases remain framework-native because current frameworks use different structures. A project written for Claude Agent SDK, Google ADK, LangGraph, OpenAI Agents SDK, or Vercel AI SDK keeps that framework’s source layout, build process, and release mechanism. At these boundaries, a frontend can talk to several agent backends through AG-UI, and a tool can serve several hosts through MCP. An Agent Skill or Agent Plugin can move between compatible clients. Independently deployed agents can collaborate through A2A. Future contracts may cover artifacts, workspace exports, lineage, delegated authority, and billing records because users and operators may need to move them between platforms. Work on a contract should begin with two independent implementations and a specific exchange problem. The contract stays at the exchange boundary while internal design remains framework-specific.

​
21. Agent Application Stores

An Agent Application Store, or Agent App Store, distributes Agent Applications much as a mobile app store distributes mobile applications. Publishers can offer a one-time purchase, a subscription, or in-app purchases. Commercial LLM inference is commonly metered by token, so many applications incur a cost each time the agent runs. A one-time purchase can continue to incur token charges for years, and a subscription must account for customers whose inference use varies widely. Long-lived instances also retain workspaces and schedules between runs. The platform observes model use, while the store owns the purchase and entitlement record. They need a shared usage and billing boundary even when one provider operates both services. In-app purchases can add usage credits or move the customer to a plan with a larger allowance.

​
Part VI: Open questions and conclusion

​
22. Open questions

The category will change as implementations take on work that lasts longer and carries more responsibility. The questions below mark places where the current model may need to grow. Implementation experience and counterexamples are especially useful, including from attempts to build agents that run large businesses or conduct frontier research. Privacy gives the first rule: information that must remain separate belongs in separate instances. That split can scatter useful context. A customer’s tickets may live in several workspaces, and each ticket may also relate to a user, account, and product. The industry still needs controlled ways to read across those boundaries without copying private data or losing the source, permissions, and retention rules of each fact.

​
22.2 How do we test and merge natural-language programs?

Two instructions can conflict even when they sit in different files. Copy and line-based merge are enough when published instructions were not edited in the instance, but the platform still has to test that local instructions do not collide with the new release. When published instructions were edited, platforms need a semantic merge and affordable tests that compare intended behavior before and after the change, first for the release and then for affected instances.

​
22.3 How do we migrate years of accumulated state?

Databases have schemas and conversion scripts. Workspaces also contain notes, generated code, installed packages, and local conventions. Some of that material can only be updated by an agent that reads and interprets it, which makes migration slower and less predictable.

​
22.4 How much may an agent improve itself?

A platform needs clear limits on which instructions, skills, tools, or subagents an instance may create and activate. It also needs a way to learn from many instances without exposing one customer’s data to another.

​
22.5 How should trust survive summarization?

A hostile instruction can be copied into a summary, passed to another agent, or saved for months. The source and trust level must survive those transformations.

​
22.6 What is the smallest useful portability contract?

Customers need to move workspaces, artifacts, lineage, and authority records. A shared format must carry enough information to resume work without forcing every application into the same internal design.

​
22.7 How should long-lived instances be priced?

Operators need to connect model, tool, compute, storage, and review costs to an instance or business result. They also need policies for dormant instances that still occupy storage and retain schedules.

​
22.8 How do identity, revocation, and deletion work over years?

An agent may outlive the employee who created it. Revoking a grant must reach suspended instances and future runs. Audit-retention rules may also conflict with a customer’s request to delete personal data.

​
22.9 Who will own the Agent Application framework layer?

Harness developers may expand into it, while model providers and Agent Application Platforms may absorb other parts. The lifecycle problems remain because the instance and its work still outlive any one model call.

​
23. Conclusion

This architecture gives readers a way to reason about the complete AI agent system surrounding its model calls and agent loops. Start with the application’s job and privacy boundary. Map its behavior across code, natural-language programs, declarations, knowledge, tools, workflows, and policy. Then assign the responsibilities for releases, instances, workspaces, authority, surfaces, operations, and recovery. Persistence is the architectural break from request-oriented AI software. An instance returns to the same work across sessions and accumulates context, artifacts, unfinished work, instructions, and generated code. A new release can therefore improve the shared application while failing against the state of one instance. Release evaluation against instance state, staged upgrades, lineage, checkpoints, and targeted repair address that condition. If the instance edited a published natural-language instruction, the upgrade merges that instruction semantically. Agent Application frameworks structure and test the project. Agent Application Platforms turn releases into long-lived instances and operate their workspaces, authority, interfaces, and fleets. An Agent Application Store handles discovery, acquisition, installation, and commercial exchange. Products can combine these roles, but keeping their responsibilities distinct makes architectures and vendor claims easier to compare. MCP, Agent Skills, Agent Plugins, AG-UI, A2A, and commerce protocols already cover several boundaries. Other contracts may emerge where independent systems need to exchange artifacts, workspace exports, lineage, identity, authority, or billing records. The internal project and release model can remain native to each framework. Teams can use this map to reason about the complete system, decide who owns each responsibility, compare implementations, and see which boundaries need to interoperate.

​
Acknowledgments

This paper stands on the shoulders of giants. Researchers, engineers, standards contributors, and product builders created the language models, agent harnesses, protocols such as MCP, formats such as Agent Skills, execution environments, and other core building blocks on which Agent Applications depend. They also explored the space of possible agent architectures through research, open-source projects, and products. Their work gave this paper’s authors a rich surface from which to carve out a reference architecture. We thank Kalyan Basu for his guidance, and especially for recognizing that the paper’s central contribution is a reference architecture. That observation clarified the paper’s purpose and what it offers its readers.

​
Appendix A: An illustrative project layout

This example maps section 12.2 onto one possible layout. It is not a portable package format. A framework may use different filenames, keep several parts in one module, or store operational configuration outside the repository.
A Goose project might use AGENTS.md; a Claude Code project might use CLAUDE.md. The skills/ directories use the Agent Skills format. Tools and workflows use framework-native TypeScript. mcp.json is one way to declare connectors. The policy files explain data-access and report-sharing rules to developers and the agent; enforceable limits still live in computer-code tools and platform configuration. Knowledge, artifact definitions, triggers, and migrations are extra parts a larger application may include. Another framework might define agents in YAML, register tools with decorators, or keep evaluations in a hosted service. The filenames would differ, but the same parts would still exist somewhere in the project or platform.

​
Appendix B: Dated evidence

This appendix records evidence that may change over time. It is current as of August 9, 2026. If an entry becomes stale, recheck the cited example; the main argument should not depend on that example remaining current. Web and mobile application comparison. Common descriptions define a web application by its browser runtime and web delivery, then explain its client-server architecture, capabilities, and distribution. The AWS, GeeksforGeeks, and HubSpot explainers follow that structure. Definitions of a mobile application begin with software designed for a mobile device, then cover operating-system integration, device capabilities, installation, and app-store distribution. The AWS mobile development and TechTarget mobile app descriptions use the same frame. Section 2 applies it to Agent Applications while adding the change in operator and the lifecycle of a persistent instance. 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 a shared base image plus a few hundred megabytes of writable delta and metadata per instance in object storage is on the order of $0.02 to $0.30 per instance-month. The ratio, roughly two to three orders of magnitude, supports the active and suspended instance distinction in section 18. The dollar figures are estimates under stated assumptions and will change. The storage model follows the same basic layout documented by Docker: read-only image layers shared across containers, with each container’s changes written to its own copy-on-write layer. Linux OverlayFS exposes these as lower and upper directories. 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 of background work described in section 17.2. Regulatory retention. The European Union (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. Vercel Eve. Vercel announced Eve on June 17, 2026 as an open-source, filesystem-first TypeScript framework for durable agents. Its agent directory packages instructions, skills, tools, subagents, channels, and schedules. The runtime supplies checkpointed durable sessions, sandboxed compute, approval gates, evaluations, tracing, and channel adapters. Section 4 uses Agent Application framework as this paper’s category label for that combination. Agent Plugins. Agent Plugins 1.0.0 defines an open, vendor-neutral package with a root plugin.json, Agent Skills in skills/, MCP server configuration in mcp.json, and reverse-domain client extensions. It also defines PLUGIN_ROOT for installed package content and PLUGIN_DATA for client-managed writable state that persists across updates. The project’s initial steering committee includes maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel. Its future-considerations document leaves permissions, provenance, secrets, enterprise controls, audit events, dependency resolution, and testing outside version 1.0.0. Codex CLI 0.147.0 added portable Agent Plugin installation and catalog search on August 7, 2026. The portable standard is smaller than the current host formats. OpenAI plugins use a .codex-plugin/plugin.json manifest and may add skills, MCP connections, assets, and lifecycle hooks. OpenAI asks users to review and trust plugin hooks before enabling them. Claude Code plugins may include skills, agents, hooks, MCP servers, LSP servers, monitors, binaries, and default settings. The paper uses these formats as implementation evidence rather than category requirements. Agent commerce and payment protocols. Coinbase announced x402 on May 6, 2025. Google announced the Agent Payments Protocol (AP2) on September 16, 2025. OpenAI and Stripe announced the Agentic Commerce Protocol on September 29, 2025. Google published the Universal Commerce Protocol on January 11, 2026. On April 28, 2026, Google announced that it was donating AP2 to the FIDO Alliance, and FIDO announced new agentic authentication and payments standards work. Section 19.1 places commerce and payments at the delegated-authority boundary; Appendix D.4 maps the current protocols to their narrower roles. General-purpose Agent Applications. ChatGPT Work works across connected apps and files, produces finished documents and sites, and supports scheduled or triggered work. ChatGPT Projects retain project files, instructions, chats, and memory. Claude Cowork Projects have project-scoped files, instructions, memory, and scheduled tasks; live artifacts persist independently of their creating chat and keep version history. Gemini Notebooks retain sources, instructions, and ongoing discussions, while Gemini Spark manages continuing tasks, tools, and schedules. Embedded and channel-based agents. Microsoft 365 Copilot appears inside Word, Excel, Outlook, and Teams. Canva AI embeds agentic creation, persistent memory, and scheduled campaign work inside its design and marketing system. Intercom Fin operates across web and mobile messengers, email, phone, WhatsApp, SMS, social channels, and Slack. OpenClaw routes personal agents through Telegram, WhatsApp, and other messaging services. Agent widgets. OpenAI ChatKit combines authentication, thread and message management, attachments, tool and reasoning visualization, and interactive widgets. CopilotKit provides chat, persistent threads, tool-call rendering, human approvals, and generated UI. AI SDK Elements provides components for the composer, model selection, attachments, conversation, reasoning, sources, and tools. AG-UI standardizes the typed event stream between an agent and a user-facing application. MCP Apps lets tools return sandboxed interactive views that render inside compatible conversation hosts. Project-building Agent Applications. Lovable Agent mode reads and changes a persistent project codebase, while project and workspace knowledge provide instructions across conversations. Replit Agent checkpoints preserve project files, installed packages, configuration, agent memory, conversation context, and connected databases. Claude Code, Codex, and GitHub Copilot’s cloud agent show other coding-agent forms, including terminal, desktop, issue, pull-request, and scheduled operation. Personal, vertical, and persistent-computer applications. OpenClaw’s agent workspace holds agent files and private memory, while its scheduler persists recurring jobs. Lightfield builds versioned customer context and runs CRM agents in chat or through automations. Manus Cloud Computer keeps files, installed tools, and running processes across sessions. Grok Bot documents a persistent cloud VM with a filesystem, terminal, and browser. Claude Managed Agents document bash, file operations, and a persistent sandbox filesystem. Perplexity Computer describes a general-purpose worker that uses a computer, and Personal Computer for Windows works across local files. Section 14 uses these as evidence for a computer as the agent’s working environment, not as a required product shape. These products organize the continuing instance around a person, a business workspace, or a computer rather than a software project. Frameworks and sandboxes. The OpenAI Agents SDK provides an agent loop, tools, handoffs, guardrails, sessions, tracing, and sandbox agents. LangGraph provides durable orchestration for long-running stateful agents. E2B and Vercel Sandbox provide isolated Linux environments for agent-run code. These are the named examples behind section 4. Partial Agent Application Platforms. The Amazon Bedrock AgentCore overview and runtime guide document its managed harness, runtime, memory, identity, tools, evaluation, and observability services, while distinguishing ephemeral session files from long-term memory. The Vercel Eve announcement documents its framework, durable workflows, sandboxes, approvals, subagents, evaluations, and deployment model. Pickaxe’s feature page and monetization guide document its builder, distribution channels, portals, user controls, memory, and payment models. Section 18 compares their documented coverage, not product quality. Builder workflow and native harness layouts. The Claude Code overview, skills documentation, subagent documentation, hooks reference, and MCP documentation establish the project files reflected in Appendix A’s illustrative layout. Harness capability snapshot. Section 12.4 compares Goose, Claude Code, Deep Agents, OpenCode, and Vercel AI SDK. Every entry links to the relevant first-party documentation. 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).” Natural-language instruction formats. OpenAI’s description of the Codex agent loop explains how it loads hierarchical AGENTS.md files. The Claude Code overview describes CLAUDE.md, and its subagent documentation describes Markdown definitions containing a specialist’s prompt, tools, and permissions. The Gemini CLI context-file documentation describes the equivalent GEMINI.md hierarchy. The Agent Skills specification defines reusable SKILL.md instructions with optional scripts, references, and assets. OpenAI’s GPT-5 developer release provides one published example of gains in instruction following and long chains of tool calls across model generations. Natural-language programming prior art. Dijkstra, “On the foolishness of natural language programming,” EWD667, 1978. Named systems and formats. Claims about named systems in sections 1, 4, 6, 7, 9, 11, 12, 14, 18, 19, and 20, as well as Appendix D, come from each vendor’s own documentation as of August 9, 2026 and should be rechecked before citation.

​
Appendix C: Companion documents

Section 12 of this paper contains the Agent Application capability model. The short public argument is the site overview. The documents in the table remain planned. A proposed contract becomes a candidate for a specification when independent implementations need to exchange the same information across a stable boundary. The current status of these documents is maintained at agentapplication.io/companion-documents.

​
Appendix D: Technical notes

This appendix holds implementation detail that is useful to platform builders but not required to understand the application model.

​
D.1 Runtime behavior and compatibility

An instance’s behavior depends on several inputs:
A runtime contract records the model and harness versions, context limits, tool protocols, filesystem features, execution features, scheduling support, policy hooks, supported plugin specifications and client extensions, and fallback routes against which the release was tested. The release input includes the resolved dependency graph and active components, so the equation does not need a separate plugin term. Compatibility means that the required features exist. It does not mean that two runtimes will produce identical behavior.

​
D.2 Change classes and semantic upgrades

The platform can classify local changes by what they affect and who may activate them. Risk rises when a change is derived from untrusted material or can reach more resources. Approval binds the exact tool definition, including its code, description, and input schema. Editing any of those parts requires a new review. A plugin installation can span several rows. The platform classifies the components it activates rather than assigning one risk class to the package. Installing content is a local program change; activation changes the running application, and authorization changes what it may reach. The lineage record keeps those events separate. Copy and line-based merge are enough for ordinary code, configuration, and files the instance did not edit. When an instance has edited a published natural-language instruction, a semantic upgrade has three steps: identify the behavior the publisher intended to change, apply that change while preserving unrelated local behavior, and run evaluations against the instance’s own checkpoint. If the instance only added local instructions, copy the new published files, then evaluate for collisions with the local program. Text diffs remain useful for review, but they cannot decide whether two natural-language instructions agree.

​
D.3 Cost model

The full cost can be written as:
Platforms share base images, managed indexes, key infrastructure, and provisioned capacity across the fleet. Each suspended instance carries its writable workspace changes, checkpoints, metadata, secret references, and schedules. Retention and compaction policies keep checkpoint history from growing without bound.

​
D.4 Existing formats and protocols

Several current formats cover part of this architecture: No widely adopted format carries the complete framework-native agent project, resolved dependency graph, workspace requirements, behavior tests, identity and authority record, communication events, artifacts, and instance lineage together. A single format for all of them would still need evidence from independent implementations. New contracts should address the specific boundaries where those implementations need to interoperate.

​
D.5 Authority and source tracking

The authority available to one step is the intersection of four limits:
The runtime attaches source and confidentiality labels to developer instructions, organization policy, user directions, retrieved knowledge, and outside content. Those labels survive summaries, tool results, subagent calls, and files written back to the workspace. Policy code can then remove credentials, narrow network access, or require approval after the agent reads untrusted content.

​
D.6 Replay and recovery

Three operations answer different questions:
  • Record replay runs deterministic application code against stored model outputs to establish what happened.
  • Re-execution runs the same release and checkpoint with fresh model calls. The result may differ.
  • A counterfactual run changes one input, such as removing a document, to test whether that input caused the behavior.
Explanation requires the release and local changes, model and harness versions, assembled context with source labels, model outputs, and ordered tool calls. Recovery also requires a checkpoint from before the action, identifiers for outside records, safe-retry keys, and the repair or reversal plan.

​
D.7 Migration patterns

Existing distributed systems offer useful patterns. Microsoft Orleans declares versions and checks compatibility before routing work to a running object. Erlang/OTP describes explicit upgrade and downgrade instructions and lets new code transform old state. Large services also migrate lazily when state is first opened and use rate-limited background jobs for the rest. Agent workspaces need all three ideas: a declared workspace version, explicit conversions where data has a schema, and agent-assisted migration for notes, generated code, installed packages, and other material that must be interpreted.