Skip to main content
BrowserPair tasks are durable coordination objects, not fire-and-forget browser RPCs. Authority, ownership, browser state, and uncertain effects remain attached to one task identity across normal reconnects.

One task identity

Idempotent creation prevents network retries from inventing duplicate work.

One current owner

Fencing generations reject stale executors after reconnect or supersession.

No blind replay

Uncertain browser effects are verified or explicitly resolved before retry.

​
Original contract and effective authority

The task contract created at start remains immutable:
  • initial domains;
  • capabilities;
  • explicit confirmation requirements; and
  • optional side-effect bound.
A later user-approved website does not rewrite that original contract. BrowserPair records a separate task-scoped grant.
Page content, redirects, models, and Skills cannot create task grants.

​
What the task remembers

Authority state

Original contract, explicit task grants, sensitive grants, and required confirmations.

Ownership state

Browser owner, fencing generation, connection generation, and strongly owned tabs.

Interaction state

Current observation/action turn and interaction generation.

Effect state

Whether a mutation is pending, executing, known complete, definitely absent, or uncertain.

Managed intelligence state

Selected providers, subgoal, observation settings, counters, limits, escalation state, and bound Skill version.

Durable result

Terminal outcome and safe task history remain attached to the same task identity.

​
Idempotent creation

POST /v1/tasks requires an idempotency key.
Same key and identical request returns the original task.
This solves duplicate task creation. Browser mutations need an additional effect-recovery model.

​
Browser and tab ownership

BrowserPair does not treat every open tab as available agent state.
  • strongly task-owned tabs may be used automatically;
  • probable or unrelated tabs are not silently adopted; and
  • navigation without an owned tab can create a new task-owned tab inside the user’s existing browser profile.

​
Reconnect and fencing

1

Durable state remains

Contract, grants, owned tabs, current interaction, and effect state remain associated with the existing task.
2

Ownership advances

A newer browser/controller connection receives the current generation.
3

Stale work is fenced out

Older executors can no longer mutate the task.
4

The agent resumes from current state

REST GET /v1/tasks/:id or MCP task_state returns the latest durable interaction.

​
Effect verification

The difficult case is a connection failure after BrowserPair sent a state-changing action but before it could prove the result.

Effect succeeded

Continue from the observed post-effect state.

Definitely not executed

A retry can be considered using the current authority and state.

Indeterminate

Do not replay blindly; require additional verification or resolution.
executing and effect-unknown mutations are never blindly replayed.

​
Managed Brain + Reflex continuity

Managed and external-Reflex tasks also preserve:
  • selected Brain and Reflex provider identities plus fallbacks;
  • current subgoal and success criteria;
  • observation mode and scope;
  • Reflex effective confidence and escalation reason;
  • Brain, Reflex, step, and duration limits; and
  • selected Skill ID and version.
These fields help BrowserPair resume coordination. They never expand browser authority.

REST API

Work with durable task state directly over HTTP.

Remote MCP

Use the same semantics through MCP tools.

Permissions

Understand the authority that remains attached to the task.