Skip to main content
tempera

No product access needed

Choose where a browser agent should pause

Define the consequential action, evidence, reviewer, and safe fallback before adding a human approval step.

Expected outcome

Your team has a written review boundary that names the exact pause, the evidence a reviewer needs, the permitted decisions, and the safe fallback.

You can use this public guide without a Tempera account, product credential, or private workspace. Product access begins only after private onboarding.

Before you start

  • One bounded browser-agent workflow
  • The outcome the agent is expected to produce
  • A person who understands the cost of a wrong action

Steps

  1. 01

    Start with the consequence

    Identify the action whose cost, irreversibility, or ambiguity justifies interruption. A low-risk, reversible step usually needs observation rather than approval; a refund, external message, permission change, or destructive update may deserve a deliberate pause.

  2. 02

    Pause before the side effect

    Place the boundary immediately before the consequential action. A review that starts after the external change can explain what happened, but it cannot prevent that change.

  3. 03

    Design the evidence packet

    Show the proposed action, the inputs that support it, the relevant recent browser state, and why review was requested. Prefer the smallest decision-ready packet over a wall of logs.

  4. 04

    Name every valid decision

    Define what approve, reject, and escalate mean for this workflow. Set a timeout or unavailable-reviewer path that defaults to no consequential side effect unless your team has explicitly chosen another safe behavior.

  5. 05

    Keep the decision reusable

    Attach the decision and short rationale to the source evidence. When the same edge case matters for later versions, treat the reviewed outcome as a candidate evaluation case rather than an isolated approval.

What success looks like

  • The pause happens before one named consequential action.
  • The reviewer receives enough context to decide without reconstructing the entire run.
  • Approve, reject, escalate, timeout, and reviewer-unavailable behavior are explicit.
  • Important reviewed outcomes have a defined path into later evaluation work.

If something is blocked

  • If nearly every step needs approval, narrow the workflow or separate observation from intervention before adding more review gates.
  • If reviewers repeatedly open raw logs, improve the evidence packet around the decision instead of asking them to investigate the whole session.
  • If the timeout behavior is disputed, keep the side effect blocked until the workflow owner names a safe fallback.