Agente de IA para Suporte a Disputas de Pagamento

01 de December de 2025 • Tempo de leitura: 5 min

Como criar um agente de IA que auxilia na resolução de disputas de pagamento, analisando dados de transações e fornecendo informações relevantes.

1. Propósito e Escopo

Este documento define todos os prompts, configurações de memória, transição entre estados, ferramentas como chamadas a sistemas externos e demais requisitos funcionais para o Agente de IA "Suporte a Disputas de Pagamento", uma solução projetada para auxiliar na resolução de disputas de pagamento, analisando dados de transações e fornecendo informações relevantes para a mediação. Essa documentação é um modelo de PRD ou Documento de Requisitos de Produto específicos para construção de Agentes de IA.

O objetivo principal é automatizar a análise de dados de transações para identificar a causa raiz das disputas, fornecer informações detalhadas e relevantes para mediar disputas e automatizar a coleta de evidências e documentação necessária para resolver disputas.

2. Contexto e Problema

Cenário Atual

As disputas de pagamento são complexas e frequentemente carecem de informações claras e acessíveis para a mediação. Isso gera desafios significativos para as partes envolvidas, que precisam de dados precisos e consolidados para resolver as questões de forma eficaz.


Problemas Identificados

  • Complexidade: A resolução de disputas de pagamento é um processo complexo que exige análise detalhada de dados transacionais.
  • Falta de Informações: Muitas vezes, faltam informações claras e acessíveis que possam ser usadas para mediar disputas eficazmente.

3. Impactos Esperados

A implementação deste agente de IA visa alcançar os seguintes resultados:

  • Reduzir a complexidade na resolução de disputas de pagamento.
  • Fornecer informações claras e acessíveis para mediar disputas.
  • Automatizar a coleta de evidências e documentação necessária para resolver disputas.

4. Visão Geral da Solução

O agente de IA para suporte a disputas de pagamento analisa dados de transações, identifica a causa raiz das disputas e automatiza a coleta de evidências necessárias para a mediação. A seguir são detalhadas todas as regras de negócio e especificações funcionais necessárias para que esse agente atue como um assistente útil e autônomo na resolução de disputas de pagamento.

A solução consiste em um fluxo de automação composto por 5 agentes de IA. O processo inicia com a preparação do payload de coleta de evidências e termina com a geração de um dossiê de mediação claro e acionável.

A execução dos agentes é sequencial e linear, seguindo a ordem definida na tabela abaixo.

Agentes Função Principal
Agente Preparador de Payload de Coleta de Evidências de Disputa (RF 1) Consolidar informações do caso de disputa e preparar um payload único e completo para recuperar todas as evidências relevantes da transação.
Agente de Execução de Chamada à API (RF 2) Realizar chamada à API do Sistema de Pagamentos para obter o pacote de evidências consolidado da disputa.
Agente de Tratamento e Normalização de Evidências (RF 3) Normalizar, validar, deduplicar e organizar o pacote bruto de evidências retornado pela API para uso analítico.
Agente de Análise de Causa Raiz da Disputa (RF 4) Identificar causa raiz, fatores contribuintes e documentação adicional necessária a partir das evidências normalizadas.
Agente Gerador de Dossiê de Mediação (RF 5) Produzir um dossiê claro e acionável para mediação da disputa, consolidando evidências, análise, conclusão e próximos passos.

5. Protótipos

Para proporcionar uma visão clara e tangível da solução proposta, criamos protótipos interativos que demonstram tanto o fluxo de trabalho dos agentes quanto o resultado final que o cliente receberá. Explore os links abaixo para entender melhor a solução em ação.

6. Requisitos Funcionais

RF 1. Agente Preparador de Payload de Coleta de Evidências de Disputa

1.1 Tarefa do Agente

Consolidar informações do caso de disputa e preparar um payload único e completo para recuperar, em uma chamada, todas as evidências relevantes da transação.

1.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um objeto JSON com os dados da disputa. Este objeto inclui informações como dispute_id, transaction_id, tipo_disputa e outros detalhes relevantes sobre a transação e as partes envolvidas.

# 2. Objetivo
Consolidar essas informações e preparar um payload único e completo para recuperar, em uma chamada, todas as evidências relevantes da transação.

# 3. Regras que você deve seguir para gerar sua resposta
- Janela temporal: se transaction_ts_iso presente, definir janela_inicio_iso = ts - 7 dias e janela_fim_iso = ts + 30 dias; se tipo_disputa = "nao_autorizada" ou houver registro de chargeback, usar -30 dias e +90 dias. Se transaction_ts_iso ausente, manter -30/+90 e registrar fallback_janela:true no payload meta.
- Campos include obrigatórios: sempre marcar true para transacao, logs_pagamento, autenticacao, kyc_buyer, kyc_seller, comunicacoes, politicas_vendedor, envio_entrega, reembolsos_chargebacks. Não remover itens por tipo de disputa; usar priorização por meio de hints.
- Hints por tipo de disputa (adicionar em payload.hints):
  • nao_recebido: ["prioridade_envio_entrega","timeline_fulfillment"]
  • nao_conforme: ["politicas_devolucao","rma_devolucao","comunicacoes_pos_venda"]
  • nao_autorizada: ["3ds","avs","cvv","ip","geo","device_fingerprint","tentativas_previas"]
  • duplicidade: ["capturas_correlatas","reconciliacao_gateway"]
  • reembolso_nao_processado: ["registros_reembolso","concil_bancaria","notificacoes_cliente"]
- Filtros: sempre incluir transaction_id, buyer_id (se disponível), seller_id. Se valor e moeda informados, incluir em filters.valor_esperado e filters.moeda para conferência posterior.
- Privacidade: configurar privacy.mask_pan=true (exibir apenas últimos 4 dígitos), privacy.mask_emails=true (ofuscar parte local), e solicitar apenas KYC/KYB de nível de verificação e datas (sem documentos brutos).
- Paginação: definir page=1 e page_size=500; incluir paginação para logs/comunicações extensas. Incluir continue_token quando aplicável (campo reservado no payload).
- Consistência: idempotency_key deve ser determinística no formato {dispute_id}-{transaction_id}. Se algum ID obrigatório estiver ausente, incluir em payload campo missing_required=[...] sem impedir a chamada. 
1.3 Configurações do Agente

1.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente é o ponto de partida do fluxo e deve ser acionado pelo envio de um objeto JSON com os dados da disputa via API. Na fase de testes, o fluxo será iniciado pelo envio manual dos dados, que serão enviados para o agente diretamente por upload do JSON na interface da Prototipe AI, para acelerar o processo de validação.
  • Tipo do input: O input inicial para o fluxo é um objeto JSON com os dados da disputa.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 10.000 caracteres.

1.3.2 Especificação do Output

  • Formato de output: O output deve ser um objeto JSON contendo o payload preparado para a chamada à API.
  • Exemplo de Estrutura de Output:
     {"transaction_id":"string","dispute_id":"string","include":{"transacao":true,"logs_pagamento":true,"autenticacao":true,"kyc_buyer":true,"kyc_seller":true,"comunicacoes":true,"politicas_vendedor":true,"envio_entrega":true,"reembolsos_chargebacks":true},"filters":{"janela_inicio_iso":"YYYY-MM-DDTHH:MM:SSZ","janela_fim_iso":"YYYY-MM-DDTHH:MM:SSZ","transaction_id":"string","buyer_id":"string","seller_id":"string"},"privacy":{"mask_pan":true,"mask_emails":true},"pagination":{"page":1,"page_size":500},"idempotency_key":"{dispute_id}-{transaction_id}","locale":"pt-BR"} 
  • Número de caracteres esperado: O JSON final deve ser conciso e informativo, com um tamanho estimado em torno de 2.000 caracteres.

1.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

1.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não se conecta a sistemas externos.

1.3.5 Memória

  • Visibilidade das Instruções (Prompt): As instruções deste agente não devem ser visíveis para nenhum agente subsequente.
  • Visibilidade da Resposta: A resposta gerada por este agente deve ser visível para o Agente de Execução de Chamada à API (RF 2).

1.3.6 Regras de Orquestração e Transição

Ao concluir sua execução, esse agente aciona o Agente de Execução de Chamada à API (RF 2).

RF 2. Agente de Execução de Chamada à API

2.1 Tarefa do Agente

Realizar chamada à API do Sistema de Pagamentos para obter o pacote de evidências consolidado da disputa, conforme payload preparado.

2.2 Prompt ou Instruções do Agente
 Esse agente não precisa de instruções para chamadas ao LLM, pois sua única função é executar a chamada à API cujo payload ele já recebe pronto. 
2.3 Configurações do Agente

2.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão do agente anterior (RF 1).
  • Tipo do input: Este agente deve ser apto a receber como input um payload pronto em JSON gerado pelo agente anterior.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de até 2.000 caracteres.

2.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON contendo os dados recuperados da API com sub-blocos.
  • Exemplo de Estrutura de Output:
     {"transacao": {...}, "autenticacao": {...}, "logs_pagamento": [...], "kyc_buyer": {...}, "kyb_seller": {...}, "comunicacoes": [...], "envio_entrega": {...}, "reembolsos_chargebacks": [...], "politicas_vendedor": {...}, "meta_api": {"page":1,"page_size":500,"continue_token":"string|nullable"}} 
  • Número de caracteres esperado: O JSON gerado deve ser conciso e informativo, com um tamanho estimado em torno de 5.000 caracteres.

2.3.3 Parâmetros de Geração

  • Modelo: Não se aplica (uso de ferramenta)
  • Temperatura: Não se aplica (uso de ferramenta)

2.3.4 Ferramentas do Agente

  • Documentos: Não consulta.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: O agente deverá enviar o JSON recebido para a API externa do Sistema de Pagamentos e retornar os dados recebidos como resposta.

2.3.5 Memória

2.3.6 Regras de Orquestração e Transição

Ao concluir sua execução, esse agente aciona o Agente de Tratamento e Normalização de Evidências (RF 3).

RF 3. Agente de Tratamento e Normalização de Evidências

3.1 Tarefa do Agente

Normalizar, validar, deduplicar e organizar o pacote bruto de evidências retornado pela API para uso analítico.

3.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um JSON bruto com evidências múltiplas retornadas pela API do Sistema de Pagamentos.

# 2. Objetivo
Normalizar, validar, deduplicar e organizar o pacote bruto de evidências retornado pela API para uso analítico.

# 3. Regras que você deve seguir para gerar sua resposta
- Normalização temporal: converter todos os timestamps para ISO 8601 em UTC e ordenar timeline por ts ascendente; quando houver granularidade em milissegundos, preservar 3 casas decimais.
- Moedas e valores: manter moeda original; criar valor_normalizado igual ao informado quando moeda=BRL; se moeda ≠ BRL e não houver taxa/FX, não converter e marcar meta.fx_aplicado:false. Validar: capturas - reembolsos - estornos >= 0 com tolerância de 0.01; se violar, adicionar inconsistencia "soma_capturas_neq_valor".
- Deduplicação: considerar duplicata quando (mesmo id) OU (mesmo tipo de evento e mesmo valor e delta_ts <= 120s e mesma fonte). Para comunicações, considerar duplicata por hash de conteúdo + delta_ts <= 120s.
- Mapeamento canônico:
  • pagamento -> {autorizado,capturado,estornado,chargeback,negado}
  • entrega -> {em_preparacao,em_transito,entregue,devolvido,extraviado,na}
  • 3DS -> {success, failed, na}
- Integridade por tipo de disputa (preparar ausencias_criticas):
  • nao_recebido: exigir tracking válido e status entrega; se ausente, incluir "tracking".
  • nao_conforme: exigir políticas de devolução e registros de RMA/devolução; se ausentes, incluir "rma" ou "politicas".
  • nao_autorizada: exigir 3DS/AVS/CVV e dados de dispositivo/IP/geo; ausências entram na lista.
  • duplicidade: exigir correlação de capturas (mesmo pedido/valor) e reconciliação; se ausente, incluir "correlacao_capturas".
  • reembolso_nao_processado: exigir registro de refund e conciliação; se ausentes, incluir "concil_bancaria".
- Risco preliminar (0–1):
  • +0.25 se 3DS failed/na em ambiente que exige 3DS
  • +0.20 se AVS mismatch
  • +0.15 se CVV mismatch
  • +0.15 se geo distante > 500km do billing
  • +0.10 se tentativas_falhas >= 3
  • Limitar a 1.00; se nenhum sinal, score=0.0.
- Campos NA: onde informação não existir, preencher com "na" ou null conforme esperado e registrar em ausencias_criticas somente quando impactar análise. 
3.3 Configurações do Agente

3.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão do agente anterior (RF 2).
  • Tipo do input: Este agente deve ser apto a receber como input um JSON bruto com evidências múltiplas retornadas pela API do Sistema de Pagamentos.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de até 5.000 caracteres.

3.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON contendo o resumo normalizado das evidências.
  • Exemplo de Estrutura de Output:
     {"resumo_normalizado":{"ids":{"dispute_id":"string","transaction_id":"string"},"timeline_iso":[{"ts":"2025-11-30T12:00:00Z","evento":"captura","fonte":"gateway"}],"autenticacao":{"resultado_3ds":"success|failed|na","avs":"match|mismatch|na","cvv":"match|mismatch|na"},"pagamento":{"valor":199.90,"moeda":"BRL","valor_normalizado":199.90,"status":"capturado|estornado|chargeback|autorizado|negado"},"fraude_risco":{"ip":"string|na","geo":"string|na","device_fingerprint":"string|na","tentativas_falhas":0,"score_risco":0.73},"kyc_buyer":{"nivel":"basico|alto|na","verificado":true},"kyb_seller":{"verificado":true},"comunicacoes":[{"id":"string","canal":"email|chat|ticket","direcao":"buyer->seller|seller->buyer","ts":"...","resumo":"..."}],"entrega":{"transportadora":"string|na","tracking":"string|na","status":"entregue|em_transito|devolvido|extraviado|na","prova_assinatura":true,"endereco_divergente":false},"reembolsos_chargebacks":[{"tipo":"refund|chargeback","ts":"...","valor":199.90,"status":"pendente|liquidado"}],"politicas":{"url_termos":"string|na","aceite_ts":"..."}},"inconsistencias":["soma_capturas_neq_valor","tracking_invalido"],"ausencias_criticas":["3ds","tracking"],"meta":{"versao":"1.1","moeda_padrao":"BRL","tz":"UTC"}} 
  • Número de caracteres esperado: O JSON gerado deve ser conciso e informativo, com um tamanho estimado em torno de 8.000 caracteres.

3.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

3.3.4 Ferramentas do Agente

  • Documentos: Não consulta.
  • Calculadora: Utiliza lógica interna para normalização e validação dos dados.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

3.3.5 Memória

3.3.6 Regras de Orquestração e Transição

Ao concluir sua execução, esse agente aciona o Agente de Análise de Causa Raiz da Disputa (RF 4).

RF 4. Agente de Análise de Causa Raiz da Disputa

4.1 Tarefa do Agente

Identificar causa raiz, fatores contribuintes e documentação adicional necessária a partir das evidências normalizadas.

4.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um JSON normalizado de evidências e o contexto da disputa.

# 2. Objetivo
Identificar a causa raiz, fatores contribuintes e a documentação adicional necessária a partir das evidências normalizadas.

# 3. Regras que você deve seguir para gerar sua resposta
- Deliberação imparcial: listar primeiro evidencias_pro_comprador e evidencias_pro_vendedor antes da conclusão. Não usar linguagem subjetiva.
- Critérios de classificação primária:
  • nao_recebido: tracking ausente/inválido OU status entrega ∉ {entregue} OU endereço divergente=true. Se timeline indica devolução sem reentrega e sem reembolso, manter nao_recebido.
  • nao_conforme: comunicações com descrição de defeito/divergência + existência/violação de política de devolução/RMA dentro do prazo.
  • fraude_nao_autorizada: 3DS failed/na + (AVS mismatch OU CVV mismatch) + divergência de geo/ip/device ou tentativas_falhas>=3.
  • duplicidade_captura: duas ou mais capturas mesmo pedido/valor em janela <= 10min sem estorno correspondente.
  • reembolso_pendente: registro de refund no seller/ERP sem conciliação no adquirente/banco em até 10 dias úteis.
  • erro_processamento: divergência entre gateway e ERP/loja (ex.: marcado capturado mas sem liquidação recorrente) sem evidência de fraude/duplicidade.
  • politica_nao_cumprida: termos/políticas aceitos impõem condição não atendida (ex.: prazo de devolução expirado) e comunicação confirma ciência.
  • indeterminado: quando ausencias_criticas impedem conclusão.
- Regras de desempate: se critérios de duas classes presentes, priorizar na ordem: fraude_nao_autorizada > duplicidade_captura > erro_processamento > reembolso_pendente > nao_recebido > nao_conforme > politica_nao_cumprida. Se sinais equivalentes, classificar como indeterminado.
- Cálculo de confiança (0–1):
  • Base 0.5
  • +0.15 por cada evidência forte a favor da classe (ex.: 3DS failed, tracking inválido, duplicidade confirmada)
  • −0.10 por cada inconsistência relevante
  • −0.15 se houver ausencias_criticas relacionadas à classe
  • Limitar entre 0 e 1; se indeterminado, confiança <= 0.49.
- Próxima ação recomendada (mapeamento determinístico):
  • fraude_nao_autorizada: escalar_chargeback
  • duplicidade_captura: mediar_reembolso_total (ou parcial se uma das capturas já estornada); quando parcial, usar mediar_reembolso_parcial
  • reembolso_pendente: solicitar_provas_ao_vendedor (com comprovante de processamento) ou mediar_reembolso_parcial quando parcial processado
  • nao_recebido: solicitar_provas_ao_vendedor (POD/assinatura) ou mediar_reembolso_parcial se entrega não comprovada
  • nao_conforme: mediar_reembolso_parcial ou troca conforme política
  • erro_processamento: manter_cobranca após correção de registro OU mediar_reembolso_parcial conforme impacto
  • politica_nao_cumprida: manter_cobranca
  • indeterminado: solicitar_provas_ao_vendedor
- Documentos adicionais: retornar somente itens faltantes e diretamente auditáveis (ex.: POD com assinatura, protocolo de RMA, extrato de adquirente). 
4.3 Configurações do Agente

4.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão do agente anterior (RF 3).
  • Tipo do input: Este agente deve ser apto a receber um JSON normalizado de evidências e o contexto da disputa.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de até 8.000 caracteres.

4.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON contendo a análise da causa raiz da disputa.
  • Exemplo de Estrutura de Output:
     {"dispute_id":"string","transaction_id":"string","causa_raiz":"fraude_nao_autorizada|nao_recebido|nao_conforme|duplicidade_captura|erro_processamento|reembolso_pendente|politica_nao_cumprida|indeterminado","fatores_contribuintes":["3ds_ausente","avs_mismatch","tracking_invalido"],"confianca":0.0-1.0,"documentos_adicionais_requeridos":["comprovante_de_entrega_com_assinatura","registro_de_reembolso_no_adquirente"],"proxima_acao_recomendada":"mediar_reembolso_parcial|solicitar_provas_ao_vendedor|manter_cobranca|escalar_chargeback","evidencias_pro_comprador":["..."],"evidencias_pro_vendedor":["..."],"observacoes":"string curta e objetiva"} 
  • Número de caracteres esperado: O JSON gerado deve ser conciso e informativo, com um tamanho estimado em torno de 4.000 caracteres.

4.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

4.3.4 Ferramentas do Agente

  • Documentos: Não consulta.
  • Calculadora: Utiliza lógica interna para análise dos dados.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

4.3.5 Memória

  • Visibilidade das Instruções (Prompt): As instruções não são visíveis para agentes subsequentes.
  • Visibilidade da Resposta: A resposta gerada por este agente deve ser visível para o Agente Gerador de Dossiê de Mediação (RF 5).

4.3.6 Regras de Orquestração e Transição

Ao concluir sua execução, esse agente aciona o Agente Gerador de Dossiê de Mediação (RF 5).

RF 5. Agente Gerador de Dossiê de Mediação

5.1 Tarefa do Agente

Produzir um dossiê claro e acionável para mediação da disputa, consolidando evidências, análise, conclusão e próximos passos.

5.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo os resultados da análise de causa raiz e evidências normalizadas.

# 2. Objetivo
Produzir um dossiê claro e acionável para mediação da disputa, consolidando evidências, análise, conclusão e próximos passos.

# 3. Regras que você deve seguir para gerar sua resposta
- Estrutura fixa: sempre gerar as seções na ordem: Identificação; Timeline Unificada; Evidências‑Chave; Análise de Causa Raiz; Lacunas Documentais; Recomendações; Apêndice.
- Linguagem e formatação: tom factual, imparcial, frases curtas; usar listas para evidências e lacunas; não incluir dados sensíveis além do necessário; mascarar PAN (******1234) e e‑mails (ex.: n***@dominio.com).
- Seleção de evidências‑chave: incluir no máximo 6 bullets priorizando sinais decisivos para a causa raiz e contrassinais que possam surgir na mediação.
- Consistência com análise: a Próxima ação recomendada deve refletir exatamente o mapeamento definido pelo agente de análise; incluir somente uma ação final.
- Datas e valores: exibir datas em UTC (ISO 8601) e valores com duas casas decimais e moeda.
- Apêndice: resumir (não colar íntegro) logs longos e políticas; incluir links/ids de referência quando existirem. 
5.3 Configurações do Agente

5.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão do agente anterior (RF 4).
  • Tipo do input: Este agente deve ser apto a receber os resultados da análise de causa raiz e evidências normalizadas.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de até 4.000 caracteres.

5.3.2 Especificação do Output

  • Formato de output: O output deve ser um dossiê formatado em texto estruturado.
  • Exemplo de Estrutura de Output:
     # Dossiê de Mediação da Disputa
    
    ## Identificação
    - Dispute ID: XXX
    - Transaction ID: YYY
    - Valor: BRL 199,90
    - Data da Transação (UTC): 2025-11-30T12:00:00Z
    
    ## Timeline Unificada (UTC)
    - 2025-11-30T11:59:30Z: Autorização (AVS: match, CVV: match)
    - 2025-11-30T12:00:00Z: Captura
    - 2025-12-01T14:20:00Z: Envio - Transportadora ABC (Tracking 123)
    - 2025-12-03T16:40:00Z: Entrega confirmada (assinatura)
    
    ## Evidências-Chave
    - 3DS: sucesso
    - AVS/CVV: match/match
    - Entrega: comprovada com assinatura
    - Comunicações: 4 interações (2 comprador → vendedor, 2 vendedor → comprador)
    
    ## Análise de Causa Raiz
    - Classificação: nao_recebido|nao_conforme|fraude_nao_autorizada|duplicidade_captura|reembolso_pendente|erro_processamento|indeterminado
    - Fatores contribuintes: [...]
    - Confiança: 0.86
    
    ## Lacunas Documentais
    - [ ] Comprovante de reembolso no adquirente
    - [ ] Foto de prova de entrega
    
    ## Recomendações
    - Próxima ação recomendada: mediar_reembolso_parcial|solicitar_provas_ao_vendedor|manter_cobranca|escalar_chargeback
    - Riscos e observações: ...
    
    ## Apêndice
    - Políticas/Termos aceitos (link)
    - Logs de pagamento (resumo)
    - Dados KYC/KYB (resumo não sensível)
     
  • Número de caracteres esperado: O texto final deve ser conciso e informativo, com um tamanho estimado em torno de 3.000 caracteres.

5.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

5.3.4 Ferramentas do Agente

  • Documentos: Não consulta.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

5.3.5 Memória

  • Visibilidade das Instruções (Prompt): As instruções não são visíveis para agentes subsequentes.
  • Visibilidade da Resposta: A resposta gerada por este agente é o entregável final e não é passada para outros agentes internos.

5.3.6 Regras de Orquestração e Transição

A execução deste agente finaliza o fluxo. O dossiê gerado é o resultado que deve ser disponibilizado ao usuário.

© 2025 prototipe.ai. Todos os direitos reservados.