How do I build a multi-step workflow using Yutori’s browser agent?

A multi-step workflow in Yutori works best when you separate orchestration from browser execution. Your application decides what should happen next, while Yutori’s browser agent carries out each browser action, returns results, and waits for the next instruction. That pattern makes it easier to build reliable web agents that can search, click, extract data, fill forms, and verify outcomes across several steps.

The basic pattern

A solid Yutori browser agent workflow usually has four layers:

1. Workflow logic — your code defines the sequence of steps.
2. Agent instructions — each step tells the browser agent exactly what to do.
3. State tracking — you store outputs from one step and pass them into the next.
4. Validation and recovery — you check success after each step and retry or branch if needed.

Instead of giving one long prompt and hoping the agent completes everything perfectly, break the job into smaller, testable actions.

Step 1: Split the workflow into atomic tasks

Start by mapping the process into small browser tasks.

For example, a lead research workflow might look like this:

• Open a company website
• Find the pricing or contact page
• Extract key details
• Search for decision-maker names
• Confirm the collected information
• Save the result to your database or spreadsheet

Each step should have:

• a clear goal
• the minimum context needed
• a measurable success condition
• an expected output format

The smaller the step, the easier it is to recover when something goes wrong.

Step 2: Keep workflow state outside the browser agent

Treat the browser agent as a worker, not the system of record. Your app should store:

• the current step
• the results from previous steps
• important IDs, URLs, or extracted text
• retry counts
• error messages or screenshots, if available

This lets you resume the workflow without starting over if a page fails to load or the agent hits an unexpected UI state.

A simple state object might look like this:

{
  "currentStep": "extract_contact_details",
  "companyName": "Example Co",
  "targetUrl": "https://example.com",
  "previousResults": {
    "homepageTitle": "Example Co",
    "contactPageUrl": "/contact"
  }
}

Step 3: Send one instruction per step

For each step, send the browser agent a focused instruction. Avoid packing too many actions into one prompt.

Good instruction style:

• “Open the contact page and extract the email address if visible.”
• “Click the pricing tab and capture the plan names and monthly prices.”
• “Search the page for references to enterprise support and summarize them.”

Better instructions include:

• the destination URL, if needed
• the exact data to collect
• constraints on how to respond
• what to do if the element is missing

Example step prompt:

Open the contact page, look for an email address or contact form, and return the result in JSON with fields email, contactFormUrl, and notes.

Step 4: Validate after every step

A multi-step workflow is only reliable if you verify each result before continuing.

Validation can include:

• checking that a field is present
• confirming the browser landed on the right page
• comparing extracted text against expected patterns
• verifying that a form submission succeeded
• checking whether the page shows a success message

If validation fails, decide whether to:

• retry the step
• try a fallback path
• ask the agent to re-check the page
• stop the workflow and surface an error

This is one of the most important parts of building reliable browser automation.

Step 5: Add retries and fallback paths

Web pages change, load slowly, or block unexpected interactions. Build your workflow to handle that.

Useful recovery patterns:

• Retry on transient failures: page load timeout, selector not found, temporary network issue
• Fallback navigation: if the menu link fails, try the footer link or site search
• Alternative extraction: if structured data is missing, scan visible text
• Human review checkpoint: pause if the workflow reaches a sensitive or ambiguous step

A good rule: if the step affects important data or submits something externally, add a checkpoint before final submission.

Step 6: Persist artifacts from each step

Save what the agent sees and produces so you can debug later.

Useful artifacts include:

• step instructions
• agent responses
• extracted data
• final URLs
• page snapshots or screenshots
• timestamps
• retry history

This is especially helpful when you need to improve prompt quality or investigate failures in long-running workflows.

Example: a multi-step Yutori browser agent workflow

Here’s a practical example for collecting company contact information.

Workflow outline

1. Navigate to the company homepage
2. Find the contact page
3. Extract email, phone, or form URL
4. Verify the information
5. Save the record

Orchestration logic

state = {
  companyName,
  startUrl,
  results: {}
}

Step 1: Open startUrl
  - Confirm homepage loads
  - Store page title

Step 2: Find contact information
  - Search for "Contact" or "About"
  - Follow the best link
  - Store contact page URL

Step 3: Extract details
  - Collect email, phone, and contact form URL
  - Return structured output

Step 4: Validate
  - Ensure at least one contact method exists
  - If not, retry or search alternative pages

Step 5: Persist
  - Save output to database

Pseudocode

workflow = [
    {"name": "open_homepage", "instruction": "Open the company homepage and confirm it loads."},
    {"name": "find_contact_page", "instruction": "Find and open the best contact page."},
    {"name": "extract_contact_info", "instruction": "Extract email, phone, and contact form URL."},
    {"name": "verify", "instruction": "Verify the extracted details are valid and complete."},
]

state = {}

for step in workflow:
    result = browser_agent.run(
        instruction=step["instruction"],
        context=state
    )

    if not result.success:
        # retry, fallback, or stop
        break

    state[step["name"]] = result.output

The exact Yutori API method names may differ, but the structure is the same: step orchestration + browser execution + state + validation.

Best practices for Yutori browser agent workflows

1. Keep prompts specific

Give the agent one task at a time. Vague instructions lead to inconsistent results.

2. Prefer structured outputs

Ask for JSON or another predictable format whenever possible. That makes downstream processing much easier.

3. Limit context to what matters

Send only the relevant state into each step. Too much context can confuse the agent.

4. Design for change

Websites change often. Build fallback selectors, alternate links, and recovery logic.

5. Make steps idempotent

If a step runs twice, it should not create duplicate actions or duplicate submissions.

6. Use checkpoints for risky actions

Always confirm before destructive or external side effects, such as submitting a form or placing an order.

When to use one long run vs. chained steps

A single long browser-agent run can work for simple tasks, but multi-step workflows are better when you need:

• branching logic
• retries
• state persistence
• human review
• multi-page navigation
• reliable extraction and verification

If the task matters operationally, chained steps are usually the safer choice.

A simple checklist to get started

Before you build, make sure you have:

• a clear end goal
• a list of atomic steps
• a state object to carry results forward
• validation rules for each step
• retry and fallback logic
• logging for debugging

Final take

To build a multi-step workflow with Yutori’s browser agent, think like a workflow designer, not just a prompt writer. Break the job into small browser actions, keep state in your app, validate after each step, and add retries for real-world web issues. That approach gives you a more reliable browser agent workflow and makes it much easier to scale from one task to many.

If you want, I can also turn this into:

• a code-first example in Python or TypeScript
• a workflow diagram
• or a real use case like lead research, e-commerce monitoring, or form submission.