Writing AI actions

An AI action takes a natural-language goal instead of a click-by-click series of steps. Read that page first for how the agent plans, caches, and self-heals. This page covers the patterns: when to use each one and what it costs.

Rolling up a Google Flights search

The examples below use a flight search on Google Flights to show the core technique of the AI action step. You take a series of low-level steps whose only purpose is to reach some state, then collapse them into a single goal that names that state. The imperative version below spells out every click and keystroke. The intent, a flight search between two cities on two dates, gets buried in the mechanics, and a reader has to reconstruct it from the steps.

flight-search.test.yaml

fileType: momentic/test/v2
id: flight-search-preset
url: https://www.google.com/travel/flights
steps:
  - click: The "Where from?" origin field
  - type:
      text: San Francisco
      into: The origin field
  - click: The "San Francisco" airport option in the suggestions
  - click: The "Where to?" destination field
  - type:
      text: New York
      into: The destination field
  - click: The "New York" option in the suggestions
  - click: The Departure date field
  - click: The August 10 date in the calendar
  - click: The Return date field
  - click: The August 17 date in the calendar
  - click: The Search button

The same flow as a single declarative goal:

flight-search.test.yaml

fileType: momentic/test/v2
id: flight-search-goal
url: https://www.google.com/travel/flights
steps:
  - act: |-
      Search for round-trip flights from San Francisco to New York, departing
      August 10 and returning August 17.

Both versions locate controls by description. Preset steps preserve the interaction sequence; an AI action lets the agent choose the sequence needed to reach the goal. Changes to the UI may require a new resolution or a test update in either form.

Assert the end state with a postcondition

The agent cannot pass its own step. When it claims success, an independent reviewer reads the settled page state, the actions the harness recorded, and your goal, then decides whether the goal’s outcome happened. You write an explicit postcondition when the goal alone does not tell the reviewer what “done” should look like. For a flight search, require rendered results for the requested cities and dates. A postcondition is a protected requirement the reviewer must also confirm, and the agent cannot skip or edit it.

flight-search.test.yaml

fileType: momentic/test/v2
id: flight-search-verified
url: https://www.google.com/travel/flights
steps:
  - act:
      goal: |-
        Search for round-trip flights from San Francisco to New York, departing
        August 10 and returning August 17.
      postcondition: |-
        The results page lists round-trip flights from San Francisco to New
        York for the August 10 to August 17 dates, and each result shows a
        price and a departure time.

A postcondition spells out what “done” means for that act. When you chain steps, each one hands off to the next at a known state instead of wherever the goal happened to stop. The section on guards below goes deeper and covers preconditions too.

Group goals into semantic phases

The rollup above has a flip side: do not collapse an entire test into one giant goal either. Aim for a few AI actions that each map to a phase a reader would recognize. Each act becomes a labeled checkpoint in the trace, so when something fails you know which phase broke.

browse-products.test.yaml

fileType: momentic/test/v2
id: browse-products
url: https://www.saucedemo.com/
steps:
  - act: Log in with username 'standard_user' and password 'secret_sauce'.
  - act: Sort the products by price from low to high.
  - act: Open the detail page for the first product in the list.

Keep each goal focused on one checkpoint, such as logging in, sorting, or opening a product. This makes the generated trace and failures easier to review. Split goals that contain several independent outcomes.

Guardrails with preconditions and postconditions

Use precondition and postcondition as guardrails for the start and end states of a V3 AI action. The agent cannot edit or skip these assertions. A failed precondition prevents the generated flow from running. If the postcondition is unmet, the agent keeps working toward it or fails the step.

url: https://www.saucedemo.com/
steps:
  - act:
      precondition: A login form with Username and Password fields is visible.
      goal: Log in with username 'standard_user' and password 'secret_sauce'.
      postcondition: The product inventory list is shown.

Use a precondition to fail fast and clearly when setup is wrong (wrong page, not logged out) instead of letting the agent retry without a plan. Add an explicit postcondition whenever the goal itself does not pin down the end state of a state-changing flow. These guards check state; they do not prescribe every intermediate interaction the agent chooses. Use preset steps when you need to control the interaction sequence.

Pre- and post-conditions follow the same rules as AI check steps. Assert structural, qualitative facts (“a confirmation is shown”). Use deterministic element or JavaScript checks for exact counts, prices, timestamps, or IDs.

Feeding the agent context it cannot infer

Supply test-specific data the agent cannot infer, such as an invite code, a specific record, or credentials, through variables. Reference them with {{ env.NAME }} in the goal.

url: https://www.saucedemo.com/
steps:
  - act:
      goal: |-
        Log in with username '{{ env.QA_USERNAME }}' and password
        '{{ env.QA_PASSWORD }}'.
      postcondition: The product inventory list is shown.

Branching on UI that only sometimes appears

Some UI appears in only some runs: cookie banners, “what’s new” modals, A/B interstitials. When the agent resolves that UI, the cache stores an If <condition> branch with the steps for that case, plus an optional else branch. Later runs re-evaluate the condition against the live UI and replay only the branch that applies, so a flow that differs between runs no longer needs the agent every time. The condition is a check, so it follows check rules: write the goal so the condition can be a structural, qualitative fact (“a cookie banner is shown”). Everything inside the branch replays from cache. If the steps in a branch no longer match the UI, the cache busts and the step heals like any other cached step. See the step cache.

Limits

An AI action has an execution budget. State a finite stopping point so the agent can complete or report a failure within that budget.

No unbounded loops

The agent will not “keep clicking Next until the list is empty” forever. It runs a bounded plan with a retry budget, then stops instead of repeating an ineffective interaction. If your intent is to repeat until a condition holds, express the bound explicitly and keep it finite.

Avoid Keep loading more results until every order is on screen.
Prefer Click "Load more" up to 3 times, then stop.

Overview

Migrate to Momentic

Frameworks

Use cases

Triage

AI actions

Authentication

Page interactions

Test data & variants

Visual testing

Reporting

Upgrading

Writing AI actions

Rolling up a Google Flights search

Assert the end state with a postcondition

Group goals into semantic phases

Guardrails with preconditions and postconditions

Feeding the agent context it cannot infer

Branching on UI that only sometimes appears

Limits

No unbounded loops

​Rolling up a Google Flights search

​Assert the end state with a postcondition

​Group goals into semantic phases

​Guardrails with preconditions and postconditions

​Feeding the agent context it cannot infer

​Branching on UI that only sometimes appears

​Limits

​No unbounded loops

​Related

Rolling up a Google Flights search

Assert the end state with a postcondition

Group goals into semantic phases

Guardrails with preconditions and postconditions

Feeding the agent context it cannot infer

Branching on UI that only sometimes appears

Limits

No unbounded loops

Related