TL;DR
WEBDART is a decomposition principle for complex tasks given to LLM agents. Instead of having the model do everything at once (search for information + filter + analyze), the task is split into three sequential stages: navigation (collecting data from every source), information extraction (structuring it into a single format), and execution (applying filters and analysis). Each stage focuses on one skill, lightening the load on the model.
Complex tasks fail because of cognitive overload: the model tries to simultaneously remember what it has already seen, apply filters, count, and plan the next step. For example, the task "find the top 3 products by number of reviews in the $100-$1,000 range" means opening dozens of pages, remembering which ones fit the price, tracking review counts, and constantly comparing. When all of that happens at once, the model loses focus, skips information, or mixes up the criteria. The researchers found that accuracy drops from 46.6% on simple tasks to 8.0% on complex ones (WebChoreArena).
The method uses a conservative strategy: first collect EVERYTHING (don't filter while collecting — that's a source of errors), then structure the data into a table, and only then apply the constraints via code or logic. If during collection something turns up that simplifies the task (filters or sorting on the site), the model revises the plan on the fly (dynamic re-planning) — it uses the filter it found instead of manually going through every page.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
STEP 1: NAVIGATION (data collection)
└─ Collect ALL pages that might contain the information you need
└─ Do NOT filter along the way — that increases errors
└─ If you find a useful element (filter/sorting) → revise the plan
STEP 2: INFORMATION EXTRACTION (structuring)
└─ From the collected pages, pick only the relevant ones
└─ Extract the needed fields into a single format (table/JSON)
STEP 3: EXECUTION (analysis)
└─ Apply the filters and constraints
└─ Run the analysis (sorting, counting, ranking)
└─ Output the final resultAll three steps run in sequence. You can do them in a single conversation with the LLM or split them into separate requests for complex tasks.
Example in Action
Task: Pick a CRM for a small online clothing store in Denver. Criteria: customer and order tracking, integration with WhatsApp and Instagram DMs, under $150/month for a team of 5, a solid mobile app, good reviews. You need a top 3 with reasoning.
Prompt:
Task: pick a CRM for an online store.
Let's break it into 3 stages:
STAGE 1 — COLLECT:
Find ALL CRM systems on the US market that:
- Work with e-commerce
- Have a mobile app
Do NOT filter by price or features at this stage — just collect the list.
If you come across ready-made roundups/rankings while searching — use them.
STAGE 2 — STRUCTURE:
For each system on the list, collect:
- Name
- Price for 5 users/month
- Integrations (WhatsApp, Instagram DMs — yes/no)
- Tracking features (customers, orders)
- Average review score
Format it as a table.
STAGE 3 — ANALYZE:
Filter:
- Price under $150/month (for 5 people)
- Has WhatsApp AND Instagram DMs
- Score 4.0+
From what's left, pick the top 3 by features-to-price ratio.
Give a short rationale for each pick.
---
Work through it in order. Show the intermediate result after each stage.Result:
The model completes the task in three steps. In the first stage it gathers a broad list of CRMs (15-20 options) without wasting effort on filtering. In the second it structures the data into a table with clear fields. In the third it applies all the filters at once to the finished table and picks the best options. You see intermediate results after each stage and can adjust the criteria if needed.
Why It Works
The problem: When a model tries to search, filter and analyze all at once, it's like a person reading an article while simultaneously trying to write the summary. Attention splits: now on finding new things, now on judging what's been found, now on remembering. The model misses information, mixes up criteria, and applies filters incorrectly.
LLM strength: Models excel at focused tasks — when only one skill is needed at a time. Finding and collecting information is one task. Structuring scattered data is another. Applying logic and constraints to a finished table is a third.
How the method uses this: Splitting into stages removes the cognitive load. In the collection stage the model simply looks for EVERYTHING that could be relevant, without thinking about filters — a conservative approach that lowers the risk of missing something important. In the structuring stage it focuses solely on extracting data into one format — no analysis, just transfer. In the final stage it gets a clean, ready table and applies filters and logic to it — something it does well, because the data is already collected and there's no risk of missing anything.
Bonus: The method gives you control levers:
- Tune how conservative the collection is: if the task is simple and there's a single source, you can filter right during collection
- Drop the intermediate outputs: if you don't need to see the stages, merge the steps into one request
- Add a re-planning condition: state explicitly "if you find a ready filter/ranking, use it instead of collecting manually"
- Split into separate conversations: for very complex tasks, run each stage in a new chat so the context doesn't bloat
Prompt Template
Task: {describe the task with criteria}
Let's break it into 3 stages:
STAGE 1 — COLLECT:
Collect ALL {data type} that {basic criteria without filters}.
Do NOT apply {specific constraints} at this stage — just collect as broadly as possible.
If you find ready-made roundups, filters or tools that simplify the task — use them and revise the plan.
STAGE 2 — STRUCTURE:
For each item, extract:
- {field 1}
- {field 2}
- {field 3}
- ...
Format it as {format: table/JSON/list}.
STAGE 3 — ANALYZE:
Apply the filters:
- {criterion 1}
- {criterion 2}
- ...
From what's left, {action: pick the top N / find the best / count}.
---
Work through it in order. Show the intermediate result after each stage.How to fill it in:
{data type}— what you're looking for: CRM systems, coworking spaces, articles, products{basic criteria}— broad boundaries WITHOUT hard filters: "the US market", "the electronics category"{specific constraints}— the exact filters you'll apply AFTER collection: price, rating, specific features{field N}— what data to extract: price, specs, reviews, contacts{format}— how to structure it: table, JSON, bulleted list{action}— what to do with the filtered data: rank, sum up, compare
Filled-in example:
Task: Find the 3 best hotels in San Diego for a family with kids
STAGE 1 — COLLECT:
Collect ALL hotels in San Diego with kid-friendly amenities.
Do NOT filter by price or star rating — just collect broadly.
STAGE 2 — STRUCTURE:
Extract: name, star rating, price per night (family of 2+2), kid-friendly amenities, reviews.
Format it as a table.
STAGE 3 — ANALYZE:
Filters: 4+ stars, under $350/night, rating 4.5+
Pick the top 3 by value for money.Limitations
⚠️ Not for simple tasks: If a task can be solved with one search or one request, decomposition will only slow things down. The method shines when the task requires collecting data from multiple sources + applying multiple filters + analyzing the results.
⚠️ Needs structure: The method works when you can cleanly separate "what to collect" from "how to filter". For creative or subjective tasks (write in a certain style, judge creativity) the split can feel artificial.
⚠️ Conservative approach = more data: Collecting "everything" in the first stage inflates the volume of intermediate data. For tasks where the source is small or the filters are obvious from the start, you can filter right during collection.
⚠️ Tokens spent on intermediate stages: Three sequential steps = three requests to the LLM. For short tasks that's overkill. For complex ones, the accuracy gain justifies it.
How They Tested It
A team from UC Santa Barbara and Accenture tested the method on WebChoreArena — a benchmark of complex web tasks where agents don't just click buttons but have to gather information from dozens of pages, apply filters and constraints, and draw conclusions. They compared it against four strong baselines (SteP, BrowserGym, AWM, AgentOccam) on three different LLMs (GPT-4o, GPT-4.5, GLM-4.5).
The idea was simple: take a task like "find the top 3 products with the most reviews in the Home Audio category, priced from $1,000 to $9,999" and see what happens when the agent tries to do everything at once (baseline) vs when it first collects all products, then filters by price, then ranks by reviews (WEBDART).
The size of the gap was striking: On the complex WebChoreArena tasks, accuracy rose from 21.6% to 35.3% (+13.7 pp) for GPT-4.5. On the simple WebArena tasks the method performed on par with the baseline agents (48.1% vs 46.6%) — so decomposition doesn't hurt when it isn't needed.
Why such a big effect? The researchers analyzed where ordinary agents break down: they lose information when moving between pages (forgetting what they've already seen), apply filters incorrectly (skipping matching options or grabbing ones that don't fit), and stop too early or too late (not realizing when the task is done). WEBDART removes these problems: conservative collection ensures nothing is missed, structuring into a table gives the full picture, and analysis at the last step doesn't depend on navigation quality.
Bonus from dynamic re-planning: In tasks where the site offered filters or sorting, the agent revised its plan on the fly and used them instead of manually going through pages — this cut the average number of navigation steps from 32.9 to 18.2 (-45%) while accuracy rose from 18.8% to 26.5% in the Shopping category. So the agent isn't just more accurate — it's more efficient too.
Adaptations and Extrapolations
💡 Adaptation for competitor analysis:
Market research often means collecting data on dozens of companies against many criteria. The standard approach — filtering as you go — leads to missing important players.
Task: Find 5 direct competitors of our food delivery service in Austin
STAGE 1 — COLLECT:
Collect ALL food delivery services operating in Austin.
Do NOT filter by business size, pricing or selection — just a list.
STAGE 2 — STRUCTURE:
For each one, extract:
- Name
- Time on the market
- Delivery areas
- Average order value
- Number of partner restaurants
- Unique features
- Approximate market share (if known)
Format it as a table.
STAGE 3 — ANALYZE:
Filters:
- In business 1+ year
- Covers the same areas we do
- Average order value within ±30% of ours
From what's left, pick the top 5 by similarity of business model.
For each, note: the main strength, the main weakness.Difference from the original: Instead of collecting pages on a website, you collect information about companies from different sources. Same principle: go broad first, then filter, then analyze.
🔧 Technique: An explicit checklist instead of "collect everything" → more control
The conservative "collect everything" approach can be too broad. For complex tasks you can give an explicit checklist of what to collect:
STAGE 1 — COLLECT (checklist):
For each candidate, collect:
[ ] Company name
[ ] Core products
[ ] Geographic footprint
[ ] Team size
[ ] Year founded
[ ] Latest funding round (if any)
Go through every source: TechCrunch, Crunchbase, official websites, LinkedIn.
Do NOT filter — collect the data even if a company looks irrelevant.The checklist makes collection more systematic and lowers the risk of missing important fields.
💡 Extrapolation: Combining with ReAct for tasks with uncertainty
WEBDART assumes you know in advance WHAT to collect. But sometimes the criteria only become clear after some initial research. Combining it with ReAct lets you adapt:
STAGE 0 — RECON (ReAct):
Thought: I don't know which criteria matter for choosing a CRM. I'll start with a general overview.
Action: Find the top 10 popular CRMs on the US market
Observation: [list]
Thought: I can see they differ by: price, integrations, industry specialization
Action: Check which integrations each one has
Observation: [data]
Thought: Now it's clear what matters. Moving on to structured collection.
STAGE 1 — COLLECT:
[conservative collection that accounts for the criteria identified]
...The hybrid gives you ReAct's adaptability in the early stage + WEBDART's rigor in the main collection.
Resources
WEBDART: Dynamic Decomposition and Re-Planning for Complex Web Tasks Jingbo Yang, Bairu Hou, Wei Wei, Shiyu Chang, Yujia Bao UC Santa Barbara, Accenture Code: https://github.com/UCSB-NLP-Chang/WebDART