1. Propósito e Escopo
Este documento define todos os prompts, configurações de memória, transição entre estados, consulta a documentos e demais requisitos funcionais para o Fluxo de Agentes "Análise de Utilização de Vale-Saúde", uma solução de automação projetada para analisar padrões de uso dos vales-saúde, fornecendo insights para otimização de benefícios e identificação de tendências de saúde. 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 é transformar dados de utilização em insights acionáveis que possam otimizar a distribuição e o uso dos vales-saúde, além de identificar tendências de saúde que possam influenciar futuros ajustes nos benefícios.
2. Contexto e Problema
Cenário Atual
As organizações enfrentam desafios significativos ao tentar entender os padrões de uso dos vales-saúde e como eles impactam os custos e benefícios. Sem ferramentas adequadas, a análise desses dados pode ser demorada e sujeita a erros.
- Dificuldade em entender os padrões de uso dos vales-saúde e como eles afetam os custos e benefícios.
- Falta de insights para otimizar a distribuição e uso dos vales-saúde.
Problemas Identificados
- Falta de visibilidade: A ausência de uma visão clara sobre o uso dos vales-saúde impede a tomada de decisões informadas.
- Complexidade na análise: A análise manual de grandes volumes de dados é trabalhosa e propensa a erros.
- Oportunidades perdidas: Sem insights acionáveis, as oportunidades de otimização de benefícios são frequentemente negligenciadas.
3. Impactos Esperados
A implementação deste fluxo de automação visa alcançar os seguintes resultados:
- Fornecer insights acionáveis para otimizar a utilização dos vales-saúde.
- Identificar tendências de saúde que possam influenciar ajustes nos benefícios.
- Reduzir custos operacionais associados à análise manual de dados.
- Aumentar a precisão na análise de dados de utilização dos vales-saúde.
4. Visão Geral da Solução
O agente de IA para análise de utilização de vale-saúde processa dados de utilização, aplica regras para identificar padrões e tendências, e gera insights para otimização de benefícios. 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 análise e otimização de benefícios de saúde.
A solução consiste em um fluxo de automação composto por 6 agentes de IA. O processo inicia com a validação e preparação dos dados de utilização e termina com a geração de um relatório executivo com insights, tendências e recomendações priorizadas.
A execução dos agentes é sequencial e linear, seguindo a ordem definida na tabela abaixo.
| Agentes | Função Principal |
|---|---|
Agente de Validação e Preparação de Dados de Utilização de Vales-Saúde (RF 1)
| Validar, padronizar e preparar o dataset de utilização de vales-saúde para análises subsequentes. |
Agente de Cálculo de Métricas e KPIs (RF 2)
| Calcular KPIs e distribuições essenciais de utilização dos vales-saúde. |
Agente de Detecção de Padrões e Anomalias (RF 3)
| Detectar padrões relevantes e anomalias que possam indicar uso atípico, abuso ou mudanças abruptas. |
Agente de Segmentação de Usuários por Padrão de Uso (RF 4)
| Segmentar usuários em grupos operacionais para gestão de benefícios e comunicação. |
Agente de Recomendações para Otimização de Benefícios (RF 5)
| Gerar recomendações acionáveis para otimização de custos e melhoria de acesso/uso do benefício. |
Agente de Geração de Relatório Executivo (RF 6)
| Consolidar achados em relatório executivo claro com insights, tendências e recomendações priorizadas. |
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 de Validação e Preparação de Dados de Utilização de Vales-Saúde
1.1 Tarefa do Agente
Validar, padronizar e preparar o dataset de utilização de vales-saúde para análises subsequentes.
1.2 Prompt ou Instruções do Agente
# 1. Contexto e explicações sobre inputs iniciais Você está recebendo um arquivo ou objeto tabular com colunas mínimas: id_usuario (string/num), data_uso (string de data ou datetime), valor_utilizado (numérico), categoria_servico (string). Parâmetros opcionais: timezone, moeda, mapa_normalizacao_categorias, limites_beneficio_por_usuario (limite_mensal), feriados (YYYY-MM-DD). # 2. Objetivo Validar, padronizar e preparar o dataset de utilização de vales-saúde para análises subsequentes. # 3. Regras que você deve seguir para gerar sua resposta - Validar esquema: exigir colunas obrigatórias; rejeitar linhas onde id_usuario está vazio, data_uso inválida, valor_utilizado nulo/NaN, categoria_servico vazia. - Parse de data: converter data_uso para datetime no timezone informado (padrão UTC); extrair ano, mês, semana ISO, dia_da_semana (0-6), hora (0-23). - Tipos e faixas: valor_utilizado deve ser numérico ≥ 0; valores negativos são descartados com motivo='valor_negativo'. Valores com separador decimal por vírgula devem ser convertidos. - Normalização de categorias: aplicar mapa_normalizacao_categorias quando fornecido; caso contrário, padronizar para minúsculas, remover acentos e trim; registrar categorias desconhecidas. - Deduplicação: remover duplicatas estritas (id_usuario, data_uso, valor_utilizado, categoria_servico); contar e registrar número removido. - Moeda: preservar moeda de entrada no metadata; não converter valores monetários sem taxa fornecida. - Limites de benefício: se limites_beneficio_por_usuario fornecido, adicionar campo 'ultrapassou_limite_mensal' por usuário/mês. - Qualidade: calcular % de nulos por coluna, número de linhas válidas e descartadas por motivo; incluir até 5 exemplos por motivo em linhas_descartadas.samples. - Privacidade: manter apenas id_usuario como identificador; não incluir nomes, e-mails ou outros PII. - Período: definir periodo_referencia como [min(data_uso), max(data_uso)] considerando apenas linhas válidas.
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 arquivo ou objeto tabular 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 na interface da Prototipe AI, para acelerar o processo de validação.
- Tipo do input: O input inicial para o fluxo é um arquivo ou objeto tabular.
-
Formatos Suportados: Esse agente deve ser capaz de receber dados nos formatos:
.csv,.xlsx. - Número de caracteres esperado: Este agente deve ter capacidade para processar um input de até 100.000 caracteres.
1.3.2 Especificação do Output
- Formato de output: O output deve ser um objeto JSON contendo: dataset_padronizado (linhas válidas, tipos coerentes), linhas_descartadas (motivo, contagem e amostras), periodo_referencia (data_min, data_max), parametros_aplicados (timezone, moeda, normalizações), sumario_qualidade (n_registros, % nulos por campo, duplicados removidos).
-
Exemplo de Estrutura de Output:
{ "dataset_padronizado": "linhas válidas, tipos coerentes", "linhas_descartadas": "motivo, contagem e amostras", "periodo_referencia": "data_min, data_max", "parametros_aplicados": "timezone, moeda, normalizações", "sumario_qualidade": "n_registros, % nulos por campo, duplicados removidos" } - Número de caracteres esperado: O JSON gerado deve ter um tamanho estimado em torno de 5.000 caracteres.
1.3.3 Parâmetros de Geração
- Modelo: GPT-4
- Temperatura: 0.5
1.3.4 Ferramentas do Agente
- Documentos: Não consulta documentos externos.
- Calculadora: Utiliza lógica interna para validação de dados.
- 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 Cálculo de Métricas e KPIs (RF 2).
1.3.6 Regras de Orquestração e Transição
Ao concluir sua execução, esse agente aciona o Agente de Cálculo de Métricas e KPIs (RF 2).
RF 2. Agente de Cálculo de Métricas e KPIs
2.1 Tarefa do Agente
Calcular KPIs e distribuições essenciais de utilização dos vales-saúde.
2.2 Prompt ou Instruções do Agente
# 1. Contexto e explicações sobre inputs iniciais Você está recebendo o dataset_padronizado e periodo_referencia do agente anterior. # 2. Objetivo Calcular KPIs e distribuições essenciais de utilização dos vales-saúde. # 3. Regras que você deve seguir para gerar sua resposta - Definições: transação = 1 linha válida; usuário ativo no mês = usuário com >=1 transação no mês. - Ticket médio = gasto_total / transacoes_total; gasto_medio_por_usuario = gasto_total / usuarios_unicos. - Frequência média mensal = média de transacoes por usuário por mês dentro do período. - Distribuição por categoria: somar gasto e contar transações por categoria; retornar top 10 categorias por gasto e agrupar demais em 'outros'. - Dia da semana: 0=segunda ... 6=domingo; retornar participação de gasto (%) e ticket médio por dia. - Hora do dia: buckets por hora (0-23) com gasto_total e participação. - Mensal: para cada YYYY-MM, calcular gasto_total, usuarios_ativos, ticket_medio, frequência média. - Percentis: computar sobre valor_utilizado por transação e sobre gasto_mensal_por_usuario (soma por usuário por mês). - Concentração: top_10_usuarios_%_gasto = (soma gasto dos 10 maiores usuários por gasto_total); índice de Gini aproximado com curva de Lorenz discreta por gasto_mensal_por_usuario. - Cobertura de limite: quando limites existem, calcular % de usuários que atingem ≥90% do limite no mês e % que ultrapassam. - Formatação: valores monetários com 2 casas decimais; percentuais com 1 casa decimal e símbolo %.
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 bem-sucedida do agente anterior (RF 1).
- Tipo do input: Este agente deve ser apto a receber como input um objeto JSON contendo o dataset_padronizado e o periodo_referencia do agente anterior.
-
Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato:
.json(JSON). - Número de caracteres esperado: Este agente deve ter capacidade para processar um input de até 10.000 caracteres.
2.3.2 Especificação do Output
- Formato de output: O output deve ser um JSON "kpis" contendo: totais (gasto_total, transacoes_total), usuarios (usuarios_unicos, usuarios_ativos_mensal, taxa_adesao se houver base_usuarios), uso (ticket_medio, gasto_medio_por_usuario, frequencia_media_mensal), distribuicoes (por_categoria, por_dia_da_semana, por_hora, por_mes), percentis (p50, p75, p90, p95, p99 de valor_utilizado e gasto_mensal_por_usuario), concentracao (top_10_usuarios_%_gasto, indice_gini_aproximado), cobertura_limite (se limites fornecidos).
-
Exemplo de Estrutura de Output:
{ "kpis": { "totais": "gasto_total, transacoes_total", "usuarios": "usuarios_unicos, usuarios_ativos_mensal, taxa_adesao", "uso": "ticket_medio, gasto_medio_por_usuario, frequencia_media_mensal", "distribuicoes": "por_categoria, por_dia_da_semana, por_hora, por_mes", "percentis": "p50, p75, p90, p95, p99", "concentracao": "top_10_usuarios_%_gasto, indice_gini_aproximado", "cobertura_limite": "%, %" } } - Número de caracteres esperado: O JSON gerado deve ter um tamanho estimado em torno de 3.000 caracteres.
2.3.3 Parâmetros de Geração
- Modelo: GPT-4
- Temperatura: 0.5
2.3.4 Ferramentas do Agente
- Documentos: Não consulta documentos externos.
- Calculadora: Utiliza lógica interna para cálculo de KPIs.
- Busca Online: Não utiliza.
- Sistemas Externos: Não se conecta a sistemas externos.
2.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 Detecção de Padrões e Anomalias (RF 3).
2.3.6 Regras de Orquestração e Transição
Ao concluir sua execução, esse agente aciona o Agente de Detecção de Padrões e Anomalias (RF 3).
RF 3. Agente de Detecção de Padrões e Anomalias
3.1 Tarefa do Agente
Detectar padrões relevantes e anomalias que possam indicar uso atípico, abuso ou mudanças abruptas.
3.2 Prompt ou Instruções do Agente
# 1. Contexto e explicações sobre inputs iniciais Você está recebendo o dataset_padronizado e kpis. # 2. Objetivo Detectar padrões relevantes e anomalias que possam indicar uso atípico, abuso ou mudanças abruptas. # 3. Regras que você deve seguir para gerar sua resposta - Transações atípicas: marcar valor_utilizado como anômalo se valor > mediana + 4*MAD da distribuição da categoria ou > p99.5 global, registrar método e limiar. - Burst diário por usuário: sinalizar se um usuário tem transacoes_dia > p99 do próprio usuário histórico ou > 8 transações/dia quando histórico insuficiente. - Crescimento abrupto: comparar gasto semanal atual vs média das últimas 4 semanas; anomalia se variação > +60% com base mínima ≥ 100 transações ou gasto ≥ P95 semanal histórico. - Queda abrupta: variação < -50% sob mesmas bases; registrar segmento afetado (categoria, dia da semana). - Categoria fora de padrão: marcar categoria se ticket_medio > p95 do ticket_medio das categorias e crescimento > 30% m/m. - Sazonalidade: identificar picos recorrentes por mês/dia_da_semana se participação de gasto variar > 1.5x da mediana sazonal. - Cada anomalia deve incluir: tipo, método (MAD/IQR/variação), limiar, valor_observado, período, dimensão (usuario/categoria/tempo) e severidade (baixa/média/alta) mapeada por distância ao limiar.
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 bem-sucedida do agente anterior (RF 2).
- Tipo do input: Este agente deve ser apto a receber como input o dataset_padronizado e os kpis gerados pelo agente anterior.
-
Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato:
.json(JSON). - Número de caracteres esperado: Este agente deve ter capacidade para processar um input de até 10.000 caracteres.
3.3.2 Especificação do Output
- Formato de output: O output deve ser um JSON "anomalias_e_padroes" com listas: anomalias_transacoes (usuario, data, valor, motivo, limiar), anomalias_agregadas (periodo, categoria, metrica, variacao, base_minima, limiar), padroes_relevantes (sazonalidades, horários de pico, categorias em ascensão/queda).
-
Exemplo de Estrutura de Output:
{ "anomalias_e_padroes": { "anomalias_transacoes": "usuario, data, valor, motivo, limiar", "anomalias_agregadas": "periodo, categoria, metrica, variacao, base_minima, limiar", "padroes_relevantes": "sazonalidades, horários de pico, categorias em ascensão/queda" } } - Número de caracteres esperado: O JSON gerado deve ter um tamanho estimado em torno de 3.000 caracteres.
3.3.3 Parâmetros de Geração
- Modelo: GPT-4
- Temperatura: 0.5
3.3.4 Ferramentas do Agente
- Documentos: Não consulta documentos externos.
- Calculadora: Utiliza lógica interna para detecção de padrões e anomalias.
- Busca Online: Não utiliza.
- Sistemas Externos: Não se conecta a sistemas externos.
3.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 Segmentação de Usuários por Padrão de Uso (RF 4).
3.3.6 Regras de Orquestração e Transição
Ao concluir sua execução, esse agente aciona o Agente de Segmentação de Usuários por Padrão de Uso (RF 4).
RF 4. Agente de Segmentação de Usuários por Padrão de Uso
4.1 Tarefa do Agente
Segmentar usuários em grupos operacionais para gestão de benefícios e comunicação.
4.2 Prompt ou Instruções do Agente
# 1. Contexto e explicações sobre inputs iniciais Você está recebendo o dataset_padronizado e kpis. # 2. Objetivo Segmentar usuários em grupos operacionais para gestão de benefícios e comunicação. # 3. Regras que você deve seguir para gerar sua resposta - Calcular gasto_mensal_por_usuario e transacoes_mensais_por_usuario na janela do período. - Heavy users: usuários no top 10% de gasto_mensal_medio ou com ≥ 4 transações/mês e gasto ≥ p75. - Moderados: entre p40 e p90 de gasto_mensal_medio, excluindo heavy e leves. - Leves: ≤ p40 de gasto_mensal_medio ou < 2 transações/mês. - Novos: primeira transação dentro dos últimos 30 dias do período. - Inativos: nenhum uso nos últimos 60 dias do período mas com histórico anterior. - Categoria dominante: atribuir ao usuário a categoria com maior gasto no período, desde que represente ≥ 50% do gasto total do usuário. - Sensíveis a horário: usuários com ≥ 70% das transações em janela de 4 horas (por exemplo, 18–22h). - Para cada segmento, retornar: n_usuarios, % do total, gasto_total, gasto_medio_usuario, ticket_medio, frequencia_media. - Um usuário pode pertencer a múltiplos rótulos; retornar critério que gerou classificação para transparência.
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 bem-sucedida do agente anterior (RF 3).
- Tipo do input: Este agente deve ser apto a receber como input o dataset_padronizado e os kpis gerados pelo agente anterior.
-
Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato:
.json(JSON). - Número de caracteres esperado: Este agente deve ter capacidade para processar um input de até 10.000 caracteres.
4.3.2 Especificação do Output
- Formato de output: O output deve ser um JSON "segmentos" com definições, critérios e contagens: heavy_users, moderados, leves, novos, inativos, por_categoria_dominante, sensiveis_a_horario; para cada segmento, lista de critérios e métricas (gasto_mensal_medio, frequencia, ticket_medio).
-
Exemplo de Estrutura de Output:
{ "segmentos": { "heavy_users": "definições, critérios e contagens", "moderados": "definições, critérios e contagens", "leves": "definições, critérios e contagens", "novos": "definições, critérios e contagens", "inativos": "definições, critérios e contagens", "por_categoria_dominante": "definições, critérios e contagens", "sensiveis_a_horario": "definições, critérios e contagens" } } - Número de caracteres esperado: O JSON gerado deve ter um tamanho estimado em torno de 3.000 caracteres.
4.3.3 Parâmetros de Geração
- Modelo: GPT-4
- Temperatura: 0.5
4.3.4 Ferramentas do Agente
- Documentos: Não consulta documentos externos.
- Calculadora: Utiliza lógica interna para segmentação de usuários.
- Busca Online: Não utiliza.
- Sistemas Externos: Não se conecta a sistemas externos.
4.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 Recomendações para Otimização de Benefícios (RF 5).
4.3.6 Regras de Orquestração e Transição
Ao concluir sua execução, esse agente aciona o Agente de Recomendações para Otimização de Benefícios (RF 5).
RF 5. Agente de Recomendações para Otimização de Benefícios
5.1 Tarefa do Agente
Gerar recomendações acionáveis para otimização de custos e melhoria de acesso/uso do benefício.
5.2 Prompt ou Instruções do Agente
# 1. Contexto e explicações sobre inputs iniciais Você está recebendo os kpis, anomalias_e_padroes e segmentos. # 2. Objetivo Gerar recomendações acionáveis para otimização de custos e melhoria de acesso/uso do benefício. # 3. Regras que você deve seguir para gerar sua resposta - Ajuste de limite por segmento: se heavy_users com ≥20% ultrapassando 90% do limite, sugerir aumento/rebalanceamento; impacto estimado ~ min(10%, %heavy_atribuivel_ao_limite). - Campanhas educativas: se ticket_medio alto e frequência baixa em uma categoria preventiva (ex: check-ups), propor campanha para moderados e leves; meta: +15% frequência, -5% ticket médio. - Renegociação com prestadores: se top 3 categorias concentram > 60% do gasto e ticket_medio > p75, sugerir renegociação/credenciamento alternativo; impacto: 3–8% de economia na categoria. - Controle de abusos: se houver bursts diários recorrentes em usuários, sugerir regras de antifraude (ex: limite de transações por dia, verificação adicional) e monitoramento; impacto: reduzir 30–50% dos casos sinalizados. - Redistribuição temporal: se picos de horário geram indisponibilidade, recomendar escalonamento de uso (incentivos fora do pico); objetivo: -10% na participação do pico e +5% na satisfação estimada. - Ajuste do portfólio de categorias: se categoria em queda com baixa adesão, avaliar substituição ou incentivo cruzado; impacto: +5–10% adesão naquela linha. - Cada recomendação deve citar a regra_acionadora (condição observada nos dados) e listar KPIs afetados (ex: ticket_medio, frequência, % ultrapasso_limite). - Priorizar pela razão impacto_estimado / custo_complexidade (baixa>média>alta) e pela severidade das anomalias relacionadas.
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 bem-sucedida do agente anterior (RF 4).
- Tipo do input: Este agente deve ser apto a receber como input os kpis, anomalias_e_padroes e segmentos gerados pelo agente anterior.
-
Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato:
.json(JSON). - Número de caracteres esperado: Este agente deve ter capacidade para processar um input de até 10.000 caracteres.
5.3.2 Especificação do Output
- Formato de output: O output deve ser um JSON "recomendacoes" com lista priorizada: recomendacao, objetivo, segmento_alvo/dimensao, regra_acionadora, impacto_estimado (economia% ou melhora adesao%), custo_complexidade (baixa/média/alta), KPIs_afetados, prazo_sugerido.
-
Exemplo de Estrutura de Output:
{ "recomendacoes": { "recomendacao": "objetivo, segmento_alvo/dimensao, regra_acionadora", "impacto_estimado": "economia% ou melhora adesao%", "custo_complexidade": "baixa/média/alta", "KPIs_afetados": "KPIs_afetados", "prazo_sugerido": "prazo_sugerido" } } - Número de caracteres esperado: O JSON gerado deve ter um tamanho estimado em torno de 3.000 caracteres.
5.3.3 Parâmetros de Geração
- Modelo: GPT-4
- Temperatura: 0.5
5.3.4 Ferramentas do Agente
- Documentos: Não consulta documentos externos.
- Calculadora: Utiliza lógica interna para geração de recomendações.
- Busca Online: Não utiliza.
- Sistemas Externos: Não se conecta a sistemas externos.
5.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 Geração de Relatório Executivo (RF 6).
5.3.6 Regras de Orquestração e Transição
Ao concluir sua execução, esse agente aciona o Agente de Geração de Relatório Executivo (RF 6).
RF 6. Agente de Geração de Relatório Executivo
6.1 Tarefa do Agente
Consolidar achados em relatório executivo claro com insights, tendências e recomendações priorizadas.
6.2 Prompt ou Instruções do Agente
# 1. Contexto e explicações sobre inputs iniciais Você está recebendo os kpis, anomalias_e_padroes, segmentos e recomendacoes. # 2. Objetivo Consolidar achados em relatório executivo claro com insights, tendências e recomendações priorizadas. # 3. Regras que você deve seguir para gerar sua resposta - Incluir números com formatação consistente (R$ com 2 casas; % com 1 casa). - Explicitar período analisado e base de dados (n_transacoes, n_usuarios). - Destacar top 3 categorias por gasto e quaisquer mudanças m/m significativas (>30%). - Listar no máximo 7 recomendações, ordenadas por prioridade calculada; cada uma com impacto_estimado, custo_complexidade e KPI alvo. - Evitar dados pessoais; nunca expor lista de usuários, apenas contagens e percentis. - Incluir observações de qualidade dos dados quando limitações influenciem conclusões.
6.3 Configurações do Agente
6.3.1 Especificação do Input
- Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão bem-sucedida do agente anterior (RF 5).
- Tipo do input: Este agente deve ser apto a receber como input os kpis, anomalias_e_padroes, segmentos e recomendacoes gerados pelo agente anterior.
-
Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato:
.json(JSON). - Número de caracteres esperado: Este agente deve ter capacidade para processar um input de até 10.000 caracteres.
6.3.2 Especificação do Output
- Formato de output: O output deve ser um relatório em markdown estruturado com: Sumário Executivo (3–5 bullet points), Período Analisado, KPIs principais, Padrões e Tendências, Anomalias e Riscos, Segmentação de Usuários, Recomendações Prioritárias (com impacto e custo), Próximos Passos, Apêndice Metodológico (definições e fórmulas).
-
Exemplo de Estrutura de Output:
**Sumário Executivo:** - Insight 1 - Insight 2 **Período Analisado:** - De XX/XX/XXXX a XX/XX/XXXX **KPIs principais:** - KPI 1 - KPI 2 **Padrões e Tendências:** - Padrão 1 - Padrão 2 **Anomalias e Riscos:** - Anomalia 1 - Anomalia 2 **Segmentação de Usuários:** - Segmento 1 - Segmento 2 **Recomendações Prioritárias:** - Recomendação 1 - Recomendação 2 **Próximos Passos:** - Passo 1 - Passo 2 **Apêndice Metodológico:** - Definição 1 - Definição 2
- Número de caracteres esperado: O relatório gerado deve ter um tamanho estimado em torno de 5.000 caracteres.
6.3.3 Parâmetros de Geração
- Modelo: GPT-4
- Temperatura: 0.5
6.3.4 Ferramentas do Agente
- Documentos: Não consulta documentos externos.
- Calculadora: Utiliza lógica interna para formatação e cálculo de dados.
- Busca Online: Não utiliza.
- Sistemas Externos: Não se conecta a sistemas externos.
6.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 (relatório executivo) é o entregável final e não é passada para outros agentes internos.
6.3.6 Regras de Orquestração e Transição
A execução deste agente finaliza o fluxo. O relatório gerado é o resultado que deve ser disponibilizado ao usuário.