MIT Media Lab

raskar@mit.edu

Network for AI Research Group AI agents portable workloads agent runtimes capability binding placement portability 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.

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 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?

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.

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.

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.

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.

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. | 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.

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.

Three Dimensions of Portability

Representation Portability Representation portability means that independent implementations can retrieve, validate, and inspect the artifact and identify its declared execution profile and requirements.

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.

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.

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.
• 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.

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.

Network Placement and Distribution

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 . 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 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.

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.

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.

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 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 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.

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?

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.

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.

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.

Informative References

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.