Why we don't use Computer Use
Screen-scraping agents look magical in demos and fail at production. We made a deliberate bet on first-party APIs for every integration — here's the reasoning and where it's already paying off.
Every week someone asks why we don't ship agents that use Anthropic's Computer Use, OpenAI Operator, or the various Claude-for-Chrome wrappers. The demos are spectacular — a screen recording of an agent booking a flight or filling a spreadsheet feels like the future.
We've tested all of them. We're not shipping any of them. Here's why.
Demos hide the failure modes
Screen-scraping agents need to recognize UI elements by pixel pattern or DOM accessibility tree. This works 95% of the time in a demo and 60% of the time in production. The 40% that breaks is: modals you didn't expect, A/B tests, session timeouts, anti-bot CAPTCHAs, ad blockers collapsing a sidebar, dark-mode variants, responsive breakpoints.
A service shop owner doesn't want an agent that "works most of the time." They want an agent that either works or tells them it can't, cleanly. First-party APIs give us that. Screen scraping doesn't.
The latency tax
Computer Use agents take 8–15 seconds per step because each action requires a screenshot, model inference, coordinate calculation, and another screenshot. An API call is 50–200 ms. For Frontline — which we hold to a 28-second response SLA — there's no budget for screen-scraping detour.
Compliance is impossible
Many of our customers are in regulated verticals (med spa, HVAC with EPA 608, auto with state DMV integrations). When an agent does something wrong via screen scrape, there's no audit trail that satisfies a regulator. With API integrations we have request IDs, timestamps, response bodies — full forensic reconstruction of every decision.
What we do instead
Every Mosco integration is a direct API partnership: Twilio, Meta Graph API, Google APIs, Housecall Pro, Zoho CRM, Stripe, Monday.com. When we want a new capability (say, ServiceTitan support in Q2), we wire a new Python module — not a new browser-automation recipe.
It's slower to build but faster to ship reliably. And when an integration's API doesn't support what we need, we don't paper over it with screen scrapes — we either partner for new endpoints or mark the feature as out of scope and say so on the site.