Agente de IA para Integração de Dados entre Sistemas de Gestão de Planos de Saúde

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

Como criar um agente de IA que facilita a integração e troca de dados entre diferentes sistemas utilizados na gestão de planos de saúde.

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 Fluxo de Agentes "Integração de Dados entre Sistemas de Gestão de Planos de Saúde", uma solução de automação projetada para facilitar a troca de dados entre sistemas distintos na gestão de planos 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 é criar interfaces de integração entre sistemas diferentes, automatizar processos de troca de dados para minimizar erros e monitorar e ajustar continuamente as integrações para garantir eficiência.

2. Contexto e Problema

Cenário Atual

A gestão de planos de saúde envolve a utilização de múltiplos sistemas de informação que frequentemente não são compatíveis entre si, gerando dificuldades na troca de dados precisa e eficiente. Os principais desafios enfrentados são:

  • Incompatibilidades entre diferentes sistemas de gestão.
  • Dificuldade na troca de dados precisa e eficiente entre plataformas.

Atualmente, a integração de dados entre esses sistemas é realizada manualmente ou por meio de processos automatizados limitados, que são propensos a erros e ineficiências.


Problemas Identificados

  • Incompatibilidades de Sistema: Sistemas de gestão de saúde frequentemente possuem esquemas de dados diferentes, dificultando a integração direta.
  • Erros na Troca de Dados: A troca manual de dados é propensa a erros humanos, enquanto processos automatizados limitados podem não capturar todas as nuances necessárias para uma integração perfeita.
  • Falta de Monitoramento: Sem um monitoramento contínuo, as integrações podem enfrentar problemas de desempenho que não são detectados até que causem impactos significativos.

3. Impactos Esperados

A implementação deste fluxo de automação visa alcançar os seguintes resultados:

  • Melhorar a precisão da troca de dados entre sistemas de gestão de saúde.
  • Reduzir o tempo gasto na integração manual de dados.
  • Aumentar a eficiência operacional por meio de automação e monitoramento contínuo.
  • Garantir a consistência dos dados através de regras de validação e transformação bem definidas.

4. Visão Geral da Solução

O agente de IA para integração de dados entre sistemas de gestão de planos de saúde processa informações de diferentes sistemas, aplica regras de transformação e validação, e automatiza a troca de dados para garantir precisão e eficiência. A seguir são detalhadas todas as regras de negócio e especificações funcionais necessárias para que esse agente atue como um facilitador eficaz na integração de dados entre sistemas de saúde.

A solução consiste em um fluxo de automação composto por 7 agentes de IA. O processo inicia com a descoberta e mapeamento de esquemas e termina com o monitoramento e alertas de integração.

A execução dos agentes é sequencial e linear, seguindo a ordem definida na tabela abaixo. O fluxo inclui etapas condicionais que são executadas apenas se critérios específicos forem atendidos, conforme detalhado após a tabela.

Agentes Função Principal
Agente de Descoberta e Mapeamento de Esquemas (RF 1) Levantar entidades, campos e regras dos sistemas de gestão de saúde e propor um modelo canônico.
Agente de Definição de Regras de Transformação e Validação (RF 2) Especificar regras determinísticas de transformação, validação e enriquecimento entre fonte e destino.
Agente de Preparação de Chamadas (Payloads e Parâmetros) (RF 3) Gerar o plano de chamadas e os payloads prontos para execução nas APIs dos sistemas envolvidos.
Agente de Execução de Chamada à API (RF 4) Realizar chamadas às APIs dos sistemas para trocar dados conforme plano de execução.
Agente de Reconciliação e Controle de Qualidade (RF 5) Confrontar respostas das APIs com contratos esperados, validar integridade e produzir relatório de reconciliação.
Agente de Orquestração de Automação (RF 6) Definir a automação da troca de dados: janelas, lotes, concorrência e política de retry/backoff.
Agente de Monitoramento e Alertas de Integração (RF 7) Especificar métricas, SLOs, alertas e runbooks para operação contínua das integrações.


Regras de Execução Condicional ou Edges

  • Ativação do Agente de Reconciliação e Controle de Qualidade (RF 5): Este agente só será executado se houver divergências detectadas nas respostas das APIs durante a execução do Agente de Execução de Chamada à API (RF 4). Caso contrário, o fluxo pulará esta etapa e prosseguirá diretamente para o Agente de Orquestração de Automação (RF 6).

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 Descoberta e Mapeamento de Esquemas

1.1 Tarefa do Agente

Levantar entidades, campos e regras dos sistemas de gestão de saúde (fonte e destino) e propor um modelo canônico com mapa de correspondência entre os sistemas.

1.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo a descrição técnica dos sistemas de gestão de saúde, incluindo documentação de API, exemplos de payloads, e requisitos de interoperabilidade.

# 2. Objetivo
Levantar entidades, campos e regras dos sistemas de gestão de saúde (fonte e destino) e propor um modelo canônico com mapa de correspondência entre os sistemas.

# 3. Regras que você deve seguir para gerar sua resposta
- Liste explicitamente as entidades e seus campos por sistema, informando: nome no sistema, tipo (string/int/decimal/dateTime/boolean), formato, cardinalidade, obrigatoriedade e valores permitidos.
- Para cada campo com código de domínio, associe o catálogo de referência e o padrão de validação.
- Defina chaves primárias e chaves naturais por entidade; para integrações idempotentes, defina uma chave de deduplicação integration_id derivada de {sistema_origem, entidade, chave_natural, timestamp_normalizado}.
- Normalize endereços e telefones e defina regra de trimming, remoção de pontuações e normalização de acentos.
- Estabeleça convenções de data/hora em UTC, offset explícito quando fornecido e regra de truncamento/rounding para segundos e milissegundos.
- Identifique campos sensíveis e marque com classificação (Pessoal, Sensível) e base legal esperada.
- Documente incompatibilidades conhecidas e proponha fallback.
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 documentação técnica dos sistemas de gestão de saúde 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 de documentos na interface da Prototipe AI, para acelerar o processo de validação.
  • Tipo do input: O input inicial para o fluxo é composto por documentação técnica, incluindo exemplos de payloads e requisitos de interoperabilidade.
  • Formatos Suportados: Esse agente deve ser capaz de receber documentos nos formatos: .pdf, .docx, .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 150.000 caracteres.

1.3.2 Especificação do Output

  • Formato de output: O output deve ser um documento de mapeamento contendo o modelo canônico proposto, tabela de correspondência campo-a-campo, lacunas e suposições, e dicionário de códigos aplicáveis por campo.
  • Exemplo de Estrutura de Output:
    Documento de mapeamento contendo: (a) modelo canônico proposto; (b) tabela de correspondência campo-a-campo (fonte->canônico->destino) com tipos, tamanhos, obrigatoriedade, códigos e unidades; (c) lacunas e suposições; (d) dicionário de códigos (CID-10, TUSS, CBOS) aplicáveis por campo.
  • Número de caracteres esperado: O documento final deve ser detalhado e informativo, com um tamanho estimado em torno de 10.000 caracteres, podendo variar conforme a complexidade dos sistemas descritos.

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 além dos fornecidos como input.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não se conecta a sistemas externos.

1.3.5 Memória

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

Ao concluir sua execução, esse agente aciona o Agente de Definição de Regras de Transformação e Validação (RF 2).

RF 2. Agente de Definição de Regras de Transformação e Validação

2.1 Tarefa do Agente

Especificar regras determinísticas de transformação, validação e enriquecimento entre fonte e destino, com contratos de payload.

2.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo o modelo canônico e o mapa campo-a-campo do agente anterior, bem como exemplos de registros reais anonimizados e requisitos de negócio.

# 2. Objetivo
Especificar regras determinísticas de transformação, validação e enriquecimento entre fonte e destino, com contratos de payload.

# 3. Regras que você deve seguir para gerar sua resposta
- Para cada campo, descreva: função de transformação, regra de valor default quando ausente e tratamento de nulos.
- Defina validações: sintaxe, referência, consistência cruzada e integridade referencial.
- Especifique regras de arredondamento financeiro e tolerância de reconciliação.
- Padronize mensagens de erro: código, severidade, ação recomendada e campo afetado.
- Defina política de idempotência: gerar header Idempotency-Key e rejeitar duplicatas.
- Forneça JSON Schema para cada payload, com required, pattern, enum e formatos.
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 o modelo canônico e o mapa campo-a-campo, além de exemplos de registros reais anonimizados.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs nos formatos: .json e .csv (para exemplos de registros).
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input combinado de até 15.000 caracteres.

2.3.2 Especificação do Output

  • Formato de output: O output deve ser uma especificação de integração contendo regras de transformação, validações, JSON Schemas dos payloads, catálogo de erros e cenários de teste.
  • Exemplo de Estrutura de Output:
    Especificação de integração contendo: (a) regras de transformação por campo; (b) validações sintáticas e semânticas; (c) JSON Schemas dos payloads request/response por endpoint; (d) catálogo de erros com códigos e mensagens; (e) cenários de teste com entradas e saídas esperadas.
  • Número de caracteres esperado: A especificação final deve ser detalhada e informativa, com um tamanho estimado em torno de 12.000 caracteres.

2.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

2.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos além dos fornecidos como input.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não se conecta a sistemas externos.

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 Preparação de Chamadas (Payloads e Parâmetros) (RF 3).

RF 3. Agente de Preparação de Chamadas (Payloads e Parâmetros)

3.1 Tarefa do Agente

Gerar o plano de chamadas e os payloads prontos para execução nas APIs dos sistemas envolvidos.

3.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo a especificação de transformação e os JSON Schemas, além de credenciais-placeholder, endpoints base e limites de paginação/rate limit informados.

# 2. Objetivo
Gerar o plano de chamadas e os payloads prontos para execução nas APIs dos sistemas envolvidos.

# 3. Regras que você deve seguir para gerar sua resposta
- Para cada entidade defina a sequência CRUD necessária e relacione dependências por chave.
- Monte URLs incluindo path e query conforme especificação; se houver paginação, inclua parâmetros page/limit ou cursor.
- Preencha headers padrão: Content-Type, Accept, Idempotency-Key quando aplicável, Authorization como placeholder.
- Valide cada corpo contra seu JSON Schema; em caso de violação, marque a requisição como inválida.
- Atribua prioridade a mensagens críticas e lote itens não críticos respeitando o menor rate limit declarado.
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 a especificação de transformação e os JSON Schemas, além de credenciais-placeholder e endpoints base.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs nos formatos: .json e .txt (para credenciais-placeholder).
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input combinado de até 20.000 caracteres.

3.3.2 Especificação do Output

  • Formato de output: O output deve ser uma lista ordenada de requisições a executar contendo método, URL completa, headers, corpo JSON validado, parâmetros de paginação e política de retry.
  • Exemplo de Estrutura de Output:
    Lista ordenada de requisições a executar contendo: método, URL completa, headers (incluindo placeholders de autenticação), corpo JSON validado, parâmetros de paginação, política de retry e dependências entre chamadas.
  • Número de caracteres esperado: A lista final deve ser detalhada e informativa, 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 documentos externos além dos fornecidos como input.
  • Calculadora: Não utiliza.
  • 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 Execução de Chamada à API (RF 4).

3.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 4).

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

4.1 Tarefa do Agente

Realizar chamadas às APIs dos sistemas para trocar dados conforme plano de execução.

4.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo a lista de requisições com método, URL, headers, corpo e política de retry já definidas.

# 2. Objetivo
Realizar chamadas às APIs dos sistemas para trocar dados conforme plano de execução.

# 3. Regras que você deve seguir para gerar sua resposta
- Execute as chamadas conforme parâmetros prontos e retorne as respostas sem aplicar lógica adicional de LLM.
- Monitore o status de cada requisição e registre latência e headers relevantes.
- Em caso de falha, aplique a política de retry definida e documente o erro para análise posterior.
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 como input a lista de requisições com método, URL, headers, corpo e política de retry.
  • 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é 10.000 caracteres.

4.3.2 Especificação do Output

  • Formato de output: O output deve ser um conjunto de respostas das chamadas por requisição contendo status HTTP, headers relevantes, corpo de resposta e latência.
  • Exemplo de Estrutura de Output:
    Respostas das chamadas por requisição contendo status HTTP, headers relevantes, corpo de resposta e latência.
  • Número de caracteres esperado: O conjunto de respostas deve ser detalhado e informativo, com um tamanho estimado em torno de 5.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 documentos externos além dos fornecidos como input.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Executa chamadas diretamente às APIs dos sistemas envolvidos.

4.3.5 Memória

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

Ao concluir sua execução, esse agente aciona o Agente de Reconciliação e Controle de Qualidade (RF 5).

RF 5. Agente de Reconciliação e Controle de Qualidade

5.1 Tarefa do Agente

Confrontar respostas das APIs com contratos esperados, validar integridade e produzir relatório de reconciliação e correções necessárias.

5.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo o plano de chamadas executado, respostas recebidas, contratos de payload e regras de validação/negócio.

# 2. Objetivo
Confrontar respostas das APIs com contratos esperados, validar integridade e produzir relatório de reconciliação e correções necessárias.

# 3. Regras que você deve seguir para gerar sua resposta
- Classifique o resultado por requisição: sucesso, sucesso com alerta, falha recuperável e falha não recuperável.
- Recalcule totais e compare com o destino; aplique tolerâncias definidas; quando excedido, registre divergência.
- Verifique idempotência e gere métricas como taxa_sucesso, p95_latencia, taxa_retry.
- Liste correções de dados na origem quando a falha for semântica indicando campo e valor inválido.
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 o plano de chamadas executado, respostas recebidas, contratos de payload e regras de validação/negócio.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs nos formatos: .json e .csv (para contratos de payload).
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input combinado de até 15.000 caracteres.

5.3.2 Especificação do Output

  • Formato de output: O output deve ser um relatório estruturado com status_global, erros_por_código, divergências detectadas, ações recomendadas e indicadores de qualidade.
  • Exemplo de Estrutura de Output:
    Relatório estruturado com: status_global, itens_processados, erros_por_código, divergências detectadas, ações recomendadas e indicadores de qualidade.
  • Número de caracteres esperado: O relatório deve ser detalhado e informativo, com um tamanho estimado em torno de 10.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 documentos externos além dos fornecidos como input.
  • Calculadora: Não utiliza.
  • 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 Orquestração de Automação (RF 6).

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

Ao concluir sua execução, esse agente aciona o Agente de Orquestração de Automação (RF 6).

RF 6. Agente de Orquestração de Automação

6.1 Tarefa do Agente

Definir a automação da troca de dados: janelas, lotes, concorrência, política de retry/backoff e checkpoints de CDC.

6.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo requisitos operacionais, tipos de eventos/dados a integrar e métricas históricas de volume.

# 2. Objetivo
Definir a automação da troca de dados: janelas, lotes, concorrência, política de retry/backoff e checkpoints de CDC.

# 3. Regras que você deve seguir para gerar sua resposta
- Defina lotes por entidade respeitando limites do menor sistema; se 429, aplique backoff exponencial.
- Estabeleça janelas de execução fora de horários de pico; caso contrário, use fluxo contínuo.
- Registre checkpoints por entidade para garantir processamento exatamente-uma-vez lógico.
- Especifique política de reprocessamento para falhas recuperáveis nas próximas janelas.
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 do agente anterior (RF 5).
  • Tipo do input: Este agente deve ser apto a receber requisitos operacionais, tipos de eventos/dados a integrar e métricas históricas de volume.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs nos formatos: .json e .csv (para métricas históricas).
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input combinado de até 12.000 caracteres.

6.3.2 Especificação do Output

  • Formato de output: O output deve ser um plano de automação contendo cronograma, tamanho de lotes, concorrência máxima, estratégia de retry, limites de taxa e critérios de reprocessamento.
  • Exemplo de Estrutura de Output:
    Plano de automação contendo: cronograma, tamanho de lotes por entidade, concorrência máxima, estratégia de retry (exponencial com jitter), limites de taxa, checkpoints de posição e critérios de reprocessamento.
  • Número de caracteres esperado: O plano de automação deve ser detalhado e informativo, com um tamanho estimado em torno de 8.000 caracteres.

6.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

6.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos além dos fornecidos como input.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não se conecta a sistemas externos.

6.3.5 Memória

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

Ao concluir sua execução, esse agente aciona o Agente de Monitoramento e Alertas de Integração (RF 7).

RF 7. Agente de Monitoramento e Alertas de Integração

7.1 Tarefa do Agente

Especificar métricas, SLOs, alertas e runbooks para operação contínua das integrações.

7.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo requisitos de SLO/SLAs, catálogo de erros definido, métricas de reconciliação e plano de automação.

# 2. Objetivo
Especificar métricas, SLOs, alertas e runbooks para operação contínua das integrações.

# 3. Regras que você deve seguir para gerar sua resposta
- Defina métricas mínimas: taxa_sucesso, taxa_erro_por_código, latência p50/p95/p99, backlog de fila, throughput, % retries.
- Estabeleça alertas: crítica quando taxa_sucesso < SLO por 5min, quando 5xx > 2% em 10min, e quando backlog excede 2x média horária.
- Forneça payload padrão de alerta com correlação.
- Inclua runbook por alerta com: possíveis causas, dados a coletar, decisão de escalonamento e critério de fechamento.
7.3 Configurações do Agente

7.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão do agente anterior (RF 6).
  • Tipo do input: Este agente deve ser apto a receber requisitos de SLO/SLAs, catálogo de erros definido, métricas de reconciliação e plano de automação.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs nos formatos: .json e .csv (para métricas de reconciliação).
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input combinado de até 15.000 caracteres.

7.3.2 Especificação do Output

  • Formato de output: O output deve ser um catálogo operacional com métricas a coletar, SLOs, alertas com limiares e mensagens, rotas de notificação e runbooks com passos de diagnóstico.
  • Exemplo de Estrutura de Output:
    Catálogo operacional com: métricas a coletar, SLOs, alertas com limiares e mensagens, rotas de notificação e runbooks com passos de diagnóstico.
  • Número de caracteres esperado: O catálogo operacional deve ser detalhado e informativo, com um tamanho estimado em torno de 10.000 caracteres.

7.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

7.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos além dos fornecidos como input.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não se conecta a sistemas externos.

7.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 é o entregável final e não é passada para outros agentes internos.

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

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

© 2025 prototipe.ai. Todos os direitos reservados.