Agent Workflows
WebTest AI treats the model as a bounded decision maker and the runtime as the authority on browser truth. This separation lets an agent factory generate and run tests without giving a model unrestricted control of the browser.
Recommended loop
- Draft a Markdown goal with explicit success conditions.
- Start an isolated browser context at the approved origin.
- Collect a fresh observation before every model decision.
- Ask the navigator for one allowed action only.
- Resolve the action target locally when its name is unique.
- Ask Jev to choose from fresh candidates only when the target is ambiguous.
- Execute the validated action and capture the resulting observation.
- Evaluate fixed assertions and publish evidence with the verdict.
Jev versus the navigator
| Component | Input | Output | Role |
|---|---|---|---|
| Navigator | Goal, approved data, URL, visible text, candidate summary, allowed tools | One bounded action such as click, fill, navigate, wait, done, or blocked | Plans the next move |
| Jev | Element intent, operation, and fresh visible candidates with context | Candidate reference, confidence, and probability distribution | Resolves target ambiguity |
| Runtime | Validated action and current browser session | Browser effect, assertion evidence, telemetry, and verdict | Enforces policy and truth |
For example, two forms in Everyday Goods contain a Save button. The navigator identifies the shipping context. Jev chooses the shipping candidate from the current snapshot. The runtime checks that the reference is still valid before clicking it. If Jev is uncertain, the test becomes INCONCLUSIVE and does not guess.
Agent factory contract
An agent factory can treat each Markdown goal as a work item and the agent-readable report as the result contract:
- Input: goal ID, base URL, approved data, tags, and runtime bounds.
- Observation: current URL, visible text, interactive candidates, and action history.
- Decision: one JSON action from the allowed vocabulary.
- Evidence: assertions, screenshots, observations, candidate decisions, tool calls, and model telemetry.
- Output: PASS, FAIL, or INCONCLUSIVE with structured failure categories.
The MCP surface can expose suite execution, report summaries, and paginated call details to an agent factory without exposing secrets or requiring prompts and model responses to be stored.
Safety bounds
- Only approved origins and supported action types are executable.
- Data entry is restricted to approved Markdown data or configured environment values.
- Candidate lists, input size, step count, browser calls, model calls, and elapsed time are bounded.
- Page content is treated as untrusted data, never as runtime instructions.
- Failed or low-confidence selector decisions stop safely.
- The model cannot modify success conditions or turn a blocked action into a pass.
Evidence and cost
Every run writes an HTML report for human review, compact agent JSON, a newline-delimited call ledger, and a manifest. Provider token usage and configured rates are used for cost estimates. When a provider or subscription bridge does not return usage, the report says usage is unavailable rather than fabricating a zero.
Use deterministic fixtures for release gates that need repeatability. Use live navigator and Jev runs for adaptable regression coverage, calibration, and agent capability evaluation. Keep both in the same report format so the difference is visible.