The button has been clicked. The command says success. The order still might not exist.

That gap is the most interesting part of Vercel Labs' agent-desktop, a tool for operating native desktop apps through their accessibility trees. Its pitch is easier targeting: read the app's controls, select a named reference, act, then look again. Its more useful promise is narrower: tell the agent what it actually knows about the action.

A successful command is not a finished job

The project's JSON output contract includes a click example with ok: true, delivery marked delivered_unverified, and retry marked unsafe. Those fields belong together. The command reached the delivery stage, but the application effect has not been proved. Clicking again could duplicate it.

The contract distinguishes that case from not_delivered, where retry is safe. Unknown delivery is not permission to repeat the action automatically. A timeout can leave the agent uncertain about whether a write already landed.

That is a better question than "did the tool return an error?" For a purchase, message or save, the next step should depend on evidence of the resulting state. An error can follow a successful action; a clean return can precede an unverified outcome.

The reference has an expiry problem

Agent-desktop is a CLI and C library for macOS, Windows and Linux, not a model that decides the task. The README describes snapshots containing references tied to that particular observation. A bare element number is rejected. If a control has changed or several targets match, the tool can refuse rather than guess.

This matters when a list refreshes between reading and clicking. The agent needs a fresh view and a clear target, not greater confidence in the old reference. The documented loop is observe, act, observe again.

Even observation has a qualification. A snapshot can return ok: true while complete is false because its budget ran out. A partial tree is useful evidence of what was seen, not proof that everything else was absent.

Readback has a boundary, too

Flavio Copes' November 1 guide supplies a concrete example from a reported Ubuntu run: changing a Mousepad text control updated its accessibility value, but did not change the file on disk. That was his test, not ours. It illustrates the distinction the project's contract makes explicitly: verified element state does not prove application-level persistence.

Independent documentation analysis by Harel Asaf also calls out uneven platform support. The README lists Linux mouse input through X11 with headed mode, while macOS shell surfaces remain planned. "Cross-platform" is a support table to inspect, not a promise that every desktop behaves alike.

Try the boundary before trusting the promise

For an evaluation, start with a disposable document and test data. Ask whether the tool can find the control, whether an uncertain write stops blind retries, and whether the saved result survives reopening. These are proposed checks, not tests GigSoul has performed.

The README also warns that snapshots, clipboard reads, screenshots and debug output can contain private desktop content. Better targeting does not make those records safe to publish.

The practical standard is simple: finding the right button, delivering the click and proving the intended result are different jobs. Agent-desktop's documentation makes those differences visible. The agent using it still has to respect them.