Agents
What agents are
An agent is a browser automation you describe in plain language instead of scripting. You give it a mission and a starting URL; it opens a real cloud browser, works through the site — navigating, filling forms, clicking, reading — and returns data that matches the output schema you defined.
The difference from a scraper is maintenance. A scraper is a list of CSS selectors that breaks when the site is redesigned. An agent reads the page it is on and works out what to do, so a moved button or a renamed field does not require a code change.
Agents are rolling out gradually. If the section is not visible in your organization yet, contact support to enable it.
Anatomy of an agent
An agent is five pieces of configuration: what to do, where to start, what it knows going in, what it must bring back, and where that goes. Everything else is handled for you.
| Part | What it is | Example |
|---|---|---|
| Mission | A plain-language instruction. Write it as you would brief a colleague, including how to handle the awkward cases. | “Log in with the provided credentials, open Orders, and record the current unit price for each part number.” |
| Start point | The URL the agent opens first. | https://portal.acme-supply.com/login |
| Variables | Values the mission can refer to. Either fixed literals or pulled from a flow run's extracted fields. | part_number |
| Captures | The typed schema of what you want back. The agent's answer is validated against it, so the output is always structured. | unit_price |
| Delivery | Where the captured output goes when the run finishes. | Email, webhook, or a Bucket row |
Nearly every disappointing agent run traces back to a vague mission. Name the exact buttons and page titles, say what to do when a lookup returns nothing, and say when to stop. A mission that reads like a runbook works; one that reads like a wish does not.
Output captures: the schema the agent must fill
Captures declare the shape of the result. Each one has a name and a type, and nested structures are supported, so an agent can return a list of objects rather than a blob of text you have to parse afterwards.
| Capture type | Returns | Use it for |
|---|---|---|
| Text | A string | Names, statuses, reference numbers, free text |
| Number | A decimal | Prices, quantities, rates |
| Integer | A whole number | Counts, stock levels |
| Boolean | True or false | In stock, approved, exists |
| Date | A date as text | Delivery dates, expiry dates |
| Object | A nested group of fields | One record with several attributes |
| List | A repeating structure | A table of results — one entry per row |
| File | A downloaded file | Invoices, statements or reports the agent has to fetch |
Every capture is optional. If the agent finds four of five values, the run returns the four it found rather than failing outright — you keep the partial result and can see exactly what is missing.
Chaining a flow to an agent
The strongest setup is extract, then act. A flow pulls fields out of a document, and the agent uses those fields as its inputs — so the document you received drives what happens on someone else's website, with no copying by hand.
- 1Open the flow's settings.
- 2Link the agent to the flow.
- 3Map extracted fields onto the agent's input variables.
- 4Run the flow — when extraction completes, the agent takes over automatically.
Variables come from one of two places, and you can mix them in a single agent:
| Variable source | Where the value comes from |
|---|---|
| Static | A fixed value stored on the agent — a portal username, a fixed warehouse code. |
| From a flow run | A field from the triggering run's output. If the flow has a Cleaner, the value is taken from the cleaned output — so conversions and computed columns are already applied. |
Worked example. A purchase order arrives by email. The flow extracts one row per line item with a part number. A Cleaner normalises the part numbers. The linked agent then logs into the supplier portal, looks up each part, captures the live unit price and lead time, and writes the results into a Bucket next to what the PO said — so the discrepancy is visible before anyone approves the order.
Downloading files
Give an agent a file-typed capture and it can fetch documents as well as read them — a statement behind a login, an invoice PDF from a portal. Files are collected during the run and stored when it finishes, then delivered as time-limited links.
| Limit | Value |
|---|---|
| Largest single file | 25 MB |
| Total files per run | 100 MB |
| How files reach you | A link in the delivered output, valid for a limited period |
Exceeding a limit does not kill the run — the agent is told the file was too large and carries on with the rest of the mission.
Watching a run
Every agent run streams its steps as they happen, and you can open a live view of the browser session to watch it work. Finished runs keep a replay, so you can see exactly what the agent did rather than inferring it from the output.
- A step-by-step log of what the agent did, in order
- The captured output, and any captured files
- Run metrics: duration and credits used
- A live session while the run is in progress, and a replay afterwards
- Run and session identifiers, for support requests
When an agent returns the wrong value, the replay usually shows why in seconds — it logged into the wrong tenant, or the search returned no results and it guessed. Fix the mission, not the schema.
Limits and credits
Agent runs are bounded so a mission that goes wrong cannot run forever. Two limits apply — a maximum runtime and a cap on how many steps the agent may take — and both can be tightened per agent.
| Limit | Default | What happens when it is hit |
|---|---|---|
| Maximum runtime | 10 minutes | The run is stopped and marked failed. |
| Step cap | 25 steps | The agent stops taking actions; the run ends without a complete result. |
| Cost | 3 credits per minute | Wall-clock time is rounded up to the next whole minute, with a one-minute minimum. |
Runtime is billed whether the run succeeds or fails. A mission that loops until it hits the ten-minute ceiling still costs the full ten minutes. Set a shorter maximum runtime on agents you are still tuning, and test with a low limit before raising it.
Starting a run requires a positive credit balance. The exact cost is not known in advance — it depends how long the browsing takes — so Tavnit checks that you have credits before it starts and charges the actual minutes when the run ends.
Where results go
An agent's captured output can be delivered three ways, or left in the app for you to read. Delivery happens once the run completes, and file captures are turned into fetchable links first.
| Delivery | What arrives |
|---|---|
| The captured output as formatted JSON, to the addresses you configure. | |
| Webhook | A POST to your endpoint with the agent, the run, its status and the captured output — see webhooks. |
| Bucket | One row per run in a Bucket, with captures mapped onto columns. |
| None | The result stays on the run's page in the app. |
Delivery can optionally include the input variables the run was given, which makes a Bucket row self-describing: what was asked, and what came back.
Permissions and lifecycle
Creating, editing and deleting agents is restricted to Owners and Admins; members with a suitable role can trigger runs. Agents can be deactivated instead of deleted, and an agent that is wired into an active flow cannot be deleted at all.
- Only Owners and Admins can create, edit or delete an agent
- An inactive agent cannot be run
- An agent linked to an active flow must be unlinked before it can be deleted
- Runs can also be started from an AI assistant via the MCP connector, or from a linked flow
Agents are designed to be triggered from the app, from a linked flow, or from an AI assistant. If you need to start one from your own system, the agent's ID is on its detail page — but the practical route for most integrations is to trigger the flow and let the chained agent follow, rather than calling the agent directly.