Fill the form once.
Not field by field.

The goal and the values

{
  "goal": "Search one-way flights for 1 adult",
  "mode": "ultrafast",
  "values": {
    "From": "Zurich",
    "To": "London",
    "Date": "2026-09-20"
  }
}

This is also the shape a coding agent passes through MCP. In the side panel, say the same thing in a sentence and switch the composer to Fast.

What happens

1. The page becomes an indexed table of elements: role, name, value, placeholder.
2. The decision model returns one operation and one element index, for example TYPE_TEXT [4].
3. The executor checks that the page and the target are unchanged, types the value with real key events, and observes what happened.
4. A field that rejected the value is reported. A moved button costs another decision, not a misclick.
5. When the goal is reached, a DONE claim gets a second yes/no check before the run reports success.

Field names do the boring work

A field named like a value key is filled without a model call. “Where to?” matches To, “Departure date” matches Date. The text is taken from your goal and values only, never from page text, so a page cannot inject a value into a field.

What to check

• The values, before you submit. Watch the fields fill on the first run.
• That the date format matched what the site wanted. A rejected value is reported, but a plausible wrong one is not.
• The confirmation page, not the model's summary of it.

What can go wrong

• A custom date picker. Some pickers are canvas or shadow DOM; Fast may miss them. Fill that field by hand and re-run from there.
• A cross-origin iframe. Payment and login widgets often sit in one. The field is not in the indexed table.
• A file upload. There is no upload tool, so a form that needs a document stops at that step.
• A CAPTCHA. Fast cannot solve it. Stop, solve it yourself, and resume.
• A validation you cannot see. The run reports a rejected value when the page changes; silent validation needs a human look.