When we first built Tensor's agent system, each agent operated in a single tab. You would say "go to Amazon and find me the best-reviewed mechanical keyboard under $150," and Tensor would navigate, search, scroll, compare, and return an answer. It worked well for simple tasks. But users kept asking for something more ambitious: "Compare prices across five different retailers simultaneously." "Research this topic from ten different sources at the same time." "Apply to the top twenty matching jobs on three different job boards."

Single-tab agents cannot do this efficiently. Visiting five retailers sequentially takes five times as long as visiting them in parallel. So we built something new: Multi-Tab Agent Swarms — the ability to spawn N parallel agents across N browser tabs, each performing its own task, with results synthesized into a single coherent answer. This is the engineering story of how we made it work.

The Architecture: Coordinator and Workers

A swarm follows a coordinator-worker pattern. When you issue a swarm-eligible command, Tensor's planner breaks it into discrete sub-tasks and spawns a coordinator agent. The coordinator is responsible for four things: decomposing the task, spawning worker agents, monitoring progress, and synthesizing results.

Each worker agent gets its own browser tab, its own execution context, and its own isolated state. Workers do not communicate with each other directly. All communication flows through the coordinator via Chrome's messaging API. This star topology keeps the system simple and avoids the complexity of peer-to-peer agent coordination.

// Simplified swarm lifecycle
Coordinator: Plan → Spawn Workers → Monitor → Synthesize

Worker 1:  Open Tab → Navigate → Extract → Report
Worker 2:  Open Tab → Navigate → Extract → Report
Worker 3:  Open Tab → Navigate → Extract → Report
  ...
Worker N:  Open Tab → Navigate → Extract → Report

Coordinator: Collect Reports → Merge → Respond to User

Tab Group Isolation

One of the earliest problems we encountered was tab interference. If multiple worker agents are operating simultaneously, they might interact with the same cookies, session state, or local storage. Imagine two workers both navigating to the same e-commerce site: one adds a keyboard to the cart, the other adds a mouse. The cart is shared state, and the results become unpredictable.

Our solution is Tab Group Isolation. Each swarm gets its own Chrome tab group, visually distinguished by color. Within a tab group, workers share a namespace but have strict boundaries enforced at the extension level. The coordinator assigns each worker a unique session ID, and all state mutations are tagged with that ID. When a worker reads page content, it operates on its own snapshot, not on shared DOM state.

For sites that rely on cookies or session storage, we intercept storage operations at the extension level and namespace them per worker. Worker A's cart is stored under tensor_swarm_a_cart, while Worker B's cart lives under tensor_swarm_b_cart. This prevents cross-contamination without requiring incognito windows or separate browser profiles.

Parallel Execution and Rate Limiting

Spawning ten tabs simultaneously and hammering ten websites with automated requests is a recipe for getting rate-limited, blocked, or CAPTCHAed. We needed to be responsible about how swarms interact with the web.

Tensor implements a graduated spawn strategy. Rather than opening all tabs at once, we spawn workers in waves. The first wave contains two to three workers. If they succeed without triggering rate limits, the next wave launches. This back-pressure mechanism adapts to each site's tolerance. We also respect robots.txt crawl-delay directives and implement per-domain rate limiting with a default of one request per two seconds per domain.

Workers also implement exponential backoff. If a worker encounters a 429 (Too Many Requests) response, it waits and retries with increasing delays. If a worker hits a CAPTCHA, it pauses and notifies the coordinator, which can either skip that source or ask the user to solve the CAPTCHA manually.

The Race Condition Problem

The hardest engineering challenge was not spawning agents or isolating tabs. It was handling the timing. Swarm workers complete at different rates. One worker might finish in three seconds while another takes thirty. Some might fail entirely. The coordinator needs to handle all of these scenarios gracefully.

We considered several approaches:

We settled on an adaptive timeout with progressive results. The coordinator sets a base timeout proportional to the expected task complexity. As workers report in, the coordinator begins constructing a partial result. If all workers finish before the timeout, it synthesizes everything. If the timeout expires with some workers still running, it synthesizes what it has and marks missing results as pending. Late-arriving results are appended to the response asynchronously.

// Adaptive timeout calculation
baseTimeout = estimatedTaskComplexity * 1000  // ms
perWorkerBonus = 2000                         // extra time per worker
maxTimeout = 120000                           // hard cap: 2 minutes

timeout = Math.min(
  baseTimeout + (workerCount * perWorkerBonus),
  maxTimeout
)

// Progressive result delivery
onWorkerComplete(result) {
  partialResults.push(result)
  if (partialResults.length >= quorum) {
    emitPartialSynthesis(partialResults)
  }
}

onTimeout() {
  emitFinalSynthesis(partialResults)
  remainingWorkers.forEach(w => w.markAsync())
}

Result Synthesis: The Hard Part

Collecting data from five tabs is straightforward. Making sense of it is not. Each worker returns data in a different format, from a different source, with different levels of detail. The coordinator needs to merge these into a coherent, deduplicated, and useful response.

We use the AI model itself for synthesis. The coordinator sends all worker results to the language model with a synthesis prompt that asks it to merge, compare, deduplicate, and rank the findings. This approach is more flexible than any rule-based merge algorithm because it can handle the inherent messiness of web data.

For structured tasks like price comparison, the synthesis prompt instructs the model to produce a comparison table. For research tasks, it produces a narrative with citations. For job applications, it produces a status report of which applications were submitted and which failed. The synthesis format adapts to the task type.

Resource Management and Cleanup

Swarms are resource-intensive. Ten open tabs, each running an AI agent, can consume significant memory and CPU. We implemented aggressive cleanup to keep the footprint manageable.

Workers close their tabs immediately upon completion. The coordinator tracks all spawned tabs and has a cleanup routine that fires on swarm completion, timeout, or user cancellation. If the user closes the browser during a swarm, the service worker catches the shutdown signal and cleans up orphaned tabs on the next startup.

We also implemented memory pressure monitoring. If Chrome signals memory pressure (via the chrome.runtime.onPerformanceWarning event, available in newer Chrome versions), the coordinator reduces the active worker count by pausing pending spawns and allowing in-flight workers to complete.

Real Performance Numbers

In our benchmarks, a five-tab swarm completes a price comparison task in an average of 12 seconds, compared to 48 seconds for a sequential single-tab agent performing the same comparison. That is a 4x speedup, which aligns with theoretical expectations given the overhead of coordination and synthesis.

For a ten-source research task, the swarm completes in 25 seconds versus 3 minutes and 20 seconds sequentially. The speedup is not a perfect 10x because some sources are slower than others and the synthesis step adds overhead, but the improvement is substantial enough to fundamentally change the user experience.

Looking Forward

Multi-Tab Agent Swarms open the door to browser-scale parallel computing. We are exploring several extensions: swarms that span multiple browser windows for even greater parallelism, persistent swarms that combine with background agents for long-running parallel tasks, and hierarchical swarms where a coordinator can spawn sub-coordinators for multi-level task decomposition.

The browser has always been a window to the web. With swarms, it becomes a fleet of windows, each carrying an intelligent agent, all working together toward your goal. That is the future of browser AI, and we are building it one tab at a time.