# Browser Agents (/concepts/browser-agents)



Yes, Trelium can work in software that has no API. A browser agent works in the tool through a web browser, much like a person logging in: it signs in, moves through the pages, and reads and fills in what is on screen. That is a plain-language description of how it works, not a promise that every login challenge or interface change will succeed without help. Your team keeps using the same system, and nothing is migrated or replaced.

<Callout title="Think of a new hire with a login">
  A browser agent gets its own account in the tool, just like a new team member
  would. It can see and do what that account allows, and nothing more.
</Callout>

## What a browser agent is [#what-a-browser-agent-is]

A browser agent is how a Trelium agent reaches a system that offers no API, or whose API does not cover what your team does by hand. It uses the system's web interface, the same one your people use.

For how this compares with an API connection, see [Integrations](/concepts/integrations). For how a system gets connected, see [Connecting Systems](/concepts/connecting-systems).

## What a browser agent can do [#what-a-browser-agent-can-do]

With its login, the agent can:

* Log in to the system.
* Navigate between pages.
* Fill in fields.
* Read what is on screen.

What it can do in a particular system depends on that system and on what its account is allowed to see and do. If you need to confirm a specific action in a specific tool, ask during setup.

## When browser automation is the right choice [#when-browser-automation-is-the-right-choice]

If a system has an API and the API covers the job, use the API. Browser automation is for everything else:

* Systems with no API.
* Systems where the API does not cover what your team does by hand.
* Work where your team's real process lives in the interface, such as a portal that only shows certain information on its pages.

## Access and security [#access-and-security]

A browser agent uses a dedicated user account that you create. This shapes what the agent can reach and how you can see what it did:

* **Access is the account's access.** The agent can see and do what that account can see and do, and nothing more. If the account cannot reach a page or action, neither can the agent.
* **Activity is distinguishable.** Because the agent has its own account, what it does stays separate from what your team does in the same system.
* **Passwords are kept in a vault.** The agent's login is stored in a 1Password vault, not in the workflow itself.

<Callout title="You set the limits" type="info">
  You decide what the account can reach when you create it, so you can give it
  only the access the work needs.
</Callout>

## When an interface changes [#when-an-interface-changes]

Websites change: a button moves, a page gets a new layout, a menu is renamed. A person would look around and find the new spot, and so does the agent. It reads the page the way you do, so it can usually work out a changed interface on its own instead of needing someone to rebuild the workflow.

## Sign-in steps [#sign-in-steps]

Some tools ask for more than a password, such as a verification code, a CAPTCHA, or a multi-step sign-in. The agent works these out the way a person would, using credentials kept in its 1Password vault. If a particular tool has an unusual sign-in, mention it during setup so it can be confirmed ahead of time.

<Callout title="A stopped run beats a wrong guess" type="warn">
  If the agent cannot tell what a page is asking for, it does not guess. The
  run stops and surfaces as an exception so your team can look at what
  happened. See [Validation & Exceptions](/concepts/validation-and-exceptions).
</Callout>

## Example: checking order status on a supplier portal [#example-checking-order-status-on-a-supplier-portal]

Say a supplier gives you a portal to look up the status of your orders, and the portal has no API. Today someone on your team logs in each morning, searches for each open order, and copies the status into your own records.

A browser agent can do that lookup using its dedicated account:

<figure style="{ margin: &#x22;1.5rem 0&#x22; }">
  <video preload="metadata" style="{ width: &#x22;100%&#x22;, borderRadius: &#x22;0.5rem&#x22; }" aria-label="An animation of a browser agent in a customer portal. The agent types a username on the sign-in page, opens the Orders page, searches for order ORD-1042, and reads the result: status Shipped, expected October 28. A label at the end says the agent reads the status on screen.">
    <source src="/docs/browser-agents/portal-lookup.mp4" type="video/mp4" />
  </video>

  <figcaption style="{ fontSize: &#x22;0.875rem&#x22;, opacity: 0.8, marginTop: &#x22;0.5rem&#x22; }">
    An animation of the lookup below, in a made-up portal: the agent signs in,
    searches for an order, and reads its status on screen.
  </figcaption>
</figure>

<Steps>
  <Step>
    ### Log in [#log-in]

    The agent signs in to the portal with its own account.
  </Step>

  <Step>
    ### Look up each order [#look-up-each-order]

    It goes to the order search page and looks up each open order.
  </Step>

  <Step>
    ### Read the status [#read-the-status]

    It reads the status shown on screen.
  </Step>

  <Step>
    ### Record what it found [#record-what-it-found]

    It records the result, so your team can see what was read and where.
  </Step>
</Steps>

If the portal is redesigned, the agent adapts to the new layout. If it ever cannot tell what a page is asking for, the run stops and raises an exception. If your process needs a person to approve a step, such as acting on a delayed order, the agent waits for that approval. Reading the portal is something the agent does. Approving is a decision a person makes. See [Human in the Loop](/concepts/human-in-the-loop).

## Where to go next [#where-to-go-next]

<Cards>
  <Card title="Integrations" href="/concepts/integrations">
    How API and browser connections differ, and how agents work inside your existing systems.
  </Card>

  <Card title="Connecting Systems" href="/concepts/connecting-systems">
    How systems are connected and what the setup involves.
  </Card>

  <Card title="Validation & Exceptions" href="/concepts/validation-and-exceptions">
    What happens when a run stops, and how your team reviews it.
  </Card>

  <Card title="Security & Data" href="/platform/security-and-data">
    What an agent can reach and where your data stays.
  </Card>
</Cards>