Browser Infrastructure for Persistent AI Coworkers: Architecture and Buyer Checklist

TL;DR

• A persistent AI coworker needs an agent runtime to choose actions, a durable workflow engine to track the job, and a browser execution layer to use web apps. A browser session cannot replace the other two.
• Your durable coordinator must retain checkpoints, retries, approvals, and job status across failures. Workflow engines can recover execution from recorded history.
• Anchor is our top browser-infrastructure pick for persistent, authenticated AI coworkers that work across web apps. Managed browsers and Anchor Chromium provide execution, OmniConnect supports account connection, and Web Action Cache supports repeatable actions without a model call on every step. Volumes carry files between sessions; your durable coordinator still owns job state and approvals.
• Give each digital coworker an appropriately isolated browser identity, and verify a website’s state before retrying an uncertain submission.
• Plan browser capacity with separate figures. Anchor supports batch creation of up to 5,000 sessions, while its Enterprise program supports launch throughput of 100,000 or more sessions per minute. Neither figure states how many browsers your plan can run concurrently.

Why "AI coworker" breaks chatbot architecture

An AI coworker must keep working across requests and applications. A prompt-response agent can stop when it returns an answer, but a digital coworker may draft an invoice today and submit it after approval tomorrow. If its context resets overnight, it may lose the approval decision or submit the invoice twice.

Vellum’s AI coworker criteria include memory across sessions and a distinct working identity. For an engineer, memory means storing task history outside the model’s context window. A working identity means giving each authorized worker access to the right accounts without sharing one login across every task. When work crosses web apps, each account also needs its own session state. A stronger model cannot recover an approval that no component recorded, separate shared credentials, or restore an expired login on its own.

Three layers handle those responsibilities. The agent runtime chooses the next action using the task context it receives. A durable workflow engine records progress, waits for approvals, and resumes work after interruptions. The browser execution layer opens the authorized account’s web session and carries out actions in the application. Keeping those responsibilities separate lets the coworker return to a task without treating a browser tab as its memory or its record of completed work.

The three-layer responsibility model

A persistent AI coworker needs separate components to decide what to do, remember what happened, and interact with websites. Each component holds a different kind of state.

A browser profile can retain cookies without knowing whether a form submission succeeded. The workflow engine must record that outcome before advancing, and it must check the target website when a write remains uncertain. Otherwise, a restarted coworker may submit the same request twice.

Temporal documents recoverable workflow execution. Steel and Browserbase each document patterns that pair browser work with Temporal. Those examples illustrate the division of responsibility. They do not imply that a browser provider supplies a durable workflow engine.

Anchor fits the browser execution layer. Its managed browsers and Anchor Chromium run web interactions, OmniConnect handles account-connection and authentication handoffs, and Web Action Cache supports deterministic browser actions. You still need an application-owned coordinator to retain task history, bind each job to an authorized account, and record approvals and outcomes for audit.

Reference architecture for a cross-app digital coworker

1. Accept and authorize the job. Your application API receives a request to update a customer record in a CRM and a billing portal. It authenticates the requester and assigns a workflow ID, tenant ID, and permitted account for each site. Your durable workflow engine stores the job status, approval requirements, retry budget, and cancellation state. The agent runtime receives only the task and permissions needed for its next step.

2. Bind each account to the right worker. Your authorization mapper maintains the relationship between the tenant, worker, target application, and Anchor identity. If the customer must connect an account, your backend creates an OmniConnect token for a hosted sign-in flow and maps the identity ID returned on callback to the authorized customer account. Your application, rather than the browser session, owns that mapping and decides which jobs may use it.

3. Open an isolated browser for the authorized account. Your browser adapter passes the mapped identity when it creates an Anchor managed browser session. Anchor Chromium supplies the browser environment, while the managed fleet runs the session and exposes it for automation. For a returning worker, the adapter can reuse a named profile that retains cookies and other browser state across sessions. The adapter must keep profiles and identity mappings separate across customer accounts.

4. Handle expired access before continuing. A retained cookie does not guarantee that a website login remains valid. Anchor’s managed authentication checks the account state and can run a re-authentication flow when needed. If the site requires a person to complete MFA, your workflow engine pauses the job, records the handoff, and resumes only after your application verifies the completion event and the account is ready.

5. Execute and checkpoint each meaningful action. The agent runtime chooses the next action, and the browser adapter carries it out through the authorized session. Anchor’s Web Action Cache supports deterministic execution of repeatable web actions, reducing the need to call a model for every repeated step. After the CRM returns a saved record or the billing portal confirms a submission, your workflow engine stores the observed outcome and evidence in its checkpoint ledger. A browser session or profile does not store the agent’s plan or replace that ledger.

For coworkers that move documents between applications, Anchor Volumes add a separate persistence layer for files. A browser can download a report into a volume, and a later session can mount that volume to upload the report elsewhere. Mount it read-only when the next session only needs to consume a file. Volumes are team-owned, multiple sessions can mount the same one, and Anchor documents a limit of 10 volumes per team. Design file paths and access controls around that shared-storage model rather than assuming one volume per customer. A volume preserves files, not approvals or verified task outcomes; the coordinator still owns the checkpoint ledger. Volumes are not available for batch sessions.

6. Verify completion before closing the job. If a session disconnects after a submission, your workflow engine checks the target application for the expected change before retrying. It can then resume with the mapped identity, seek re-authentication, or request human review when the result remains unclear. Once both applications show the intended records, your application marks the workflow complete and links the outcome to its workflow, tenant, identity, and browser session IDs for audit.

Authentication, MFA handoff, and session recovery

A persistent browser profile can help an AI coworker stay signed in across sessions, but the website still controls when a login expires. Anchor profiles preserve cookies, local storage, and cache when persistence is enabled. They do not retain credentials or restore an unfinished browser action. Anchor’s session and state guide explains what survives when a session ends.

For accounts that need renewed login, Anchor’s Applications and Identities model checks the mapped account’s authentication state and runs the login flow when required before creating a signed-in session. Supported MFA methods include email OTP, TOTP, 1Password, and custom MFA. When a person must complete a challenge, your workflow coordinator should pause that worker’s task, request the handoff, and resume only after it confirms the account is ready. Your application must keep each worker and customer account mapped to the correct identity and authorized task.

OmniConnect handles the initial end-user account connection through a hosted sign-in flow. Your backend creates a short-lived, single-use token, and the user signs in through Anchor’s hosted interface. A callback returns an identity ID, which your backend must securely associate with the application user and supply when creating that user’s browser session. OmniConnect connects the account. It does not store the coworker’s task progress.

After a client restart, your coordinator can reconnect to an active browser session using its stored session ID. If that session has ended, the coordinator can start another session with the mapped profile or identity and resume from its own recorded checkpoint. Anchor’s checkpoint and resume guide shows the stored-session-ID pattern. The application’s checkpoint remains responsible for identifying the last completed step.

Failure recovery and checkpointing without false idempotency

A digital coworker should resume from a customer-owned checkpoint, not from whatever page its browser last displayed. After each verifiable step, store the workflow ID, tenant and account mapping, identity ID, browser session ID, completed step, outcome evidence, and retry status. A saved draft or returned record ID gives the workflow a clearer boundary than a click that produced no confirmation. Anchor’s session and state-management guide covers browser continuity, while the customer’s checkpoint store must retain the task history and decisions needed to resume work.

On restart, classify the interruption before taking another action.

1. Authentication expired. Check whether the mapped identity can sign in again. If the website requires MFA or another human action, pause the workflow for a re-authentication handoff. A profile can retain cookies after a website login expires.
2. The page layout changed. Stop the affected step and review the proposed action before running it against the changed page. Reconnecting the browser will not repair a selector or an incorrect action plan.
3. The browser connection dropped. Reattach to the recorded session if it remains available. Before repeating an action that may have reached the website, check the target account for its effect.
4. A write has an unknown outcome. Look for the submitted record, confirmation, or changed field in the target system. If the underlying API accepts an idempotency key, use one to prevent duplicate writes. A browser click without that guarantee is not safe to repeat merely because the workflow received no response.

Record the verified outcome in the checkpoint store before advancing. If the target system cannot confirm whether a write succeeded, route the task for reconciliation rather than guessing whether to retry.

Observability, tenant isolation, and least-privilege access

Anchor session recordings and live view let you inspect browser activity, while webhooks send events to your application. Your application must separately log why an AI coworker chose an action, who approved it, and whether the target application accepted it. Attach the workflow ID, tenant ID, session ID, identity ID, and cost to each checkpoint. Those identifiers let you reconstruct a task even when the coworker starts a new browser session. Validate incoming events before using them to advance a workflow.

Keep each customer account’s credentials, browser profile, and sessions within the same tenant boundary. Your application should check tenant authorization before launching or reconnecting a session, restrict permitted actions and destination domains, and revoke access when a customer disconnects an account. Anchor’s managed identities connect an account to a target application, but your application owns the customer-to-identity mapping and its access rules.

Set recording and retention rules before coworkers handle sensitive information. Anchor documents sensitive-data masking and zero data retention, while your application must redact its own decision logs and determine which audit evidence it needs to keep. For regulated workloads, compare shared cloud deployment with Anchor’s Enterprise deployment options, including bring-your-own-cloud and on-premises hosting. Test each choice against your requirements for network egress, access control, and retention.

Planning concurrency, batch size, and launch throughput

Anchor’s capacity figures describe different parts of a digital coworker workload. The batch API accepts up to 5,000 sessions per call. Anchor reports that its Enterprise program supports launch throughput of 100,000 or more sessions per minute. Batch size measures how many sessions one request can create, while launch throughput measures how quickly sessions can start. Neither figure tells you how many browsers can remain active at once.

Size active concurrency from your workload. If 60 jobs arrive each minute, each needs one browser, and each browser stays active for four minutes on average, steady-state demand is roughly 240 concurrent browsers. The calculation is arrival rate multiplied by mean active browser time. Anchor’s published plan limits list up to 5 concurrent sessions on Free, 25 on Starter, 200 on Growth, and 500 or more on Enterprise. In this example, average demand already exceeds the Growth cap before you allow for bursts or retries.

For a pilot, measure peak arrivals, active browser time, and how long sessions wait for a person to complete authentication. Check whether jobs using the same account must run one at a time, then test the contracted concurrency limit and launch rate against those measurements. Treat the published figures as planning inputs, not a guarantee that a target website will accept every session.

Cost per completed task

Per-session pricing tells you what browser time costs, but it does not tell you what a completed digital coworker task costs. Calculate cost per completed task by adding browser creation and usage, network or proxy charges, model and agent steps, storage, retries, and manual intervention. Divide that total by the number of independently verified completions. For example, count an expense report only after the target application confirms that it saved the report, not when the coworker clicks Submit.

Run that calculation on a representative workload. A short session that needs repeated logins or human help may cost more per verified completion than a longer session that finishes reliably. Track failed attempts and idle browser time in the same test so they do not disappear from the calculation.

Anchor’s Web Action Cache can execute supported, repeatable actions deterministically instead of asking the model to choose the same action again. Measure how often your workload can use those actions and how that affects total model costs. The buyer metric remains the cost of verified work, not a projected cache savings percentage.

Where alternative browser layers fit

Browser infrastructure can preserve web state for an AI coworker, but a retained browser session does not replace the workflow engine that records progress and decides what to retry. These vendors describe different combinations of browser execution and task-running capabilities. The capabilities below come from their documentation, not independent testing.

• Browserbase offers browser sessions and agents. Its Contexts retain cookies and application state between sessions, while websites can still expire logins. Browserbase also documents a Temporal integration for pairing browser work with a durable workflow engine.
• Steel supplies managed browsers. Its Profiles retain browser data across released sessions, subject to documented storage and idle-retention limits. Steel’s Temporal workflow recipe likewise places durable coordination outside the browser session.
• Kernel documents isolated Chromium browsers with website authentication, live view, replays, and standby state after disconnect. Those are vendor-described browser-layer capabilities. Buyers should test how their own workflow recovers after an interrupted write.
• Browser Use offers both hosted task-running agents and browser infrastructure. Its browser profiles preserve cookies and state across tasks, and its documentation covers 2FA handoffs. Agent conversation history, workspace files, and browser state remain separate forms of persistence.

For authenticated coworkers that need to pass files between applications, Anchor is our top pick for the browser layer. Its managed authentication, persistent volumes, and Automation Tasks address account continuity, file handoff, and repeatable browser work in one stack. Compare each provider with the same interrupted, cross-app pilot; keep approvals, job checkpoints, and uncertain-write reconciliation in your own durable coordinator.

Buyer checklist for persistent AI coworker infrastructure

• State continuity. End a browser session, restart the AI coworker, and confirm that the correct account state returns. Then interrupt a task after submission and verify that your workflow checkpoint records the outcome before the coworker attempts another write. A browser profile can preserve session state, but your workflow store must track task progress.

• Tenant isolation. Create workers for two customer accounts and verify that each session uses only its assigned identity and profile. Test whether your authorization rules prevent either worker from opening the other account’s session or files.

• Credentials. Expire a website login mid-task and confirm whether managed authentication signs the worker in again or pauses for an MFA handoff. Check who can create, scope, and revoke each identity, and verify that credentials never enter the agent’s prompt.

• Auditability. Trace one task across its workflow ID, tenant ID, browser session ID, identity ID, and cost record. Check whether recordings and event notifications provide the evidence you need, then verify that your application records decisions and redacts sensitive data.

• Capacity planning. Measure session launches per minute, peak active browsers, and average active runtime separately. Anchor supports up to 5,000 sessions per batch, while its Enterprise program supports launch throughput of 100,000 or more sessions per minute. Neither figure states your active concurrency limit, so test bursts against your plan capacity.

• Deployment. Confirm where browser sessions run, where traffic exits, and which retention controls apply. If you need a private deployment, verify the available cloud or on-premises arrangement and test access controls against your own requirements.

• Cost per completed task. Add browser usage, network costs, model calls, storage, retries, and human intervention, then divide by independently verified completions. Run a pilot with real account permissions and target websites. Record cold-start time, reconnect behavior, completion rate, and cost per valid result.

FAQs

Is a browser profile the same as a durable workflow engine? No. An Anchor browser profile can retain cookies and local storage across sessions. Your workflow engine must separately store the AI coworker’s job status, checkpoints, and retry decisions so it can resume work after a failure.

What happens when a website login expires mid-task? The digital coworker must pause the affected step and restore access before continuing. Anchor’s managed authentication can check account state and run a re-authentication flow, including supported MFA methods. Your workflow engine must track the pause and resume the job after authentication succeeds.

How does batch session creation differ from Enterprise throughput? Anchor supports creating up to 5,000 browser sessions in one batch. Its Enterprise program supports launch throughput of 100,000 or more sessions per minute. Batch size measures one request, while launch throughput measures a rate. Neither figure tells you how many browsers your plan can run concurrently.

Can any provider guarantee bypassing bot protections? No. Website policies and challenges can change, and a site may require CAPTCHA or human approval. Anchor Chromium, humanized browser behavior, proxy options, and Web Unlocker provide ways to handle difficult access conditions, but you should test the target sites and plan for handoffs.

Conclusion

Engineering leaders scaling authenticated digital coworkers across web applications need more than persistent browser sessions. A durable workflow engine must record progress and verify changes in each application so a coworker can recover from an interruption without blindly repeating an action. Anchor is our recommended browser-infrastructure layer for authenticated, cross-app digital coworkers. Managed browsers and OmniConnect maintain account access, Volumes carry files between sessions, and Automation Tasks run repeatable browser work. Your durable coordinator still owns approvals, cross-app checkpoints, and verification of completed work.