RevOps teams often need to confirm that two systems agree, for example, that invoices in a vendor portal match records in the CRM, a few hundred at a time before close. That means staying logged into both UIs and paging through every row.
Claude can compare two records it can see. It cannot run that check across a full set of pages on a schedule.
That's a common assumption worth naming directly: "Claude can already do this if I ask it, use Computer Use, or wire an MCP." It can reason about whether two records match. It cannot reliably hold five authenticated sessions open, page through a vendor portal's UI, and repeat that exact sequence tomorrow without drift. Those are two different jobs, and conflating them is where verification work goes sideways.
- Claude is strong at judgment: deciding whether two records match, flagging discrepancies, and drafting the resolution. It has no durable way to stay logged into multiple web UIs across runs.
- Fully agentic Computer Use re-reasons every step, and state-of-the-art Computer Use models produce unexpected or incorrect behavior 20 to 60 percent of the time, depending on complexity. That variance compounds when you're checking hundreds of records against a vendor portal.
- Verification breaks on the boring stuff: SSO redirects, session drift, pagination, layout changes, and silent partial success, not on the reasoning itself.
- The fix isn't dropping Claude. It's letting Claude own intent and judgment while a compiled agent handles login, navigation, and extraction the same way every time.
- Airtop's Agent Builder compiles described workflows into a compiled agent that authenticates to any site behind a login, paginates, and self-heals when a layout shifts, and you can connect Claude Code to your Airtop agents to keep the judgment layer intact.
Where Claude is helpful for verifying records across web UIs
Claude's real strength in this workflow is judgment, not navigation. Give it two records side by side, and it's good at deciding whether "Acme Corp LLC" and "Acme Corporation" are the same account, whether a $4,821.00 line item matches a $4,821 charge, or whether a status field that reads "active" in one system should count as "current" in another. That's a language and reasoning problem, and Claude is built for it.
Claude is also useful for drafting the output of a verification run: a summary of mismatches, a Slack message to the ops channel, an escalation email. Feed it structured findings and it writes a clean report faster than a person would.
Where it diverges is everything upstream of the judgment call. To verify records across web UIs, something has to log into the CRM, log into the vendor portal, find the right record, page through results if there are more than one screen's worth, and pull the fields Claude needs to compare. Claude in a chat window has no persistent browser session. Computer Use gives it a screen to look at, but it re-decides how to click through that screen every single time, with no guarantee it takes the same path twice. Neither one is built to hold state across a scheduled, repeated job. That mismatch isn't a Claude failure. It's a difference between what a reasoning model does well and what authenticated, repetitive browsing requires.
Why verifying records across web UIs breaks
Non-determinism is fine for a one-off question. It's disqualifying for reconciliation, because errors compound across every record you check. If Claude mishandles even a small percentage of individual lookups, and you're running that lookup hundreds of times, you end up with a report you can't trust without re-checking it by hand, which defeats the purpose of automating it.
The specific failure modes show up in familiar order:
- Login and SSO: a session that authenticates fine the first time, then hits a re-auth prompt or a multi-factor step on run three, with no reliable way for a chat session to clear it.
- CAPTCHA and anti-bot checks: vendor portals and financial platforms often gate repeated automated access, and a Computer Use session has no standing mechanism to solve or avoid that.
- Session drift: a session that was valid an hour ago silently expires mid-task, and the model keeps working against a logged-out page without recognizing it.
- JS-rendered content: records that only appear after a script populates the page, which a static read or a mistimed screenshot misses entirely.
- Pagination and infinite scroll: a portal with 200 records across 20 pages, where the model stops at page one or three because nothing forced it to keep going.
- File downloads behind the UI: statements or exports that require a click-through sequence the model has to reconstruct from scratch every run.
- Rate limits and blocks: portals that throttle or block after repeated automated-looking access, ending the session mid-verification.
- Silent partial success: the most dangerous failure mode, where the run reports done, but only checked 40 of 200 records, and nothing surfaces that shortfall.
Any one of these can happen once and get missed. Across a recurring reconciliation job, they happen often enough that you stop trusting the output without spot-checking it manually, which is the exact work you were trying to remove.
Can't we just use Computer Use?
The first Computer Use demo for this kind of task usually works. You watch it log in, click into a record, read a field, and report back, and it feels like the problem is solved. That's a fair reaction. It's also where the hidden cost shows up, because a demo that works once tells you almost nothing about whether it works the same way on run fifty.
Computer Use is fully agentic: it re-reasons its path through the interface on every step, every run. That flexibility is valuable when the task is genuinely novel each time. Verification isn't that. You're running the same check against the same portal, over and over, and you want the same navigation path every time, not a fresh interpretation.
This is the part worth taking seriously: state-of-the-art Computer Use models produce unexpected or incorrect behavior 20 to 60 percent of the time, depending on task complexity. For a repeated reconciliation job, that variance isn't a rounding error. It means a meaningful share of your record checks are wrong, skipped, or silently different from the last run, and you have no built-in way to know which ones without checking by hand.
What works for verifying records across web UIs
The fix is a division of labor, not a replacement. Claude keeps the parts of the job that are genuinely variable: interpreting field values, deciding whether two records match under fuzzy conditions, and writing up what it found. A managed browser runtime keeps the parts that should be stable: logging in, finding the record, paging through results, and pulling the fields in a consistent structure.
That's the same distinction Airtop draws between what should reason once, at build time, then run the compiled artifact and what should stay a live model call. Navigation, clicking, typing, and scrolling compile into code. Reading a page, extracting data from a layout that might shift, and deciding whether two records match stay model calls. You reason through the ambiguity once, at build time, and the compiled steps run the same way on the hundredth pass as the first. This also tends to require fewer reasoning steps, since code-first agents require fewer reasoning steps than JSON-based tool-calling agents, which is part of why the compiled version is faster and cheaper to run at scale.
Concretely, Agent Builder lets you describe the verification workflow in plain English and compiles it into a reusable agent that authenticates to the CRM and the vendor portal, keeps credentials in a secure vault, paginates through every record, and self-heals if the portal's layout changes slightly. If you'd rather start conversationally, you can describe the reconciliation you need in plain English and let Mark handle the build.
Claude stays in the loop as the judgment layer. You can trigger a verification agent directly from your terminal using Claude Code, or connect Claude Code to your Airtop agents so Claude calls the agent, gets back structured records from both systems, and applies its judgment to flag mismatches. This matters most when the records only live in the page itself: most vendor portals and legacy systems have no API for records like these, so browser automation isn't optional. It's the only path in. The same pattern shows up in lead enrichment, where a compiled agent reads from one source and writes everything back to the system of record automatically, and in monitoring work using agents that can be customized to monitor any website, including behind logins.
Record-check use cases that deterministic agents can solve
Verification is a compare job. Claude is good at the compare. The two UIs still need a browser that can open both records the same way every day.
Match a CRM row against a vendor portal
The CRM says one status. The vendor UI says another. Claude can reconcile a pasted pair. It cannot log into both systems on a cadence and return the mismatch table. A compiled agent can.
Confirm a license or registration is still active
Public boards and paid portals change a status without sending you a webhook. A chat checks when someone remembers to ask. A compiled agent checks the same ID list every morning and hands Claude the exceptions.
Re-verify a batch after a data import
Imports go stale the day after they land. Re-reasoning through 200 record pages with Computer Use is the expensive path. Compile the lookup. Let Claude decide which mismatches are real.
Keep a vendor's UI and your warehouse in agreement
The warehouse is not the system of record if the vendor only tells the truth in a grid behind login. Airtop reads the grid. Claude explains the diff in language ops can act on.
Build the check once, run it every day
Verification only earns its keep if it runs the same way tomorrow as it did today, and that's precisely what a chat session or a Computer Use loop can't guarantee. Keep Claude for the part it's genuinely good at: deciding whether two records agree. Let a compiled agent handle the login, the pagination, and the repeat runs, so the reconciliation you build once keeps working without you re-checking its work by hand. Session persistence that survives scheduled runs is the mechanical piece worth understanding before you scale a verification job past a handful of records.
Spin up your first verification agent in five minutes
You don't need to choose between Claude's judgment and a reliable browser layer. Build the compiled agent once, let it log in, paginate, and pull records from every portal you need to check, and keep Claude for deciding what counts as a match. Try it for free and spin up your first agent in five minutes.
FAQs
Can Claude Code verify records across two portals directly?
Not reliably on its own. Claude Code is excellent at the judgment step, comparing two records and deciding whether they match, but it has no persistent way to hold authenticated sessions open in a browser across a scheduled job. The workable pattern is to connect Claude Code to your Airtop agents so Claude sends the request, the agent handles login and navigation, and Claude receives structured data back to reason over.
How is this different from web scraping?
Traditional scraping assumes a static page or an accessible API and breaks the moment a site requires login, renders content with JavaScript, or paginates results. Verification across web UIs almost always involves authenticated portals, which is exactly the case when the records only live in the page itself. A compiled browser agent handles the navigation and session management that scraping scripts typically can't.
What happens when the vendor portal changes its layout?
A hard-coded script breaks the first time a button moves or a field gets renamed. Airtop's compiled agent that authenticates to any site behind a login carries a degree of self-healing, using a small amount of model intelligence to adapt to minor layout drift instead of failing the whole run.
Can I keep Claude in the loop for the judgment calls?
Yes, and that's the intended split. The compiled agent does the stable work: login, pagination, extraction. Claude does the variable work: deciding whether two records match. You can trigger a verification agent directly from your terminal and let Claude apply judgment to whatever the agent returns.
Why not just use Computer Use for everything, including the navigation?
Because it re-reasons its path every run, and state-of-the-art computer use models show unexpected or incorrect behavior 20 to 60 percent of the time depending on complexity. For a one-off task that variance is tolerable. For a recurring reconciliation job across hundreds of records, it means a meaningful share of checks are wrong or silently skipped, which is disqualifying.
How do I handle logins and MFA for verification jobs that run on a schedule?
This is one of the more common failure points in Claude-only setups, since chat sessions and Computer Use loops have no standing mechanism to persist credentials or clear re-auth prompts. It's worth understanding session persistence across scheduled runs before scaling any verification job past a handful of records.
What if I don't want to write the automation myself?
You don't have to. You can describe the reconciliation you need in plain English and get a working agent built from that description, rather than hand-coding navigation logic for each portal you need to check.
Does this approach only work for CRM-to-portal checks, or does it generalize?
It generalizes to any scenario where you're comparing records across two or more authenticated web sources: invoices against bank statements, leads against LinkedIn, inventory against a supplier portal. The same compiled-agent-plus-judgment pattern shows up in adjacent work like lead enrichment, where an agent writes everything back to the system of record automatically, and in monitoring, where agents that can be customized to monitor any website, including behind logins run the same underlying checks.
