A mind discovers its body by moving it, failing, and trying again. An AI agent
controlling physical devices can do neither half of that — which is why the
device has to introduce itself, and why nobody quite agrees on what that
introduction should contain.
You did not learn what your hand does by reading a specification. You spent
about a year dropping things.
Somewhere in that year you worked out that the hand grips, that grip has degrees,
and that a glass held too loosely falls while one held too tightly breaks. Nobody
told you. It arrived through use, through failure, and through a sense that
reports for free, all the time, on where your limbs are and what they touch.
An AI agent connected to a building full of devices has none of that.
It cannot feel that a camera is there. There is no perceptual channel by which a
language model discovers a temperature sensor in the next room the way you
discover your own foot. And more importantly, it cannot afford the other half
either. A mind learns a lock by trying the lock. An agent that tries a lock
has unlocked a door — that is not an experiment, that is an event, and it may be
the wrong one at three in the morning.
So the discovery route is closed at both ends. Which leaves exactly one option:
the device has to say what it is.
That is what a manifest is. Not a convenience, not a config format. It is a
substitute for a developmental process that cannot happen. And once you frame
it that way, the interesting question stops being what format and becomes
what does the introduction have to contain for a mind that will never get to
find out by hand.
What most systems declare
Almost every attempt at this — and there are several serious ones now — answers
the same layer: what the thing can do.
A lock exposes lock and unlock. A light exposes turn_on and a brightness
parameter with a range. A thermostat exposes a target temperature in degrees. It
is the layer that maps most cleanly onto function signatures, which is probably
why it is the one everyone builds first.
It is also genuinely necessary, and it is more than a name. A hand that "grips"
is useless information; a hand that grips with a force between zero and forty
newtons is something a mind can plan with. Types, ranges, units. That layer is
mostly solved, and where it isn't, it's an implementation gap rather than a
conceptual one.
But it is not enough, and you can see why with a thought experiment that has
nothing to do with software.
The layer nobody writes down
Suppose I hand you a tool you have never seen. I tell you it has a lever, that
the lever has two positions, and that moving it takes about two newtons.
You now know exactly what it can do. You still have no idea whether to touch it.
What you are missing is not capability. It is consequence: is this reversible?
If I move the lever and I was wrong, can I move it back? Or have I just done
something that stays done?
Your hands know this about the world and the knowledge is not in the joints. You
handle a glass differently from a rock, and the difference is not grip strength —
it is that one of them is unrecoverable. You learned that by breaking a glass.
A device declaring lock and a device declaring turn_on look identical at the
capability layer. One of them, done wrong at the wrong hour, leaves someone
outside their own house. The other is a light you turn off again. Nothing in
the interface distinguishes them, and an agent reasoning only from capabilities
has no way to be more careful with the first than the second.
And the layer that isn't about the device at all
There is a third thing, and it is the one I find hardest to place.
Knowing what a hand does, and knowing that a broken glass stays broken, still
does not tell you when reaching for something is the right move. That
judgement is not a property of the hand. It comes from the situation.
The same is true of devices, and it produces a problem that manifests handle
badly. A manufacturer can truthfully declare that their product opens and closes.
They cannot declare that it is the door of an operating theatre, or that it
matters during an evacuation, or that this particular one should never be touched
automatically because of what is behind it. That is not information about the
product. It is information about the deployment, and it is known only by whoever
installed it.
When those two get written into the same field — and they usually do, because
it's convenient — something predictable happens. Ask an installer "could this
device matter in an emergency?" and the honest answer for a light is yes. For a
temperature sensor, also yes. For nearly everything, yes. The question invites a
universal affirmative, and a field where almost everything is marked relevant
tells the agent nothing at all.
The question the system actually needs is a different one: not could this
participate, but should it. Those look similar and they behave nothing alike.
Where the analogy breaks, and why that's the point
Bodies do not have this problem, and it is worth being precise about why.
Your hand never declared anything to you. You have no manifest. What you have is
a decade of continuous feedback and permission to be wrong about small things
until you stopped being wrong about them. The analogy holds right up until that
observation and then falls apart completely — a mind and its body co-develop,
and an agent and a device do not.
I don't think that weakens the comparison. I think it locates the actual
engineering problem. Everything a manifest has to carry is there precisely
because the loop that would otherwise teach it is unavailable, for reasons that
are not going away. The perception gap is technical and might narrow. The
prohibition on experimenting with locks and industrial machinery is not
technical, and it should not narrow.
The open question
I don't have a clean answer, and I am suspicious of anyone who presents one,
because these three things are declared by three different parties who never meet:
- The manufacturer knows what it does and what it costs to be wrong
- The installer knows where it is and what it must never touch
- The situation decides which of them matters right now
Most designs I've looked at, including my own, collapse at least two of those
into one field and then wonder why the result is either too permissive or too
brittle.
So the question I'd put to anyone building in this space: what is the minimum a
device must declare so that an agent can act on it correctly without ever having
been allowed to experiment on it? Not the maximum — the maximum is easy and
nobody fills it in. The minimum.
I've been trying to make this concrete in
DoSync (an open protocol I maintain). The practical
version of the question there is more specific and more annoying: I have a field
doing all three jobs at once, and measuring it made clear that it does none of
them well. Which is roughly where the conceptual problem stops being conceptual.
If you've built something in this space and landed somewhere different, I'd
genuinely like to know where.
GitHub: github.com/giulianireg-spec/dosync-protocol
Web: https://dosync.dev/
License: Apache 2.0
DoSync — the semantic layer between AI agents and physical systems.
Top comments (2)
Well, it depends. If you want an AI to never break a thing, you expose all the tools, but you guard the tool execution, behind a user's approval. That way before it can trigger 'light_on', the user has to explicitly tell the tool layer 'it's okay, let them try it'. That's pretty much how all agentic platforms work, you guard the tool, not the user. That way dangerous tasks have a human's sign off.
My theory is that if a tool is self-declaring, so the LLM can understand the outcome, before they trigger it, they're less likely to click the kill switch and more likely to click the try switch, because they do have a decent understanding of risk aversion to a degree (usually thanks to the harness), but overall, it learns more from failing and succeeding, if it tries to hit the kill switch and you deny it at a tool level and it gets a 'denied' response back from the tool, it understands the boundary. It'll only ever try that boundary again if explicitly told, or absolutely necessary. Eg. tell a LLM to push to git. It calls the git MCP tool, it gets denied by user, so it knows push wont work that way and would explain itself to the user to get clarity on what method they should have used, if that's the fastest immediate path. If the user says try a different way, it'll look for git cli, or after that, try to download git cli and execute through there, or worst case scenario, open a browser and do it manually. All fair workarounds, because it's testing a boundary, to see if it's a little wall blocking a single path, or if it's a fence.