Skip to main content
Teams have built persistent, tool-using agents as product-specific systems. These products use different names and divide responsibilities differently, even when they share the same broad shape. The paper identifies that shape and presents a reference architecture for building and operating the complete product, which it calls an Agent Application.

​
Who it is for

Boundary cases, counterexamples, and prior art are useful input to the next draft, including cases that challenge the proposed terms or contracts. The paper provides guided reading paths for these different uses.

​
The initiative

The work is a public effort to make Agent Application a recognizable category the way web application is. MCP, Agent Skills, and related contracts already sit at specific boundaries. This paper names the complete product those boundaries plug into. It is maintained in the open. The first draft has a named author. The category will only hold if people who ship these systems test it. The first review is one product you know, then the definition.

​
What the paper is trying to do now

The paper defines the elements of an Agent Application, assigns responsibilities to them, and maps the lifecycle from project to release, instance, workspace, and durable work. Its capability model helps developers design applications and helps framework authors describe what their systems provide. The paper calls a harness an Agent Application Framework when it includes a coherent project structure, development tools, evaluations, packaging, deployment, and production runtime support. An Agent Application Platform turns tested projects into immutable releases and operates long-lived instances. The architecture defines no conformance test. Products may combine several elements in one service, use different names, and keep their own project and release formats.

​
Longer-term direction

Many agent products combine the project format, runtime, user interface, state, artifacts, and commercial services under one provider. The long-term goal is a software market in which developers can build with the framework that suits the work, run applications on compatible platforms, and distribute them through competing Agent Application Stores. Users should be able to keep the context, artifacts, and completed work that their instances accumulate over time. Agent Projects and releases can remain framework-native. Shared contracts are most useful where independent systems meet, including tools, instructions, interfaces, identity and authority, artifact sharing, workspace migration, and commerce. The paper maps standards that already cover some boundaries and identifies others that may need further work. Read the overview, the full paper, the companion documents, or review the draft.