What if responsibilities were unclear?

A browser test says, “Submit the request and check that it succeeded.” The button is easy to find. After clicking it, a confirmation appears. Does the agent close it? Save a screenshot? Read the new status behind it? Has the step finished, or has the next one already started?

People cross these small gaps all the time. An agent can reason through them too. We do not need to script every click before useful automation becomes possible.

That leaves a practical question: when responsibilities are unclear, how much work are we asking the agent to absorb?

Flexibility is something worth buying

A fixed browser script needs its author to decide the route in advance. An agent can inspect the page, locate the relevant field, and work out how to reach the result described in a test. That can be useful when a screen changes or the same task appears in several layouts.

I would not make every uncertain detail a reason to stop a project. If the goal is clear and the actions are within the agreed scope, letting the agent resolve an awkward interaction can be a sensible trade. More reasoning may be cheaper than writing and maintaining another special case.

The trade changes when the missing detail is what counts as success, who may approve a change, or whether a second submission is allowed. Those decisions need an owner. A plausible interpretation from the model cannot establish permission.

Give the different decisions a home

In the browser test-automation code I reviewed, tests are written as numbered steps in Markdown. The model works out how to carry out the current step. Python starts the browser worker, checks the returned records, carries captured values forward, and writes the report.

That gives the work three places to live:

The test author defines the meaning. Which action is intended, what data to use, and which visible result would satisfy the test.
The agent interprets the interface. Find the relevant controls, perform the requested interaction, read the result, and return evidence.
The framework controls progression and records. Dispatch the numbered steps, check their result records and required outputs, record usage, and stop when its configured limits are reached.

The distinction still leaves room for judgement. A result record with the right shape and a screenshot attached does not establish that the agent understood the business outcome correctly. General business checks still depend on the test wording and the agent's reading of the page. Declared structured comparisons have a narrower path: the agent transcribes the data and code compares it.

A small boundary can save a lot of interpretation

The current prompt builder gives each step a fresh agent while keeping the same browser session open. It includes the test header and steps up to the current one, and withholds later steps. Previous agent conversations are not carried into the next prompt.

For the submission example, the instructions say to capture a resulting dialog and stop unless the current step explicitly names a button inside it. Closing a popup may belong to the next checkpoint. The agent should not consume that checkpoint just to leave the page looking tidy.

Withholding future step text reduces the information available to act ahead. It does not remove the browser's ability to click another button. The stop instruction still relies on the agent following it; it is not a separate permission check on each click.

This is useful progress without pretending that every responsibility has become a hard control. The framework chooses which step to dispatch. The agent still has to respect the action boundary inside that step.

When the action finishes but the record does not

There is a revealing recovery path in the worker. An agent can finish an interaction and return without the structured result line the framework expects. The browser may already have changed state, while the runner still lacks a usable record.

Repeating the whole step could repeat a submission. The worker therefore first tries a short recovery call when the agent has submitted its response but the record is missing. The recovery agent is told to observe the current page, gather the missing evidence, and return the record without clicking, typing or navigating.

That is a concrete example of paying for more interpretation: another agent call to reconcile what happened with what was recorded. The recovery has an agent step limit, but its observe-only behaviour is an instruction using the same browser environment. It should not be described as an independently enforced read-only interface.

Where the extra cost goes

The model bill is one part of the trade. The work can also show up as:

More observation. Read another section, inspect a dialog, or find the exact value needed for evidence.
More checking and recovery. Repair a missing result record or resolve a mismatch between the expected checkpoint and the live page.
More review. Someone must decide whether a confusing run found an application defect, an unclear test, or an agent mistake.

These are possible costs of the design, not a measured surcharge. Some extra observation is necessary even in a well-defined test. The code review does not show what fraction comes from unclear responsibilities, or whether the increase is small.

The runner records token usage and estimates model cost from configured input, cached-input and output rates. Its configured token budgets are checked between attempts and steps, allowing it to stop further work. That does not prevent an in-progress attempt from crossing the threshold, and a token limit does not account for a person's review time.

Measure the accepted result

To decide whether the flexibility is worth paying for, I would compare the same tasks under the same model and starting conditions, before and after clarifying a responsibility. Define acceptance before running the comparison, then include failed attempts and recovery calls in the cost.

I would look at completed tasks accepted after review, total model usage, elapsed time, repeated actions, and the time spent reviewing or repairing the run. Dividing total spend by accepted outcomes is more useful than quoting the cheapest successful attempt. If nothing is accepted, there is no successful-outcome cost to report.

A cheaper run that missed a required checkpoint has not bought the same result. Equally, an agent that costs a little more to run may still save enough scripting and maintenance effort to justify it. That comparison needs evidence from the work itself.

We can start before every detail is settled

I would start with a bounded task whose owner can explain the intended result, whose permitted actions are clear enough to review, and whose outcome can be checked. Let the agent handle the interface details. Record where it spends time interpreting, recovering or asking for help.

Then use repeated friction to decide what to clarify. If the agent keeps guessing whether to close a dialog, make that checkpoint explicit. If a comparison has a precise rule, consider putting the comparison in code. If the cost of adapting to a changing layout remains acceptable, keep the flexibility.

My background in quality and delivery makes this a familiar decision. We can make progress with imperfect handoffs, provided somebody owns the result and we can see the rework. An agent can absorb some uncertainty. We still need to know which uncertainty we asked it to absorb, and what that cost us.

Based on a review of browser test-automation code and test definitions. The submission example is generalised; employer, application, account and internal system identifiers are omitted. No new live run or matched cost comparison was performed for this article.