Marketers and GTM engineers now own login and portal checks that used to sit with engineering. You can describe the flow in plain English, which means nobody has to write a test script first.
What you do need is the difference between "build time" and "runtime." Build time is the first session, when you watch a live cloud browser attempt the flow, correct anything that goes wrong, and save the working steps. Airtop calls that save "compile." Runtime is every later run, when those saved steps execute on their own and leave traces and video attached.
Start by walking through the check in a live browser. Describe what should happen, watch the attempt, and fix the steps that miss. When the run works, Airtop saves those clicks so they can repeat. Then you can run the same check every night, and it should click the same buttons you saw the first time.
- Marketers and GTM engineers can describe a login or portal check in plain English and watch a live cloud browser attempt it, so nobody has to write test code first.
- Build time is when you teach the check: you describe it, watch it, and fix it. Runtime is when the saved version runs on a schedule, the same way every time.
- You keep correcting the first run until Airtop can save the working steps. After that, the same input should produce the same output every time you run it.
- You rerun the saved test with full traces and video so a blocked login or an empty scrape shows exactly where it failed, instead of failing silently.
- Keep Claude, Codex, or your workflow tool for planning what to test, and let Airtop own the interactive browser steps behind someone else's login.
Marketers now run portal checks that used to need developers
These checks used to require a developer who would write a script in a tool like Playwright or Cypress. When the vendor moved a button, the script broke, and the ticket went back to engineering.
That work now shows up on GTM teams that need to confirm invoices loaded or see whether a partner portal still signs in. If marketing cannot run the check, the work waits on engineering. If marketing asks Claude to click through it every morning, the path can change and the cost adds up.
The practical move is to get the flow right once, while you are watching, and then reuse those saved steps. You can start from a typed description of the flow, even if you have never written a test.
A passing check can hide missing data
When you're testing someone else's login, you don't control the page. You also don't control multi-factor authentication, or MFA, which is the extra code that arrives on a phone. A script that only talks to an API hopes the response still looks the same. When it doesn't, you get a silent empty scrape instead of an error you can act on.
That's the failure that matters for marketers. The run can look fine even though the spreadsheet is empty. Nobody notices until a deal stalls or an invoice is already late.
A portal check that worked in the demo can fail later for reasons that have nothing to do with your logic. The session may have died, or a CAPTCHA may have appeared. None of that shows up as a red error. It shows up later as missing data.
Teach the flow once, then reuse the saved steps
The distinction to understand is between build time and runtime. Build time is when you teach the flow, and runtime is when that flow runs without you.
At build time, the model should think because the page is still new. You watch a live browser, correct a missed field, and save the result as reusable steps. Compiling the run means taking the clicks that just worked and storing them so they can run again.
At runtime, asking the model to think through the page again is the problem. A nightly invoice check should click the same buttons it clicked when you watched it. If the model chooses a different button, the cost jumps and the output can change.
This matters because GTM work is usually a repeated check, not a first look at a new site. You use the model while you figure out the flow. After that, you run the saved test.
If you skip that distinction, two things go wrong. You pay a model to re-learn a login it already knows. A check that looks like it passed can also hide an empty scrape, because nothing recorded what the browser did.
Rethinking the same login every night is expensive
An "LLM-per-step" loop is a chat agent that re-reads the page and re-decides every click. Chat-based agents and "Computer Use" loops work that way: they read the page, decide what to do, act, and then read the page again. That approach is useful the first time you try something new, but it is expensive and slow to repeat every night.
On the same multi-step task, a compiled agent finished in 1 minute 21 seconds for $0.063 versus 7 minutes 58 seconds and $6.26 for an LLM-per-step run against Claude Code Opus 4.7.
Thinking through the page is useful when you first figure out the login. It is wasted when you already know which buttons to click. A login test you run every night does not need to be figured out from scratch every night. It should click the same buttons each time, without inventing a new route through the page.
Watch the first run and save the clicks that worked
This is where the teaching loop comes in. You describe the flow in plain English and watch a live cloud browser attempt it. You correct anything that goes sideways, and Airtop compiles the corrected run into reusable code.
Airtop is not a wrapper around Playwright. It is a browser stack built for AI agents, with authenticated cloud browsing, proxies, CAPTCHA solving, and a password vault already in place.
Code-first agents follow the same split. You use the model while you build, then you run the saved steps later. You do not ask the model to re-read the page and choose new clicks every night.
"Fully tested at build time" means you prove the flow works while you are still watching. You see the live browser hit MFA or a field that didn't fill, and you correct it before you put the test on a schedule. After that, the saved agent should use the same clicks and pull the same fields it pulled in that first session.
If tonight's run does something different, the trace and video show the step that changed. You can see the miss instead of being left with a green check next to an empty table.
A green check sitting next to empty data is easy to miss. The team thinks the invoices are there, but they are not. That is why you watch the first run, and why every later run keeps a recording.
You describe the check instead of writing selectors
In Agent Builder, you describe the login or portal check in plain English: log in with test credentials and confirm the last three invoices are visible. Agent Builder builds and tests the automation for you instead of asking you to hand-write selectors. A selector is a stored address that points at a specific button on a page. It is brittle because a small label change can break it.
If you'd rather start from a working example, start from a template and adjust it to the portal you're testing.
A live browser shows the miss on screen
Instead of trusting a chat transcript, you watch the run happen in a real, authenticated cloud browser, the same kind of session behind sign in once, stay signed in workflows. You'll see the MFA prompt and the field that didn't populate. This is where a blocked login or a portal that renders differently shows up on screen, instead of failing silently after you've already trusted it.
You don't have to read a log to know what happened, because you can watch the browser do the work. Build time is your chance to catch a wrong click or an empty field while you are still looking at the screen.
Correct a wrong field on screen, then save the run
When something goes wrong mid-run, you correct it directly by pointing at the right field or adjusting a wait. Airtop saves the run again from that correction. This is different from patching a brittle selector by hand or rewriting a prompt and hoping the model behaves the same way next time. Once the run is saved, it becomes a deterministic agent, which means it produces the same output from the same input every time you run the login or scrape test again.
Saving the steps does not cure a silent wrong extraction. If the page still needs judgment—which invoice is "last," whether a status badge counts as paid—the model can still pick the wrong field. On later runs, the agent has fewer choices to make. It does not make a bad scrape look like a passing test unless you watch the video.
Later runs leave video so you can see what broke
Once the steps are saved, rerun the test on a schedule or a trigger. Every run comes with full traces and video of every run, so debugging an agent looks like watching a recording instead of reading an error log. If a vendor changes their login page in a small way, broken runs heal themselves. If the page is rebuilt, the recording shows you which step broke so you can teach that step again. Self-healing cannot absorb a full redesign of the site.
Later runs still need a recording, because you need to see whether the saved test did what you watched it do the first time. When it doesn't, the recording is how a marketer sees the miss without waiting on an engineer to explain a log.
The same teach-once pattern covers logins and portals
A login test looks like this: you walk through the sign-in once, including MFA and vault credentials. Then you rerun it nightly to confirm the vendor hasn't broken authentication underneath you. If that login dies overnight, the morning checks that depend on it fail too.
A scrape test looks like this: you show the agent which fields to copy once, then rerun it against accounts you don't control. When the page layout changes, you can rely on video evidence to see what happened.
A portal check looks like this: you walk through the clicks to the page that matters. Then a scheduled saved agent confirms the flow still works before a customer tells your team it doesn't.
Keep Claude for planning and Airtop for the clicks
Saving the browser clicks doesn't remove the reasoning model. It uses the model while you build. The nightly login then repeats without asking the model to choose each click.
Use Claude, Codex, n8n, Make, or Zapier for planning what to test and how to sequence the results. Give your AI agents a browser for the interactive step instead of asking a chat agent to click through a login on every single run.
For GTM checks, such as confirming a lead list stays reachable or a CRM portal hasn't changed shape, you can also tell Mark what you're trying to achieve and let it sequence the checks alongside the rest of your GTM plan. Either way, you describe the flow and watch it run in a live cloud browser. You correct it until the working steps are saved, and then you use the traces and video to see what happened on later runs.
FAQs about automated browser testing
Build time is teaching, and runtime is the saved repeat
Build time is when you teach the test. You describe the flow, watch it, correct it, and save the working steps. Runtime is when that saved test runs later, on a schedule or a trigger.
Figure out the clicks while you are watching, then repeat those saved clicks later. If you reverse that, you save a broken first run, or you pay a model to re-think a login every night.
Playwright and Cypress are developer tools for apps you own
Playwright and Cypress are developer tools for apps you own, with selectors you maintain. They are not built for marketers or GTM engineers. Automated browser testing of someone else's login or portal is a live-web problem: sessions, MFA, CAPTCHA, and pages you don't control. Airtop is not a wrapper around Playwright. It is a browser stack built for agents, with a teaching loop that saves the flow after you watch it.
Failed tests show up as video of the cloud browser
Every saved run leaves full traces and video. Debugging looks like watching a recording of the cloud browser, not reading an error log. That's how you tell a blocked login from an extraction that clicked the wrong control.
You describe the flow instead of writing selectors
You describe the flow in plain English. Agent Builder builds and tests the automation and saves the click path. You correct on screen when a step is wrong. You can start from a template if you want a working example first.
Small page changes can self-heal, but a redesign cannot
Self-healing is for small cosmetic changes that move a selector, and broken runs heal themselves. A full redesign still needs a rebuild. You watch the recording, teach the broken step again, and save the run once it works.
Saved tests can run every night on a schedule
Yes, you can run the saved agent on a schedule or a trigger. After the first working run is saved, the tenth nightly login check does not have to figure out the page again. The saved test repeats the same clicks, and it keeps traces attached so you can see what happened.
Claude can still plan while Airtop runs the login
You can keep Claude, Codex, n8n, Make, or Zapier for planning what to test and wiring results into the rest of the stack. Let Airtop run the browser steps so the model is not clicking the same login every night.
A compiled run is faster and cheaper on the same task
On the published Agent Builder benchmark, a compiled agent finished the same multi-step task in 1 minute 21 seconds for $0.063 versus 7 minutes 58 seconds and $6.26 for an LLM-per-step run against Claude Code Opus 4.7. On that task, the compiled run was about 6x faster and about 1 percent the cost.
Start in a live browser instead of a local script
You can skip the local script that only works on your laptop. Try it for free and spin up your first agent in five minutes. Describe the login, watch the cloud browser, save the working steps, and run them again with traces attached. If the work is a GTM check, you can also talk to Mark.
