Skip to main content
Asteroid implements browser automation as graph workflows: a simple but powerful way to break complex tasks into small, reliable components. Instead of one large “do everything” agent, your automation is built from nodes (focused subtasks) linked by transitions (rules that determine what happens next). This structure makes your agents:

Reliable

Each node handles a narrow responsibility, reducing ambiguity and improving success rates

Observable

Every state, transition, and action is visible, making debugging and monitoring effortless

Composable

Mix AI actions, Playwright scripts, API calls, navigation, and outputs seamlessly

In Control

Assign different models, permissions, and capabilities to each part of your workflow

​
Nodes & Transitions

Asteroid workflows are built from two core concepts: nodes and transitions.

​
Nodes

Nodes represent individual steps of your automation. They come in a range of types, depending on the nature of their subtask:

AI Task Node

Instruct an LLM to interact with the webpage

Playwright Node

Use JavaScript Playwright scripts for deterministic actions

API Node

Make HTTP calls to external services to fetch, send, or process data

URL Node

Navigate directly to a URL

Output Node

End the execution and return an outcome label plus structured results

​
Transitions

Transitions define how the workflow moves between nodes:
  • Agent-driven transitions: The AI detects when a subtask is complete and moves forward
  • Deterministic transitions: Code or conditions trigger movement (e.g., “element X appeared”)
This hybrid architecture gives you the freedom to pair AI reasoning with deterministic logic—ideal for real-world, multi-step browser flows.
Curious why we chose this architecture? Read our deep dive: Graph-Powered Browser Agents.

​
Context Management

​
Local context

Each node receives only the information it needs for its subtask. This prevents context pollution, reduces reasoning drift, and makes each step more deterministic.

​
Passing information between nodes

When data must flow between steps, you should use:
  • Scratchpad: store information in a file shared by nodes
  • Query Context: allow the LLM to query values from earlier nodes
This model avoids “giant prompts” and encourages clean, modular design—similar to strong function boundaries in software engineering.

​
Workflow Design Best Practices

​
1. Start simple

Begin with:
  • One AI Task node, and
  • One Output node
This helps validate the core task before introducing structure.

​
2. Add nodes as complexity grows

Introduce more nodes when:
  • You interact with multiple portals or move between distinct URLs
  • The workflow involves separate tabs or pages within one portal
  • A subtask becomes long or has multiple sub-steps
  • You want different models or timeouts for different stages
  • You’ve gained grounded knowledge and can safely split steps
A good rule of thumb:
If a node needs more than a paragraph of instructions, it should probably be split.
Each node should represent a clear, single intention, such as: “Fill driver information” | “Upload documents” | “Retrieve quote”.

​
4. Use descriptive naming

Clear names make your graph self-documenting:
  • Agent Name – what the whole flow accomplishes
  • Node Names – the subtask (“Drivers Node”, “Billing Node”)
  • Variables – reflect real-world meaning (customer_id, doctor_note)
  • Outcome labels – predictable and explicit

​
5. Always define failure paths

Every AI Task node should have a Failure transition to an output node. Failure paths make debugging easier and enable safe recoverability.

​
6. Choosing the right node type

  • Prefer using URL nodes over go to url tool
  • Prefer using Learn & Compile over pure Playwright nodes

​
Examples Task Decomposition

Here are high-level examples of how complex workflows break naturally into nodes.

​
Insurance Carrier Quoting

Task: Generate an insurance quote for a customer. Nodes:
  • Go to carrier (URL node)
  • Login (Playwright node)
  • Create quote (AI Task node)
  • Insert driver info (AI Task node)
  • Output quote (Output node)

​
Healthcare EHR Data Entry

Task: File a patient consultation on an EHR. Nodes:
  • Go to EHR (URL node)
  • Login (Playwright node)
  • Lookup patient (AI Task node)
  • Fill consultation (AI Task node)
  • Confirm success (Output node)

​
Property Management Workflow

Task: Update the lease information for a tenant. Nodes:
  • Go to portal (URL node)
  • Login (Playwright node)
  • Search tenant (AI Task node)
  • Update lease info (AI Task node)
  • Return updated records (Output node)
These flows remain readable, predictable, and easy to iterate on, far more than a single long-running “mega-agent.”