Can you automate a CRM that has no API?

You can drive it at the screen level. agent-desktop reads the app's accessibility tree and acts on element references, so no vendor endpoint is needed. Reliability still has to be tested on your own app.

What does agent-desktop need to run?

It installs globally from npm, needs Node 18 or later, and runs on macOS, Windows and Linux. On macOS it needs the Accessibility grant, which `agent-desktop permissions --guide` walks you through.

Is a computer-use agent safe to point at customer data?

Not by default. The repo itself warns that snapshots, clipboard reads and screenshots can contain private desktop content, so keep those artifacts out of logs and keep every write behind a human approval.

CRM workflow automation with no API: a 3-hour pilot

CRM workflow automation without a vendor API

agent-desktop reads the accessibility tree of a desktop app and returns it as JSON, with a reference for every element an agent can act on, no screenshots and no pixel matching. The agent clicks a reference, reads the UI again, and repeats. The loop lives in your agent; there is no model inside the tool. It installs globally from npm and needs Node 18 or later.

That matters because the blocker is rarely budget. It is that the CRM on the estimator's desktop has no endpoints and the vendor is not building any.

What this means for a small business

You can test the idea in an afternoon instead of arguing with a roadmap. You cannot conclude the problem is solved. Screen-level control is not a contract that the screen will stay put after the next update, so scope the first pass as one screen with a person approving every write.

The three-hour pilot

The time budgets are my estimates from reading the docs, not from a production run.

Install and grant permissions, about 20 minutes. npm install -g agent-desktop, then agent-desktop status for platform, permissions and supported surfaces, and agent-desktop permissions --guide for the macOS Accessibility grant.
Snapshot one screen, about 30 minutes. agent-desktop snapshot --app <YourCRM> -i returns the interactive elements, each with a reference. Pick the screen that costs the most hand typing.
Script the read-only path, about 40 minutes. Find, get, click, then snapshot again to verify. No writes yet.
Add one write behind a human, about 40 minutes. One field, one record, one confirmation. Hand it to your agent over MCP with agent-desktop mcp if you want the model driving.
Run it twenty times and log every failure, about 30 minutes.
Decide, about 20 minutes: keep, park, or go back to the vendor.

Total: about three hours.

The failure log that decides it

Failure	What it means	Keep going
Reference not found after an update	element ids move when the UI moves	No, add a find-by-name fallback first
A dialog you did not expect	the path has branches you have not mapped	Yes, map the branch
The write landed twice	no idempotency on your side	No, add a check before the write
Nothing happened, no error	the action was not available on that element	Yes, read the available actions first

The threshold I would set: 18 of 20 clean runs on the read path before any write runs unwatched. That is a rule of thumb, not a measurement.

The arithmetic

Use your own numbers. If one person re-types 40 records a day at 90 seconds each, that adds up to about an hour a day. Even at a high success rate you still handle a couple of records by hand, so you buy back most of that hour, minus the time someone spends reading the log. Run that sum before you spend a day on this.

Limitations

The accessibility tree is only as good as the app. Old Windows software with custom-drawn controls may expose almost nothing.
The repo warns that snapshots, clipboard reads, screenshots and debug artifacts can contain private desktop content. Keep them out of shipped logs.
There is no compliance story out of the box. Decide containment before an agent touches your CRM, keep a record of what the agent actually did, and put an approval layer in front of writes.
Speculation: my guess is the first thing to break is a vendor update that renames a field, not the agent.

My take

This removes the excuse, not the work. The honest answer today is pilot, measure, and keep a human on the writes. If the twenty runs are clean, you have a path your vendor was never going to give you.