O Sequential Thinking é o motor de orquestração da plataforma. Recebe uma instrução em linguagem natural (ex: “crie um formulário com nome, e-mail e telefone”), monta um plano de steps e executa cada um com contexto, persistência e controle de falhas. Todos os domínios reutilizam o mesmo motor em vez de reinventar planejamento, execução e retomada.

Por que isso importa

  • Evita duplicação de lógica entre produtos e squads
  • Garante padrão único de execução, erros, retries e auditoria
  • Permite pausar, retomar e cancelar fluxos longos com segurança
  • Expõe eventos de progresso para frontend em tempo real
  • Reduz custo quando o fluxo é fixo usando PlanTemplate (sem custo de planejamento)

Base URL

{{BASE_URL}}/api/externalAPIs/public/sequentialThinking

Use {{BASE_URL}} nos exemplos. Em ambiente local, substitua por http://localhost:3000/api/externalAPIs/public/sequentialThinking.

Autenticação

  • listActions e run: rotas públicas, sem autenticação (testes).
  • runWithAgents: exige token Bearer. O KrakenD injeta X-Host-Id e X-Domain-Id nos headers.
Authorization: Bearer {TOKEN}

Em ambiente local, quando os headers do KrakenD não estão presentes, o hostId pode ser passado no body.


Como ler esta documentação

Endpoints da API

  • GET /listActions
  • POST /run
  • POST /runWithAgents

Use /run para validar prompts e comportamento do motor sem efeitos colaterais.
Use /runWithAgents para execução real em produção.

Estruturas de dados

StepResult

CampoTipoDescrição
stepNumbernumberPosição do step no plano (1-based)
actionstringNome da ação executada
statusstring"completed" | "failed" | "skipped"
resultobjectDados retornados pela ação
paramsobjectParâmetros capturados pelo LLM
errorstringMensagem de erro (quando status é "failed")
durationMsnumberTempo de execução em milissegundos

Eventos (array events)

Cada item segue o envelope documentado em Eventos e WebSocket: type, intentId, sessionId (quando houver sessão), timestamp, seq, chapterId, chapterKey, payload.

Resumo: use seq para ordenar; chapter_started / chapter_completed delimitam fases (initialization, preparation, planning, feasibility, continuation_planning, execution, containment, recommendation_replan, delivery_comparison, full_retry, audit, compile). O evento final_answer_ready marca a fronteira em que a mensagem final está garantida.

O campo progress em eventos de step é tipicamente:

Math.round((stepNumber / totalSteps) * 100);

Para o catálogo completo (incluindo delivery comparison, full retry, RAG, query DB, cost_reconciled, performance_report, cancelamento e Socket.IO), consulte Eventos e WebSocket.

Métricas (objeto metrics)

CampoTipoDescrição
totalDurationMsnumberDuração total da execução em milissegundos
totalLlmCallsnumberTotal de chamadas ao LLM
totalTokensUsedobject{ prompt: number, completion: number }
totalCostInDollarsnumberCusto total acumulado em dólares
stepDurationsobjectDuração por step: { [stepNumber]: number }

FeasibilityAnalysis

CampoTipoDescrição
feasiblebooleanSe o plano é viável
issuesstring[]Bloqueadores — execução não deve prosseguir
warningsstring[]Alertas — execução pode prosseguir, mas com risco
recommendationsstring[]Sugestões de melhoria do plano

Contrato de Retorno (resultado completo)

CampoTipoDescrição
successbooleanSe a execução foi bem-sucedida
intentIdstringUUID persistido — use para retomar execuções
finalAnswerobjectSempre presente, mesmo em falhas e cancelamentos
stepsStepResult[]Array de resultados por step
feasibilityAnalysisFeasibilityAnalysisAnálise de viabilidade do plano
metricsobjectMétricas de execução (ver tabela acima)
auditLogstring[]Log textual da execução
auditInsightobject | nullDiagnóstico de falha gerado pelo Failure Audit (presente quando auditOnFailure: true e houve falha)
errorstring | nullMensagem de erro quando success é false

O campo finalAnswer é sempre garantido pelo motor — inclusive em falhas, cancelamentos e bloqueios por inviabilidade. Em casos de falha, o motor compõe uma resposta explicativa com message, executionStatus, explanation e retryGuidance.