Modes e performance

O Sequential Thinking expõe dois eixos ortogonais além da camada de permissão stLayer:

Confundir os dois eixos é erro comum: um token Host pode usar mode: 'lean'; uma sessão Conversational pode usar pipeline completo (sem mode).

​

options.mode — presets de pipeline

Um mode restringe ou especializa o motor antes da fase PREPARATION:

• Subset de ações — ex.: copilot de ticket vê só ações de tickets/leads.
• Constraints e guidance — regras SQL, primers de domínio, políticas de área.
• Opções de execução — maxSteps, timeouts, flags de performance embutidas.
• Plano pré-construído — prebuiltPlan determinístico (sem Planner LLM).

​

Modes built-in (referência)

​

Como ativar via API

Passe modeInput no body de runWithAgents (ou screenTags legado):

{
  "instructions": "Atualize o ticket 12345678 com prioridade alta",
  "modeInput": {
    "mode": "copilot_ticket",
    "screen": "ticket_detail",
    "entityIds": { "ticketId": "uuid-do-ticket" }
  }
}

Quando modeInput.mode está presente, o backend resolve bindings de tela (screenBindings) e injeta registry/opções antes do pipeline.

Parâmetros relacionados:

​

options.performanceMode — presets de custo/latência

Atalho para ligar/desligar gates LLM caros. Valores: balanced (padrão), fast, turbo. Flags explícitas no mesmo options sempre vencem o preset.

Flags individuais (override fino): skipDeliveryComparator, skipAvatarPersona, skipResultEvaluator, skipNarration, skipActionPrefilter, skipConstraintPrefilter, skipSessionContext, enableRag: false, terseOutput, persistenceMode, avatarPersonaMode (fused | rewrite | off).

O motor expõe result.metrics.perfMode = { preset, resolvedFlags } quando um preset foi aplicado.

​

Clusters feature-flagged no catálogo

Além das ~60 ações base, o GET /listActions pode incluir clusters conforme variáveis de ambiente:

Workflow builder (addWorkflowNode, importN8nWorkflow, …) não entra no catálogo padrão de listActions — só no mode workflowBuilder.

SecOps crypto (encryptJson, hashFromText, …) e tracers investigateV3 (toolCallTracer, timelineReverseTrace, …) fazem parte do catálogo base quando registrados no deploy.

​

Sub-planner (delegateToSubPlanner) — default ON

Quando o catálogo inclui delegateToSubPlanner, o Planner pode decompor pedidos multi-parte em sub-runs headless (filhos com o mesmo hostId). Caps principais: ST_SUB_PLANNER_MAX_DEPTH (default 1), ST_SUB_PLANNER_MAX_PARALLEL (default 3). Supervisão (ST_SUB_PLANNER_SUPERVISION_*) e composição com Investigation Loop (ST_SUB_PLANNER_IN_LOOP_ENABLED) são opt-in e default OFF.

Não há campo no body do cliente para ligar/desligar — só variáveis de ambiente do serviço.

​

Canvas Curator — default ON

Instância paralela ao Planner que preenche o Side Track (painel visual) do webchat com tabelas, imagens e Atomic Visuals produzidos no turno, sem exigir que o plano peça ações de canvas. Master: ST_CANVAS_CURATOR_ENABLED (opt-out com =false). Layers: ST_CANVAS_CURATOR_LAYERS (default conversational,host,admin). Budget da live wave: ST_CANVAS_CURATOR_LIVE_MAX_PER_TURN (default 3).

O curador não altera a resposta textual do Planner; só emite comandos de canvas no trilho canônico. Pedidos explícitos de curadoria (ST_CANVAS_CURATOR_USER_REQUESTS_ENABLED) continuam opt-in OFF.

​

Investigation Loop (server-side, default OFF)

O motor tem um loop proativo INVESTIGAR→DECIDIR: cada ciclo é um plan+execute completo, e um decisor avalia os resultados acumulados para entregar, rodar outro ciclo ou pausar e perguntar. A ativação é 100% por variável de ambiente do serviço — não há campo em options do request; o payload do cliente não influencia.

Quando ligado, o stream de eventos pode incluir investigation_cycle_started, continuation_decision_made e cycle_limit_reached; cada ciclo tem intentId próprio, correlacionado por loopGroupId no resultado.

Composição loop × delegação (ST_SUB_PLANNER_IN_LOOP_ENABLED) permanece opt-in OFF: com OFF, turnos sob Investigation Loop não registram delegateToSubPlanner no catálogo daquele turno.

​

Transporte de eventos (ST_TRANSPORT_MODE)

Saída dos eventos do motor para o gateway webchat:

O contrato browser (nomes de evento, seq, rooms) permanece o mesmo — muda só o caminho interno entre pods. Detalhes de conexão em Eventos e WebSocket.

​

Relação com stLayer

Para isolamento por tenant/host, veja Camadas de permissão.