| Internet-Draft | Portable Agent Runtime Architecture | November 2026 |
| Raskar | Expires 6 May 2027 | [Page] |
AI agent definitions are commonly coupled to a particular framework, model provider, tool environment, or execution service. This coupling makes it difficult for an independently operated runtime to determine whether it can interpret, place, authorize, and execute an agent workload.¶
This document describes an architecture for portable AI agent workloads across heterogeneous Internet runtimes. It separates authoring, packaging and distribution, and execution; identifies the information a workload needs to declare at that boundary; and distinguishes representation portability, execution portability, and placement portability. It also identifies research questions around capability matching, workload placement, dependency distribution, identity, authorization, state, and migration.¶
This document is architectural and research-oriented. It does not define a package wire format, universal agent language, runtime API, discovery service, or new transport protocol.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
AI agents increasingly execute across user devices, browsers, edge infrastructure, enterprise systems, and cloud environments. Today, the representation of an agent is often meaningful only inside the framework or service that created it. Even when an agent definition can be copied elsewhere, an independent runtime may not know how to interpret its behavior, which model interfaces it expects, which tools and state it requires, or which resource assumptions are essential.¶
The Internet has repeatedly benefited from separating content or workload creation from distribution and independent interpretation. Portable AI agents require a similar separation, but agent execution introduces additional concerns. An agent can invoke models, access private data, use tools, communicate with remote services, and modify state. A portable representation therefore needs to describe requirements without conferring authority to use the requested resources.¶
This document focuses on one architectural question relevant to NET4AI: what must an AI workload communicate so that an independently operated Internet runtime can determine whether, where, and under what authority it can execute that workload?¶
This document defines architectural responsibilities and research questions. It does not define conformance requirements or a wire protocol. Package encoding, signature formats, execution semantics, discovery, and runtime APIs can be specified separately.¶
This document does not define a universal agent programming language, package archive, model API, tool protocol, agent directory, semantic search service, payment mechanism, or inter-agent messaging protocol. It does not guarantee identical outputs across different models or execution environments.¶
The architecture separates three functions: authoring, packaging and distribution, and execution. A single product can implement more than one function, but the separation identifies the interoperability boundary.¶
Authoring Packaging / Distribution
+----------------+ +-------------------------+
| Agent framework| | Portable artifact |
| Workflow / code+------>| behavior + requirements |
| Instructions | | metadata + integrity |
+----------------+ +------------+------------+
|
Internet
|
v
+-------------------------+
| Independent Runtime |
| validate |
| match capabilities |
| choose placement |
| authorize and bind |
| execute |
+------------+------------+
|
+-------------+-------------+
| | | | |
Models Tools Memory Net Compute
¶
The portable artifact is the interoperability boundary between the authoring and execution environments. Placing framework-specific data in a common archive is not sufficient if its semantics remain defined only by the original framework.¶
The author describes intended behavior. The package producer records behavior and requirements. The publisher makes the artifact reachable. A signer can provide cryptographic evidence about content. The Runtime decides what resources can be used under local policy. These roles can be operated by different entities.¶
A workload can request a capability but cannot authorize itself to use that capability. A valid signature can authenticate content relative to a key, but it does not by itself establish that the workload is safe or that access to user resources is permitted.¶
Representation portability means that independent implementations can retrieve, validate, and inspect the artifact and identify its declared execution profile and requirements.¶
Execution portability additionally requires a Runtime to implement the declared Execution Profile and to provide compatible mandatory interfaces. A structurally valid artifact can therefore be unsupported by a particular Runtime.¶
Placement portability means that the same logical Agent Workload can execute in different environments while rebinding its declared requirements to suitable local or remote capabilities. Candidate placements can include a user device, browser, enterprise Runtime, edge node, telecom edge, or cloud service.¶
Placement decisions can depend on latency, data locality, privacy, trust, jurisdiction, available accelerators, model availability, network conditions, cost, energy constraints, and policy. This architecture identifies those factors but does not define a placement protocol or optimization algorithm.¶
A portable workload boundary needs enough information for a Runtime to decide whether the artifact can be interpreted and admitted without first executing untrusted workload logic.¶
The contract can include four categories of information:¶
The exact encoding of these elements is outside the scope of this document.¶
An independent Runtime needs to distinguish three questions:¶
These questions correspond to interpretation, compatibility, and authorization. They have different failure modes and should not be collapsed into a single success or failure result.¶
For model inference, compatibility can depend on structured output, context constraints, tool-call conventions, streaming behavior, or other profile-defined semantics. Binding a different model to a workload does not imply equivalent output quality, latency, cost, or behavior.¶
A publisher can distribute a portable artifact using HTTP or other existing Internet mechanisms. HTTP semantics for retrieval, caching, redirects, and representation metadata are defined by [RFC9110]. A future package specification can define a media type once its wire representation has stabilized.¶
Agent workloads can contain shared dependencies or large immutable components. Content-addressed dependencies, CDN caching, deduplicated retrieval, partial retrieval, and prefetching are therefore relevant research topics. The security model needs to ensure that caching and substitution do not bypass integrity or authorization checks.¶
Placement changes which capabilities are nearby and which data must cross a network boundary. A local Runtime can provide privacy and low-latency access to user data, while an edge or cloud Runtime can provide larger models, accelerators, or enterprise services. A portable workload architecture should make such differences explicit enough for policy and placement systems to reason about them.¶
Moving a workload between Runtimes is more difficult when behavior depends on persistent memory, open sessions, credentials, or external side effects. Portable definition does not imply portable live state. Future work needs to distinguish immutable workload content from mutable execution state and to specify which state, if any, can be checkpointed or transferred safely.¶
Several identities can exist simultaneously and should not be conflated:¶
Different security decisions can require different parts of this chain. This document does not define a universal identity system.¶
This architecture is complementary to, rather than a replacement for, existing Internet and agent interoperability mechanisms. HTTP can transport artifacts. Web Linking [RFC8288] can advertise relationships between resources. Agent communication and tool protocols such as A2A and MCP can be used by an executing workload, but they do not by themselves define how an independently developed Runtime loads an arbitrary Agent Workload for local execution.¶
Software supply-chain transparency mechanisms such as SCITT [RFC9943] can provide provenance and transparency evidence about an artifact. Such evidence is distinct from Runtime compatibility and local authorization.¶
The NET4AI research agenda includes architectural support for AI workloads, distributed AI systems, content distribution, identity, and new security requirements. This document narrows that broader space to portable execution across independently operated Runtimes. It does not attempt to define the broader naming, discovery, messaging, payment, or delegation architecture for all Internet agents. See the NET4AI research group description.¶
The architecture exposes several questions suitable for measurement, experimentation, and further specification:¶
A portable Agent Workload can contain executable code, model instructions, dependencies, and capability requests. Retrieval or successful integrity verification does not establish that the workload is safe to execute. A Runtime needs bounded parsing, dependency validation, sandboxing, and independent authorization for security- relevant capabilities.¶
Model-generated requests and workload instructions are untrusted inputs. A Runtime should mediate tool invocation, network access, storage, credentials, and user data according to local policy. Moving a workload between administrative domains can change its trust context; portability should not silently transfer permissions that were granted only in the original environment.¶
Placement and capability negotiation can themselves leak sensitive information about available models, enterprise tools, location, or policy. Future protocols need to consider selective disclosure, authenticated negotiation, downgrade resistance, and denial-of-service risks.¶
An agent can process personal data, memory, browser context, or enterprise information. Local execution does not necessarily imply local processing because a Runtime can bind inference or tools to remote services. The Runtime should make externally transmitted data and the providers receiving it visible to applicable policy.¶
Placement decisions, capability negotiation, package retrieval, and diagnostic records can reveal user intent or sensitive infrastructure information. Data minimization and retention policies therefore apply to both execution and the control mechanisms surrounding it.¶
This document has no IANA actions. A future package-format or distribution specification can request a media type, Web link relation, or other registrations after stable processing semantics have been defined.¶
This document builds on discussions about portable agents, agent-native execution environments, and Internet support for distributed AI workloads. Feedback from the NET4AI research community is invited.¶