Plan the fill before touching the page

Your agent has a contact form to complete. It knows the customer's email address. It doesn't know which subscription the customer wants.

Don't guess the subscription.

form-fill-plan, in the browser-workflow cluster, is for preparing browser actions from static HTML. The useful boundary is between deciding what to enter and executing those decisions against a live page.

Start with the form. Give the planner a specific goal and the data you're allowed to use. Then check the proposed actions against the fields that still need an answer.

A plan isn't permission to submit.

Give the planner the actual form

Consider this HTML snapshot: 

<form id="demo-request">
  <label for="email">Work email</label>
  <input id="email" name="email" type="email" required>

  <label for="plan">Subscription</label>
  <select id="plan" name="plan" required>
    <option value="">Choose a subscription</option>
    <option value="monthly">Monthly</option>
    <option value="annual">Annual</option>
  </select>

  <label for="notes">What would you like to discuss?</label>
  <textarea id="notes" name="notes"></textarea>

  <button type="submit">Request a demo</button>
</form>

Keep the labels. Keep the option values, too. The visible text “Annual” helps interpret the choice, while annual is the value a browser action would select.

The empty option matters. It tells the caller that leaving the subscription unchanged doesn't answer the required question.

And keep the submit button in the snapshot. The caller needs to distinguish entering information from sending it.

Static HTML has limits. It doesn't establish that a field is currently visible or that the live page still matches the snapshot. Your execution step needs to check those conditions.

State what success means

“Complete this form” leaves too much room for interpretation. Does completion include submission? Can the agent choose a subscription?

Use a tighter goal: 

Prepare the demo request using the supplied customer data.
Leave the subscription unresolved because the customer hasn't
chosen one. Don't submit the form.

Then supply known values without filling gaps: 

{
  "email": "[email protected]",
  "notes": "We'd like a demo for a five-person support team."
}

These examples show the information to prepare for the call. They aren't a documented request schema for form-fill-plan.

Missing data should stay missing. An annual subscription isn't justified by the size of the customer's team, and the first nonempty option isn't a default the agent can invent.

Check actions against unresolved fields

Before execution, turn the returned plan into a review your caller can enforce. Here's an illustrative caller-side record, rather than a claimed endpoint response: 

{
  "approved_actions": [
    {
      "target": "#email",
      "operation": "fill",
      "value": "[email protected]"
    },
    {
      "target": "#notes",
      "operation": "fill",
      "value": "We'd like a demo for a five-person support team."
    }
  ],
  "unresolved_fields": [
    {
      "target": "#plan",
      "reason": "The customer hasn't chosen a subscription.",
      "blocks_submission": true
    }
  ],
  "submission_allowed": false
}

Check each proposed value against the supplied data. Reject an action that selects annual, even if the rest of the plan looks correct.

Then check coverage. Did the review account for the required subscription field? An action list containing two valid fills can still leave the form incomplete.

Look at submission separately. The goal explicitly excludes it, so a proposed click on the submit button must fail review regardless of whether every required field has a value.

Recheck the page before execution

Planning from a snapshot doesn't freeze the browser.

Before applying an approved action, confirm that its target identifies the intended control on the current page. If the subscription choices have changed, stop and prepare a fresh plan from updated HTML.

For an agent router, route a request here when the job is to prepare form actions for review. Keep execution behind the caller's checks.

In this example, the next customer question is short: “Monthly or annual?” Once the customer answers, add that value and review the revised plan. Submission still needs authorization because the original goal didn't grant it.