AGENTES ADI · TRANSAÇÕES
Operações autenticadas por voz, em segundos
Transferência, consulta e pagamento executados dentro do app, com autenticação e registro completo de cada passo.
O salto operacional
Da informação à execução
Os dois modelos atendem o mesmo pedido. O que muda é quem conclui a operação.
Assistente que só informa
Agente de transações ADI
Resultados em produção
Impacto que se mede
Medido sobre pilha de voz própria, sem encadeamento de APIs de terceiros.
Como opera
Da instrução ao comprovante
Cliente autenticado
A conversa começa dentro do app ou em canal autenticado, com a sessão já validada.
Pedido em fala livre
O cliente diz o que quer fazer, sem menu e sem escolher opção numerada.
Ação permitida
A operação é resolvida para um enum registrado. O que não está na lista não acontece.
Confirmação e política
O agente confirma dados e invoca o seu endpoint, que opera sob a sua política de autorização.
Operação concluída
Transferência, consulta ou agendamento executados por HTTP Tools nas suas APIs.
Evento verificável
Comprovante ao cliente e evento assinado com HMAC-SHA256 ao seu sistema.
Capacidades
Executar sem abrir margem
Catálogo fechado de ações
Transferir, consultar saldo, agendar pagamento. O que não está registrado não acontece, independentemente do pedido.
Sem credencial no agente
O agente não recebe credencial do cliente final; invoca endpoint autenticado por API key ou header.
Valores bem pronunciados
O agente lê "mil duzentos e trinta e quatro reais e cinquenta centavos", não a string bruta.
Chamada cifrada ponta a ponta
SIP TLS 5061 com SRTP, inclusive na camada telefônica.
Barge-in por VAD
O cliente interrompe e o agente cede o turno, como numa conversa real.
Evento por operação
Cada ação executada gera webhook assinado, rastreável no seu sistema.
Viabilidade
Conecta ao que você já tem
Core, APIs transacionais e telefonia ligados por interface documentada. Sem alteração no core.
Onboarding em 1 a 3 semanas. Com SIP trunk já existente, o canal de voz sobe em 2 a 5 dias.
Dentro da norma
Transacionar sem sair da política
Autorização no seu lado
O endpoint invocado já opera sob a sua política; o agente não decide permissão.
Guardrails em código
Filtros determinísticos antes e depois do modelo, três deles obrigatórios em qualquer agente.
Rastreabilidade por turno
O que o agente disse, com que versão, sob quais controles, e qual ação executou.
PII tokenizada
Dado pessoal tokenizado antes de qualquer chamada a provedor de modelo.
O ciclo completo
Um motor, cinco agentes
Uma aprovação de compliance cobre as cinco etapas. Você entra pela que mais dói e expande sem projeto novo.
Originação
Capta, pré-qualifica e converte em fala livre, por web ou voz.
Ver →Onboarding
Cadastro e ativação com validação determinística de identidade.
Ver →Cobrança
Negocia dentro da política definida e registra o compromisso no CRM.
Ver →Atendimento
Resolve no primeiro contato, com contexto entre os três canais.
Ver →FAQ
Perguntas frequentes
O agente pode executar uma operação que não autorizamos?
Não. Cada ação disponível está registrada como enum validado fora do modelo. O que não está na lista não acontece, independentemente do que o cliente peça ou de como peça.
O agente tem acesso às credenciais do cliente?
Não. Ele invoca um endpoint seu, autenticado por API key ou header, que já opera sob a sua política de autorização.
Como auditamos cada operação?
Cada operação gera um evento verificável, entregue por webhook assinado com HMAC-SHA256, e a interação fica reconstruível com a versão do agente e os controles ativos.
A voz é segura o suficiente para transacionar?
A chamada trafega cifrada, inclusive na camada telefônica, em SIP TLS 5061 com SRTP. A autenticação da sessão acontece antes de qualquer valor ser mencionado.
Por que 800 ms importa?
Acima desse limiar o cliente percebe a espera entre a instrução e a confirmação e passa a repetir a frase. A pilha de voz é própria justamente para controlar a latência num só lugar.