Helix: Orquestração Multi-Agente em Produção

O Helix é a plataforma de orquestração multi-agente que desenvolvo no Grupo Studio para operações de marketing B2B. Ela transforma uma solicitação de negócio não estruturada (um briefing) em um run auditável, onde agentes especialistas planejam, pesquisam, escrevem, revisam, pedem aprovação humana, persistem estado, rastreiam custo e produzem entregáveis reutilizáveis.

O problema

A produção de campanhas B2B envolvia coordenação entre estratégia, conteúdo, SEO, social, design e analytics — dias de idas e vindas entre pessoas e uma agência externa. O objetivo do Helix é mover as demandas mais comuns para runs guiados por IA com aprovação humana, medindo custo, qualidade e impacto de cada execução.

Arquitetura geral

Dashboard React (operador)
   |
Gateway Express: auth, CRUD, relay de WebSocket
   |
Runtime GenAI em FastAPI
   |
StateGraphs LangGraph (squads)
   |-- briefing-intake
   |-- studio-marketing
   |-- cyber-security
   |
PostgreSQL: runs, checkpoints, custo, qualidade
   |
Memória: RAG híbrido + Neo4j + Qdrant

Escolhi LangGraph com grafos de estado explícitos (e não loops de chat multi-agente) porque workflows corporativos precisam de controle determinístico, checkpoints resumíveis, fronteiras de retry e transições de estado auditáveis. Cada squad é um grafo, cada agente é um nó — a squad de marketing tem 17 nós e um catálogo com mais de 20 pipelines.

Roteamento híbrido: determinismo quando dá, autonomia quando precisa

A decisão central de arquitetura é um triage que classifica cada demanda em três rotas:

• DIRECT — a demanda é muito parecida com um entregável já arquivado: o time apenas faz a troca cirúrgica de dados. Rápido e barato.
• PIPELINE — a demanda casa com um pipeline do catálogo: o grafo caminha de forma determinística pela lista de agentes definida ("a lista é lei").
• AD_HOC — nenhum pipeline cobre o caso: entra o trio planner → executor → verifier, que monta um plano em DAG, executa a fronteira de tarefas prontas em paralelo e valida cada resultado. Ao final, o fluxo que funcionou é registrado como um novo pipeline no catálogo — na próxima demanda parecida, a rota vira determinística. O sistema se auto-melhora.

No modo AD_HOC, a verificação é adversarial em painel: um revisor avalia o resultado e um segundo agente cético tenta refutá-lo — a tarefa só passa se ambos aceitam. Isso corrige o viés de um juiz único leniente.

Aprovação humana como estado durável

Human-in-the-loop não é um input() no meio do código: é o interrupt() do LangGraph combinado com checkpoints no PostgreSQL (AsyncPostgresSaver). Um run pausa no checkpoint de aprovação, sobrevive a restart do serviço e resume dias depois exatamente de onde parou, com todo o estado do grafo intacto.

Governança de custo e roteamento de modelos

Cada chamada de LLM passa por um callback de custo que grava tokens de entrada/saída, modelo e custo estimado em USD — por chamada, por agente e por run. Isso alimenta uma API de impacto que compara custo de IA contra horas manuais economizadas.

O roteamento de modelos é por dificuldade da tarefa: tarefas simples vão para o tier rápido (Claude Haiku), moderadas e complexas para o tier padrão (Claude Sonnet) e críticas para o tier premium (Claude Opus) — um ponto único de governança, com rebaixamento dinâmico para o tier barato quando heurísticas indicam demanda simples.

Memória e RAG híbrido

A camada de memória separa recall semântico, relações em grafo e estado episódico dos runs:

• Busca híbrida: BM25 (lexical) + busca vetorial (Qdrant), fundidas por Reciprocal Rank Fusion e refinadas com rerank de cross-encoder.
• Grafo de conhecimento (Neo4j) para entidades e relações entre marcas, públicos e campanhas.
• Um endpoint "smart" faz reescrita de query → busca híbrida → rerank → compressão de contexto.

Isso evita o "prompt stuffing": em vez de carregar todas as diretrizes no prompt, cada agente recupera só o contexto certo para a campanha em questão.

Avaliação contínua de qualidade

Todo run concluído pode ser avaliado automaticamente:

• LLM-as-Judge com rubrica de 5 critérios: relevância, completude, voz de marca, acionabilidade e acurácia.
• Ragas para faithfulness e precisão contextual da geração apoiada em memória.

Os scores ficam persistidos junto do run — o que abre caminho para testar A/B de prompts, supervisores e políticas de roteamento com dados reais.

Resiliência

Nós do grafo têm retry com backoff exponencial; se um agente esgota as tentativas, ele devolve um estado de falha e o supervisor roteia ao redor do nó quebrado em vez de derrubar o run inteiro. Escritas no catálogo de pipelines são atômicas e idempotentes.

Stack

• Orquestração: LangGraph + LangChain (Python)
• Runtime: FastAPI · Gateway: Node/Express · Dashboard: React + TypeScript
• LLMs: Claude (Anthropic) em três tiers, com structured output via Instructor
• Dados: PostgreSQL (runs, checkpoints, custo), Qdrant (vetores), Neo4j (grafo), S3/MinIO (artefatos)
• Observabilidade: Langfuse (tracing de runs e chamadas)
• Infra: Docker Compose, CI com GitHub Actions

Resultados e próximos passos

As metas de negócio são projeções em validação: reduzir em ~78% o tempo de produção de campanha (de dias para menos de 2 horas em demandas comuns) e em ~65% a dependência de agência externa. O próximo marco é substituir essas projeções por métricas medidas em runs internos reais — custo por run, taxa de sucesso de tarefas, taxa de intervenção em checkpoints e horas economizadas.

O que esse projeto me ensinou

1. Determinismo primeiro, autonomia depois. A maior parte do valor vem de pipelines previsíveis; agentes autônomos são a exceção controlada — e o que eles descobrem vira pipeline.
2. Custo é requisito de produto. Sem medir custo por agente e por run, não existe conversa séria sobre ROI de IA.
3. Avaliação não é opcional. LLM-as-Judge + verificação adversarial mudam a qualidade do que chega ao humano aprovar.

Quer conversar sobre orquestração multi-agente, LangGraph ou LLMOps? Me chame no LinkedIn.