Every RevOps or finance ops team has one of these rituals: log into a vendor portal, click through two or three screens, find the right PDF or CSV, and download it before the weekly sync. Someone eventually asks Claude to handle it. The first attempt looks promising in a chat window or a Computer Use demo. Then the portal redraws its layout slightly, the session expires, and the download either fails silently or grabs last week's file. Teams end up back where they started, downloading reports manually while the automation sits unused.
- Claude reasons well about a report's content, but it isn't built to hold a session, manage credentials, or repeat a click path the same way every run.
- Portals resist naive automation on purpose: logins, MFA, JS-rendered tables, and download buttons wired behind scripts all break chat-based or Computer Use approaches.
- Fully agentic automation that improvises live re-solves the same navigation problem every run, which is slow, costly, and inconsistent for a task that never changes.
- Computer Use models show incorrect behavior across a wide range of runs on complex tasks, which is a real problem when the report has to land every morning.
- The fix is splitting the job: a compiled agent handles login, navigation, and the download deterministically, while Claude reads and reasons about what the report says.
Where Claude is helpful for downloading reports behind portals
What Claude is genuinely good at
Claude is excellent at reasoning about a report once you have it. Feed it a downloaded PDF and ask what changed since last month, which accounts are trending down, or how to phrase a summary for leadership, and it delivers. That's judgment work: interpreting numbers, drafting language, deciding what's worth flagging. None of that requires a browser.
What a portal download requires
Downloading a report behind a portal is a different category of problem. It requires authenticating, holding that session, navigating a specific click path, waiting for a JS-rendered table to load, triggering the download event, and confirming the right file landed. None of that is a reasoning task. It's a repeatable, mechanical sequence that has to behave the same way every time it runs. Claude was built to think about content, not to manage a browser session across a week of scheduled runs.
Why portal report downloads break in Claude-only workflows
No persistent session or credential vault
Claude doesn't retain a logged-in browser session between conversations, and storing credentials in a chat thread or MCP call isn't a real security posture. Portals expect a session cookie or token that survives past a single interaction. Without a durable session layer, every run starts from a cold login, which is exactly where things go wrong: MFA prompts, "verify it's you" emails, or a login form that renders differently than the model expects.
Non-determinism compounds across scheduled runs
A single successful download doesn't mean the next one will look the same. Language models are non-deterministic by design, so the same instruction can produce a different click sequence or a different interpretation of "the latest report" from one run to the next. That's tolerable for a one-off task. It's untenable for something that has to run identically every night, which is the entire point of a recurring report pull.
Portals resist naive automation by design
Vendor portals, client extranets, and legacy dashboards are frequently the kind of surface where browser automation beats an API-based approach, precisely because there's no API to call. That also means the data sits behind logins, JS-rendered content, pagination, and download buttons that fire only after a script executes. A chat model asked to click the download button has no persistent way to confirm the file saved, or to notice a silent partial success where the page loaded but the export never triggered.
Can Computer Use handle report downloads instead?
Why Computer Use models look like the answer
Computer Use looks like the natural next step. Claude can see a screen, move a cursor, and click buttons, so the first demo of logging into a portal and grabbing a file often works. Watching it happen feels like the problem is solved.
The failure modes at scale
The trouble shows up on the second, tenth, and hundredth run. Even the most capable Computer Use models produce incorrect behavior 20 to 60 percent of the time, depending on task complexity. A portal login with MFA, dynamic menus, and a download trigger buried behind JavaScript sits squarely in that complex range. Computer Use sessions also run one at a time, cost more in tokens per run than a compiled path, and take noticeably longer to complete each cycle. That's extra agency helping the first run more than the hundredth, which is exactly backwards from what a recurring report pull needs.
What reliable portal report retrieval needs
Compile the retrieval once, keep Claude for judgment
The workable pattern splits the job. A compiled agent that authenticates to any site behind a login handles the mechanical steps once, then runs that exact sequence like software from then on. Claude keeps the part it's good at: reading the downloaded report and deciding what it means.
What a working pipeline looks like
Airtop stores credentials in a secure vault rather than a chat transcript, runs on a schedule or a trigger, navigates the portal's actual DOM, and downloads the file. If the portal shifts a button or renames a menu item, broken runs heal themselves instead of failing outright. The report lands in a known location, and Claude picks it up from there for summarization or drafting. That's deterministic AI that compiles the workflow instead of re-reasoning it every time it runs.
Orchestrating from Claude Code
Teams that live in Claude Code don't have to leave it. You can run Airtop agents directly from Claude Code, letting Claude stay the interface for planning and analysis while Airtop owns the portal work behind the scenes. This also tends to mean code-first agents that need fewer reasoning steps than LLM-per-step agents, which shows up directly in lower token cost per run. You can also describe the report workflow to Mark in plain English if you'd rather skip the coding layer entirely.
Portal-download use cases that deterministic agents can solve
Vendor portals hide the file behind login, a date range, and a download button that is not an API. Claude can read the report. Retrieving it is a compiled browser job.
Fetch the weekly vendor PDF on Monday morning
The file is always in the same menu, after the same login. Asking Claude to fetch it starts a new Computer Use loop, including MFA theater. A compiled agent signs in, hits download, and stores the file. Claude summarizes what changed.
Pull invoices or usage exports from a billing portal
Finance does not want a different CSV shape each month. Chat-driven retrieval drifts. A compiled path returns the same columns, and Claude flags line items that look off.
Collect campaign reports from an ad or analytics login
Some useful exports still live in a UI, not in a warehouse. Claude can interpret ROAS once the sheet exists. Getting the export on a schedule, without someone clicking through the wizard, is Airtop's part.
Archive compliance PDFs before a portal purges them
Portals rotate statements and attestations. A chat will not remember to grab last quarter. A compiled run can, with a replay of the session if audit asks how the file was obtained.
Split the job: Claude reasons, Airtop retrieves
Claude isn't the wrong tool for reports behind portals. It's the wrong tool for the login, the click path, and the download trigger. Keep Claude for interpreting what the report says, and hand the mechanical, repeatable half to a runtime that authenticates, clicks, and downloads, or start building your first agent and stop re-solving the same portal login every week.
Stop babysitting portal logins every morning
If a weekly report pull still depends on someone manually logging into a portal, or a Claude session that breaks the moment the layout shifts, it's worth handing the mechanical half to something built to run it the same way every time. Try it for free and spin up your first agent in five minutes.
FAQs
Can Claude Computer Use log into a portal and download a PDF?
It can on a good run. Computer Use models can see a screen, click a login button, and trigger a download, so a single demo often succeeds. The problem is consistency: the same research showing they produce incorrect behavior 20 to 60 percent of the time applies directly to multi-step portal flows with MFA and dynamic menus, which is exactly the complexity range where failures cluster.
Why does my Claude-based report download work once and then fail?
Because nothing about a chat-based or Computer Use run guarantees repeatability. Language models are non-deterministic, so the same instruction can produce a different click path, a different interpretation of "this week's report," or a stalled session on the next attempt. A compiled agent that authenticates to any site behind a login avoids this by running the same sequence as code instead of re-deciding it each time.
How do I automate downloading reports from a portal that requires login?
Use a browser-based agent that holds credentials in a secure vault, maintains the session, and compiles the navigation and download steps into a repeatable routine rather than re-reasoning them live. This is exactly the case where browser automation beats an API-based approach, since most vendor portals have no API to call in the first place.
Can I still use Claude to analyze the reports once they're downloaded?
Yes, and that's the right division of labor. Once a compiled agent lands the file in a known location, Claude is genuinely strong at summarizing it, spotting trends, and drafting language for stakeholders. The retrieval and the analysis are separate problems, and splitting them is the core fix described throughout this piece.
What's the difference between a "compiled" agent and a Computer Use agent?
A compiled agent turns the stable, repeatable parts of a task, including navigation, clicks, typing, and file downloads, into code that runs the same way every time, while reserving model calls for genuinely variable judgment. This is the idea behind deterministic AI that compiles the workflow instead of re-reasoning it, and it's a different architecture than a Computer Use model that re-decides each click at runtime.
Is a compiled agent faster or cheaper than asking Claude Code to do it live?
In head-to-head testing on the same multi-step task, a compiled Airtop agent finished in 1m21s at $0.063, compared to 7m58s and $6.26 for Claude Code on Opus 4.7. The gap comes from not re-reasoning through navigation on every step, which also lines up with code-first agents that need fewer reasoning steps than LLM-per-step agents.
Can I trigger portal downloads from inside Claude Code instead of switching tools?
Yes. Teams can connect Claude Code to your Airtop agents and keep Claude as the interface for planning, while the underlying agent handles login, navigation, and the download itself. It's installable as a skill, so the coding agent you already use can call out to a browser-based agent without leaving its own workflow.
What happens when the portal changes its layout or renames a button?
A well-built compiled agent is designed to tolerate small drift: broken runs heal themselves when a page shifts slightly, instead of failing outright the way a brittle selector-based script would. That resilience is part of why a compiled approach holds up over months of scheduled runs, not just the first successful demo.
