Seu agente de IA está esperando por você: transforme aprovações em chamadas

Sumário

• Quão comuns são os incidentes com agentes, de verdade?
• O que acontece de fato quando um agente precisa de uma pessoa?
• Quais eventos de agente merecem uma chamada telefônica?
• Como ligar uma aprovação de agente a uma chamada telefônica
• Passo 1 — Crie um canal de Chamada para agentes bloqueados
• Passo 2 — Dispare o webhook a partir do seu ramo de aprovação
• Passo 3 — Use hooks quando o agente for uma CLI, e não uma biblioteca
• Passo 4 — Capture os agentes que só mandam e-mail
• Passo 5 — Adicione condições para que só bloqueios reais toquem
• Passo 6 — Teste com o Não perturbe ligado
• Isso não vai só recriar a fadiga de alertas com um sino mais alto?
• O que o Echobell não faz
• Perguntas frequentes
• Posso aprovar uma ação do agente pela própria chamada?
• Quais eventos do framework devem disparar o webhook?
• Isso funciona com agentes headless em CI?
• E quanto à elicitation do MCP especificamente?
• É seguro colocar a saída do agente na notificação?
• Meu time inteiro pode receber o mesmo alerta do agente?
• Isso é só para iOS?
• Qual a diferença em relação à configuração com WebhookMCP?
• Relacionados

Todo framework de agentes autônomos lançado em 2026 tem o mesmo buraco. O agente trabalha por horas sem você, esbarra em uma ação que não pode executar sozinho, para — e então nada acontece. A execução não falha. Não tenta de novo. Fica na memória segurando um objeto de estado serializado, esperando por uma pessoa que não faz ideia de que está sendo esperada. Este guia mostra como fechar essa lacuna transformando o momento "preciso de uma pessoa" do agente em uma chamada que toca de verdade, com o Echobell.

A lacuna é estrutural, não é um bug de um produto específico. A documentação de agentes da OpenAI descreve o fluxo de aprovação com precisão: quando uma ferramenta precisa de aprovação, "a execução pausa até você aprovar ou rejeitar", o resultado devolve interruptions mais um state retomável e, se a revisão puder demorar, você deve serializar esse estado, guardá-lo e retomar depois (OpenAI, guia do Agents SDK). Em nenhum ponto desse fluxo alguma coisa chega a uma pessoa. Avisar quem aprova fica inteiramente por sua conta.

Enquanto isso, as execuções ficam mais longas. A AWS descreve seus agentes de fronteira como capazes de "operar por horas ou dias sem exigir intervenção" (About Amazon). O Kiro Crew, lançado em 4 de agosto de 2026, é direto: "Dispare uma migração e ela segue avançando por checkpoints e retentativas enquanto você está em uma reunião ou dormindo" — ao mesmo tempo em que observa que "as solicitações de ferramentas podem exigir aprovação" (Kiro). As duas metades são verdadeiras ao mesmo tempo. O agente trabalha enquanto você dorme, e o agente para enquanto você dorme.

Quão comuns são os incidentes com agentes, de verdade?

Comuns o bastante para que a maioria das empresas já tenha tido um, e a maioria não roda agentes sem supervisão. Em uma pesquisa com 418 profissionais de TI e segurança conduzida em janeiro de 2026 pela Cloud Security Alliance e encomendada pela Token Security, 65% das organizações relataram pelo menos um incidente relacionado a agentes de IA no último ano — 61% envolvendo exposição de dados, 43% interrupção operacional e 35% prejuízo financeiro (comunicado da CSA, relatório).

Os números de governança da mesma pesquisa são os que importam para o alerta. Apenas 13% rodam agentes totalmente autônomos. 53% deixam os agentes agirem de forma autônoma em tarefas de baixo risco, com revisão humana para ações de risco maior, e 24% mantêm uma pessoa no circuito na maioria das tarefas. 82% haviam descoberto agentes de IA sombra em seu ambiente no último ano.

Leia isso como um fato operacional, e não como uma estatística de susto: cerca de três quartos das organizações construíram deliberadamente uma pausa dentro dos seus agentes. Cada uma dessas pausas é um momento em que uma máquina está travada esperando por uma pessoa. Se a pessoa só descobre às 09:00 da manhã seguinte, a capacidade do agente de trabalhar durante a noite não valeu nada.

O que acontece de fato quando um agente precisa de uma pessoa?

Ele espera, em silêncio, e todo framework deixa a notificação por sua conta. O mecanismo muda; o resultado, não.

O Model Context Protocol deixa isso explícito no nível da especificação. A elicitation existe justamente para que um servidor possa perguntar algo a uma pessoa no meio da execução, e a revisão atual (2026-07-28) avisa que os servidores "NÃO DEVEM presumir que as solicitações de elicitation sempre terão sucesso" e precisam tratar recusa, cancelamento e falha do cliente (especificação do MCP). O protocolo padroniza a pergunta. Ele não padroniza — e não tem como padronizar — como conseguir a atenção da pessoa.

É aí que está toda a oportunidade. Cada camada da pilha de agentes tem uma pausa bem projetada. Nenhuma delas tem um número de telefone.

Quais eventos de agente merecem uma chamada telefônica?

Dois, e você deve ser implacável com o resto. Uma chamada é um recurso escasso; gaste-a só onde uma pessoa dormindo é realmente o gargalo.

1. Uma aprovação travada em uma execução que não avança sem ela. O agente está parado, o relógio corre e nenhuma quantidade de espera resolve. Este é o caso clássico.
2. A falha definitiva de uma execução longa e sem supervisão. Seis horas de migração que morreram na segunda hora são seis horas que você não recupera, e você preferiria saber na segunda hora.

Todo o resto pertence a um canal mais silencioso. "Tarefa concluída com sucesso" é uma notificação normal. "O agente usou 80% do orçamento dele" é, no máximo, urgente. "O agente iniciou" não é nem notificação. Os três tipos de notificação do Echobell — Normal, Urgente e Chamada — existem exatamente para essa triagem, e mapear os eventos do agente sobre eles é a decisão de design mais importante aqui. Se você já está lutando contra o volume de notificações, leia como resolver a fadiga de alertas antes de acrescentar um canal que toca.

Como ligar uma aprovação de agente a uma chamada telefônica

O Echobell transforma um webhook ou um e-mail em uma chamada telefônica — uma chamada de verdade, que toca e vibra e atravessa o Foco e o Não perturbe do iOS do mesmo jeito que a ligação de um familiar atravessaria (veja como driblar o Foco do iOS). Ele fica entre o agente que para e a pessoa que pode despausá-lo.

Passo 1 — Crie um canal de Chamada para agentes bloqueados

Crie um canal no app e defina o tipo de notificação dele como Chamada. Dê a ele um nome inequívoco, como "Agente bloqueado — precisa de aprovação", e não o use para mais nada. Copie a URL do webhook nos detalhes do canal; ela se parece com https://hook.echobell.one/t/<channel-token>. Trate-a como um segredo — quem tiver essa URL pode fazer seu celular tocar (guia de webhooks).

Defina os modelos de título e corpo com algo sobre o qual você consiga agir direto da tela de bloqueio:

Title: Agent blocked: {{agent}}
Body: Waiting on {{action}} in {{project}} — since {{time}} UTC

{{time}} e as demais variáveis de tempo do sistema estão sempre disponíveis em UTC, sem que você precise enviá-las.

Passo 2 — Dispare o webhook a partir do seu ramo de aprovação

Em qualquer SDK que devolva interrupções, a pausa é um ramo comum do seu código. Faça um POST para a URL do canal antes de estacionar a execução:

let result = await run(agent, input, { stream: false });

if (result.interruptions?.length) {
  await fetch(process.env.ECHOBELL_BLOCKED_URL, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      agent: agent.name,
      action: result.interruptions[0].rawItem.name,
      project: process.env.PROJECT_NAME,
      externalLink: `https://ops.example.com/runs/${runId}`,
    }),
  });
  await saveState(runId, result.state); // serialize e retome após a aprovação
}

A variável especial externalLink vira um link clicável no registro da notificação, então quem atender a chamada cai direto na execução, em vez de ter que procurá-la.

Passo 3 — Use hooks quando o agente for uma CLI, e não uma biblioteca

O Claude Code expõe um hook Notification cujo matcher filtra por tipo de notificação, incluindo agent_needs_input e agent_completed, e os handlers do hook podem ser comandos de shell ou POSTs HTTP diretos (referência de hooks). Um handler command dá a você controle sobre o formato do payload, o que importa porque o Echobell renderiza as chaves JSON que você enviar:

{
  "hooks": {
    "Notification": [
      {
        "matcher": "agent_needs_input",
        "hooks": [
          {
            "type": "command",
            "command": "jq -c '{agent: \"claude-code\", action: .message, project: .cwd}' | curl -sS -X POST -H 'Content-Type: application/json' -d @- \"$ECHOBELL_BLOCKED_URL\""
          }
        ]
      }
    ]
  }
}

Nos handlers command, a entrada do hook chega como JSON pelo stdin, com campos como session_id, cwd, hook_event_name e permission_mode. O tipo de handler http envia esse mesmo JSON direto para uma URL, sem script nenhum, o que é tentador — mas ele também espera que a resposta seja um documento de saída de hook, e a resposta do Echobell não é. Use command, a menos que você tenha verificado que o http se comporta do jeito que você quer na sua configuração.

Passo 4 — Capture os agentes que só mandam e-mail

Muitas plataformas de agentes, serviços de execução agendada e ferramentas internas reportam por e-mail e nada mais. Todo canal do Echobell pode ter o próprio endereço, então uma regra de encaminhamento transforma essas mensagens em chamadas (gatilhos por e-mail, configuração de e-mail para chamada). Os gatilhos por e-mail expõem from, to, subject, text e html como variáveis de modelo, então você consegue montar uma condição sobre a linha de assunto sem precisar fazer parsing de nada.

Passo 5 — Adicione condições para que só bloqueios reais toquem

Um canal que toca a cada evento do agente deixa de ser uma chamada telefônica e vira ruído de fundo. As condições do Echobell filtram por valores de variáveis com a mesma sintaxe de expressão dos modelos, então você pode exigir, por exemplo:

blocking == true && risk == "high"

Mande tudo o que ficar abaixo dessa régua para um canal Urgente separado. Uma meta útil: o canal de Chamada deveria tocar, no máximo, um punhado de vezes por semana. Se tocar mais do que isso, o limite de autonomia do seu agente está traçado no lugar errado, e nenhuma configuração de notificação vai consertar isso.

Passo 6 — Teste com o Não perturbe ligado

Acione o canal com curl enquanto o Não perturbe estiver ativo no celular que vai de fato receber o alerta:

curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{"agent":"test","action":"deploy to prod","project":"demo","blocking":true,"risk":"high"}'

Ative Repetir chamada perdida no app para que uma chamada bloqueada pelo modo Foco seja tentada de novo. Um caminho de escalonamento não testado é só uma suposição.

Isso não vai só recriar a fadiga de alertas com um sino mais alto?

Vai, se você pular o passo 5. O modo de falha é real e vale nomear. Agentes geram muito mais eventos do que servidores — cada chamada de ferramenta, cada checkpoint, cada retentativa — e a tentação de mandar tudo isso para algum lugar visível é grande.

A disciplina que funciona: uma chamada telefônica fica reservada para eventos em que uma pessoa dormindo é a única coisa entre o agente e o progresso. Esse conjunto é bem menor que "coisas importantes que o agente fez". Se você não consegue descrever, em uma frase, o que a pessoa vai fazer nos noventa segundos depois de atender, não merece uma chamada.

Há também um argumento de segurança para manter a régua alta. A mesma pesquisa da CSA descobriu que as organizações classificam o risco da ação (63%) e a autorização humana (53%) como seus principais sinais de governança. Esses sinais só significam alguma coisa se a autorização humana realmente acontecer rápido. Uma aprovação que é rotineiramente respondida com oito horas de atraso ensina todo mundo a alargar o portão — e é assim que os 13% de autonomia total viram, silenciosamente, o padrão pelos motivos errados.

O que o Echobell não faz

Ser preciso aqui importa, porque infraestrutura de agentes atrai promessas exageradas.

O Echobell faz: transformar um webhook ou um e-mail em uma chamada que toca, em um alerta urgente ou em uma notificação push normal; filtrar com condições; renderizar contexto com modelos; entregar o mesmo gatilho a um canal compartilhado do time, no qual cada inscrito escolhe a própria urgência.

O Echobell não faz:

• Aprovar nada. Ele não é uma interface de aprovação e não tem nenhuma conexão com o estado do seu agente. Ele faz seu celular tocar; você ainda vai abrir um notebook, um painel ou um terminal para aprovar ou rejeitar. Não existe "aperte 1 para aprovar".
• Retomar a execução. Serializar e restaurar o estado do agente é trabalho do seu framework. O Echobell nunca encosta nisso.
• Oferecer políticas de escalonamento, confirmação de recebimento ou escalas de plantão. Não existe "se ninguém atender em cinco minutos, ligue para a próxima pessoa". Ele liga para os inscritos de um canal. Se você precisa de rodízios agendados e rastreamento de confirmações, precisa de uma plataforma de incidentes — veja a comparação de alternativas ao Opsgenie para essa classe de ferramenta.
• Proteger seus agentes. Nada aqui resolve agentes sombra, permissões de ferramenta amplas demais ou a lacuna de descomissionamento que o relatório da CSA descreve. Atenção humana mais rápida é uma mitigação para resposta lenta, não para arquitetura ruim.
• Garantir a entrega. Uma chamada depende da infraestrutura de push, da rede e de um celular carregado. Trate isso como a camada que encurta a espera, não como um controle do qual você pode depender de forma absoluta.

O enquadramento honesto: o limite de autonomia do seu agente não muda por causa de qual app faz seu celular tocar. O que uma chamada muda é o número de horas entre o agente parar e uma pessoa perceber — e, em uma execução que roda a noite toda, essas horas são todo o valor de rodá-la à noite.

Perguntas frequentes

Posso aprovar uma ação do agente pela própria chamada?

Não. O Echobell entrega uma chamada com o conteúdo da notificação e um link clicável; ele não tem nenhum caminho de resposta interativo de volta para o seu agente. O padrão realista é: a chamada acorda você, o externalLink leva você ao painel da execução ou ao endpoint de aprovação, e você decide ali. Se você precisa aprovar respondendo, terá que construir esse endpoint por conta própria — o Echobell só cuida da metade que acorda.

Quais eventos do framework devem disparar o webhook?

Aqueles em que a execução não consegue continuar. No OpenAI Agents SDK, é um array interruptions não vazio. No MCP, uma solicitação elicitation/create que seu cliente não consegue responder sem uma pessoa. No Claude Code, o hook Notification com o matcher agent_needs_input. Eventos de conclusão pertencem a um canal Normal ou Urgente, não a um de Chamada.

Isso funciona com agentes headless em CI?

Funciona, e é aí que importa mais, já que ninguém está olhando para um terminal. Qualquer passo de CI que consiga rodar curl consegue acionar um canal. Dispare no ramo de falha de um job longo, e não em todo job, senão seu pipeline vira a coisa mais barulhenta que você tem.

E quanto à elicitation do MCP especificamente?

A elicitation foi projetada para um cliente com uma pessoa presente para renderizar um prompt. Em uma execução sem supervisão não há para quem renderizar, e a especificação diz explicitamente aos servidores para tratarem recusa e cancelamento em vez de presumir uma resposta. Um padrão razoável é o wrapper do cliente MCP disparar um webhook do Echobell quando recebe uma solicitação de elicitation que não consegue responder sozinho, e então segurar ou cancelar conforme a sua própria política.

É seguro colocar a saída do agente na notificação?

Envie o mínimo possível. Prefira um identificador e um link à saída real do agente — use externalLink para apontar para o registro da execução em um sistema feito para guardá-lo. O Echobell armazena o conteúdo e o histórico das notificações apenas no seu dispositivo, deixando no servidor só contas, canais e inscrições (modelo de privacidade), o que é bom para a minimização de dados, mas não é motivo para enviar mais do que você precisa.

Meu time inteiro pode receber o mesmo alerta do agente?

Pode. Compartilhe o canal e cada inscrito recebe o gatilho, escolhendo o próprio tipo de notificação. Uma configuração comum: a pessoa que cuida do agente se inscreve como Chamada, e o resto do time como Urgente.

Isso é só para iOS?

Não. O Echobell roda no iOS e no Android via Google Play (veja o lançamento do Android). O comportamento dos alertas em formato de chamada difere entre as plataformas, então teste nos aparelhos que as pessoas de plantão realmente carregam.

Qual a diferença em relação à configuração com WebhookMCP?

O WebhookMCP dá ao modelo uma ferramenta que ele pode escolher chamar quando uma tarefa termina — útil, mas depende de o agente decidir avisar você. A abordagem daqui dispara a partir do seu próprio código ou de um hook do framework, então funciona mesmo quando o agente está travado, confuso ou quebrou. Use as duas: uma para "pronto", outra para "bloqueado".

---

Relacionados

• Seja avisado quando as tarefas de IA terminarem com o WebhookMCP
• Como driblar o modo Foco do iOS para alertas críticos
• Resolvendo a fadiga de alertas: guia para desenvolvedores
• Alertas de falha em cron jobs
• Guia de integração de webhooks
• Guia de condições