Skip to main content

PRD-005 — Intent Engine

Interpretação de Intenção e Resolução de Referências Contextuais​

Versão: 1.0 Status: Proposta para desenvolvimento Dependências: PRD-003 — Knowledge Router; PRD-004 — Capability Registry Próximo documento: PRD-006 — Agent Planner & Execution Orchestrator

1. Objetivo

O Intent Engine será responsável por transformar a linguagem natural do usuário em uma intenção estruturada, contextual e executável.

Ele será a camada que responde:

"O que exatamente o usuário quis dizer?"

Não executará diretamente a operação.

Sua responsabilidade termina quando produzir uma intenção suficientemente clara para que o Planner possa decidir o que fazer.

2. Problema central

Em um sistema simples, o usuário poderia escrever:

"Altere a validade para 30 dias."

Mas, em um sistema complexo, isso é insuficiente.

O agente precisa descobrir:

Qual registro?
Qual entidade?
Qual campo?
Qual valor?
Qual página?
Qual tab?
Qual objeto está selecionado?
Qual registro está em foco?
O usuário está pedindo explicação ou alteração?
É necessário confirmação?

A maior parte dessas informações não estará explicitamente na frase.

Elas estarão no contexto da aplicação.

3. Princípio fundamental

A intenção será construída a partir de:

User Message
      +
UI Context
      +
Conversation Context
      +
Knowledge Context
      +
Capability Context
      +
Application State

Portanto:

A mensagem do usuário não é o contexto completo.

4. Arquitetura

                    USER MESSAGE
                         │
                         ▼
                  Query Normalizer
                         │
                         ▼
                   Intent Detector
                         │
              ┌──────────┼──────────┐
              ▼          ▼          ▼
           Context     HAG       Capabilities
              │          │          │
              └──────────┼──────────┘
                         ▼
                 Reference Resolver
                         │
                         ▼
                  Intent Classifier
                         │
                         ▼
                  Intent Validator
                         │
                         ▼
                  Structured Intent

5. Tipos principais de intenção

A primeira versão deverá reconhecer pelo menos:

KNOWLEDGE_QUERY
EXPLANATION
SEARCH
NAVIGATION
CREATE
UPDATE
DELETE
APPROVE
CANCEL
EXECUTE
MULTI_STEP_ACTION

6. KNOWLEDGE_QUERY

Exemplo:

"O que é uma APR?"

Resultado:

{
  "type": "KNOWLEDGE_QUERY",
  "subject": "APR"
}

O fluxo será:

Intent
 ↓
Knowledge Router
 ↓
HAG
 ↓
Answer

7. EXPLANATION

Exemplo:

"Explique."

Aqui começa a parte mais interessante.

A palavra "explique" sozinha não possui objeto.

O Intent Engine deverá utilizar o contexto.

Exemplo:

page = Work Permit
tab = Components
focus = PPE Component
selectedEntity = Respirator

Resultado:

{
  "type": "EXPLANATION",
  "target": {
    "semanticId": "workPermit.components.ppe.respirator"
  }
}

O agente então sabe o que deve explicar.

8. Referências anafóricas

O sistema deverá compreender:

isso
esse
essa
ele
ela
aquele
este
o anterior
o selecionado
o atual
aqui
nessa tela
nesse campo

Exemplo:

"Qual a validade deste documento?"

O objeto "deste documento" poderá ser resolvido pelo contexto da interface.

9. Context Resolution

O frontend deverá enviar ao agente um contexto estruturado.

Exemplo:

interface AgentUIContext {
  applicationId: string;

  route: string;

  pageId: string;

  pageTitle?: string;

  activeTab?: string;

  focusedElement?: FocusContext;

  selectedEntity?: EntityContext;

  visibleEntities?: EntityContext[];

  breadcrumbs?: Breadcrumb[];

  filters?: Record<string, unknown>;

  formState?: Record<string, unknown>;
}

10. Não enviar o DOM inteiro

É fundamental evitar:

HTML inteiro
+
React tree inteiro
+
todos os componentes

Isso seria caro e lento.

Em vez disso, a aplicação deverá produzir um:

Semantic UI Context

contendo somente informações relevantes.

11. Semantic UI Context

Exemplo:

{
  "page": {
    "id": "workPermit",
    "title": "Permissão de Trabalho"
  },
  "tab": {
    "id": "components",
    "title": "Componentes"
  },
  "focus": {
    "semanticId": "workPermit.components",
    "type": "data-grid"
  },
  "selection": {
    "entity": "workPermit",
    "id": "WP-10231"
  }
}

Esse pequeno objeto poderá substituir milhares de tokens.

12. Focus Tracking

O frontend deverá informar qual elemento possui foco semântico.

Não necessariamente o foco físico do navegador.

São conceitos diferentes.

Browser focus​

input
button
select

Agent focus​

workPermit.validity
workPermit.components
workPermit.responsiblePerson

O segundo é muito mais importante.

13. Semantic Focus

Cada componente relevante poderá possuir:

data-agent-id="workPermit.validity"

ou equivalente em uma abstração React própria.

Exemplo:

<AgentContext
  semanticId="workPermit.validity"
  entity="workPermit"
>
  ...
</AgentContext>

14. Active Tab

Em interfaces com múltiplas tabs:

Overview
Documents
Components
Approvals
History

o agente deverá saber:

activeTab = components

Assim:

"Adicione um equipamento."

pode ser interpretado como:

workPermit.components.add

sem que o usuário precise explicar todo o contexto.

15. Hidden Areas

Áreas ocultas não deverão ser consideradas automaticamente.

Por exemplo:

Tab A
 ├── visible
 └── hidden

Tab B
 └── hidden

O contexto deverá diferenciar:

visible
active
selected
focused
available

Isso evita que o agente confunda elementos apenas porque existem no DOM.

16. Selected Entity

Exemplo:

Work Permit #1234

O frontend enviará:

{
  "entity": "workPermit",
  "id": "1234"
}

O usuário poderá simplesmente dizer:

"Aprove."

O Intent Engine poderá produzir:

{
  "type": "APPROVE",
  "target": {
    "entity": "workPermit",
    "id": "1234"
  }
}

17. Conversation Context

Além do contexto da tela, existe o contexto conversacional.

Exemplo:

Usuário:

"Qual a validade dessa permissão?"

Agente:

"A validade é de 30 dias."

Usuário:

"Mude para 60."

O segundo comando não contém:

permissão

nem:

validade

Mas a conversa contém essa referência.

O Intent Engine deverá resolvê-la.

18. Context Hierarchy

Quando houver conflito, deverá existir uma ordem de prioridade.

Sugestão:

1. Explicit user reference
2. Current selection
3. Current semantic focus
4. Current tab
5. Current page
6. Conversation context
7. HAG inference
8. General inference

Exemplo:

"Altere o equipamento selecionado."

A seleção explícita vence o foco.

19. Ambiguidade

O agente não deverá inventar uma referência.

Se houver:

selectedEntity = equipment A
focusedEntity = equipment B

e o usuário disser:

"Atualize o equipamento."

a intenção será:

AMBIGUOUS

e o agente deverá perguntar:

"Você quer atualizar o Equipamento A ou o Equipamento B?"

20. Confidence

A intenção possuirá confidence.

interface IntentConfidence {
  score: number;

  level: "high" | "medium" | "low";

  reasons: string[];
}

Exemplo:

{
  "score": 0.96,
  "level": "high",
  "reasons": [
    "selected entity matches request",
    "capability uniquely resolved"
  ]
}

21. Intent Schema

Modelo inicial:

interface AgentIntent {
  id: string;

  type: IntentType;

  confidence: number;

  target?: IntentTarget;

  parameters?: Record<string, unknown>;

  capabilityCandidates?: string[];

  context: IntentContext;

  requiresClarification: boolean;

  requiresConfirmation: boolean;
}

22. Exemplo completo

Usuário:

"Mude a validade para 30 dias."

Contexto:

page = workPermit
tab = details
selected = WP-123
focus = validity

Intent:

{
  "type": "UPDATE",
  "target": {
    "semanticId": "workPermit.validity",
    "entityId": "WP-123"
  },
  "parameters": {
    "validityDays": 30
  },
  "capabilityCandidates": [
    "workPermit.updateValidity"
  ],
  "confidence": 0.98,
  "requiresConfirmation": true
}

23. Capability Resolution

O Intent Engine deverá consultar o Capability Registry.

Intent
 ↓
Candidate Capabilities
 ↓
Filtering
 ↓
Ranking
 ↓
Best Capability

Exemplo:

"altere validade"

Candidates:

workPermit.update
workPermit.updateValidity
certificate.updateValidity

Contexto:

page = workPermit
focus = workPermit.validity

Resultado:

workPermit.updateValidity

24. HAG-assisted Intent Resolution

A HAG poderá esclarecer termos de domínio.

Exemplo:

"Faça a liberação."

O termo "liberação" poderá ser relacionado na HAG a:

workPermit.release

ou:

equipment.release

O contexto da UI resolverá a ambiguidade.

25. BM25 no Intent Engine

O BM25 desenvolvido no PRD-003 também poderá ser utilizado para localizar:

  • capabilities;
  • semantic IDs;
  • entidades;
  • conceitos;
  • terminologia do domínio.

Portanto:

User language
 ↓
BM25
 ↓
Domain terminology
 ↓
Semantic IDs

26. Não usar LLM para tudo

O Intent Engine deverá seguir a mesma filosofia de performance.

Primeiro:

rules
exact
context
keyword
BM25

Somente depois:

LLM

para casos ambíguos ou semanticamente complexos.

27. Intent Fast Path

Exemplo:

"Abra os componentes."

Pode ser resolvido:

phrase
 ↓
navigation mapping
 ↓
semanticId
 ↓
navigation capability

sem LLM.

28. Intent LLM Path

Exemplo:

"Quero deixar essa permissão válida por mais tempo, mas sem ultrapassar o limite permitido."

Isso exige:

LLM
+
HAG
+
Capability
+
Policy

para interpretar a intenção.

29. Structured Output obrigatório

Quando o LLM for utilizado, deverá retornar exclusivamente um schema estruturado.

Nunca:

"Entendi, você quer..."

para a camada interna.

Preferir:

{
  "intent": "UPDATE",
  "target": "workPermit.validity",
  "requestedValue": 60
}

30. Intent Validation

Após o LLM:

LLM
 ↓
JSON Schema
 ↓
Semantic Validation
 ↓
Capability Validation
 ↓
Policy Validation

Somente então:

VALID INTENT

31. Clarification Engine

Quando faltar informação:

Intent
 ↓
Missing parameter
 ↓
Can context resolve?
   /        \
 YES        NO
 │           │
resolve    ask user

Exemplo:

"Crie um registro."

Se existirem 15 tipos de registro possíveis:

"Qual tipo de registro você deseja criar?"

32. Minimizar perguntas

O agente deverá utilizar o máximo possível do contexto antes de perguntar.

Se:

page = Employee
tab = Documents

e o usuário disser:

"Adicione um documento."

não perguntar:

"Que tipo de objeto?"

A interface já fornece forte evidência.

33. Confirmation ≠ Clarification

São coisas diferentes.

Clarification​

Falta informação:

"Qual equipamento?"

Confirmation​

Informação suficiente, mas a operação exige autorização explícita:

"Confirma a exclusão do equipamento X?"

Essa distinção deverá ser preservada no estado do agente.

34. Navigation Intent

Exemplo:

"Vá para os documentos."

Resultado:

{
  "type": "NAVIGATION",
  "target": {
    "semanticId": "workPermit.documents"
  }
}

O Planner poderá executar a capability de navegação.

35. Navigation por referência

"Volte para onde estávamos antes."

Isso poderá utilizar:

conversation navigation history

e não necessariamente HAG.

36. Multi-intent

Usuário:

"Abra os componentes, adicione o equipamento X e depois explique a validade dele."

Isso contém:

1. NAVIGATION
2. CREATE
3. EXPLANATION

O Intent Engine deverá identificar uma intenção composta:

MULTI_STEP_ACTION

O Planner será responsável pela sequência.

37. Intent Graph

Exemplo:

Intent A
  │
  ▼
Navigation
  │
  ▼
Intent B
  │
  ▼
Create
  │
  ▼
Intent C
  │
  ▼
Explain

Isso será tratado no PRD-006.

38. Negação

O Intent Engine precisa entender:

"Não altere a validade."

Isso não é um UPDATE.

Também:

"Não aprove ainda."

deve impedir execução.

39. Condicionais

Exemplo:

"Se estiver vencida, renove."

Resultado:

IF
  validity < today
THEN
  renew

Isso é uma intenção condicional e deverá ser entregue ao Planner.

40. Quantificadores

O sistema deverá reconhecer:

todos
alguns
somente
o primeiro
os selecionados
os vencidos
os desta página

Exemplo:

"Atualize todos os equipamentos vencidos."

Isso possui impacto muito maior que:

"Atualize este equipamento."

O Risk Engine deverá considerar a cardinalidade.

41. Cardinality

Intent deverá possuir:

scope: {
  type: "single" | "multiple" | "all" | "filtered";
  count?: number;
  filter?: Record<string, unknown>;
}

42. Guard Against Mass Actions

Operações em massa deverão possuir proteção.

1 record
→ normal

5 records
→ confirmation

100 records
→ strong confirmation

10,000 records
→ blocked / explicit workflow

Os limites serão configuráveis.

43. Tenant Context

Toda intenção deverá carregar:

tenantId
userId
sessionId

mas o LLM não deverá ser responsável por determinar esses valores.

Eles serão fornecidos pelo runtime confiável.

44. Session State

O Agent Runtime manterá:

currentPage
currentTab
currentFocus
selectedEntity
conversationReferences
pendingConfirmation
pendingIntent

Isso permitirá diálogos naturais.

45. Exemplo de diálogo completo

Usuário:

"Explique isso."

Contexto:

page = Work Permit
tab = Components
focus = PPE

Intent Engine:

EXPLANATION
target = workPermit.components.ppe

Agente:

explica o PPE.

Usuário:

"E esse aqui?"

O usuário muda o foco para:

equipment

O agente entende:

EXPLANATION
target = equipment

Sem o usuário precisar repetir o nome.

46. Exemplo Agentic

Usuário:

"Adicione este equipamento."

Contexto:

selectedEquipment = EQ-883
workPermit = WP-102

Intent:

{
  "type": "CREATE_RELATION",
  "capability": "workPermit.components.add",
  "parameters": {
    "workPermitId": "WP-102",
    "equipmentId": "EQ-883"
  }
}

47. Exemplo com confirmação

Usuário:

"Exclua este equipamento."

Intent:

DELETE

Capability:

workPermit.components.remove

Risk:

HIGH

O Intent Engine marcará:

requiresConfirmation = true

Mas não executará.

48. Pending Intent

O estado deverá ser preservado.

Intent
 ↓
Confirmation Required
 ↓
PENDING

Usuário:

"Sim."

O sistema não deverá reprocessar toda a conversa do zero.

Deverá recuperar:

pendingIntentId

e prosseguir.

49. Segurança contra confirmação ambígua

"Sim" só poderá confirmar uma operação pendente imediatamente anterior.

Se houver:

pendingIntent = DELETE

e o usuário iniciar outro assunto:

"Ah, antes disso, qual é a validade?"

o estado de confirmação deverá ser invalidado ou colocado em suspensão.

50. Observabilidade

Registrar:

intentId
intentType
confidence
contextResolution
candidateCapabilities
selectedCapability
clarification
confirmation
latency

Isso permitirá entender por que o agente tomou determinada decisão.

51. Métricas

Indicadores:

intent_accuracy
intent_latency
context_resolution_accuracy
ambiguity_rate
clarification_rate
false_action_rate
wrong_capability_rate
confirmation_rate

A métrica mais importante será:

Wrong Action Rate

Uma resposta incorreta é ruim.

Uma ação incorreta é potencialmente muito mais grave.

52. Test Suite

Criar casos reais:

Contextual​

"Explique."
"Altere para 30."
"Exclua este."
"Abra aquele."

Explícitos​

"Crie uma permissão."
"Atualize a validade da permissão 123."

Ambíguos​

"Atualize o equipamento."

Multi-step​

"Abra os componentes e adicione este equipamento."

Negação​

"Não altere esse registro."

Condicional​

"Se estiver vencido, renove."

53. Critérios de aceite

Evidência de implementação e produção — 2026-09-05​

O Intent Engine determinístico classifica consulta, criação, atualização, remoção, aprovação, navegação, explicação, cancelamento e multi-step; usa página, tab, foco, seleção e alvo conversacional para resolver referências. Ele separa ambiguidades/clarificações de intents resolvidas, preserva confidence e confirmação, associa capabilities e trata instruções de bypass como UNKNOWN. O corpus de avaliação, testes do engine/Work Permit e rota autenticada aprovaram 44 casos em 2026-09-04; toda saída mantém authorizesExecution=false.

Em 2026-09-05, os contratos de intent, avaliação, preview e rota passaram com 53 testes em 6 arquivos, e o typecheck do Agent passou. A validação cobre classificação, contexto semântico/conversacional, resolução anafórica e de capability, confiança, clarificação, confirmação, cardinalidade, multi-intent, condição e saída não executável. O slow path usa json_schema estrito com propriedades fechadas e o engine aceita somente proposta estruturada validada, sempre não executável.

Em 2026-09-05, a trilha do preview foi publicada no Worker 71233ee1-3a73-46c3-b662-2da10117cf9d, com as migrações D1 0138 e 0139. O canário autenticado intent-canary-c62aa06465c5409cb4b7720b131082b7 comprovou dois recibos distintos para o mesmo requestId (RESOLVED e AMBIGUOUS), hashes do texto/contexto/resultado e metadados de confiança, resolução contextual, capabilities candidatas, clarificação, confirmação e latência. A capability selecionada é null, pois essa decisão pertence ao Planner. O intentId legado contém texto do usuário e é registrado apenas como hash. O teste SQL comprova preservação de recibos anteriores e bloqueio de UPDATE, DELETE e INSERT OR REPLACE. A rota falha com 503 se a gravação falhar. Verificação: sete testes da rota, typecheck, teste SQL, 323 testes do pré-deploy e demais gates do deploy aprovados; acesso anônimo retorna 401. As identidades sintéticas foram removidas; os recibos imutáveis permanecem.

Na revisão subsequente, comandos compostos passaram a preservar também resumos de cada etapa, com IDs em hash e sem parâmetros, alvos ou IDs de entidades. A versão b36ce7a8-a5ad-4b47-9a97-6650fd8cd317 foi publicada com oito testes da rota, typecheck, teste SQL integrado ao deploy, 324 testes do pré-deploy e todos os demais gates aprovados. O canário intent-canary-48b6fa69164846db9668eb328d0b41ed confirmou três recibos com o mesmo requestId: atualização resolvida, explicação ambígua e comando composto resolvido. Conferiu hashes, metadados e capabilities das etapas diretamente na D1. A revisão independente não identificou problemas materiais restantes nesse incremento.

Comandos reproduzíveis: pnpm --dir apps/agente run verify:intent-audit e pnpm --dir apps/agente run canary:intent-audit. O canário exige DATABASE_URL por ambiente, cria identidades sintéticas, remove-as ao terminar e mantém seus recibos imutáveis; não imprime credenciais.

Em 2026-09-05, a mesma escrita de recibo foi integrada ao outro produtor de AgentIntent: POST /orchestration/work-permits/preview. Ela é aguardada após interpretar e antes de RBAC, policy ou plano. Falhas de D1 retornam somente INTENT_AUDIT_UNAVAILABLE com 503. A versão publicada b231e35b-104f-4852-a9b8-a301b1507c1b passou 327 testes de pré-deploy, todos os gates adicionais e o typecheck. Os canários release-preview-e5062ca4453a4844 e release-preview-54a4dd43a3ad4ea8 provaram em produção a release canário pinada, um recibo ORCHESTRATION_PREVIEW, identidade conferida, hashes de entrada/contexto e zero autorização de execução. Ambos confirmaram limpeza completa do tenant e das contas sintéticas (remainingRows: 0). Uma falha anterior da limpeza deixou 1 tenant, 2 usuários, 3 papéis, 1 atribuição e 2 registros de autenticação; foi recuperada com contagem zero e a sequência transacional passou a remover autenticação, papéis e vínculos antes do purge. O teste verify:synthetic-cleanup agora é parte do deploy.

Em 2026-09-05, a migração D1 0140_intent_audit_model_failure.sql passou a distinguir INTERPRETATION de MODEL_FAILURE e restringe o código de falha a INTENT_MODEL_UNAVAILABLE ou INVALID_INTENT_MODEL_OUTPUT. No slow path de /intents/preview, indisponibilidade do modelo ou saída inválida grava o recibo sanitizado, com hashes, latência e authorizesExecution=false, antes do 502; se a própria auditoria falhar, a rota devolve somente 503. Dez testes da rota, o teste SQL de compatibilidade e imutabilidade, typecheck, 329 testes de pré-deploy e todos os gates passaram. A versão 923d9939-c4f7-4936-965b-8e19d7a9d090 foi publicada em 100%. O canário autenticado intent-canary-d645751f0baa47e49a0a1b9a8cece61a confirmou em produção três recibos de interpretação, seus event_kind/metadados, hashes, 401 anônimo e não execução; o canário de release confirmou novamente um recibo ORCHESTRATION_PREVIEW e limpeza sintética com contagem zero. Não foi introduzido um mecanismo de injeção de falha em produção apenas para fabricar uma falha do provedor; portanto o caminho MODEL_FAILURE tem prova local e esquema remoto, mas ainda não um recibo de falha deliberadamente provocado em produção.

Também em 2026-09-05, a integração de conhecimento na resolução de intenção foi comprovada em produção. O comando vermelho pnpm --dir apps/agente run canary:intent-knowledge, no canário intent-knowledge-35cbe55c4cc8, falhou contra o Worker anterior com CANARY_INTENT_KNOWLEDGE_PREVIEW_INVALID; sua limpeza terminou com cleanupVerified:true e remainingRows:0. Após o deploy, o mesmo comando passou no canário intent-knowledge-cd6c966909ad, com bundle knowledge-canary-cd6c966909ad: uma capability de alto risco percorreu aprovações independentes TECHNICAL e BUSINESS via API até ACTIVE; o bundle ficou ACTIVE; e o índice ficou READY com 6/6 vetores, 6 chunks e uma mutação vetorial. A consulta BM25 standalone retornou resultado. O preview /intents/preview retornou KNOWLEDGE_QUERY/RESOLVED, alvo workPermit.validity, confidence 0.7187006347109383 e trace híbrido BM25/SEMANTIC_ID/CONTEXT, com 2 correspondências e 2 citações. A resposta não vazou texto-fonte nem vínculo de capability, manteve candidatos de capability vazios e authorizesExecution:false. O canário confirmou limpeza com contagem zero. O pin exato é {bundleId,version:'1.0.0'}, após os gates de ciclo de vida D1/R2, confiança e integridade implementados no Worker.

O Worker publicado na versão 6b291b3e-bb0d-4e54-8472-db8da0018bbd foi roteado em 100%; pnpm --dir apps/agente run deploy passou todos os gates, incluindo a suite final agentic-exceptions com 55 arquivos e 314 testes. As regressões pós-deploy preservaram as fronteiras de não execução: pnpm --dir apps/agente run canary:intent-audit registrou, no canário intent-canary-a634a2fd6ae74774bb9eb0920f47a584, três recibos imutáveis RESOLVED/AMBIGUOUS/RESOLVED, com hashes e metadados de decisão verificados, 401 anônimo, nenhuma execução e limpeza zero. pnpm --dir apps/agente run canary:release-control-plane confirmou, no canário canary-ccbafd47e00140d4, release pinada, rollout em 100%, preview READY, um recibo de auditoria de prévia de orquestração, nenhuma execução e limpeza zero. Os três canários reproduzíveis mantêm a disciplina de identidades sintéticas e limpeza ao fim. Não há ainda evidência de Pages para este documento.

Uma revisão final encontrou e corrigiu a possibilidade de manifesto de bundle e validade D1 inconsistentes seguirem para o modelo lento, além de limitar o tamanho da versão do seletor. O commit 1e77a7f2c adicionou a cerca de validade exata de manifesto/registry/captured-time e o limite de 64 caracteres. O deploy corretivo pnpm --dir apps/agente run deploy passou todos os gates, incluindo agentic-exceptions com 55 arquivos e 314 testes; o Worker atual 91543bec-886c-413c-94cd-25a39abb3538 está roteado em 100%.

O canário corretivo pnpm --dir apps/agente run canary:intent-knowledge, intent-knowledge-82242c3576c8, confirmou capability e bundle ACTIVE, 6 chunks, 6 vetores, uma mutação, BM25 standalone e preview resolvido para workPermit.validity, com confidence 0.7187006347109383, trace híbrido BM25/SEMANTIC_ID/CONTEXT, 2 correspondências e 2 citações. Não houve capability, execução ou vazamento; a limpeza terminou com contagem zero. As regressões confirmaram no canário de auditoria intent-canary-891f67657a554cbe88f65d152fdad08c três recibos, 401 anônimo, nenhuma execução e limpeza zero; e no canário de release canary-212da8385df54b50, release CANARY pinada em 100%, preview READY, um recibo, nenhuma execução e limpeza zero.

Os dois produtores atuais encontrados por inspeção (/intents/preview e a prévia de Work Permit) persistem recibos imutáveis para resultados de interpretação. A integração HAG/BM25 no Intent Engine está comprovada em produção; permanecem abertos o contexto conversacional na rota pública e corpus/fluxos além de Work Permit. Não considerar este PRD integralmente certificado.

Em 2026-09-06, POST /intents/preview passou a aceitar apenas um seletor de conversa {id,revision} e resolve o alvo exclusivamente pelo AgenticSession Durable Object vinculado a tenant, usuário e empresa verificados. O corpo do cliente não transporta conversationTarget; revisão divergente, sessão ausente, escopo divergente ou tópico malformado falham com 409 antes de interpretar ou gravar audit. O Worker b18852a7-99fa-4f4c-8fff-8003940dfa76 foi publicado a 100% após 53 arquivos e 448 testes. O canário intent-canary-64a39bfb060d443c86d29ccce0e653a4 inicializou uma sessão sintética, persistiu o tópico workPermit.validity, confirmou resolução conversacional, três recibos de interpretação, hashes verificados, 401 anônimo, authorizesExecution:false e limpeza PostgreSQL zero; o identificador da entidade conversacional não foi gravado em texto nos recibos. Isto fecha somente o contexto conversacional da rota pública; o inventário global de produtores de intent continua aberto.

Também em 2026-09-06, o inventário dos produtores atuais foi revalidado contra o Worker corrente 32b62b38-c4bc-4d00-a657-7eda210c6b90: /intents/preview e /orchestration/work-permits/preview aguardam a escrita em intent_audit_trail, que é imutável e falha fechada. Os 31 testes focados passaram, e o canário intent-canary-46875ef23c684b4d9c937031bbc2b81b confirmou três recibos RESOLVED/AMBIGUOUS/RESOLVED, contexto conversacional, hashes e metadados de decisão, 401 anônimo, nenhuma autorização de execução e limpeza PostgreSQL zero. Esta certificação inclui os resultados de interpretação dos produtores inventariados; o caminho de falha deliberada do provedor continua coberto por teste local, pois não se injeta indisponibilidade de modelo em produção.

Em 2026-09-06, uma busca de domínio não suportado passou a falhar fechada: busque auditorias abertas resulta em UNKNOWN, sem receber a capability workPermit.search. A regressão de engine, corpus e rota passou com 56 testes; os gates de produção posteriores passaram com 39, 72, 33, 83 e 336 testes. O Worker 49c34f09-4101-4a34-9c70-9ef0e2d8733a foi publicado a 100%, e o health público confirmou bindings. O PRD permanece PARTIAL pelo corpus e pela integração ampla de domínios/telas ainda ausentes.

  • Intent Engine implementado;
  • classificação de intents implementada;
  • Semantic UI Context integrado;
  • page context integrado;
  • tab context integrado;
  • semantic focus integrado;
  • selected entity integrado;
  • conversation context integrado na rota pública;
  • anaphora resolution implementada;
  • capability resolution implementada;
  • HAG integration no fluxo de resolução de intent comprovada;
  • BM25 integration no fluxo de resolução de intent comprovada;
  • confidence score implementado;
  • clarification implementada;
  • confirmation state implementado;
  • multi-intent reconhecido;
  • conditional intent reconhecido;
  • cardinalidade reconhecida;
  • LLM structured output implementado;
  • JSON Schema validation implementada;
  • intent audit trail completo, incluindo falhas de interpretação (todos os produtores atuais de resultados persistem e foram verificados em produção);
  • testes de regressão implementados.

54. Resultado

Com PRD-003, PRD-004 e PRD-005, teremos construído três camadas distintas:

┌────────────────────────────────────┐
│          KNOWLEDGE ROUTER          │
│                                    │
│ "Onde está a informação?"          │
│                                    │
│ HAG + Markdown + BM25 + Wikilinks │
│ + Vectorize + Context              │
└──────────────────┬─────────────────┘
                   │
                   ▼
┌────────────────────────────────────┐
│         INTENT ENGINE              │
│                                    │
│ "O que o usuário quer?"             │
│                                    │
│ Message + UI + Conversation        │
│ + HAG + Capabilities               │
└──────────────────┬─────────────────┘
                   │
                   ▼
┌────────────────────────────────────┐
│       CAPABILITY REGISTRY          │
│                                    │
│ "O que o sistema permite fazer?"  │
│                                    │
│ Schema + Permission + Risk         │
│ + Policy + Endpoint               │
└────────────────────────────────────┘

Evidência parcial de implementação — 2026-09-04​

O engine determinístico classifica consulta, explicação, busca, navegação, criação, alteração, exclusão, aprovação, cancelamento e multi-intent; recebe contexto confiável de tenant/usuário/sessão, página, aba, foco semântico, seleção e referência conversacional. Negação, cardinalidade e alvo ambíguo falham para CANCEL ou AMBIGUOUS; a saída não autoriza execução. O preview autenticado limita contexto e entrada, e o slow path usa json_schema estrito, valida a saída e reconcilia capabilities declaradas antes de devolvê-la como LLM_STRUCTURED não executável.

Em 2026-09-04, 44 testes locais em quatro suites (engine, corpus de avaliação, Work Permit e rota) passaram. O corpus atual cobre 24 enunciados de Work Permit, incluindo anáfora, negação, seleção ambígua, cardinalidade, multi-intent, injeção hostil e a condição determinística workPermit.validity BEFORE_NOW. Essa condição só é aceita para renovação com entidade única explícita; sem ela retorna AMBIGUOUS, e texto hostil permanece UNKNOWN. Ainda faltam audit trail persistente e corpus/integração para domínios e telas além de Work Permit; portanto este PRD permanece parcial.

E agora chegamos à parte mais importante do Agentic Work.

PRD-006 — Agent Planner & Execution Orchestrator

No próximo estágio vamos finalmente conectar tudo isso:

Usuário
   ↓
Contexto da aplicação
   ↓
Intent Engine
   ↓
Knowledge Router
   ↓
Capability Registry
   ↓
Planner
   ↓
Policy
   ↓
Confirmation
   ↓
Execution
   ↓
Verification
   ↓
Knowledge update / UI update
   ↓
Resposta

O Planner será responsável por decidir como chegar ao objetivo, inclusive quando uma solicitação exigir várias operações.

Por exemplo:

"Crie uma nova permissão igual à atual, trocando o responsável para João e deixando válida por 30 dias."

Isso não é uma simples chamada REST.

O Planner poderá decompor em:

1. Identificar permissão atual
2. Ler dados
3. Validar se pode ser clonada
4. Criar nova permissão
5. Copiar componentes permitidos
6. Alterar responsável
7. Alterar validade
8. Validar regras
9. Verificar resultado
10. Informar usuário

É nesse PRD-006 que a arquitetura deixa de ser apenas "AI que responde perguntas" e passa efetivamente a ser um agente capaz de operar o sistema com segurança, rastreabilidade e autonomia controlada.