The same CDP connection shows up in a CI pipeline and in a back-office automation that files claims on an internal portal. Same page.goto(), same selectors, same Playwright API—and almost nothing else in common. A test suite exists to catch regressions before they ship. An enterprise operations workflow exists to get real work done inside systems that were never built with automation, audit, or compliance in mind. Treat one like the other and you either ship a brittle test suite or an automation that can't survive a compliance review.
What Testing Actually Optimizes For
A test suite answers one question, over and over: did this build break this flow? That means:
- Determinism. The same test should pass or fail the same way every run. A flaky login step is worse than a broken one, because it erodes trust in the whole suite.
- Disposable sessions. Each run spins up a clean context, executes in seconds, and tears down. Nothing needs to persist past the assertion.
- A DOM you control. Locators target an app your team owns, so a broken selector is a legitimate signal that something changed upstream.
What Enterprise Operations Actually Optimizes For
An operations workflow—renewing a vendor contract, pulling claims data from a carrier portal, updating a record in a system with no API—is answering a different question: did this task complete correctly, on a system you don't control, in a way you can prove later. That changes almost every requirement:
- Identity that outlives the script. Logging back into a claims portal or an internal SSO gateway every run isn't a minor inconvenience—on some systems it triggers a fraud flag or an MFA challenge. The session needs to pick up where a previous one left off, days later.
- Evidence, not just a pass/fail signal. Compliance and audit teams don't want "the workflow succeeded"; they want a record of what happened—screenshots, a session recording, a timestamped trail—that holds up when someone asks why a claim was filed the way it was.
- Network and access that match policy. Traffic hitting a regulated portal often needs to originate from an approved location or a consistent IP, not whatever residential proxy happens to be free.
- A place for a human to step in. Some actions—approving a payment, submitting a legal filing—shouldn't complete unattended. The workflow needs a checkpoint, not just a retry loop.
Same Library, Different Infrastructure
"Just use Playwright" is true for both jobs and incomplete for either. The automation API is shared; what has to persist underneath it isn't. A CI runner wants a browser that disappears the moment the test finishes. An operations workflow wants a session whose login state survives the run entirely:
import os
from anchorbrowser import Anchorbrowser
anchor_client = Anchorbrowser(api_key=os.getenv("ANCHOR_API_KEY"))
session = anchor_client.sessions.create(
browser={"profile": {"name": "vendor-portal", "persist": True}}
)That single persist flag is the difference: the next run reconnects to a browser profile that's already authenticated, instead of re-running a login flow that might not be idempotent. For systems Anchor manages the credentials for directly, the same call takes an identity instead of a profile:
session = anchor_client.sessions.create(
identities=[{"id": "vendor-portal-identity"}]
)Sessions also start recorded by default, which matters more here than it ever does in CI—a recording is the audit evidence an operations team needs, not a debugging convenience. Neither workload is the more sophisticated one; they're solving for opposite failure modes. A test should fail loudly the instant your own app regresses. An operations workflow should keep a paper trail and pick up its identity again next week, on a system that owes you nothing.
If what you're building looks like the second kind—authenticated sessions that need to persist, and a record of every action for the compliance team—that's what Anchor is built for. Get an API key and point it at the portal your team currently logs into by hand.
