Files
ampmInsights/ROADMAP_AGENTICO.md
Antonio Sergio Rodrigues Figueiredo e519811f80 Adiciona ROADMAP_AGENTICO.md: análise para v3.0.0 (sistema agêntico)
- Diagnóstico do padrão atual (PRC_26AI_TECH single-shot) vs. padrão de
  agentes/tasks/tools/teams de um case bancário de referência
  (DBMS_CLOUD_AI_AGENT, Property Graph, Blockchain Table, VPD, Knowledge
  Graph chain).
- Mapeamento de analogia Persona/Agente/Task/Tools aplicado ao domínio de
  vulnerability management do AMPM.
- Achado prático destacado: padrão fn_analise_carteira_json (separar
  cálculo determinístico de narrativa da IA) — não depende de agentes,
  pode entrar como v2.1.0.
- Achado de acelerador: app pronto da Oracle 'Ask Oracle Select AI
  Chatbot' já expõe builder visual de agentes sobre o mesmo
  DBMS_CLOUD_AI_AGENT.
- Sequenciamento: v3.0.0 depende do v2.0.0 estar em produção primeiro.
  Nenhuma mudança no trabalho em andamento do v2.0.0.
- README.md e TASKS.md referenciam o novo doc.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-09 16:19:20 -03:00

8.3 KiB

Roadmap — ampmInsights Agêntico (v3.0.0, ainda não iniciado)

Análise feita em 2026-09-09 a partir de um material de referência compartilhado pelo usuário (case bancário "DEMO_CONVERGENTE" — Oracle AI Database 26ai + APEX, com DBMS_CLOUD_AI_AGENT, Property Graph, Blockchain Table, VPD e Knowledge Graph chain) e de dois repositórios oracle-devrel. Este documento não implementa nada — é a base para decidir se/quando o AMPM evolui de um Q&A semântico de tiro único para um sistema agêntico. Não altera nem depende de nenhuma tarefa aberta do v2.0.0 (TASKS.md), exceto onde indicado explicitamente na seção 4.

1. Diagnóstico: onde o ampmInsights está hoje

PRC_26AI_TECH é single-shot: monta um JSON com a linha de V_26AI_TECH e manda para um único prompt genérico, que responde de uma vez os 4 blocos (análise, diagnóstico, recomendações, plano de ação). Não há divisão de trabalho — é um "analista generalista" respondendo tudo, sempre.

2. O padrão do case bancário (Agent Framework)

O case usa DBMS_CLOUD_AI_AGENT para construir uma hierarquia:

TEAM (supervisor_agent = ROTEADOR)
 ├─ AGENT "ANALISE_CENARIO_ECONOMICO" → TASK → TOOL (function)
 ├─ AGENT "OBTER_DADOS_DE_CLIENTE"    → TASK → TOOL (SQL profile)
 └─ AGENT "OBTER_PERFIL_INVESTIDOR"   → TASK → TOOL (function)

O agente roteador (supervisor: true) classifica a pergunta e delega para um único especialista — nunca responde ele mesmo, nunca deixa dois agentes tentarem a mesma pergunta. Cada especialista só vê o profile/tools do seu domínio (ex.: OBTER_DADOS_DE_CLIENTE não consegue interpretar perfil de risco, mesmo que o dado estivesse acessível).

3. Mapeamento de analogia para o AMPM

Do slide original (Persona → Agente/Competências → Task → Tools), aplicado ao domínio de gestão de vulnerabilidades:

Slide (genérico) Case bancário AMPM (proposta)
Persona/Cargo Gerente de Investimento Gestor de Vulnerabilidades / CISO Ops
Agente (competências) Cenário econômico / Dados cliente / Perfil investidor Triagem CVE/Threat Intel, Contexto de Ativo (CMDB), Remediação/Patch Plan, Relatório Executivo
Task "responder pergunta sobre X" "priorizar achado", "explicar exposição do ativo", "montar plano 30-60-90"
Tools CONSULTAR_DADOS_CLIENTE, CONSULTAR_PERFIL_INVESTIDOR CONSULTAR_CVE_CRITICO (CVSS/EPSS/CISA KEV), CONSULTAR_CONTEXTO_ATIVO (CMDB: criticidade, responsável, SO), CONSULTAR_HISTORICO_REMEDIACAO

Um roteador (ROTEADOR_VULNERABILIDADES, supervisor: true) classificaria a pergunta/achado e delegaria a um especialista — resolvendo o problema real de hoje, onde um único prompt tenta simultaneamente avaliar severidade técnica, contexto de negócio do ativo e plano de ação.

Pré-requisito de dados: os tools de triagem/CMDB só funcionam depois que as colunas Tier-1 do v2.0.0 (DEFINITION_CVE, DEFINITION_CVSS3_BASE_SCORE, DEFINITION_EPSS_SCORE, CISA_KEV_FLAG, etc. — ver sql/03_v2_ddl_schema_evolution.sql) estiverem carregadas com dado real. v3.0.0 depende do v2.0.0 estar em produção, não o contrário.

4. O achado mais diretamente portável — não depende de agentes

fn_analise_carteira_json → fn_analise_carteira_com_ia_json é o padrão de maior valor prático do material, e é ortogonal à arquitetura de agentes:

  1. Uma função PL/SQL determinística calcula em SQL puro (sem LLM) os números que importam — no case: concentração por emissor, por grau de risco, por prazo. No AMPM seria: % de achados na lista CISA KEV, distribuição por faixa de CVSS/EPSS, aging vs. SLA de correção, concentração por sistema/criticidade — usando exatamente os campos novos do v2.0.0.
  2. Uma segunda função monta um prompt que só interpreta esse JSON já calculado (não pede pro LLM "adivinhar" a matemática) e devolve uma narrativa.
  3. JSON_MERGEPATCH junta o JSON determinístico + a narrativa da IA num único documento.

Resultado: menos alucinação (números vêm de SQL, não do modelo), mais barato (prompt menor, menos tokens), e auditável (o JSON determinístico pode ser conferido independente do texto da IA). Isso pode entrar como evolução do PRC_26AI_TECH já dentro do ciclo v2.0.0/v2.1.0, uma vez que os campos novos estejam carregados — não precisa esperar o framework de agentes.

5. Outros padrões do material — aplicabilidade

Padrão O que faz no case Aplicação no AMPM Quando
Property Graph Cliente→Produto→Emissor→Agência, perguntas tipo "produtos de baixo risco pro perfil do cliente X" Resolve a decisão que ficou em aberto no gap-analysis do v2.0.0 (seção 5): normalizar CVE/pacote como grafo Ativo→Pacote→CVE para "quantos ativos têm a CVE-X" / "quais VMs rodam pacote Y desatualizado" — sem herdar custo de JOINs relacionais complexos Candidato a v2.1.0/v3.0.0, não v2.0.0 (que decidiu manter texto/lista na linha)
Blockchain Table Saldo diário imutável e verificável (SALDO_FECHAMENTO_BCT) Histórico de status de vulnerabilidade à prova de edição retroativa, se surgir exigência de auditoria formal Não há gatilho identificado hoje — só mapeado
Knowledge Graph chain (kc_chain_api) Organiza documentos internos por assunto (ANALISE→MACROECONOMIA→INFLACAO) para RAG dirigido Runbooks de remediação, políticas internas de segurança, playbooks por criticidade — hoje TB_26AI_TECH_VECTOR só vetoriza insights já gerados (memória), não conhecimento de referência. É uma lacuna real v3.0.0
VPD (vpd_filter_customers) Cada gerente só vê os clientes/contas sob sua responsabilidade Analista só vendo ativos do seu grupo responsável — colunas GRUPO_RESPONSÁVEL/ANALISTA_RESPONSAVEL já existem no schema Relevante só quando o app tiver múltiplos usuários com visões restritas

6. Achado sobre acelerador pronto da Oracle

O app "Ask Oracle Select AI Chatbot" (oracle-devrel/oracle-autonomous-database-samples, apex/Ask-Oracle-Select-AI-Chatbot/V 5.0.0.1) já entrega um construtor visual de agentes/times + "Agent Team Map" rodando sobre o mesmo DBMS_CLOUD_AI_AGENT do case bancário, empacotado como app APEX instalável (export completo em ADB-AskOracle-Chatbot-2026-08-06.sql, requer APEX 24.2.17+). Antes de programar um framework de agentes do zero para o AMPM, vale avaliar esse app como acelerador — instalar, testar se o "Team Map" já serve de UI de administração dos agentes, e decidir se dá pra reaproveitar em vez de reconstruir à mão.

7. Sequenciamento proposto

v2.0.0 (em andamento)         v2.1.0 (proposto)              v3.0.0 (proposto, este doc)
DDL aditivo + view/proc   →   fn_analise_..._json/ia    →   Agentes (roteador + especialistas)
carga real dos campos         (item 4 — ponte, sem            + Property Graph CVE/pacote
Tenable/ServiceNow            depender de agentes)            + Knowledge Graph de runbooks
                                                               + avaliar app pronto (seção 6)

8. Próximos passos (nenhum iniciado)

  • Validar v2.0.0 ponta a ponta primeiro (pré-requisito de dados para tudo abaixo).
  • Desenhar fn_analise_ampm_json / fn_analise_ampm_com_ia_json (item 4) como próximo passo documentável do v2.0.0/v2.1.0.
  • Instalar e avaliar o "Ask Oracle Select AI Chatbot" (seção 6) num ambiente de teste, à parte do AMPM em si, só para decidir se é acelerador viável.
  • Só depois disso, desenhar o primeiro agente/task/tool real (provavelmente CONSULTAR_CONTEXTO_ATIVO sobre o CMDB, o mais parecido com CONSULTAR_DADOS_CLIENTE do case) como piloto, antes de construir o roteador completo.

Fontes

  • Material de referência: case bancário "DEMO_CONVERGENTE" (5 scripts SQL: cadastro/VPD/spatial, grafo de investimentos + função determinística+IA, agentes/tasks/tools/teams, knowledge graph chain de documentos, admin/ACL) — compartilhado pelo usuário em 2026-09-09, não versionado neste repositório (é material de outro projeto/cliente, não da AM/PM).
  • https://github.com/oracle-devrel/oracle-autonomous-database-samples/tree/main/apex/Ask-Oracle-Select-AI-Chatbot/V%205.0.0.1