Skip to main content

Browser Control and Computer Use

Not every system has a clean API. Some systems have no API at all. Others expose part of the workflow but leave the important steps trapped in a browser or desktop app.

Worka needs to cover those cases as well, because real work is not limited to clean API integrations.

Browser control and computer use are different​

Browser control​

Browser control is for work that happens inside a web browser.

Examples:

  • navigating a browser-only Shopify Admin flow
  • reading data from a Looker or Grafana dashboard
  • completing a form or review flow

Desktop computer use​

Desktop computer use is for work that depends on the broader device environment.

Examples:

  • acting on a native desktop app
  • interacting with system windows or dialogs
  • combining a local application with other workspace actions

Both are powerful capabilities, but they should stay explicit and well-scoped.

When you should use an API instead​

Prefer a normal API when it can do the job.

API-based automation is usually:

  • more stable
  • easier to review
  • easier to govern
  • easier to debug

Browser or desktop automation is most useful when the real workflow cannot be completed through a normal integration path.

Browser session modes​

Browser automation can run in different session styles.

Isolated mode​

Use isolated mode when you want a clean browser session that does not reuse your everyday signed-in browser profile.

This is the safer default.

Persistent profile mode​

Use persistent mode only when the task really needs a signed-in browser profile that already exists on your device.

This should always be an explicit choice. Worka should never silently switch from isolated mode to persistent mode.

What to check before you enable browser control​

Before you allow browser automation in a workspace, check:

  • which websites or browser-only systems it may touch, such as Shopify Admin or a legacy internal portal
  • whether isolated mode is enough
  • whether persistent mode is actually necessary
  • which AI team members or workflows may use it
  • whether those actions should require approval

Persistent browser access is powerful because it can reuse a signed-in local identity. Treat it that way.

What to check before you enable desktop computer use​

Before you allow desktop computer use, check:

  • which local apps or system actions the workspace needs
  • which device it will run on
  • whether the necessary OS permissions have been granted
  • which actions should stay approval-gated

Desktop computer use is usually the most sensitive edge capability in a workspace. It should never feel hidden.

What should stay visible​

If browser or desktop automation is active, you should be able to see:

  • that the capability is enabled
  • whether the task is using browser or desktop control
  • whether approval is still required
  • which task used the capability
  • what happened afterwards

If those things are invisible, the workspace is not exposing enough state.

Local-only capabilities​

Some capabilities stay tied to your own device, even if the device contributes general compute.

That is especially important for:

  • persistent signed-in browser profiles
  • desktop computer control

You should not have to guess whether those are being shared beyond your own local use.

Example​

Imagine your team needs a workspace that:

  • reads incoming Gmail
  • checks a browser-only Shopify Admin flow
  • updates an internal order-management system

If Shopify Admin has no API for the exact workflow you need, browser control lets Worka complete the real job instead of stopping halfway and telling you to do the rest manually. If part of the same workflow depends on a desktop app, desktop computer use can cover that edge as well.

That is the point of these capabilities: finishing the actual workflow when the real world is messier than a clean integration diagram.