That's a bold claim. But I genuinely feel like I might have actually solved computer use (demo: https://x.com/mdlahfir/status/2088109763783700827?s=20)

For context, I've been building agent-desktop (Inspired by agent-browser by Vercel Labs), an automation CLI for desktop apps. It's like Playwright but for desktops, not just native, but for Chromium apps as well. Trust me, yes, Chromium apps whose accessibility tree is dense.

MacOS is GA; I'm almost close to launching for Windows and Linux!

So, how did I solve it?

Basically interoperability.

The biggest issue with computer use is that we have reliable frameworks for browser use, like Playwright, agent-browser, and many more, but not the same with desktops.

We have really good solutions emerging, like tryCua, which I'm a big fan of. My vision with agent-desktop is to build the most reliable framework that agents can use for long-horizon tasks.

agent-desktop is lightweight, built on Rust, fast, and not token-hungry (It can go for hours without exceeding the context window)

Here's the approach I used to make it possible:

a) skeleton snapshots - when you want to snapshot a window/app, it only snapshots the parent containers and gives back a ref id, not the entire accessibility tree.

b) skeleton drilling - once the agent has that tree, it can then decide to drill into a specific region. All the subcommands like --find, --click, --wait... all work on that specific ref aware region. Meaning if you want to find an element in the entire app, it doesn't take forever searching for the entire app for that element; rather, the agent will have an exact clue on where that element might be for a fraction of the token costs.

c) chained interaction fallback - a single click isn't one API call but it's an ordered chain of mechanisms (AXPress -> AXOpen -> activate through the inner cell -> write selection -> AXConfirm). Each step only runs if the element advertises it, and success is judged by watching the app's state change, not by the return code, because apps lie in both directions: Finder returns an error for an action that worked and success for one that did nothing. First observed effect wins. The response reports every step tried, so the agent knows exactly which mechanism landed.

d) after-action feedback - every action reports its disposition (delivered and verified, delivered but unverified, not delivered) plus any surface that opened (dialog, menu, sheet), so the agent knows what happened without re-scanning the whole app.

e) strict ref re-identification - a ref isn't a pointer; it's identity evidence (role, path, stable text, bounds hash). Before every action, it's re-resolved against the live UI. If the UI changed, you get STALE_REF; if two elements now match, you get AMBIGUOUS_TARGET. It never guesses.

The most important part about all this is Chromium app accessibility. How did I do it? The magic word is CDP!

Most desktop apps today are Chromium-based (Slack, VS Code, Obsidian, Discord...). One command launches the app with a CDP endpoint that agent-desktop verifies is actually answering before returning it. From there, any browser automation framework can connect and drive the web contents: Playwright, Puppeteer, agent-browser, whatever you already use. Reading Obsidian's web content over CDP takes 201ms vs 2.3s through the accessibility tree.

$ agent-desktop launch "Obsidian" --cdp

  { "ok": true, "data": {
    "renderer": "chromium",
    "cdp": { "port": 57500,
             "http_endpoint": "http://127.0.0.1:57500",
             "websocket_url": "ws://127.0.0.1:57500/devtools/browser/..." },
    "suggestion": "Next: run `agent-browser connect 57500` ..." } }

This is what makes agent-desktop interoperable with the entire browser automation ecosystem instead of competing with it.

Go try agent-desktop -> https://github.com/lahfir/agent-desktop