[!NOTE] AI App Spec treats an AI application as an assembly of resources that is deployable to a compatible AI application runtime.
An AI application runtime turns models, tools, instructions, state, compute, and policy into an application that people and other systems can use over time.
The runtime is the governed environment in which an app operates. It authenticates actors, resolves and marshals configured resources, mediates access to models and external systems, executes attended and background work, persists state and outputs, and makes activity observable. A runtime may be a hosted product, an enterprise control plane, or a local implementation. The specification intends to be agnostic of the provider service topology.
A runtime has two cooperating planes.
These are responsibility boundaries, not necessarily deployment boundaries.
| Term | Meaning |
|---|---|
| App | A named product or capability designed by a publisher and expressed as a related set of runtime resources. |
| Package | An immutable, versioned distribution of an app definition and associated portable assets. |
| Resource | A logical component of an app, such as an agent, workflow, skill, tool, schedule, or artifact definition. |
| Runtime | The governed environment that realizes and operates app resources. |
| Runtime provider | An implementation of the runtime contract. Providers can differ substantially in architecture and native capabilities. |
| Target | A concrete runtime environment into which an app can be deployed, such as an organization, account, project, or local instance. |
| Installation | A package deployed to a target with target-specific configuration, permissions, and bindings. |
| Binding | The resolution of a logical app requirement to a concrete runtime-managed or customer-managed resource. |
| Capability | A feature or semantic contract a runtime advertises and an app may require or optionally use. |
| Execution | An individual session, task, run, or scheduled invocation produced by an installed app. |
A package is publisher-authored and reusable. An installation is customer-specific. Executions are protected runtime state.
AI runtimes are converging on a common set of responsibilities even as their APIs and product surfaces diverge. The specification targets common portable primitives.
| Primitive | App-level intent | Runtime responsibility |
|---|---|---|
| Agents | Identify a packaged agent implementation and its portable invocation contract. | Resolve a supported package format, instantiate the implementation, provide scoped access to runtime capabilities, and manage execution, limits, interruption, and telemetry. |
| Workflows | Define explicit coordination among agent, tool, human, and deterministic steps, including ordering, branching, and data flow. | Orchestrate steps, persist progress, pass data between them, and enforce retry, timeout, concurrency, and failure policies. |
| Inference | Declare required model capabilities or profiles. | Select models, hold provider credentials, route requests, enforce budgets, and handle availability policy. |
| Tools and connectors | Declare callable capabilities and the external systems the app expects to reach. | Discover implementations, authenticate and authorize connections, validate inputs, mediate calls, and return typed results. |
| Skills and context | Package or reference reusable instructions, domain knowledge, and context-loading behavior. | Resolve, index, scope, and load the right material into an execution. |
| Memory | Declare persistent memory requirements and the scopes in which memory may be read or written. | Store, retrieve, and isolate memory while enforcing access, provenance, and retention policy. |
| Execution environment | Declare code, filesystem, dependency, network, or isolation requirements. | Provision sandboxes or other logical isolation boundary, constrain resources and egress, collect outputs. |
| Automation and triggers | Define events, retries, or conditions that initiate deferred and scheduled work. | Deliver triggers durably, control concurrency, retry safely, and record outcomes. |
| Artifacts | Define durable inputs and outputs such as documents, files, generated assets, or structured results. | Store content and metadata, enforce access control, manage provenance and lifecycle. |
| Interaction and delivery | Declare human entry points, notifications, approval steps, or supported channels. | Render or route interactions through native clients and connected channels while preserving identity. |
| Configuration and secrets | Define typed configuration and secret requirements without embedding customer values. | Collect and validate values, store secrets securely, and inject them only where authorized. |
Not every app needs every primitive, and not every runtime will support every primitive initially. In order to provide value, this specification needs a small common core plus an explicit way to negotiate additional capabilities.
An app is a graph of resources and references whose edges express dependencies: an agent uses a skill, a workflow invokes a tool, a schedule starts a workflow, and a generated artifact is delivered through a channel.
Resources can come from different places:
The package identifies and references resources using stable logical names. The runtime provider resolves the graph for each installation and maintains the mapping between portable identifiers and provider-native object identifiers.
The app manifest does not reproduce an agent’s logic, framework configuration, dependencies, or deployment procedure. An agent resource instead identifies an immutable implementation package using:
The package format defines how its bytes are interpreted. A portable container format can use an OCI image together with a standard agent invocation contract. Provider-native formats can package concepts such as a managed-agent definition without adding their fields to the core app schema. Implementations built with agent frameworks can be distributed through either kind of format.
Package-relative locations resolve only within the app package. Absolute filesystem paths and file: URIs are not portable package references. External locations remain subject to runtime resolution and admission policy.
The specification does not define container construction or isolation, compute allocation, placement, scaling, warm capacity, or provider deployment topology. Those are runtime and operator concerns. An app may eventually declare portable capability requirements, but cannot commit runtime resources through its implementation descriptor.
See Packaging agent implementations for the canonical OCI package direction and the role of provider- and framework-format adapters.
A runtime provider binding translates the portable contract into a provider’s native concepts.
Bindings must support:
A provider may implement a core resource directly, map it to several native resources, or reject it as unsupported. Provider-specific behavior lives behind declared capabilities and namespaced extensions, validated through conformance testing.
The package describes what constitutes the app and what it requires. The runtime decides how to realize those requirements safely on a target.
The package is responsible for declaring:
The end user operator is responsible for supplying:
The runtime (runtime provider) is responsible for:
A runtime provider must be able to state which resource kinds, versions, behaviors, and limits it implements. An app package must distinguish requirements from enhancements.
Portability includes the following concerns:
Deployment must be convergent (applying the same package and config does not create duplicate resources or untracked side effects.)
App packages may contain untrusted executable code or provider-native definitions, request access to sensitive systems, and cause long-running or autonomous work. The runtime must treat package content as untrusted input while still giving operators enough information to make informed decisions.