Uma empresa operada com agentes e com processo

Agente não é produto. É mão de obra. E mão de obra precisa de escopo, memória, supervisão, registro e demissão. Esta página documenta como o Jatobá Lab organiza isso: a arquitetura, o piloto de marketing, as ferramentas em avaliação e os controles de LGPD que valem para qualquer cliente.

Versão 0.1 · Documento vivo · Atualizado em 3 de novembro de 2026

O princípio: centralizar contratos, não ferramentas

Trocar de fornecedor deve ser uma decisão de operação, não uma reescrita. Por isso o que fica no centro são os contratos: ficha do agente, política de dados, formato do trace, esquema das ferramentas e registro de decisões. A ferramenta é implementação.

Todo agente tem ficha e dono

Nome, objetivo, engine, modelo, ferramentas permitidas, dados que pode ver, limite de custo e critério de desligamento. Sem ficha, não entra em produção.

Toda ação tem trace

Cada turno registra modelo, ferramentas chamadas, tokens, custo, latência e resultado. O trace é a fonte de auditoria e de melhoria, não um painel decorativo.

Toda memória tem origem e prazo

Um fato guardado precisa dizer de onde veio, quem pode ler, quando expira e como é apagado. Memória sem proveniência é passivo de LGPD.

Todo processo tem desenho e porta de saída

BPMN simples, critério de aprovação e plano de interrupção. Se o agente errar, o processo para e uma pessoa decide, sem heroísmo.

Arquitetura em cinco camadas

A mesma estrutura serve para o piloto de marketing e para qualquer cliente. O que muda por projeto são os conectores e as políticas, não o desenho.

O que já está no ar

O gateway LiteLLM concentra as chaves e o orçamento, hoje apontando para o OpenRouter com um modelo único. O Langfuse recebe traces de cada chamada, com retenção curta e projeto separado por ambiente. O runtime fica atrás do Tailscale, sem porta pública. Bloks e OpenBot são laboratório; não entram como fundação comercial por causa da licença.

O que ainda é decisão aberta

Memória de longo prazo, orquestração durável e identidade por agente estão em avaliação. A regra é não adotar nada que só funcione no fornecedor. As opções e o que cada uma custa em operação estão na seção de ferramentas.

Piloto: marketing em 30 dias

Marketing é o melhor primeiro caso porque tem demanda recorrente, entregável verificável e um humano no caminho da publicação. O piloto não tenta automatizar a área inteira: testa três agentes e um processo com aprovação obrigatória.

Fluxo do piloto de marketing Cinco raias: demanda, estratégia, produção, aprovação e publicação. O fluxo começa no briefing, passa por pesquisa e estratégia, produção de conteúdo, revisão de marca, checagem de LGPD, publicação e medição, terminando no registro de aprendizado. Demanda gestor + solicitante Estratégia agente pesquisador Produção agentes de conteúdo Aprovação humano no circuito Publicação e medição agente + analytics início Briefing eobjetivo Triagem eprioridade escopo? Devolver aosolicitante fim Pesquisa demercado e público Estratégia ecalendário Produção deconteúdo Revisão demarca ok? ajustes ChecagemLGPD e dados Aprovaçãofinal Publicação edistribuição Medição eatribuição Registro eaprendizado fim
tarefa executada por agente tarefa com decisão humana

Os três agentes do piloto

  • Pesquisador. Lê briefing, concorrentes e dados públicos. Entrega um dossiê com fontes e lacunas. Não escreve conteúdo final.
  • Redator. Transforma dossiê e tom de voz em pauta e texto. Trabalha com template e checklist de marca. Não publica.
  • Analista. Lê métricas de alcance, clique e conversão, propõe leitura e próximo teste. Não altera campanha sozinho.

Cada agente tem uma ficha com engine, modelo, ferramentas, dados permitidos e teto de custo. O que não estiver na ficha não é usado.

Escopo e critério de parada

  • Entregável: 8 peças publicadas em um canal próprio, com revisão humana registrada.
  • Métrica principal: custo por peça aprovada e tempo entre briefing e publicação.
  • Métricas de qualidade: retrabalho por peça, incidentes de marca e alegações não sustentadas.
  • Parada: qualquer publicação sem aprovação, vazamento de dado de cliente ou custo acima do teto definido.

O piloto termina com um relatório de decisão: manter, ajustar ou encerrar. Nada vira rotina por inércia.

Memória: três coisas diferentes

O erro mais comum é chamar tudo de “memória” e comprar uma ferramenta só. São três problemas com prazos, donos e riscos distintos.

Tipos de memória e o que cada um exige.
TipoO que guardaPrazoDonoRisco principal
Memória de agente Contexto de uma conversa, preferências do usuário, fatos da tarefa em andamento. Curto, expira com a tarefa ou em dias. Operação Vazar contexto entre clientes ou sessões.
Memória da organização Fatos canônicos: tom de voz, políticas, decisões, quem aprova o quê. Longo, versionado. Diretoria e jurídico Fato desatualizado virar verdade operacional.
Segundo cérebro Conhecimento curado por uma pessoa: notas, referências, leituras, ideias. Pessoal e revisável. A própria pessoa Virar arquivo morto ou vazar dado pessoal.

Decisão proposta: biblioteca primeiro, índice depois

Fase 1 e fase 2 usam Markdown versionado em Git para o conhecimento canônico e Postgres para a memória operacional com TTL. Mem0, Cognee e Graphiti não entram por padrão. Eles entram quando o diferencial de cada um for o gargalo real, não quando a necessidade é apenas buscar. Uma ferramenta só resolve, no máximo, um dos três tipos de memória.

Quando cada framework faz sentido

  • Mem0: memória por usuário dentro de um mesmo tenant, com extração automática de fatos.
  • Cognee: grafo mais vetor, com isolamento por dataset e pipeline de ingestão.
  • Graphiti: fatos que mudam no tempo e exigem invalidação explícita.
  • Letta: referência conceitual de memória hierárquica, não serviço self-host em 2026.
  • Fora: Supermemory (servidor proprietário), OpenMemory (descontinuado) e Zep Community Edition (descontinuado).

Second brain: biblioteca, não acúmulo

Faz sentido como metáfora de biblioteca com bibliotecário, não como um cérebro que engole tudo. O ativo é conhecimento curado, com dono, versão, prazo e proveniência. O ciclo é captura rápida, revisão semanal, ligação entre notas, busca e expiração. A implementação começa em Markdown com Git (Obsidian, Logseq ou basic-memory) antes de qualquer banco vetorial.

Dado de cliente não entra no segundo cérebro pessoal. Nota pessoal com dado de terceiro é tratamento de dados e segue a mesma política.

Embedding também é dado pessoal. Índice não é compartilhado entre clientes, a remoção do titular alcança o vetor e o texto de origem, e a origem de cada fato fica registrada para permitir auditoria e expurgo.

Workflow: por que não Temporal agora

Temporal é o melhor encaixe técnico entre as opções 100% open source e o pior encaixe de fase. O problema que ele resolve é real: execução durável, replay, aprovação humana e medição que atravessa dias. O estágio ainda não justifica quatro serviços e uma disciplina de determinismo com uma pessoa operando.

Veredito

Adiar a adoção, não descartar. A fase 1 usa pg-boss + Postgres + máquina de estados explícita, desenhada para migrar. Temporal single-node entra na fase 2 quando dois ou mais gatilhos objetivos forem verdadeiros. Restate e Inngest têm boa experiência de desenvolvimento, mas as licenças (BUSL 1.1 e SSPL 1.0) os desqualificam como espinha dorsal.

Opções de orquestração e a licença real.
OpçãoLicençaEncaixeDecisão
pg-boss + PostgresMITFila com retry e agendamento, sem serviço novofase 1
TemporalMITExecução durável, replay, updates e schedulesfase 2, com gatilhos
RestateBUSL 1.1Binário único, boa DXfora pelo licenciamento
InngestSSPL 1.0Excelente DX, self-hostfora pelo licenciamento
WindmillAGPL + trechos proprietáriosScripts e fluxosem avaliação com ressalva
n8nSustainable Use (fair-code)Automação visualopcional, sem revenda
FlowiseApache-2.0Camada de agentefora, projeto encerrado em 2026
Camunda 8Licença paga em produçãoBPMN com execuçãofora do critério

Gatilhos para adotar Temporal

Dois ou mais destes, registrados em ADR:

  • Três ou mais processos críticos com cinco etapas e aprovação humana.
  • Volume acima de 100 execuções por dia.
  • Dois ou mais operadores alterando o mesmo caso.
  • Necessidade de replay e prova de decisão que o pg-boss não entrega.
  • Máquina de estados chegando a 2.000 linhas ou terceiro mecanismo caseiro de retry.
  • Uma segunda pessoa, ou tempo dedicado, para operar a infraestrutura.

Como a fase 1 fica “Temporal-ready”

  • Atividades idempotentes, com chave de deduplicação por etapa.
  • run_id propagado do primeiro passo ao último.
  • Estado persistido em Postgres, não em memória do processo.
  • Timeout, retry e compensação declarados por etapa.
  • Aprovação humana como evento registrado, não como mensagem no chat.

BPMN entra como documentação e contrato entre pessoas. A execução fica no código. Quando o processo exigir execução BPMN de verdade, a decisão volta para a mesa com um caso concreto e um ADR próprio.

Observabilidade e custo

Sem trace não existe auditoria, avaliação nem controle de custo. O arranjo atual já cobre o essencial e é a base para o resto.

O mínimo por trace: identificador do agente e do projeto, modelo, tokens de entrada e saída, custo estimado, ferramentas chamadas, latência, resultado e se houve aprovação humana. Como retenção automática, mascaramento server-side e RBAC por projeto estão na edição Enterprise do Langfuse, essas três coisas são feitas fora dele: máscara no cliente e no LiteLLM, expurgo por job na API e acesso restrito por rede. O contrato de trace é OpenTelemetry, não o SDK do fornecedor.

Ferramentas: o que entra, o que fica de fora

O critério não é popularidade. É licença aprovada pela OSI, self-host possível, dados exportáveis e custo de operação que caiba numa VPS de 15 GB. Quando a licença tem zona cinzenta, ela aparece na tabela em vez de virar surpresa depois.

LiteLLM

Gateway, chaves virtuais, orçamento por agente, rate limit, fallback e guardrails. O centro de custo e de acesso a modelo.

MIT no núcleo · adotado

Langfuse

Traces, prompts, datasets e avaliação. Retenção, mascaramento server-side e RBAC são Enterprise, então o controle é construído fora.

MIT no núcleo · adotado com ressalvas

OpenTelemetry

Contrato de instrumentação em gen_ai.*. É o que permite trocar o painel sem reescrever agente.

Apache-2.0 · adotado como contrato

GLPI

Chamados, projetos, tarefas e aprovação. Formulários nativos, webhooks e 2FA na versão 11.

GPL-3.0 · adotado

Rocket.Chat

Canal humano e fonte de contexto. O MCP lê salas e mensagens; escrita fica desligada por padrão.

MIT no núcleo · adotado

Metabase

Leitura de indicadores. O MCP executa apenas cards existentes, nunca SQL gerado pelo modelo.

AGPL-3.0 · adotado

Ghost

Blog próprio do piloto, com editor para quem não é técnico. Alternativa estática: Astro.

MIT · recomendado no piloto

Umami

Analytics sem cookies, com hash de sessão e salt mensal. Menos peso de LGPD que um analytics tradicional.

MIT · recomendado no piloto

Matriz de decisão

Licença verificada na fonte oficial em 3 de novembro de 2026. Decisão operacional, não parecer jurídico.
FerramentaLicençaPapelDecisão
LiteLLMMIT (núcleo)Gateway de modelosadotado
LangfuseMIT (núcleo), EE pagoObservabilidade e avaliaçãoadotado com ressalvas
OpenTelemetryApache-2.0Contrato de traceadotado
GLPIGPL-3.0Chamados e aprovaçãoadotado
Rocket.ChatMIT (núcleo)Canal e contextoadotado
MetabaseAGPL-3.0BI e indicadoresadotado
GhostMITBlog do pilotorecomendado
UmamiMITAnalytics sem cookierecomendado
ListmonkAGPL-3.0Newsletterrecomendado
PostizAGPL-3.0Publicação socialrecomendado, com plano manual
NextcloudAGPL-3.0Arquivos e versõesrecomendado
PenpotMPL-2.0Designrecomendado
HyperFramesApache-2.0Vídeo programáticorecomendado
KeycloakApache-2.0Identidade e token exchangefase 2
SOPS + ageMPL-2.0 / BSD-3Segredos no Gitfase 1
OPAApache-2.0Política de acessofase 2
pg-bossMITFila e retryfase 1
TemporalMITExecução durávelfase 2, com gatilhos
n8nSustainable Use (fair-code)Automaçãoopcional, sem revenda
BloksFSL-1.1-MIT (source-available)Runtime de agentesfora do critério OSI
OpenBotPolyForm NoncommercialRuntime de agentesfora do uso comercial
BackstageApache-2.0Catálogo de agentesfora na fase 1 (6 GB)
InfisicalMIT (núcleo), EE pagoSegredosfora na fase 1 (4 GB+)
RemotionLicença própria, não OSIVídeoevitar acima de 3 pessoas
LangSmith, Lunary, HeliconeProprietário ou descontinuadoObservabilidadefora

Licença é critério de arquitetura

Bloks é source-available (FSL), OpenBot é noncommercial, n8n é fair-code e Remotion tem licença própria. Nenhum deles pode ser o centro de uma empresa que quer operar sem pedir licença. O centro é o que é exportável: LiteLLM, OpenTelemetry, MCP e os arquivos em Git. O runtime de agente é trocável por desenho.

O Cloudflare Pages continua como conveniência de hospedagem estática deste site. O conteúdo é HTML e CSS puro, então a saída para VPS com Caddy não exige reescrita. A dependência está registrada, com plano de saída.

Como isso é registrado na organização

Documentação não é burocracia paralela: é o que permite delegar, auditar e trocar de ferramenta sem perder memória. Cada artefato tem um dono e um lugar.

Ficha do agente

Objetivo, engine, modelo, dono, ferramentas, dados permitidos, teto de custo, critério de desligamento e versão do prompt.

ROPA da operação

Finalidade, base legal, categorias de dado, origem, compartilhamento, retenção e medidas de segurança. Uma linha por operação com agente.

BPMN do processo

Desenho com raias, tarefas, aprovações e pontos de parada. Versão no repositório, não em imagem solta no chat.

ADR

Decisão de arquitetura com contexto, alternativas, escolha e consequência. Serve para explicar por que não se usa tal fornecedor.

Runbook

O que fazer quando o agente falha, o gateway cai ou um trace mostra vazamento. Passos, responsável e prazo.

Catálogo de prompts

Prompts versionados com dono, caso de uso, modelo testado e avaliação. Prompt fora do catálogo não vai para produção.

Diário de execução

O que o agente fez, quando, com qual aprovação e qual foi o resultado. É a ponte entre o trace técnico e a operação.

Registro de incidentes

Data, descrição, dados afetados, risco, comunicação e correção. Mesmo incidente sem dado pessoal entra no registro.

O repositório do projeto guarda os artefatos em texto: docs/agentes/<nome>.md, docs/processos/<processo>.bpmn, docs/decisoes/ADR-0001.md e docs/runbooks/. O GLPI continua sendo o sistema de chamados e tarefas. O Metabase lê os indicadores. O Langfuse guarda o trace. Nenhum desses sistemas é a fonte da verdade do processo.

LGPD e segurança por desenho

A política completa está em lgpd.jatoba.tech. Aqui ficam os controles que a operação com agentes acrescenta.

Dados

  • Base legal declarada por operação, antes do primeiro prompt.
  • Minimização: o agente recebe o recorte necessário, não a base inteira.
  • Dado pessoal mascarado no trace e proibido em prompt de modelo externo sem base e contrato.
  • Retenção definida por tipo: trace 30 dias, memória de tarefa dias, documento de cliente enquanto durar o contrato.
  • Direito de eliminação com procedimento que alcança trace, memória e backup.

Acesso e operação

  • Menor privilégio por agente: cada MCP tem token próprio e escopo próprio.
  • Escrita desligada por padrão. Publicar, enviar e alterar exigem flag e aprovação.
  • Segredos fora do prompt e do repositório, com rotação e registro de uso.
  • Isolamento por cliente: memória, trace e credencial não se misturam.
  • Incidente com risco relevante segue o fluxo da política, com prazo regulamentar e comunicação à ANPD quando cabível.

Transparência de IA

Conteúdo produzido com agente e publicado em nome do Jatobá Lab leva identificação. Piloto com cliente real exige cláusula de tratamento, ROPA preenchido e revisão jurídica. Esta página não é parecer jurídico e não substitui essa revisão.

Decisões abertas

O que ainda não está fechado, com o critério que vai fechar cada ponto. A pesquisa completa fica no repositório, em research/.

Pauta de decisão conjunta.
TemaPerguntaCritérioStatus
MemóriaMem0, Cognee, grafo temporal ou Markdown versionado?Proveniência, exclusão por titular e custo de operação.Markdown + Postgres na fase 1
OrquestraçãoTemporal, n8n ou fila simples?Precisa de execução durável com aprovação humana?pg-boss agora, Temporal na fase 2
IdentidadeKeycloak, Authentik ou conta de serviço por agente?SSO, RBAC e auditoria sem Kubernetes.em avaliação
SegredosInfisical, OpenBao ou SOPS com age?Rotação, trilha de acesso e operação por uma pessoa.em avaliação
PublicaçãoPostiz, Mixpost ou publicação manual?Licença, API oficial e aprovação registrada.em avaliação
Second brainFerramenta dedicada ou Markdown com git?Curadoria humana e busca confiável.em avaliação

Roadmap em três fases

Fase 1: fundação

Ficha de agente, catálogo de prompts, ROPA do piloto, Langfuse com retenção e máscara, LiteLLM com teto por projeto, MCPs read-only de GLPI, Rocket.Chat e Metabase, pg-boss e segredos com SOPS + age.

Fase 2: piloto

Três agentes de marketing, BPMN com aprovação humana, um canal próprio, medição no Metabase e relatório de decisão em 30 dias.

Fase 3: escala

Memória com proveniência, identidade por agente, orquestração durável e avaliação automatizada. Só entra o que sobreviveu ao piloto.

O que avaliar primeiro

A ordem importa mais que a ferramenta. Primeiro o processo e o contrato de dados, depois a memória, por último a orquestração. Ferramenta escolhida antes do processo vira dívida.

Se você quer discutir esta arquitetura, o ponto de partida é a política de LGPD e o piloto de marketing. O resto é consequência.