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.
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.
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.
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.
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.
Um fato guardado precisa dizer de onde veio, quem pode ler, quando expira e como é apagado. Memória sem proveniência é passivo de LGPD.
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.
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 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.
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.
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.
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.
O piloto termina com um relatório de decisão: manter, ajustar ou encerrar. Nada vira rotina por inércia.
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.
| Tipo | O que guarda | Prazo | Dono | Risco 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. |
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.
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.
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.
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ção | Licença | Encaixe | Decisão |
|---|---|---|---|
| pg-boss + Postgres | MIT | Fila com retry e agendamento, sem serviço novo | fase 1 |
| Temporal | MIT | Execução durável, replay, updates e schedules | fase 2, com gatilhos |
| Restate | BUSL 1.1 | Binário único, boa DX | fora pelo licenciamento |
| Inngest | SSPL 1.0 | Excelente DX, self-host | fora pelo licenciamento |
| Windmill | AGPL + trechos proprietários | Scripts e fluxos | em avaliação com ressalva |
| n8n | Sustainable Use (fair-code) | Automação visual | opcional, sem revenda |
| Flowise | Apache-2.0 | Camada de agente | fora, projeto encerrado em 2026 |
| Camunda 8 | Licença paga em produção | BPMN com execução | fora do critério |
Dois ou mais destes, registrados em ADR:
run_id propagado do primeiro passo ao último.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.
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.
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.
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 · adotadoTraces, 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 ressalvasContrato de instrumentação em gen_ai.*. É o que permite trocar o painel sem reescrever agente.
Chamados, projetos, tarefas e aprovação. Formulários nativos, webhooks e 2FA na versão 11.
GPL-3.0 · adotadoCanal humano e fonte de contexto. O MCP lê salas e mensagens; escrita fica desligada por padrão.
MIT no núcleo · adotadoLeitura de indicadores. O MCP executa apenas cards existentes, nunca SQL gerado pelo modelo.
AGPL-3.0 · adotadoBlog próprio do piloto, com editor para quem não é técnico. Alternativa estática: Astro.
MIT · recomendado no pilotoAnalytics sem cookies, com hash de sessão e salt mensal. Menos peso de LGPD que um analytics tradicional.
MIT · recomendado no piloto| Ferramenta | Licença | Papel | Decisão |
|---|---|---|---|
| LiteLLM | MIT (núcleo) | Gateway de modelos | adotado |
| Langfuse | MIT (núcleo), EE pago | Observabilidade e avaliação | adotado com ressalvas |
| OpenTelemetry | Apache-2.0 | Contrato de trace | adotado |
| GLPI | GPL-3.0 | Chamados e aprovação | adotado |
| Rocket.Chat | MIT (núcleo) | Canal e contexto | adotado |
| Metabase | AGPL-3.0 | BI e indicadores | adotado |
| Ghost | MIT | Blog do piloto | recomendado |
| Umami | MIT | Analytics sem cookie | recomendado |
| Listmonk | AGPL-3.0 | Newsletter | recomendado |
| Postiz | AGPL-3.0 | Publicação social | recomendado, com plano manual |
| Nextcloud | AGPL-3.0 | Arquivos e versões | recomendado |
| Penpot | MPL-2.0 | Design | recomendado |
| HyperFrames | Apache-2.0 | Vídeo programático | recomendado |
| Keycloak | Apache-2.0 | Identidade e token exchange | fase 2 |
| SOPS + age | MPL-2.0 / BSD-3 | Segredos no Git | fase 1 |
| OPA | Apache-2.0 | Política de acesso | fase 2 |
| pg-boss | MIT | Fila e retry | fase 1 |
| Temporal | MIT | Execução durável | fase 2, com gatilhos |
| n8n | Sustainable Use (fair-code) | Automação | opcional, sem revenda |
| Bloks | FSL-1.1-MIT (source-available) | Runtime de agentes | fora do critério OSI |
| OpenBot | PolyForm Noncommercial | Runtime de agentes | fora do uso comercial |
| Backstage | Apache-2.0 | Catálogo de agentes | fora na fase 1 (6 GB) |
| Infisical | MIT (núcleo), EE pago | Segredos | fora na fase 1 (4 GB+) |
| Remotion | Licença própria, não OSI | Vídeo | evitar acima de 3 pessoas |
| LangSmith, Lunary, Helicone | Proprietário ou descontinuado | Observabilidade | fora |
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.
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.
Objetivo, engine, modelo, dono, ferramentas, dados permitidos, teto de custo, critério de desligamento e versão do prompt.
Finalidade, base legal, categorias de dado, origem, compartilhamento, retenção e medidas de segurança. Uma linha por operação com agente.
Desenho com raias, tarefas, aprovações e pontos de parada. Versão no repositório, não em imagem solta no chat.
Decisão de arquitetura com contexto, alternativas, escolha e consequência. Serve para explicar por que não se usa tal fornecedor.
O que fazer quando o agente falha, o gateway cai ou um trace mostra vazamento. Passos, responsável e prazo.
Prompts versionados com dono, caso de uso, modelo testado e avaliação. Prompt fora do catálogo não vai para produçã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.
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.
A política completa está em lgpd.jatoba.tech. Aqui ficam os controles que a operação com agentes acrescenta.
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.
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/.
| Tema | Pergunta | Critério | Status |
|---|---|---|---|
| Memória | Mem0, Cognee, grafo temporal ou Markdown versionado? | Proveniência, exclusão por titular e custo de operação. | Markdown + Postgres na fase 1 |
| Orquestração | Temporal, n8n ou fila simples? | Precisa de execução durável com aprovação humana? | pg-boss agora, Temporal na fase 2 |
| Identidade | Keycloak, Authentik ou conta de serviço por agente? | SSO, RBAC e auditoria sem Kubernetes. | em avaliação |
| Segredos | Infisical, OpenBao ou SOPS com age? | Rotação, trilha de acesso e operação por uma pessoa. | em avaliação |
| Publicação | Postiz, Mixpost ou publicação manual? | Licença, API oficial e aprovação registrada. | em avaliação |
| Second brain | Ferramenta dedicada ou Markdown com git? | Curadoria humana e busca confiável. | em avaliaçã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.
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.
Memória com proveniência, identidade por agente, orquestração durável e avaliação automatizada. Só entra o que sobreviveu ao piloto.
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.