The Body Problem

Software agents are getting better at deciding. They are not getting better at operating the physical world.

The modern world was designed around human presence. Addresses, signatures, payments, access control, identity verification, logistics systems, and the appliances already in a home all assume a human body somewhere in the loop. Agents do not fail at these workflows because they lack intelligence. They fail because the infrastructure was never designed for software actors to inherit authority, custody, or physical execution directly.

Governed execution refers to physical actions initiated or coordinated by software that remain inspectable, attributable, revocable, policy-scoped, and persistently recorded across providers and execution environments.

The body problem names the moment an agentic workflow needs a body — someone or something on site to start a washer, change a thermostat, receive a package, unlock a door, or accept custody — and software has no governed way to complete that step.

The industry is solving the body problem with bodies. Humanoids, robots, and humans-for-hire are one answer: put a new actor on site so the world does not have to change. That is not the only answer. The body problem does not require a humanoid. It emerges anywhere software must coordinate everyday products, custody, mobility, or access across infrastructure that already exists.

This is not a rare edge case, and it is not a commerce problem with logistics at the edges. It starts in the home: appliances, locks, climate, and the other products people already own. It then shows up again in mobility, storage, access, and payments that touch atoms.

An agent may know laundry should start, the oven should preheat, or the thermostat should drop overnight. It still cannot issue that command as a governed action on the appliance that already sits in the room. It may successfully purchase medication online, yet still fail to securely receive it. It may reserve transportation without being able to identify the correct passenger. The software run completes; the real-world operation does not.

The body problem is not only presence in space. It is also context — what a run should already know, what field evidence attaches to a handoff or an appliance state change, and what must survive when execution crosses providers. We use three terms throughout: inherited context (mandates, custody, prior grants at action start), multimodal context (scans, location, signatures, telemetry bound to the run), and persistent context (the same item, site, appliance, and policy references for the full governed run). Most stacks still treat all three as prompt stuffing or session-local state.

We use the body problem as an organizing frame for research on execution infrastructure — including protocol work at OpenMatter, but not limited to it. The missing layer is shared standards: a way for intelligence to address, authorize, and complete action on the world as it already exists. Without governed execution and a unified harness for context and proof, “autonomous operations” is a transcript fiction.

The industry still sells autonomy while shipping products that assume a human operator behind the glass. Someone approves, someone signs in, someone starts the washer, someone meets the driver, someone catches the exception.

The market is also beginning to name the gap openly. RentAHuman markets humans-for-hire wired to agents through MCP — accept custody on site, meet couriers, run errands — because the default stack cannot complete those steps alone [1]. Humanoid and robotics programs make the same bet in the home: if intelligence cannot operate the appliances people already own, give it a body that can press the buttons. Both categories treat the body as the integration surface. That is an honest admission of the body problem, not a substitute for governed execution.

Payment rails are advancing on a different axis. At Stripe Sessions 2026, Kaliski et al. walk checkout (UCP) and machine payments (MPP, x402): structured APIs and scoped credentials instead of agents scraping human checkout pages [4]. Stripe’s machine payments documentation describes the same software-metered pattern — per invocation, with protocols such as MPP and x402 settling in USDC or card rails [2]. That improves how an agent pays for API access or a structured checkout session. Commerce is one domain where the gap is visible. It is not the first one. Payment success still does not let an agent buy something for an actor end to end, and it does not let an agent start a dryer or prove the thermostat changed.

Academic research frames the same divide from the modeling side. Fung et al. survey embodied agents — virtual, wearable, and robotic — and argue that world models integrating perception, planning, and memory are central to acting in the physical world [3]. They distinguish agents “instantiated in a visual, virtual, or physical form” from web-based agents that “do not possess embodiment” [3]. That work targets how embodied systems learn and plan. The body problem names what disembodied operational agents still cannot complete across the home, logistics, custody, and human-built infrastructure — unless everyday products become addressable and commandable through shared standards.

Tool use expanded what agents can request. It did not standardize what it means for a physical operation to complete.

Orchestration frameworks chain software tools well. They do not, by themselves, give agents durable identities for appliances and custodied items, scoped authority for a washer or a carrier, or state that survives from dispatch through handoff through completion.

A successful HTTP response is not operational completion. Completion requires the world itself to change state — a cycle started, a lock opened, custody transferred, access granted, delivery received, mobility engaged — and for that state transition to remain attributable to the initiating actor and agent.

World-model work emphasizes multimodal perception inside an embodied agent [3]. Operational agents still need field signals bound to the same run as API metadata — not orphaned in chat. A robot that can perceive a dishwasher is not the same as a standard that lets software command that dishwasher under policy.

We stress-test the body problem with seven exemplar workflows that appear constantly in agent product demos and production roadmaps. The first is the most ordinary: operating the products already in a home. Commerce is later in the list, not the center of it. For each, we ask what the agent can actually execute versus what still requires a human proxy or a new body.

Operating everyday products and appliances.An agent may know that laundry should start, an oven should preheat, a dishwasher should run after dinner, or a thermostat should drop overnight. It cannot issue that command as a governed action on the appliance that already sits in the room. Most home products have no shared identity, no scoped grant a software actor can hold, and no receipt that the cycle started, finished, or faulted. Control still lives in a proprietary app, a panel on the device, or a person standing in the kitchen. Without standards that make everyday appliances addressable and commandable, the agent either stops at “tell someone at home” or waits for a robot body to press the same buttons a human would.

Accepting custody on behalf of an actor.An agent may know that an item is arriving — from a tracking webhook, inventory record, or actor instruction — and that custody should transfer at a specific place and time. It cannot be present at that place: a residence, curbside, retail counter, locker, or facility loading dock. It cannot verify condition, witness the handoff, or accept custody into a governed record on the actor’s behalf. Custody changes are physical events wherever they occur, not only in warehouses. Without an execution surface that represents sites, principals, and handoffs, the agent stops at “notify the user.”

Authorizing an outbound handoff.An agent may draft a release request or fill a form. It cannot meet a carrier at a curb, release items under policy, or bind authority to a specific driver and time window in a revocable, inspectable way. The “authorization” lives in chat or email unless infrastructure carries grants and receipts.

Accessing mobility infrastructure.An agent may call a mobility API and receive a quote or even a reservation ID. It cannot enter a vehicle, confirm the correct passenger, or enforce route constraints in the world. Mobility state often dies when the session ends — the next turn rebuilds context from prompts instead of reading persistent infrastructure state.

Granting physical access.An agent may know that a courier, technician, or guest should enter a building, unit, or locker bank at a specific time. It cannot unlock a door, issue a revocable credential tied to place and policy, or prove who crossed the threshold and when. Access still flows through proprietary apps, SMS codes, or a human with a key — not a governed grant the run can inspect, extend, or revoke.

Completing end-to-end agentic commerce.An agent may find a product, populate a cart, and call checkout APIs. It cannot buy something for an actor without a human proxy at nearly every step: approving or supplying a payment method, confirming billing address, confirming shipping address, and often re-authorizing per merchant. Machine payments and shared payment tokens [2, 4] narrow the software settlement gap; they do not install governed delivery identity, fulfillment proof, or continuity when a different agent resumes the purchase. Context a human entered for one agent does not reliably exist for the next — billing, shipping, and mandate state fragment across sessions and vendors instead of inheriting through a unified execution harness. Commerce makes the gap familiar. It is not the first place the same structure appears.

Persisting context across the workflow.Each exemplar above spans multiple services. Inherited, multimodal, and persistent context should compose for the full run. Instead, an agent may pay via machine payments [2, 4] while still unable to prove which appliance ran, who accepted custody, who authorized handoff, or who was admitted on site — and rebuilds references at every boundary. That amnesia is a body-problem symptom: no unified execution harness for atoms.

Across all seven exemplars, the pattern is the same. The agent produces plausible language and partial software artifacts. The operation remains incomplete until a person, a robot, or a field system closes the gap.

Operating everyday products and appliances.A plan may name the correct washer, oven, or thermostat while the run holds no addressable identity, no scoped grant, and no proof the cycle started, finished, or faulted. Someone is still standing in the kitchen. The agent still cannot command the appliance that already exists.

Accepting custody on behalf of an actor.Custody is ambiguous at every site type. The agent cannot prove what was received on the actor’s behalf, by whom, under which grant, or at which addressable location — whether the handoff happened at home, on a curb, or in a facility.

Authorizing an outbound handoff.Carriers and senders coordinate through ad hoc channels. The agent did not authorize the handoff in a machine-readable, revocable form.

Accessing mobility infrastructure.The agent may hold a reservation reference while the user still stands outside, or the trip diverges from intent with no durable state for the run to recover.

Granting physical access.Entry may happen in the world while the run holds only a message like “code sent” or “ask the front desk.” The agent cannot bind admission to scoped policy, receipt it, or revoke it when the visit ends.

End-to-end agentic commerce.A checkout may clear in demo while the actor’s addresses and mandates stay outside the run. Payment success is not delivery completed. When another agent continues the workflow, shipping, billing, and spend authority are not reliably inherited — the human must proxy the same details again.

Persisting context across the workflow.A later agent turn cannot reliably answer “which appliance ran, which item is under custody, who may authorize release, what mobility was engaged, who was admitted where, and what was purchased for whom at which address?” without re-deriving everything from scratch.

Context dimensions.Inherited and multimodal context fail at provider boundaries: mandates and field evidence drop instead of binding to the execution record, so software cannot reconcile what was authorized with what occurred.

These are not model failures. They are infrastructure failures. The body problem is the correct name for the gap between software intent, physical completion, and context that should travel with both.

The body problem is why agent-native execution cannot mean software-native execution with humans assumed at every handoff — or humanoids assumed at every appliance.

Closing the gap requires shared standards, not a new class of bodies. Protocol primitives composed as one harness: addressable items, sites, and home products; scoped grants for appliance control, handoff, spend, and admission; composed logistics, mobility, access, and the everyday systems already in a residence; the three context dimensions carried with traceability after execution.

Human-in-the-loop copy does not solve the body problem. It documents it. Rebuilding the home around robots documents it in hardware. The design target remains governed execution on the products and appliances people already own — including when a physical step must still be assigned to a person or robot with explicit authority.

Renting humans through marketplaces such as RentAHuman [1] scales the symptom on the physical side. Humanoid programs scale the same bet. Machine payments [2, 4] scale agent spend, not a started wash cycle or custody completion. World-model research [3] advances planning inside a body but does not by itself give operational agents commandable appliances, governed handoffs, or cross-provider state. Verification that payment cleared is not verification that the world changed [4]. None of these alone closes the full gap.

Limitations: this paper defines and illustrates the problem frame. Provider benchmarks and controlled trials across live networks are reported in subsequent company essays and implementation notes.

Agents are incapable of operating everyday products and appliances, accepting custody, authorizing outbound handoffs, accessing mobility infrastructure, granting governed physical access, completing agentic commerce on an actor’s behalf, and carrying inherited, multimodal, and persistent context through a single governed run — not because they lack intelligence, but because the stack lacks shared standards for atoms.

The internet standardized communication between computers. The next infrastructure transition standardizes execution across the physical world — so intelligence can operate the washer, lock, and thermostat that already exist instead of waiting for a body that can press the same buttons.

The missing layer is not intelligence. It is operational continuity between software intent and physical state change.

Naming the body problem sets the design bar: items, sites, and home products addressable; authority explicit; services composable; governed execution with context that inherits and persists. OpenMatter’s protocol catalog is one attempt at that bar; we expect other stacks to pursue overlapping goals in different shapes.

Any product claiming operational agents should be evaluated on the seven exemplars in this essay. If the physical world still depends on invisible human intervention — or a new body — to complete the workflow, the body problem remains unsolved.