The tools an agent can actually use

A spray bottle is designed around a human hand. Its handle, trigger and centre of gravity assume a particular grip. Cleaning with it feels like one task because we already have the body and experience its designer expected.

Give it to a robot and the assumptions become problems to solve. Hold the container. Squeeze the trigger. Aim the spray. Check what happened. We can try to improve the robot at every step. We can also ask whether it needs a different dispenser.

That second question interests me because it changes where the difficulty lives. Some of the intelligence apparently required by a task belongs to the interface through which we ask it to be performed.

The environment does part of the work

Coding agents have a useful environment. They can read files, make edits, run commands and inspect outputs. A change leaves an artifact that can be compared with an earlier version. Many actions can be repeated in a fresh checkout. Some failures announce themselves through a syntax error or a failed assertion.

Those conveniences do not make programming fully verified. A program can compile and implement the wrong requirement; a passing test can omit the case that matters. But the environment gives an agent observations it can use to revise its work.

A household task may be less repeatable and harder to undo. A clean-looking surface is a different kind of evidence from a passing assertion, and neither answers every question about success. Moving from a coding demonstration to another domain means rebuilding much of that relationship between action and feedback.

The same issue appears within software. Imagine a service available only through a visual form. An agent must locate controls, infer their meaning and decide whether a click succeeded. An API can expose the operation, accepted inputs and result directly. Permissions and error handling still matter, but the agent no longer has to reconstruct the operation from its visual wrapper.

Adaptation has a cost too

It is tempting to follow this argument all the way to a world redesigned for robots. A dispenser matched to an actuator could demand less dexterity. Tools could expose controls that machines operate more reliably.

But homes remain shared human environments. Replacing ordinary objects costs money, disrupts existing habits and can make things less accessible to people. A robot that needs every object replaced has transferred much of its work to its owner.

The useful question is which adaptations save enough difficulty to justify that cost. ALOHA 2 treats hardware and environment as part of the research problem, changing grippers, cameras and the workcell alongside teleoperation. Capability depends on this whole arrangement, rather than on the model alone.

Feedback needs an address

PCB design offers a more structured example. An agent needs access to the schematic and board, ways to change them, and checks whose findings identify the relevant parts of the design.

KiCad documents electrical checks in its schematic editor and physical design checks in its board editor. A clean report covers those rules; it does not prove that a device will perform every intended function. Still, a finding tied to a component or connection gives the agent something specific to inspect and correct. A picture alone leaves much of that information implicit.

Learning also needs observations from the domain. The Open X-Embodiment project brings together physical-interaction datasets from different robots and institutions, exploring how experience can transfer between them.

This makes predictions about general intelligence less useful to me than questions about the next workable interface. What can the agent observe? What can it change? How will it know whether the change helped? Better models can expand the answers, but designing the tools is work we can already do.