new feature: Multi-Intent

agent_framework_oci/docs/features/en/16_multi_intent_planning.md

@@ -2,9 +2,8 @@
 
 `MultiIntentPlanner` recognizes independent requests in one utterance and
 builds a plan constrained to the intents, agents, and tools declared in
-`config/routing.yaml`. It does not execute operations or let the LLM invent a
-sequence: the router selects the primary operation and the domain workflow
-continues to own the transaction.
+`config/routing.yaml`. It does not execute operations: the router selects the
+primary operation and the domain workflow continues to own the transaction.
 
 ## Configuration and execution
 
@@ -12,12 +11,21 @@ No additional configuration is required. The planner uses the intents already
 declared in `routing.yaml`, selects the single transactional operation from
 `tool_policies.yaml`, and persists the remaining requests as `pending_topics`.
 
+When `ENABLE_LLM_ROUTER=true`, a compound message whose deterministic plan is
+missing or incomplete is sent to a structured multi-intent classifier. The LLM
+may return only configured intent names and source fragments. Agent, domain,
+and tool ownership are always hydrated from `routing.yaml`; unknown intents,
+low confidence, and invalid JSON are rejected. The default confidence threshold
+is `0.65` and can be overridden with
+`multi_intent.llm_confidence_threshold`.
+
 Known read-only topics execute through their own agent. A second mutation stays
 pending for its own confirmation, while an unknown clause becomes off-context.
 
-The router resolves clauses from registered intent keywords and routes the
-transactional operation first. The graph drains read-only pending topics before
-output supervision. During an open transaction,
+The router first resolves clauses from registered intent keywords, then uses the
+semantic fallback only for an absent or incomplete compound plan, and routes
+the transactional operation first. The graph drains read-only pending topics
+before output supervision. During an open transaction,
 `yes, and send me the invoice` confirms the transaction and records the
 secondary request instead of causing an intent shift.
 

agent_framework_oci/docs/features/pt-BR/16_multi_intent_planning.md

@@ -2,9 +2,8 @@
 
 O `MultiIntentPlanner` reconhece solicitações independentes na mesma mensagem e
 cria um plano limitado às intents, agents e tools declarados em
-`config/routing.yaml`. O planejador não executa operações nem permite que o LLM
-invente uma sequência: o roteador escolhe a operação primária e o workflow do
-domínio continua responsável pela transação.
+`config/routing.yaml`. O planejador não executa operações. O roteador escolhe a
+operação primária e o workflow do domínio continua responsável pela transação.
 
 ## Configuração
 
@@ -12,6 +11,13 @@ Não existe configuração adicional. O planejador usa as intents do `routing.ya
 e lê `tool_policies.yaml` para priorizar automaticamente a única operação
 transacional. Pedidos secundários são persistidos em `pending_topics`.
 
+Quando `ENABLE_LLM_ROUTER=true`, mensagens compostas que não produzam um plano
+determinístico completo passam por um classificador multi-intent estruturado. O
+resultado do LLM só informa nomes de intents e trechos da mensagem. Agent,
+domínio e tools são sempre recuperados do `routing.yaml`; intent inexistente,
+baixa confiança ou JSON inválido são rejeitados. O limite padrão de confiança é
+`0.65` e pode ser sobrescrito por `multi_intent.llm_confidence_threshold`.
+
 - intent conhecida e read-only: executada pelo agent correspondente;
 - intent conhecida e transacional: mantida pendente para confirmação própria;
 - trecho sem capability correspondente: respondido como `off_context`.
@@ -24,10 +30,12 @@ workflow transacional coordenador.
 
 1. O `EnterpriseRouter` separa a entrada em cláusulas e resolve cada uma pelas
    keywords das intents cadastradas.
-2. `tool_policies.yaml` identifica a operação transacional e a torna primária.
-3. A primeira operação é roteada normalmente para seu agent/workflow.
-4. O `agent_graph` compõe as mensagens públicas antes do supervisor de saída.
-5. Durante uma confirmação, uma frase como `sim e me manda a segunda via`
+2. Se o plano estiver ausente ou contiver trecho provisoriamente fora de escopo,
+   o classificador LLM tenta reconhecer semanticamente as intents componentes.
+3. `tool_policies.yaml` identifica a operação transacional e a torna primária.
+4. A primeira operação é roteada normalmente para seu agent/workflow.
+5. O `agent_graph` compõe as mensagens públicas antes do supervisor de saída.
+6. Durante uma confirmação, uma frase como `sim e me manda a segunda via`
    confirma a transação aberta e registra a solicitação secundária, sem causar
    troca indevida de intent.