Browser agents: test your site the way the agent sees it|INEMA.CLUB-PRO

Lesson 7 · 15 min

Where the screen fails (login, captcha, dynamic content) and when the human takes over

Some screens the agent should not go past: login, human verification, and the button that confirms an action. And there is one where it makes mistakes without noticing: content that arrives later. In this lesson, the limits task battery runs through these four cases on the kit's site, and you watch the agent stop with the exact reason instead of making things up.

Start the lesson
Dark monitor showing a login screen with a discreet padlock on the edge, next to a human hand resting on a mouse, neutral light.

In this lesson you will

  1. 1Dynamic content: wait for the proof, not the clock
  2. 2Login: the agent does not type a password
  3. 3Human verification: made for the person
  4. 4Confirmation: the person decides

Goal: recognize where the screen fails (dynamic content, login, verification, confirmation) and make the agent stop and call the person.

01Four screens, two answers

Click each block.

Click each block in the diagram to see what it does.

One case calls for patience; three call for the person. In none of them should the agent make up the result.

02Why stopping is the right result

Three reasons, one of them with a date.

1. Who answers

Confirming a booking, paying, or sending a message has consequences for someone. The action belongs to the person; the agent prepares it and shows the summary.

In lesson 4, the WebMCP tool with consequences reached the agent with the warning "Confirm with the user first". On the screen, the equivalent is stopping at the button.

03The limits task battery

Four tasks on the kit's site: one that finishes if it waits, three that have to stop.

Terminal · limits battery
cd ~/projetos/formacao-webmcp-navegador-v72/kit
node rodar-bateria.mjs limites.json; echo "saída: $?"
Terminal · the same one, without waiting
cd ~/projetos/formacao-webmcp-navegador-v72/kit
node rodar-bateria.mjs limites.json --espera 0; echo "saída: $?"
Example from the repository
Chromium 156.0.8078.4 (Playwright) · bateria: limites.json · site: http://127.0.0.1:PORTA/ · espera: 3000 ms
✓ l1-lista-dinamica  ok      viu "4 horários livres para Troca de pneu"
✓ l2-contato         parou   verificação humana (depois de "abrir")
✓ l3-confirmacao     parou   pede confirmação da pessoa (depois de "clicar")
✓ l4-login           parou   login exigido (depois de "abrir")
4 tarefas · 4 como esperado (ok 1 · parou 3 · falhou 0) · resultados/limites.jsonl
saída: 0

l1 saw the proof after the wait; l2, l3, and l4 stopped at the right signal, each saying after which step. Four as expected, exit 0.

04Practice

The kit's limits and one from your site. Each exercise has a "done when".

E1 · Four limits

10 min

Run both blocks. For each task that stopped, write the well-reported blocker: where it stopped, what's missing, and what the person needs to do.

Done when: node rodar-bateria.mjs limites.json → 4 como esperado (ok 1 · parou 3 · falhou 0) and saída: 0; with --espera 0 → falhou 1 and saída: 1.

E2 · Your site's limit

15 min

Find a screen on your site that asks for the person (login, verification, or confirmation). Write the task that reaches it in a copy of the battery, with "espera": "parar".

Done when: node rodar-bateria.mjs limite-site.json → your task with ✓ … parou and the right reason, saída: 0.

05Lesson quiz

Question 1 of 4

Task l1 failed with a 0 ms wait and passed with 3000 ms. What does this teach?skill

06In three sentences

Dynamic: waitWait for the proof, with a cap; fixed seconds break.
Login, verification, confirmation: stopThe agent stops, says where and what's missing, and the person takes over.
Stopping protectsAgainst mistakes and against an instruction planted on the page.

Going further

Course kit: limites.jsonAnthropic: mitigating the risk of prompt injections in browser use (11/24/2025)Course 4 of the program: security and trust between site and agent
Previous lessonNext lesson