Em 15 de junho de 2026, sha256_Nulled postou no Show HN o AgentSIM com um problema que qualquer dev de agente de IA já enfrentou: o bot precisa passar por verificação por SMS, mas os números programáveis baratos que todo mundo usa (Twilio e cia) são VoIP, e serviços sérios rejeitam VoIP no carrier lookup antes de mandar o código. Três projetos apareceram em seis meses tentando resolver o mesmo problema por ângulos diferentes — AgentSIM (Show HN, jun/2026), AgentCall (Show HN, abr/2026) e Agent OTP (jan/2026). O espaço está quente porque o problema é real: o seu agente de IA não consegue mais "ser uma API" pra criar conta, validar identidade, rodar CI de fluxo de auth — ele precisa de um número de telefone de verdade, com SIM de verdade, ou com VoIP que o serviço aceite.
Resposta direta
Quando o seu agente de IA (ou um job de CI) precisa receber um SMS OTP — não enviar, mas receber — três opções apareceram em 2026: (1) mocar o código (não exercita o fluxo real de entrega, e você descobre o bug em produção); (2) alugar um número Twilio mensal (caro pra um teste, e dá trabalho manter); (3) usar uma sessão efêmera, modelo AgentSIM/AgentCall/Agent OTP: você provisiona um número, espera o código, recebe ele parseado em JSON, libera o número. Preço: de US$ 0 (10 sessões/mês no AgentSIM) a US$ 0,99 por sessão. Integração: um comando via MCP no Claude Code / Cursor / Windsurf. A limitação real: nenhum dos três passa Google, Stripe, WhatsApp ou banco — eles gateam no tipo de carrier, e SIM de verdade é o que abre essa porta, e isso está no roadmap, não no produto. Pra CI de auth do seu próprio app, Supabase, Auth0 ou Firebase, funciona.
O que é e por que importa agora
O SMS OTP (One-Time Password, Wikipedia) existe desde os anos 90 e é o segundo fator mais comum em apps que precisam de identidade forte. O fluxo tradicional é direto: usuário digita telefone, sistema envia código de 4–6 dígitos por SMS, usuário digita código, sessão autenticada. O problema, do lado do agente de IA, é que esse fluxo foi desenhado pra um humano com um telefone na mão — não pra um bot.
A primeira geração de agentes lidava com isso de três jeitos ruins. Mocando: o dev sobrescreve o handler de SMS em ambiente de teste, retorna o código esperado, e o teste passa — até o dia em que a formatação da mensagem muda e ninguém percebeu. Aluguel mensal de número: você paga Twilio o mês inteiro pra rodar um teste de 30 segundos, e ainda tem que manter o número, o webhook, e a lógica de "qual foi o último código". Pool de números VoIP comprados em massa: funciona com serviços permissivos, falha com qualquer coisa séria (Google, Stripe, WhatsApp, banco) porque o carrier lookup identifica VoIP antes do SMS ser enviado. É a categoria de produto que o autor do AgentSIM chamou de "qualquer um que te vende número barato que verifica em qualquer lugar está mentindo ou prestes a ter o pool queimado".
Por que importa agora: três fatores convergiram em 2026. Primeiro, a Anthropic/Google/OpenAI continuam empurrando SDKs de agent com suporte nativo a MCP, e o agent deixou de ser "coisa de dev" e virou produto rodando em produção — e produto em produção passa por auth de verdade. Segundo, a IETF publicou em março de 2026 um draft de "AI Agent Authentication and Authorization" que separa o "agent chama o authorization server" do "subject recebe OTP na frente" — modelo CIBA do OpenID Connect. Em outras palavras, o SMS OTP continua sendo o problema do user, e os vendors de agent estão construindo ferramentas pra resolver. Terceiro, três produtos chegaram em seis meses (Agent OTP em janeiro, AgentCall em abril, AgentSIM em junho), com padrão de preço convergente (free tier + US$ 0,50–0,99 por sessão) e integração via MCP como default. A categoria existe.
Como funciona (sem jargão)
Quatro blocos, na ordem em que aparecem quando você liga o agent no fluxo.
1. Provisiona o número. Você chama POST /api/v1/numbers/rent (Agent OTP) ou o equivalente MCP do AgentSIM/AgentCall. O serviço atribui um número temporário, com TTL (no AgentSIM, 10 minutos default; configurável). Cada sessão é um número novo — você não compartilha número entre jobs.
2. O agent usa o número no fluxo de auth do app. Clica "verificar telefone", digita o número retornado, espera. O agent está rodando um browser headless, ou chamando a API do serviço alvo direto, ou interagindo via Playwright — depende do caso.
3. Espera o SMS com classificação de outcome. O serviço escuta SMS no número, e quando chega, parseia o código via regex do corpo da mensagem. O ponto crítico: se o SMS não chega, o agent não fica em timeout silencioso. O AgentSIM classifica o resultado em no_sms, sms_no_otp, phone_rejected, anti_bot_gate. Saber por que falhou economiza 80% do tempo de debug.
4. Libera o número. O número é efêmero — você chama DELETE (ou ele auto-expira no TTL). Não fica custo mensal, não fica número zumbi, não vaza SMS de outros jobs.
A integração via MCP, no AgentSIM, é um comando:
$ claude mcp add agentsim -- npx agentsim-mcp
$ export AGENTSIM_TOKEN=***
A partir daí, o agent tem as três tools (rent_number, wait_for_otp, release_number) e age direto no fluxo de auth, sem você escrever glue code.
Comparativo rápido: antes vs agora
| Aspecto | Mocar o código | Twilio mensal | Sessão efêmera (AgentSIM/AgentCall/Agent OTP) |
|---|---|---|---|
| Exercita fluxo real de entrega | Não | Sim | Sim |
| Exercita formatação da mensagem | Não | Sim | Sim |
| Custo por teste | US$ 0 | ~US$ 1–15/mês fixo | US$ 0–0,99 |
| Custo pra 100 testes/mês | US$ 0 | US$ 15+ (aluguel) | ~US$ 30–99 (ou 0 se dentro do free tier) |
| Cleanup depois | Nenhum | Cancelar número | Automático (TTL) |
| Passa carrier lookup sério | Sim (mocado) | Depende do número | Não (VoIP) — exceto AgentCall, que usa SIM real |
| Integração com agent (MCP) | Não precisa | Manual | 1 comando |
| Funciona com Google/Stripe/bancos | Sim (mocado) | Às vezes (depende) | Não (ainda) |
A diferença prática: mocar é o atalho que esconde bugs. Twilio mensal é o que o seu time sênior já tem rodando, funciona, mas não escala pra 50 jobs de CI paralelos. Sessão efêmera é o modelo novo, e o AgentCall é a única das três que já usa SIM de verdade — então é a única que já passa em Google e Stripe. As outras duas são honestas: funcionam com auth que você controla (seu próprio app, Supabase/Auth0/Firebase test tenants, CI/QA), não passam em serviço que gatea no carrier type.
O que isso muda para o seu negócio
Três perguntas valem ser feitas agora se você roda agente de IA em produção ou tem QA automatizado:
Você tem job de CI que testa fluxo de SMS OTP hoje? Se a resposta é "não, moca", você está aceitando um risco grande — qualquer mudança na formatação da mensagem, no provider de SMS, no regex de extração, vai pra produção sem teste. A Wikipedia lista, entre as falhas comuns, justamente "sistemas que usam OTPs sem implementar com segurança" — e mockar é a porta de entrada pra esse problema. Sessão efêmera, mesmo a US$ 0,99, paga o custo no primeiro bug que ela pega.
Seu agente cria conta em serviço externo? Se sim, você precisa decidir: ou paga US$ 0,99 por sessão efêmera VoIP (funciona pros serviços permissivos), ou migra pra AgentCall e usa SIM real (mais caro, mas passa Google/Stripe/banco), ou implementa manualmente um pool de SIM (caro, doloroso, e "qualquer um que te vende barato está mentindo"). Os três caminhos existem em 2026; o que não dá é ignorar.
Seu agente é o problema ou a solução do SMS OTP? Se você é varejista brasileiro recebendo OTP pra confirmar cadastro de cliente, seu agente é o que envia, não o que recebe — Twilio Verify, Zenvia, SMSAPI resolvem. O post todo aqui é sobre o outro lado: agent como consumidor do fluxo de auth. São problemas diferentes, com vendors diferentes, e misturar os dois é o erro mais comum que o pessoal de produto faz.
A Agendai trabalha com varejo brasileiro montando operação de agentes de IA que enviam SMS OTP (confirmação de cadastro, código de primeira compra, 2FA pro cliente final) — esse lado do fluxo usa Twilio Verify ou Zenvia, é commodity, e roda em produção faz anos. O lado "agent recebe OTP" é o que está mudando em 2026 com AgentSIM/AgentCall/Agent OTP, e importa mais pra time de QA e de automação interna do que pro time de produto.
Referência natural Agendai
O padrão que esses três vendors (AgentSIM, AgentCall, Agent OTP) materializaram em 2026 — "sessão curta, API clara, outcome classificado, número liberável" — é o mesmo padrão que a Agendai aplica em fluxos conversacionais de WhatsApp que implanta em varejistas. A sessão de OTP vira sessão de atendimento: provisiona contexto, espera input do cliente, classifica outcome (cliente_respondeu, cliente_pediu_humano, cliente_enviou_midia_nao_suportada), libera. A diferença é que no WhatsApp o número é fixo (o número comercial da loja) e a sessão é de minutos a horas; no SMS OTP pra agent, o número é descartável e a sessão é de segundos. Se você quer ver o primeiro caso rodando no seu negócio, a Agendai implementa em ~2 semanas — a primeira semana é de graça, sem fidelidade.
Perguntas frequentes
O que é SMS OTP pra agente de IA?
É o uso de um número de telefone temporário (VoIP ou SIM real) que um agente de IA ou um job de CI aluga só pelo tempo de um teste, recebe o código de verificação que o serviço envia, e devolve o código parseado pro agent usar. Em 2026, os três produtos de referência são AgentSIM (Show HN, jun/2026), AgentCall (Show HN, abr/2026) e Agent OTP (jan/2026). O conceito de one-time password é antigo (Wikipedia), o novo é o modelo de sessão curta via API/MCP.
Como funciona na prática?
Três chamadas de API. rent_number provisiona um número temporário. O agent usa o número no fluxo de auth do app (UI, API, ou browser headless). wait_for_otp fica escutando SMS, parseia o código, e devolve o resultado classificado (no_sms, sms_no_otp, phone_rejected, anti_bot_gate). release_number (ou TTL automático) libera o número. Integração MCP no Claude Code / Cursor / Windsurf é um comando. Detalhes na doc do AgentSIM.
Quanto custa?
Três faixas de preço em 2026. AgentSIM: free, 10 sessões/mês; depois US$ 0,99/sessão. AgentCall: free tier disponível; preço por sessão não publicado no site. Agent OTP: 5 OTPs grátis/mês; depois US$ 9/50 OTPs, US$ 29/200, US$ 49/500. Twilio Verify (caminho antigo) cobra ~US$ 0,05 por envio + aluguel mensal do número (US$ 1–15/mês). Para 100 testes/mês, sessão efêmera sai US$ 30–99; Twilio fixo sai US$ 15–50 de aluguel mais o mesmo US$ 5 de envio. Sessão efêmera vence em elasticidade; Twilio fixo vence em volume constante e necessidade de SIM real.
Quais os riscos?
Quatro principais em 2026. Primeiro, o serviço gatear no carrier type e o número VoIP não passar — você descobre em runtime, não em build. Segundo, a "SMS pumping attack" (gente abusando do endpoint de envio pra inflacionar a conta): o tutorial da MessageCentral recomenda limite de 3 tentativas de envio por sessão exatamente por isso. Terceiro, persistência indevida do número entre jobs — se você não libera, vira custo recorrente. Quarto, o agent tratar phone_rejected como retry cego e queimar o pool — por isso outcome classificado importa mais que timeout silencioso.
Substitui o test environment do meu app?
Não. Sessão efêmera testa o caminho de entrega (SMS chegou, código parseado, formato correto) — não substitui teste de UX, de fluxo de erro, de edge case de formatação. Em CI maduro, os dois coexistem: mocks pros casos triviais, sessão efêmera pros casos que tocam provider real. A regra do Arkesel sobre boas práticas de OTP é explícita: mock é o começo, validação contra provider real é o que evita o incidente em produção.
Recomendamos também: QodFlow: o kanban onde humanos e agentes de IA mexem no mesmo card e Kanban boards que AI agents dirigem via MCP em 2026.
Precisa que seu agente de IA opere fluxos com SMS, WhatsApp ou autenticação no varejo? A Agendai monta a operação em ~2 semanas — primeira semana de graça. Fale com a gente.