Architecture for Portable AI Agent Workloads Across Internet Runtimes
draft-raskar-portable-agent-runtime-architecture-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Ramesh Raskar | ||
| Last updated | 2026-11-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-raskar-portable-agent-runtime-architecture-00
Network for AI Research Group R. Raskar
Internet-Draft MIT Media Lab
Intended status: Informational 2 November 2026
Expires: 6 May 2027
Architecture for Portable AI Agent Workloads Across Internet Runtimes
draft-raskar-portable-agent-runtime-architecture-00
Abstract
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.
Status of This Memo
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.
Raskar Expires 6 May 2027 [Page 1]
Internet-Draft Portable Agent Runtime Architecture November 2026
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architectural Model . . . . . . . . . . . . . . . . . . . . . 5
3.1. Trust Boundaries . . . . . . . . . . . . . . . . . . . . 5
4. Three Dimensions of Portability . . . . . . . . . . . . . . . 6
4.1. Representation Portability . . . . . . . . . . . . . . . 6
4.2. Execution Portability . . . . . . . . . . . . . . . . . . 6
4.3. Placement Portability . . . . . . . . . . . . . . . . . . 6
5. Portable Workload Contract . . . . . . . . . . . . . . . . . 6
6. Capability Matching, Binding, and Authorization . . . . . . . 7
7. Network Placement and Distribution . . . . . . . . . . . . . 7
7.1. Distribution . . . . . . . . . . . . . . . . . . . . . . 7
7.2. Placement . . . . . . . . . . . . . . . . . . . . . . . . 8
7.3. State and Migration . . . . . . . . . . . . . . . . . . . 8
8. Identity Considerations . . . . . . . . . . . . . . . . . . . 8
9. Relationship to Existing Work . . . . . . . . . . . . . . . . 8
10. Research Questions . . . . . . . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
14. Informative References . . . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
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
Raskar Expires 6 May 2027 [Page 2]
Internet-Draft Portable Agent Runtime Architecture November 2026
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?
1.1. Scope
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.
1.2. Goals
* Separate agent authoring from portable workload interpretation and
execution.
* Let an independent runtime determine whether it supports the
workload's execution semantics and required capabilities.
* Allow model, tool, memory, compute, and network resources to be
supplied by the runtime rather than fixed by the authoring
framework.
* Keep capability requirements distinct from authorization grants.
* Support reasoning about execution on devices, edge systems,
enterprise infrastructure, and cloud runtimes.
1.3. Non-Goals
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.
Raskar Expires 6 May 2027 [Page 3]
Internet-Draft Portable Agent Runtime Architecture November 2026
2. Terminology
Agent Workload:
A representation of agent behavior together with the metadata,
resources, dependencies, and execution requirements needed for an
independent runtime to evaluate it.
Authoring System:
A framework or tool that creates or transforms an agent
definition.
Portable Artifact:
A distributable representation of an Agent Workload that can be
retrieved and inspected independently of the original authoring
system.
Execution Profile:
An identified specification that defines how a runtime interprets
the behavior representation, entry point, model and tool
interfaces, state, and errors of an Agent Workload.
Runtime:
An execution environment that retrieves and evaluates a portable
artifact and, if compatible and authorized, executes the Agent
Workload.
Capability:
A function or resource offered by a Runtime, such as model
inference, tool invocation, storage, network access, user
interaction, or bounded computation.
Capability Requirement:
A workload declaration describing a capability or constraint
needed for execution. It is not an authorization grant.
Binding:
An association selected by the Runtime between a declared
Capability Requirement and an available implementation.
Grant:
Authority established under local policy for a specific operation
or resource.
Placement:
The selection of an execution environment or network location for
a workload instance.
Raskar Expires 6 May 2027 [Page 4]
Internet-Draft Portable Agent Runtime Architecture November 2026
3. Architectural Model
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.
3.1. Trust Boundaries
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.
Raskar Expires 6 May 2027 [Page 5]
Internet-Draft Portable Agent Runtime Architecture November 2026
4. Three Dimensions of Portability
4.1. Representation Portability
Representation portability means that independent implementations can
retrieve, validate, and inspect the artifact and identify its
declared execution profile and requirements.
4.2. Execution Portability
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.
4.3. Placement Portability
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.
5. Portable Workload Contract
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:
* *Identity and description:* workload identifier, version,
publisher assertions, and human- or machine-readable description.
* *Behavior representation:* the executable or declarative
definition, an entry point, and an identified Execution Profile.
* *Requirements and resources:* model interfaces, tools, state,
dependencies, network requirements, compute limits, and other
mandatory capabilities.
Raskar Expires 6 May 2027 [Page 6]
Internet-Draft Portable Agent Runtime Architecture November 2026
* *Integrity and provenance:* digests, signatures or equivalent
authenticated statements, and references used by local trust
policy.
The exact encoding of these elements is outside the scope of this
document.
6. Capability Matching, Binding, and Authorization
An independent Runtime needs to distinguish three questions:
1. Can the Runtime interpret the workload's Execution Profile?
2. Can the Runtime supply implementations compatible with the
mandatory Capability Requirements?
3. Does local policy authorize the workload to use those
capabilities for this execution?
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.
7. Network Placement and Distribution
7.1. Distribution
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.
Raskar Expires 6 May 2027 [Page 7]
Internet-Draft Portable Agent Runtime Architecture November 2026
7.2. Placement
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.
7.3. State and Migration
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.
8. Identity Considerations
Several identities can exist simultaneously and should not be
conflated:
* the identity of the human or organization that delegates work;
* the logical identity of the agent;
* the identity or digest of a particular portable artifact;
* the identity of the Runtime executing it; and
* the identities of model, tool, and service providers bound during
execution.
Different security decisions can require different parts of this
chain. This document does not define a universal identity system.
9. Relationship to Existing Work
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.
Raskar Expires 6 May 2027 [Page 8]
Internet-Draft Portable Agent Runtime Architecture November 2026
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
(https://datatracker.ietf.org/group/net4ai/about/).
10. Research Questions
The architecture exposes several questions suitable for measurement,
experimentation, and further specification:
* What is the smallest useful capability vocabulary that allows
independent Runtimes to reject incompatible workloads before
execution?
* Which model-interface properties need standardized description,
and which should remain profile-specific?
* How should placement systems compare latency, privacy, data
locality, trust, cost, energy, and accelerator availability?
* How can immutable workload content and dependencies be cached and
deduplicated safely across the Internet?
* Which identities and attestations are necessary to establish
provenance without coupling execution to a single platform?
* How should authorization grants be represented and mediated when
workloads move across administrative domains?
* Which portions of agent state can be checkpointed or migrated
without changing workload semantics or leaking sensitive data?
* What benchmarks and testbeds are needed to measure portability
across device, edge, enterprise, and cloud Runtimes?
Raskar Expires 6 May 2027 [Page 9]
Internet-Draft Portable Agent Runtime Architecture November 2026
11. Security Considerations
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.
12. Privacy Considerations
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.
13. IANA Considerations
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.
14. Informative References
[RFC9110] Fielding, R., Nottingham, M., and J. Reschke, "HTTP
Semantics", RFC 9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
Raskar Expires 6 May 2027 [Page 10]
Internet-Draft Portable Agent Runtime Architecture November 2026
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, October 2017,
<https://www.rfc-editor.org/rfc/rfc8288>.
[RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", RFC 9943, June 2026,
<https://www.rfc-editor.org/rfc/rfc9943>.
Acknowledgements
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.
Author's Address
Ramesh Raskar
MIT Media Lab
Email: raskar@mit.edu
Raskar Expires 6 May 2027 [Page 11]