Xero is a real accounting product with a real, documented API (an application programming interface, the interface other software uses to talk to a product automatically). You still can’t reconcile a bank statement through that API, and Xero says it has no intention of adding that. Reconciliation is the routine month-end job of matching each line on a bank statement against the invoice or bill already sitting in the books. A practitioner who builds AI automations for a living hit this while automating a client’s bookkeeping: “Xero is a classic example of a really popular app that has really limited integration features. It has an API, but last I checked, there’s very limited features when it comes to actually reconciling your accounts” [1]. His hedge, “last I checked,” undersold the problem. Xero’s own developer platform team has confirmed it: “We will not be adding the ability to reconcile bank statement lines via the API or to expose unreconciled bank statement data via the public API” [2]. In markets such as Australia, this data is treated as banking data under consumer data rights regimes, and Xero has chosen not to redistribute it that way [2]. So the API exists, and under Xero’s current legal and risk framework it will not cover this job [2].
That’s the more common case: a real endpoint, for a popular product, that doesn’t do the one thing you need. We’ll walk through what a developer tries next, in the order they’d actually try it. Then we take on a harder question. Two funded founders gave competing answers to it at the same conference, in the same week. Will the structured half of the web grow enough that a developer rarely needs to read raw pixels at all? Or will the long tail (the millions of small, rarely updated sites that far outnumber the popular ones) keep the top of the ladder load-bearing indefinitely?
Figure 1 - The Ladder a Developer Actually Climbs: Check the API first, then write a deterministic script if the API can’t do the job, then reach for a vision-driven browser agent only when the task needs judgment a script can’t make. Whether that top rung shrinks as the web adds more structure, or stays load-bearing for the long tail, is the argument the rest of this article works through.
Xero has an API that won’t do this job
The first question to ask is whether the API covers the specific task in front of you. Xero’s team settled that one fast. Xero says the reconciliation gap is a stated policy that will stay in place under its current legal and risk framework [2]. There’s nothing to wait for.
The reconciliation still has to happen. Either a person clicks through Xero’s web interface, or something else does what that person would do. That means checking an unreconciled line and finding the invoice or bill it matches. When the amounts don’t line up cleanly, it means splitting a payment across two invoices, and then someone, or something, has to confirm the match before submitting it.
Figure 2 - An API That Exists, and a Job It Doesn’t Cover: Xero’s public API covers the reconciled side of the books: invoices, bills, and already-completed transactions. Bank statement reconciliation sits outside that boundary as a matter of Xero’s own stated policy, tied to its current legal and risk framework.
KEY INSIGHT: Before you automate against a third-party product, check that its API covers the exact task. If the vendor has declined the feature in writing, plan as if it will not arrive.
The obvious next move: write a script
Once the API is ruled out, most developers reach for a deterministic macro or a fixed click-path script next. You hardcode the exact clicks and field entries a reconciliation needs, then replay that sequence on every run. No model runs in the loop, so the script does exactly what it was told, costs the least to run, and behaves the same way every time. For a page that never changes shape, it’s the right choice.
Xero’s reconciliation screen isn’t that predictable. It has to handle partial payments, invoices split across several transactions, and a judgment call about which bill a given line actually belongs to. A fixed script can’t make that call. It will also break once the page’s underlying layout shifts, and most actively maintained web apps change their markup sooner or later.
Figure 3 - Why the Fixed Script Runs Out of Road: A deterministic click-path script works reliably against a page that never changes and never asks for judgment. Reconciliation needs both: it has to weigh a partial payment against a split invoice, and the page it runs against will eventually change shape.
Handing the judgment to a model
The script fails here for a structural reason. All it has is a fixed sequence of coordinates and keystrokes to replay, so it can’t read what’s on the page or decide anything. To get past that, you need something that can look at the page, understand what’s there, and choose an action. That’s a browser-use agent: a model that drives an actual browser session directly.
A browser-use agent can read a page in two structured ways. The first is the DOM (the Document Object Model, the tree of HTML elements a browser builds from a page’s markup). Raw DOM is dense. It’s full of implementation detail nobody ever meant an agent to read. The second is the accessibility tree, a simpler tree the browser already builds alongside the DOM so that screen readers and other assistive tools can describe what a page means without parsing raw markup [3].
There’s a third option. It skips structure entirely. A screenshot-based, or computer-use, agent looks at a picture of the rendered screen and decides where to click, the same way a person does. It’s usually the slowest and most expensive of the three, since a screenshot burns far more tokens than a named tool call [4]. It’s also the only one that still works when a page’s structure gives the agent nothing useful to parse.
Figure 4 - Three Ways an Agent Reads a Page: Raw DOM parsing is dense and was never written for a machine to interpret. The accessibility tree gives a simpler, meaning-first view built for assistive tools. A screenshot works when neither structure is usable, usually at a higher cost in time and tokens.
The judgment rung works, and it’s still weak
On Xero, this rung worked well enough to use. A computer-use model, GPT-6 Astra (OpenAI’s flagship model, launched September 2026 [5]), worked against the Xero web app directly, with only a high-level instruction to reconcile whatever clearly matched. In the practitioner’s own recording, after 10 minutes it had reconciled 7 transactions, including checking existing invoices and bills and splitting a partial payment across an invoice [1]. A fixed script couldn’t have made those matching decisions.
One demo doesn’t prove much. The broader evidence on this rung isn’t reassuring. Cua-Bench is a benchmark built to score computer-use agents against real professional software [6], and Cua, a company that builds computer-use agent tooling, publishes the leaderboard itself [6]. Its electrical-design test set, built against KiCad, a computer-aided design (CAD) tool for drawing circuit schematics, gives the sharpest read on where this rung stands. By Cua’s own current leaderboard, the best frontier agents tested (the most capable current models from the major labs) cleared 6 of 25 schematic tasks, a tie between two of them. Cua’s page adds: “None of the models reliably built a schematic from a blank canvas” [6].
A second account comes from Snorkel AI, which built its own 25-task KiCad benchmark and ran it using Cua’s own evaluation harness and verifier [7]. Snorkel’s run puts one specific frontier model at 4 of 25 full passes and states the blank-canvas result exactly: 0 of 16 tasks that started from nothing succeeded at all. Every recorded pass was an edit to something that already existed [7].
Read those two accounts together, with a caveat. Both come from the benchmark’s own builders, so it’s fair to ask how independent this corroboration really is. The exact pass count depends on which model, which task set, and which snapshot of the benchmark you read, but both land on the same key fact. Every recorded run failed when it had to start from a blank state, with no partial work to build on.
Figure 5 - What a Real Benchmark Says About the Top Rung: On Cua-Bench’s KiCad electrical-design tasks, the best frontier agents tested clear 6 of 25 schematic tasks on Cua’s own leaderboard. In a separate run, Snorkel AI’s benchmark of the same software found 0 of 16 build-from-scratch tasks passed. Every recorded pass in either account was an edit to something that already existed, never a build from nothing.
KEY INSIGHT: Read Cua-Bench as a snapshot of how weak this rung is today, and budget for that weakness. Build in more supervision, smaller tasks, and a human check before anything ships.
Use a browser only where you have to
So reach for the top rung less often. An Oxylabs engineer rebuilt a friend’s broken personal-shopping agent [8]. Each replacement tool in the rebuild is an Oxylabs product, so read the tool choices as a vendor’s own example [8]. He found the original build slow, expensive, and unreliable, and it hit CAPTCHAs (challenges meant to tell a human apart from a bot) constantly. It also applied no geolocation, so items shown as available sometimes weren’t by the time checkout ran [8].
His rebuild matched the cheapest tool to each stage of the task. A search API found candidate pages, and a non-browser scraper checked and validated them. A real, stealth-capable headless browser (a browser with no visible window, driven entirely by code) handled only the one step that needs interactive rendering: the checkout itself [8]. His rule: use a browser only when you absolutely have to [8].
The same discipline applies to Xero. Parts of a month-end close (the accounting work of finalizing a month’s books) are deterministic, like pulling a list of unreconciled lines or checking existing invoices. Those parts can stay on cheaper rungs. Only the judgment calls go to the computer-use agent.
Figure 6 - The Cheapest Tool for Each Stage: A search API handles discovery, a non-browser scraper handles verification, and a real browser is reserved for the one stage, checkout, that structurally needs interactive rendering. The rule: use a browser only when you absolutely have to.
Let the expensive run pay for the next one
The practitioner’s follow-on advice: have that same computer-use run save what it learned. It becomes a named, reusable skill, for example one called reconcile accounts, that a new session next month can pick up [1]. The first time a recurring task runs, the expensive model does the exploring and writes down what it found, and next time a cheaper model follows that written procedure and skips the blank-page exploration.
OpenAI’s GPT-5.6 (Generative Pre-trained Transformer) model family ships in tiers: a flagship model, Sol, and a cheaper, faster mid-tier model, Terra, which OpenAI describes as “a balanced model for everyday work” [9]. The practitioner suggests handing the saved skill to GPT-5.6 Terra, which uses the first run’s skill as its blueprint for the same task later [1].
That first run still carries the Cua-Bench weakness above. What changes is how often you pay full price: once per recurring task, with a cheaper model handling every run after it.
Figure 7 - One Expensive Run, Many Cheap Reruns: The first run of a recurring task uses the frontier computer-use model and costs the most. It writes what it learned as a reusable skill. Every following run on the same task can hand that skill to a cheaper model and skip the exploration cost entirely.
KEY INSIGHT: If a computer-use task will recur, tell the expensive first run to write a reusable skill. That makes the slow, costly exploration a one-time discovery cost.
Two funded founders, two routes onto the web
Every rung above is available today. The harder question is whether the structured half of the web grows enough to make the top rung rare, or whether the long tail keeps it load-bearing indefinitely. Two people with a direct financial stake in their own answer gave competing accounts of how agents should read that web. Both spoke at the same event: AI Engineer World’s Fair 2026, held June 29 to July 2 in San Francisco [10].
Paul Klein IV founded Browserbase, a company that builds infrastructure for browser-driving agents, and raised a $40M Series B (a later-stage venture funding round) in June 2025, about a year before his talk [11][12]. Dhruv Batra co-founded Yutori, a company building a computer-use agent product called Navigator, on a $15M seed round (a first institutional funding round) raised more than a year before his own talk [13][14]. Neither speaker is a neutral observer. Every capability claim either speaker makes below is attributed to the company selling into the exact market the claim is about.
Figure 8 - Two Companies, Two Routes Onto the Web: Browserbase argues for meeting the agent halfway, a web that increasingly exposes structure an agent can read directly. Yutori argues the agent must read the pixels, because the long tail of the web will never add that structure. Both spoke at the same conference.
Klein’s case: the web meets the agent halfway
Klein’s argument is simple. The underlying models are already capable enough, he says. What’s missing is engineering work: better harnesses (the tools, prompts, and control loop wrapped around a model), more reliable infrastructure, and a web that is gradually being built to meet the agent halfway [11]. His first example is already happening: the strongest browser agents read a page’s accessibility tree, the same structure defined above [11].
His second example is WebMCP. Chrome is running a public origin trial for it (Chrome 149 at the time of writing), a program that lets a feature run on real sites before it becomes a finished, stable standard. WebMCP is a proposal inspired by MCP (Model Context Protocol, a standard way for a model to discover and call a service’s tools at runtime). It shares MCP’s vocabulary of tools and schemas, but it’s a separate design built natively for the web page itself [15]. It lets a web page publish its own agent-callable tools inside the page, so an agent can call a defined action directly [16][15]. The specification is a draft report from a W3C (World Wide Web Consortium, the organization that maintains web standards) Community Group. It is not on the W3C Standards Track [17]. Chrome’s own documentation says it is “under active discussion and subject to change in the future” [18]. It works on real sites today. The specification can still change.
Two more implementations already exist. In a demo on the Google Cloud Tech channel, Ugo, a Google Developer Expert, shows a page declaring typed, agent-callable tools in its own JavaScript. That cuts the tokens an agent spends compared to parsing a screenshot or scraping raw HTML [4]. OpenAI also shipped a client-side implementation of a subset of the WebMCP APIs inside Codex and ChatGPT’s built-in browser, and its own documentation says its “site tools” are “ChatGPT’s implementation of the proposed WebMCP standard” [19].
Klein also points to a newer protocol, auth.md. It’s a single Markdown file a site hosts on its own domain. The file tells an agent how to register on a user’s behalf, which flows and scopes the site supports, and how to receive secure, user-scoped credentials, all without a human-facing sign-up form [20].
Klein ends on the long tail too. He closes by pointing at logistics companies, banks, and lumber factories running on PHP sites (PHP is a decades-old server-side scripting language still common on small-business websites), with forms and people clicking buttons every day. That is the market his own browser agents are built for [11].
Figure 9 - A Page Publishing Its Own Tools: Under Chrome’s WebMCP origin trial, a page can declare a typed, callable tool on the page. An agent calls the named tool directly, skipping rendered HTML and screenshots entirely, the mechanism behind Klein’s argument that the web can meet the agent halfway.
Batra’s case: agents have to read the pixels
Batra aims narrower. His argument is about the long tail of the web: “the head of the distribution, the most popular website perhaps, will give you the API, but the long tail will not” [13]. His examples are concrete. A restaurant’s menu can exist only as JPEG (a common compressed image format) files in a photo gallery, with no menu text anywhere on the page [13]. Batra counts roughly 15,000 to 20,000 school districts in the US, then walks through a few of their procurement pages. One publishes solicitations only as scanned PDFs. Another answers a Freedom of Information Act (FOIA) request by scanning the requester’s email and posting it, with PDFs attached, to a Google Drive folder [13].
Even a clean page can defeat an agent that reads markup. An NBA (National Basketball Association) score page or a product’s stock status is often calculated and rendered after the page loads, so there’s nothing static to read [13].
He explains why this part of the web won’t converge on an API: “this information that you are seeing on screen is not written somewhere as pure text. It is calculated. It is rendered… Pixels are the source of the truth because the consumers of the websites are humans. That is what it was built for” [13]. For the long tail, his claim is structural. No engineering effort will get a small school district or a small restaurant to ship a queryable endpoint on any near-term timeline. In his account, vision-driven browser use is the durable, permanent answer for that part of the web.
What the evidence can and can’t settle
Neither side wins outright. Neither has offered a measurement that would settle it, and we won’t pretend to break the tie here. The evidence does settle something narrower and more useful. Whichever account proves right for a given system, the top rung has to work today, on the task in front of you, and Cua-Bench’s numbers already showed how well that goes.
For this quarter, the practical question is narrower still. Does the system you’re automating behave like a modern software-as-a-service (SaaS) product that’s actively shipping accessibility trees and WebMCP? Or does it behave like a scanned PDF in a Google Drive folder that hasn’t changed in a decade?
Figure 10 - The Decision This Quarter: Check whether an API exists and covers the task. If not, try a deterministic script. If the task still needs judgment, use a computer-use agent, then stage it so the browser only runs where it’s required, and save a skill if the task will recur.
Conclusion: what to do this quarter
The Xero example is the shape most automation against a third-party system actually takes: a real API that covers most of what you need and stops short of the one thing you’re trying to do. The ladder under that gap works today: check the API, try a deterministic script, and only then reach for a computer-use agent. The evidence on that top rung says to use it deliberately. Stage it so a browser runs only where the task needs judgment. Have a recurring task’s first expensive run write down what it learns, so the next run doesn’t pay full price again.
You don’t need to know whether the web grows enough structure to make that top rung rare before you make this quarter’s call. Pick the tool that matches the task in front of you. Budget for the top rung’s current weakness. Revisit the decision only when the system you’re automating against actually changes.
References
[1] The AI Automators, “GPT-6 Astra’s Computer Use Is Incredible,” YouTube, Sep 2026. https://www.youtube.com/watch?v=rIb2KXTno70
[2] “Reconcile via the API,” Xero Developer Ideas (UserVoice), response from Xero’s Developer Platform team. https://xero.uservoice.com/forums/5528-accounting-api/suggestions/2884040-reconcile-via-the-api
[3] “Accessibility tree,” MDN Web Docs Glossary. https://developer.mozilla.org/en-US/docs/Glossary/Accessibility_tree
[4] Ugo, “Make Your Website Agent Ready With WebMCP,” Google Cloud Tech, YouTube, Aug 2026. https://www.youtube.com/watch?v=FARxSG_EY98
[5] “GPT-6 Astra: A New Generation of Intelligence,” OpenAI, Sep 2026. https://openai.com/index/gpt-6-astra
[6] “Cua-Bench,” Cua. https://cua.ai/cuabench
[7] “Cua-Bench: benchmarking computer-use agents on professional software,” Snorkel AI. https://snorkel.ai/blog/cua-bench-benchmarking-computer-use-agents-on-professional-software/
[8] G. Šteimantas, “The Missing Layer in Agentic AI,” Oxylabs, AI Engineer World’s Fair 2026, YouTube, Aug 2026. https://www.youtube.com/watch?v=XsvUhpnHepE
[9] “GPT-5.6,” OpenAI. https://openai.com/index/gpt-5-6/
[10] “AI Engineer World’s Fair 2026,” AI Engineer. https://ai.engineer/worldsfair/2026
[11] P. Klein IV, “Bringing Agents Onto the World Wide Web,” Browserbase, AI Engineer World’s Fair 2026, YouTube, Aug 2026. https://www.youtube.com/watch?v=GqoNrUz8hEU
[12] P. Klein, “Browserbase Raises $40M Series B,” Browserbase, Jun 2025. https://www.browserbase.com/blog/series-b-and-beyond
[13] D. Batra, “Computer-Use Models Will Agentify the Web, Not APIs,” Yutori, AI Engineer World’s Fair 2026, YouTube, Aug 2026. https://www.youtube.com/watch?v=Ki980nV0__0
[14] A. Das, D. Parikh, and D. Batra, “Announcing Yutori’s Mission and Seed Funding Round,” Yutori, Mar 2025. https://yutori.com/blog/announcing-mission-and-seed-round
[15] “webmachinelearning/webmcp,” W3C Web Machine Learning Community Group, GitHub. https://github.com/webmachinelearning/webmcp
[16] “Join the WebMCP origin trial,” Chrome for Developers, Jun 2026. https://developer.chrome.com/blog/ai-webmcp-origin-trial
[17] “WebMCP,” Draft Community Group Report, W3C Web Machine Learning Community Group. https://webmachinelearning.github.io/webmcp/
[18] “WebMCP,” AI in Chrome, Chrome for Developers. https://developer.chrome.com/docs/ai/webmcp
[19] “Site tools,” OpenAI ChatGPT Learn. https://learn.chatgpt.com/docs/webmcp
[20] WorkOS, “Auth.md,” WorkOS. https://workos.com/auth-md
Building production AI, or modernizing a legacy system?
That is the kind of work we do at Dotzlaw Consulting. Book a free 20-minute intro call and tell us what you are trying to build, or what is slowing you down.