Quick Answer
Run each Browser Use agent in its own Browser instance and give that browser an independent residential proxy session. Cap the number of simultaneous browsers with a semaphore, verify the proxy IP before the task, and check it again afterward when a Sticky identity must remain stable.
This is an advanced guide for teams that already have one Browser Use agent working through a proxy. If that path is not stable yet, complete the single-agent Browser Use and residential proxy setup before adding parallel workers.
Do not treat tabs as independent agent environments. Tabs in one mutable browser profile can share cookies, storage, permissions, and website location. Do not concurrently reuse one Sticky credential when the jobs require independent routing state.
The minimum orchestration pattern is:
The complete implementation below adds secret-safe lease loading, domain restrictions, timeouts, IP preflight and postflight checks, Sticky-session quarantine, duplicate-exit detection, and sanitized failure results.
Key Takeaways
- Allocate one Browser, temporary profile, and proxy session per concurrent work unit.
- Use Sticky mode through a coherent multi-step task and refresh the session only at a safe job boundary.
- Limit concurrency based on measured Chromium memory, CPU, bandwidth, and target rate limits.
- Verify the observed exit before the task and quarantine a Sticky job if the exit changes afterward.
- Treat browser, proxy, agent, and website state as one work-unit bundle with one owner and lifecycle.
Methodology and responsible-use note: Browser Use behavior, source, and first-party documentation were checked on August 25, 2026. The examples target Browser Use 0.13.8. Proxidize session and targeting behavior was checked against current first-party product documentation. The prerequisite single-agent route passed live authenticated HTTP, in-browser IP, Example Domain, cleanup, and five-fresh-browser Sticky tests. The complete multi-agent program. Run agents only against targets you are authorized to automate, and comply with applicable laws, contracts, website terms, privacy obligations, and reasonable request rates.
Start With the Single-Agent Integration
This guide assumes one Browser Use agent already works through one Proxidize residential access point. Complete the single-agent preflight first:
How to Use Residential Proxies with Browser Use for AI Agents
Do not add concurrency until the following path is stable:
The single-agent guide covers installation, ProxySettings, HTTP authentication, IP-allowlisted SOCKS5, country/city/ISP targeting, Sticky versus Random mode, Browser Use Cloud, and error troubleshooting. This article starts where that integration ends: allocating independent state to several simultaneous agents.
Why Every Agent Needs Its Own Browser and Proxy Session
Agent isolation has four layers:
| State layer | Contains | What goes wrong when agents share it |
|---|---|---|
| Agent state | Goal, observations, tool results, retries, checkpoint | One job can reuse or overwrite another job's context |
| Browser state | Cookies, storage, tabs, permissions, selected location | Accounts, carts, regions, and target sessions can mix |
| Proxy state | Access point, Sticky ID, location, exit IP, lease age | Independent jobs can appear as one network identity |
| Website state | Login, CSRF token, store, cart, server session | Target-side state no longer maps cleanly to one work unit |
The isolation boundary should therefore be a work unit, not a tab:
Browser Use's own parallel-agent reference shows separate Browser instances and profiles for independent agents. Sharing one browser between concurrent agents is described in the project examples as experimental.
Separate Sessions Do Not Guarantee Different IPs
Two independent residential sessions can select the same eligible peer by chance. Separate sessions provide routing isolation, not a mathematical uniqueness guarantee.
If distinct observed IPs are a hard requirement, the coordinator must:
- Allocate a session to each job.
- Open an IP-check page inside each worker's Browser.
- Compare the observations without publishing the raw IPs.
- Refresh a duplicate session before either worker reaches the target.
- Apply a retry limit so a constrained location pool cannot create an infinite loop.
Do not refresh a duplicate midway through a stateful task. Session allocation belongs before target interaction.
Choose the Work-Unit Boundary First
A request is not always a work unit. One browser task may open many pages and network connections while preserving one website session.
| Workflow | Work-unit boundary | Proxy policy | Browser policy |
|---|---|---|---|
| Independent public-page lookup | One validated observation | Fresh short session or tested Random route | Fresh temporary profile |
| Multi-page research bundle | All related pages for one subject | Sticky through the bundle | One Browser for the bundle |
| Localized price or availability check | One product + location result | Sticky country/city session | Fresh Browser; validate visible market |
| Authorized account workflow | Approved account transaction or review | Stable Sticky identity | Protected profile bound to that account |
| Scheduled recurring observation | One scheduled run | Normally fresh session per run | Fresh profile unless continuity is required |
Rotate after the result is validated and checkpointed. Changing IPs during a login, location-selection flow, cart, form, or multi-page observation can create a result assembled from incompatible identities.
For the deeper state model, see proxy sessions for AI agents.
Architecture: Scheduler, Lease Pool, Workers, and Results
A production orchestrator needs four responsibilities:
| Component | Responsibility |
|---|---|
| Job queue | Holds independent, idempotent work units |
| Session allocator | Assigns one unused proxy session and intended geography |
| Worker | Owns one Agent and Browser for the job's lifetime |
| Semaphore | Prevents unbounded Chromium processes |
| Validator | Checks IP, target-visible location, completion, and result schema |
| Result store | Records evidence without proxy credentials or unnecessary raw IPs |
| Recovery policy | Decides retry, quarantine, checkpoint, or permanent failure |
Proxidize supplies the residential route, targeting, and session policy. The application still owns job scheduling, Browser lifecycle, retry semantics, and result validation.
Create Independent Proxy Leases
Create proxy-leases.json locally. Each object should represent a separate dashboard-generated HTTP Sticky session or access point for one concurrent worker:
The values are placeholders. Copy the actual endpoint and credentials from Proxidize. Keep the file out of Git:
In production, replace the file with a secret manager and lease service. The scheduler should pass a lease reference to the worker, not include the password in an LLM prompt or general-purpose job payload.
Complete Multi-Agent Python Example
Save this as multi_agent.py:
Run it:
The code deliberately uses documentation-only targets. Replace them only with public or private targets the organization is authorized to automate.
The duplicate hashes in this example are an after-batch audit signal; they do not stop two workers before target navigation. If unique exits are mandatory, split allocation into two phases: preflight every Browser, resolve duplicate observations behind a synchronization barrier, and release workers to their targets only after the assignments pass. Most workflows need independent sessions rather than strictly unique IPs, so that extra coordination should be requirement-driven.
What the Example Protects Against
One Browser Per Work Unit
user_data_dir=None gives each Browser a temporary profile. Cookies, storage, tabs, and proxy configuration remain inside one worker instead of leaking into another job.
Use a persistent profile only when an authorized workflow needs it. A persistent profile should be bound to one approved identity and network policy, encrypted at rest, and never shared concurrently.
One Proxy Lease Per Concurrent Agent
The length check rejects a job batch that has fewer leases than workers. The zip(..., strict=True) call pairs each selected lease with exactly one job.
Several jobs may draw bandwidth from the same Proxidize account, but their Sticky session credentials should remain independent when routing isolation matters.
Bounded Chromium Concurrency
An asyncio.Semaphore caps the active browsers even if the queue contains more jobs. Browser processes consume substantial memory and CPU. Provider connection limits are only one capacity constraint.
Measure:
- Resident memory per Browser and per active page.
- CPU during page rendering and screenshots.
- Browser startup and teardown time.
- Proxy bandwidth per completed work unit.
- Median and p95 task time.
- LLM token and retry cost.
- Successful validated jobs per minute.
- Target rate-limit and failure behavior.
Increase concurrency gradually. Unlimited proxy connections do not make unbounded browser processes safe or respectful.
Deterministic Proxy Preflight
The worker opens the IP-check page before Agent.run(). This prevents an authentication or route problem from consuming LLM steps and producing a vague agent failure.
The IP never enters the prompt. The result output stores only a truncated SHA-256 fingerprint so operators can compare observations without publishing the raw address. A plain hash is pseudonymous, not anonymous; use a keyed HMAC and appropriate access controls when the threat model requires stronger protection against enumeration.
Sticky Postflight and Quarantine
keep_alive=True preserves Chromium after the Agent finishes. The program restarts the Browser event bus, checks the IP again, and quarantines a Sticky work unit when the preflight and postflight addresses differ.
This does not prove the IP was constant at every millisecond. It gives two deterministic boundaries. Higher-risk workflows can add observations at safe checkpoints, but should avoid navigating away from the target or disrupting its state merely to over-sample the IP.
Timeouts and Forced Cleanup
asyncio.wait_for() caps the complete Agent run. max_steps also limits agent actions. browser.kill() runs in finally because keep_alive=True would otherwise preserve the process after the postflight.
A production worker should also have an outer process or container timeout. Application cleanup cannot protect against a killed runtime, kernel fault, or machine failure.
Sanitized Failures
The public result includes error_type, not the full exception string. Some clients place server or authentication details in errors. Send detailed logs through a redaction layer that removes API keys, proxy usernames, passwords, cookies, and credential-bearing URLs.
Sticky Sessions, Rotation, and Job Reuse
A Sticky session should normally belong to one active work unit. After completion, choose between three policies:
| Policy | Behavior | Fit |
|---|---|---|
| Dispose | Delete or refresh the session after every job | Strong isolation for independent observations |
| Reuse sequentially | Keep the same session for related jobs, never concurrently | Research bundles that intentionally share identity |
| Persist | Bind the lease and browser profile to one approved identity | Authorized recurring account workflows |
Do not put a Sticky lease back into a general pool while its Browser or target session is still active. The allocator needs explicit states such as:
Random mode changes the model. A gateway may select another residential peer on a new proxy connection, while Chromium can reuse connections. Random mode is useful for independent sampling only after its real connection behavior is measured. It is not a replacement for job-aware rotation.
Failure and Recovery Policy
Different failures require different actions:
| Failure | Retry same Browser? | Retry same proxy session? | Recommended action |
|---|---|---|---|
| LLM timeout before target mutation | Sometimes | Yes, if Sticky continuity is intact | Retry from the last safe checkpoint with a strict limit |
| 407 Proxy Authentication Required | No value until fixed | No | Stop; correct the credential or authentication mode |
| Proxy connection failure before target | New Browser optional | Refresh or replace | Re-run preflight before target access |
| Sticky IP changes | Usually no | No | Quarantine the bundle and restart from a safe boundary |
| Target-visible location mismatch | Fresh state preferred | Replace with the correct geo policy | Do not accept or merge the result |
| Invalid extracted data | Sometimes | Usually yes | Re-check page state and schema before rotating |
| Target rate limit | No immediate retry | Do not rotate reflexively | Back off and respect target limits |
| Browser process crash | No | Depends on task sensitivity | Dispose of live state and recover from checkpoint |
Retries should be idempotent. Do not automatically repeat purchases, messages, account changes, uploads, or other consequential actions. Those require explicit state checks and human approval.
Location-Aware Parallel Agents
When agents represent different markets, make location part of the job and lease contract:
The worker should validate both network and website state:
- Observed public IP and approved geolocation evidence.
- Target-visible country, store, or delivery location.
- Currency and language where required.
- Cookie or account state that could override the IP.
- Result fields tied to the requested market.
Do not merge a New York observation with a Berlin result merely because both jobs opened the same URL. Location is part of the data's provenance.
Proxidize Residential Proxies support country, city, and ISP targeting across 195+ countries. Configure city and ISP through the dashboard or Session Builder, then issue the generated access point to the correct worker. Do not ask the LLM to invent or rewrite proxy credentials.
Production Checklist
- Prove the single-agent route before enabling concurrency.
- Pin Browser Use and retest lifecycle behavior after upgrades.
- Store proxy and LLM credentials in a secret manager.
- Allocate one proxy lease and Browser per concurrent work unit.
- Give every job an explicit ID, target, geography, and allowed-domain set.
- Preflight the proxy before the LLM task.
- Hash or protect raw IP observations according to policy.
- Use Sticky mode through stateful jobs and rotate at checkpoints.
- Quarantine unexpected IP or target-location changes.
- Cap steps, task time, process time, memory, and concurrency.
- Classify errors before retrying; do not rotate for every failure.
- Make consequential actions idempotent or human-approved.
- Kill persistent browsers in finally and with an outer process timeout.
- Monitor validated job success, p95 duration, retries, proxy usage, and cleanup failures.
- Follow applicable laws, target terms, privacy rules, and reasonable request rates.