Agente de IA para Relatórios Diários de Progresso Clínico

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

Como criar um agente de IA que gera relatórios diários de progresso clínico para pacientes internados.

Biblioteca de Prompts e Agentes

1. Propósito e Escopo

Este documento define todos os prompts, configurações de memória, transição entre estados e demais requisitos funcionais para o Agente de IA "Relatórios Diários de Progresso Clínico", uma solução projetada para gerar relatórios diários de progresso clínico para pacientes internados, sintetizando dados de exames, sinais vitais e observações médicas. 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 é garantir que os relatórios sejam compreensíveis, úteis, atualizados em tempo real e facilmente acessíveis para a equipe médica e de cuidados.

2. Contexto e Problema

Cenário Atual

Os hospitais enfrentam desafios significativos na geração de relatórios diários consistentes e atualizados sobre o progresso clínico dos pacientes internados. Atualmente, os dados de exames e sinais vitais são coletados de várias fontes, mas a integração desses dados em um único relatório compreensível é complexa e demorada.


Problemas Identificados

  • Falta de relatórios diários consistentes: A ausência de relatórios diários padronizados dificulta o acompanhamento do progresso clínico dos pacientes.
  • Dificuldade de integração de dados: A coleta de dados de diferentes fontes, como exames laboratoriais e sinais vitais, não é integrada eficientemente em um único documento.

3. Impactos Esperados

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

  • Melhorar a consistência e atualização dos relatórios diários para a equipe médica.
  • Facilitar a integração de dados de diferentes fontes em um relatório único e compreensível.
  • Aumentar a eficiência do acompanhamento clínico dos pacientes internados.

4. Visão Geral da Solução

O agente de IA para relatórios diários de progresso clínico coleta e sintetiza dados de várias fontes, incluindo exames laboratoriais e sinais vitais, para gerar relatórios diários compreensíveis e úteis para a equipe médica. 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 elaboração de relatórios clínicos.

A solução consiste em um fluxo de automação composto por 6 agentes de IA. O processo inicia com a preparação de parâmetros para coleta de dados e termina com a geração de um relatório diário estruturado e pronto para ser utilizado pela equipe médica.

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

Agentes Função Principal
Agente de Preparação de Parâmetros de Coleta (RF 1) Construir parâmetros padronizados de coleta para recuperar dados clínicos das últimas 24 horas de pacientes internados.
Agente de Execução de Chamada à API - Exames Laboratoriais (RF 2) Realizar chamada à API do sistema de laboratório para obter exames dentro da janela definida.
Agente de Execução de Chamada à API - Sinais Vitais (RF 3) Realizar chamada à API do sistema de monitoramento para obter sinais vitais dentro da janela definida.
Agente de Execução de Chamada à API - Observações Médicas (RF 4) Realizar chamada à API do prontuário para obter observações médicas e intercorrências dentro da janela definida.
Agente de Consolidação e Normalização de Dados Clínicos (RF 5) Consolidar dados brutos de exames, vitais e observações em um JSON clínico estruturado e consistente para síntese.
Agente de Geração de Relatório Diário de Progresso Clínico (RF 6) Gerar relatório diário de progresso clínico claro, útil e acionável para a equipe assistencial, a partir do JSON consolidado.

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.

Ver Agente na Prototipe AI

6. Requisitos Funcionais

RF 1. Agente de Preparação de Parâmetros de Coleta

1.1 Tarefa do Agente

Construir parâmetros padronizados de coleta para recuperar dados clínicos das últimas 24 horas de pacientes internados.

1.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo identificadores do paciente e preferências de janela temporal para coleta de dados clínicos.

# 2. Objetivo
Construir parâmetros padronizados de coleta para recuperar dados clínicos das últimas 24 horas de pacientes internados.

# 3. Regras que você deve seguir para gerar sua resposta
- Se nenhum período for informado, defina window_end como agora e window_start como agora - 24h.
- Sempre incluir no payload filtro por patient_id e intervalo [window_start, window_end] em fuso horário explícito (UTC ou TZ informado no input), sem conversões implícitas.
- Ordenar resultados por carimbo de coleta/registro ascendente e limitar a paginação para evitar truncamento (ex.: page_size padrão 500) incluindo cursor/token no payload.
- Incluir campos mínimos solicitados para cada categoria: 
  • Exames: codigo_exame, nome_exame, valor, unidade, referencia_min, referencia_max, metodo (se houver), data_coleta.
  • Vitais: tipo_sinal (PA, FC, FR, Temp, SpO2), valor, unidade, postura (se houver), data_medicao.
  • Observacoes: tipo (evolucao, prescricao, intercorrencia), texto, autor, data_registro.
- Produzir payloads independentes por categoria, sem combinar lógicas de filtragem entre si.
- Inserir no output um campo trigger_condition_result: paciente_internado = true/false se recebido no input; se ausente, definir como true.
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 identificadores do paciente e preferências de janela temporal via API. Na fase de testes, os dados serão enviados pelo agente diretamente por upload de um csv na interface da Prototipe AI, para acelerar o processo de validação.
  • Tipo do input: Dados estruturados incluindo identificadores do paciente e carimbo de data/hora de referência.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs nos formatos: .csv, .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de até 5.000 caracteres.

1.3.2 Especificação do Output

  • Formato de output: O output deve ser um objeto JSON contendo parâmetros padronizados de coleta para cada categoria de dados.
  • Exemplo de Estrutura de Output: 
     {
  "window_start": "2025-12-05T10:00:00Z",
  "window_end": "2025-12-06T10:00:00Z",
  "patient_id": "12345",
  "payload_exames": {
    "filters": { "patient_id": "12345", "date_range": { "start": "2025-12-05T10:00:00Z", "end": "2025-12-06T10:00:00Z" } },
    "order_by": "data_coleta",
    "page_size": 500
  },
  "payload_vitais": {
    "filters": { "patient_id": "12345", "date_range": { "start": "2025-12-05T10:00:00Z", "end": "2025-12-06T10:00:00Z" } },
    "order_by": "data_medicao",
    "page_size": 500
  }
}
  • Número de caracteres esperado: O JSON gerado deve ter um tamanho estimado de 1.500 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 os agentes subsequentes.

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 - Exames Laboratoriais (RF 2).

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

2.1 Tarefa do Agente

Realizar chamada à API do sistema de laboratório para obter exames dentro da janela definida.

2.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um payload de exames contendo filtros para execução de chamada à API do sistema de laboratório.

# 2. Objetivo
Realizar chamada à API do sistema de laboratório para obter exames dentro da janela definida.

# 3. Regras que você deve seguir para gerar sua resposta
- Agente exclusivo de execução da chamada. Não requer instruções de LLM. Deve apenas executar a chamada com o payload recebido.
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 JSON contendo filtros para execução de chamada à API do sistema de laboratório.
  • 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 uma lista de resultados de exames laboratoriais brutos conforme retornados pela API, incluindo metadados de paginação quando aplicável.
  • Exemplo de Estrutura de Output: 
     [
  {
    "codigo_exame": "HB",
    "nome_exame": "Hemoglobina",
    "valor": 13.5,
    "unidade": "g/dL",
    "data_coleta": "2025-12-05T08:00:00Z"
  }
]
  • Número de caracteres esperado: O output da API pode variar, mas espera-se um tamanho médio de 3.000 caracteres.

2.3.3 Parâmetros de Geração

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

2.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: O agente deverá enviar o payload recebido para a API do sistema de laboratório e retornar os resultados recebidos como resposta.

2.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 os agentes subsequentes.

2.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 - Sinais Vitais (RF 3).

RF 3. Agente de Execução de Chamada à API - Sinais Vitais

3.1 Tarefa do Agente

Realizar chamada à API do sistema de monitoramento para obter sinais vitais dentro da janela definida.

3.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um payload de sinais vitais contendo filtros para execução de chamada à API do sistema de monitoramento.

# 2. Objetivo
Realizar chamada à API do sistema de monitoramento para obter sinais vitais dentro da janela definida.

# 3. Regras que você deve seguir para gerar sua resposta
- Agente exclusivo de execução da chamada. Não requer instruções de LLM. Deve apenas executar a chamada com o payload recebido.
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 payload JSON contendo filtros para execução de chamada à API do sistema de monitoramento.
  • 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.

3.3.2 Especificação do Output

  • Formato de output: O output deve ser uma lista de resultados brutos de sinais vitais conforme retornados pela API, incluindo metadados de paginação quando aplicável.
  • Exemplo de Estrutura de Output: 
     [
  {
    "tipo_sinal": "FC",
    "valor": 75,
    "unidade": "bpm",
    "data_medicao": "2025-12-05T09:00:00Z"
  }
]
  • Número de caracteres esperado: O output da API pode variar, mas espera-se um tamanho médio de 3.000 caracteres.

3.3.3 Parâmetros de Geração

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

3.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: O agente deverá enviar o payload recebido para a API do sistema de monitoramento e retornar os resultados recebidos como resposta.

3.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 os agentes subsequentes.

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 - Observações Médicas (RF 4).

RF 4. Agente de Execução de Chamada à API - Observações Médicas

4.1 Tarefa do Agente

Realizar chamada à API do prontuário para obter observações médicas e intercorrências dentro da janela definida.

4.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um payload de observações médicas contendo filtros para execução de chamada à API do prontuário.

# 2. Objetivo
Realizar chamada à API do prontuário para obter observações médicas e intercorrências dentro da janela definida.

# 3. Regras que você deve seguir para gerar sua resposta
- Agente exclusivo de execução da chamada. Não requer instruções de LLM. Deve apenas executar a chamada com o payload recebido.
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 um payload JSON contendo filtros para execução de chamada à API do prontuário.
  • 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.

4.3.2 Especificação do Output

  • Formato de output: O output deve ser uma lista de observações médicas brutas conforme retornadas pela API, incluindo metadados de paginação quando aplicável.
  • Exemplo de Estrutura de Output: 
     [
  {
    "tipo": "Evolução",
    "texto": "Paciente sem queixas durante a noite.",
    "autor": "Dr. Silva",
    "data_registro": "2025-12-05T07:00:00Z"
  }
]
  • Número de caracteres esperado: O output da API pode variar, mas espera-se um tamanho médio de 3.000 caracteres.

4.3.3 Parâmetros de Geração

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

4.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: O agente deverá enviar o payload recebido para a API do prontuário e retornar os resultados recebidos como resposta.

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 os agentes subsequentes.

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

Ao concluir sua execução, esse agente aciona o Agente de Consolidação e Normalização de Dados Clínicos (RF 5).

RF 5. Agente de Consolidação e Normalização de Dados Clínicos

5.1 Tarefa do Agente

Consolidar dados brutos de exames, vitais e observações em um JSON clínico estruturado e consistente para síntese.

5.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo dados brutos de exames, sinais vitais e observações médicas coletados nos últimos 24 horas.

# 2. Objetivo
Consolidar dados brutos de exames, vitais e observações em um JSON clínico estruturado e consistente para síntese.

# 3. Regras que você deve seguir para gerar sua resposta
- Inclua em metadados_periodo: window_start, window_end, timezone, patient_id, fontes_disponiveis.
- Deduplicação: para exames, agrupe por (codigo_exame, data_coleta arredondada a minuto). Se múltiplos registros iguais, mantenha o mais recente por data_registro.
- Unidades: normalize para unidades canônicas por tipo (ex.: hemoglobina g/dL, creatinina mg/dL, glicemia mg/dL, potássio mEq/L, temperatura °C, FC bpm, FR irpm, PA mmHg, SpO2 %). Se conversão for necessária, aplique fator e registre unidade_original e valor_original.
- Referências: preserve referencia_min e referencia_max quando fornecidas. Se ausentes, marque referencia_indisponivel = true sem inferir valores.
- Tendências: calcule para as últimas 24h e, quando possível, contexto de 72h (min, max, mediana, primeiro e último valor). Inclua delta_absoluto e delta_percentual entre primeiro e último da janela de 24h.
- Marcação de anormalidade: defina status_exame = 'alto', 'baixo' ou 'normal' usando referencia_min/max quando disponíveis; se ausentes, status_exame = 'indefinido'. Para vitais, utilize faixas clínicas usuais: 
  • FC: normal 60-100 bpm; 
  • FR: normal 12-20 irpm; 
  • Temp: normal 36.1-37.2 °C; 
  • PA: flag sistólica <90 ou >180 mmHg, diastólica <60 ou >110 mmHg; 
  • SpO2: flag <92% (sem condições específicas). Sempre registrar regra_aplicada.
- Observações: classifique tipo por palavras-chave do campo tipo ou título; extraia marcadores estruturados quando houver (ex.: 'sem queixas', 'dor', 'queda', 'febre'), mantendo o texto original completo.
- Lacunas: para cada categoria requerida sem dados na janela, adicione em lacunas_de_dados um item com categoria, descricao e recomendacao (ex.: 'Sem sinais vitais nas últimas 24h; verificar conectividade/rotina de aferição').
- Ordenação: liste exames por data_coleta ascendente dentro de cada codigo_exame; vitais por data_medicao ascendente por tipo.
- Integridade temporal: descarte registros fora de [window_start, window_end].
- Saída deve ser determinística: não criar campos livres além dos especificados.
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 dados brutos de exames, sinais vitais e observações médicas coletados nos últimos 24 horas.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs nos formatos: .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 estruturado com seções: metadados_periodo, exames_normalizados, vitais_normalizados, observacoes_estruturadas, lacunas_de_dados, e sumario_estatistico_24h/72h.
  • Exemplo de Estrutura de Output: 
     {
  "metadados_periodo": {
    "window_start": "2025-12-05T10:00:00Z",
    "window_end": "2025-12-06T10:00:00Z",
    "timezone": "UTC",
    "patient_id": "12345"
  },
  "exames_normalizados": [
    {
      "codigo_exame": "HB",
      "valor": 13.5,
      "unidade": "g/dL",
      "status_exame": "normal"
    }
  ],
  "vitals_normalized": [],
  "observacoes_estruturadas": [],
  "lacunas_de_dados": [],
  "sumario_estatistico_24h/72h": {}
}
  • Número de caracteres esperado: O JSON gerado deve ter um tamanho estimado de 5.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.
  • 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 deve ser visível para os agentes subsequentes.

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 Diário de Progresso Clínico (RF 6).

RF 6. Agente de Geração de Relatório Diário de Progresso Clínico

6.1 Tarefa do Agente

Gerar relatório diário de progresso clínico claro, útil e acionável para a equipe assistencial, a partir do JSON consolidado.

6.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um JSON consolidado com dados clínicos estruturados coletados nas últimas 24 horas.

# 2. Objetivo
Gerar relatório diário de progresso clínico claro, útil e acionável para a equipe assistencial, a partir do JSON consolidado.

# 3. Regras que você deve seguir para gerar sua resposta
- Cobertura temporal: explicitar período [window_start, window_end] e data/hora da geração.
- Estrutura mínima das seções: 
  1) Identificação e Período; 
  2) Resumo do Dia (3-5 bullet points objetivos com principais achados e mudanças relevantes); 
  3) Sinais Vitais (último valor por tipo + tendência 24h com seta ↑/↓/→ e delta); 
  4) Exames Relevantes (listar apenas os alterados ou com variação absoluta >10% no período; demais, resumir como 'sem alterações significativas'); 
  5) Observações e Intercorrências (síntese cronológica do que é clinicamente relevante, com timestamps e autor se disponível); 
  6) Avaliação por Sistemas (respiratório, cardiovascular, renal/metabólico, infeccioso, neurologia/estado geral) com uma frase por sistema quando houver dados; 
  7) Pendências e Ações Recomendadas (itens objetivos, como 'repetir creatinina em 12h se tendência de alta'); 
  8) Alertas e Criticidades (listar critérios disparados, ex.: hipotensão, febre, hipoxemia), citando regra_aplicada e horário do pior valor.
- Clareza e padronização: frases curtas, termos técnicos usuais, sem jargões ambíguos; evitar especulação; basear-se exclusivamente nos dados consolidados.
- Tendências: representar delta_percentual com 1 casa decimal; incluir setas: ↑ se último > primeiro por >3%, ↓ se < -3%, → caso contrário.
- Destaque de anormais: prefixar itens alterados com marcador '!' e indicar o valor e referência (ex.: '! K 5.8 mEq/L (ref 3.5-5.1) ↑').
- Ausência de dados: seções devem registrar explicitamente quando houver lacunas_de_dados, com orientação prática breve.
- Acessibilidade: garantir que o texto seja legível em dispositivos móveis (parágrafos curtos e listas); limitar cada lista a no máximo 8 itens, criando sublistas se necessário.
- Determinismo: não incluir hipóteses diagnósticas novas; não sugerir condutas medicamentosas específicas; focar em descrição e organização do progresso e pendências operacionais.
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 um JSON consolidado com dados clínicos estruturados coletados nas últimas 24 horas.
  • 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.

6.3.2 Especificação do Output

  • Formato de output: O output deve ser um relatório diário em dois formatos: texto estruturado (seções identificáveis por cabeçalhos) e json_relatorio (mesmas seções em formato JSON, com campos prontos para integração).
  • Exemplo de Estrutura de Output: 
     {
  "texto_estruturado": "Identificação e Período: Paciente 12345, 05/12/2025 a 06/12/2025...",
  "json_relatorio": {
    "identificacao_periodo": "Paciente 12345, 05/12/2025 a 06/12/2025",
    "resumo_dia": "...",
    "sinais_vitais": "..."
  }
}
  • Número de caracteres esperado: O relatório gerado deve ter um tamanho estimado de 7.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.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

6.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.

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

A execução deste agente finaliza o fluxo. O relatório gerado deve ser disponibilizado ao usuário.

Posts Relacionados

© 2025 prototipe.ai. Todos os direitos reservados.