O que minha pilha agente realmente faz

Minha pilha de agentes é como eu faço dogfood Neotoma. É também meu sistema operacional pessoal. Um monorepo privado onde agentes de IA cuidam de tudo, desde triagem de e-mail até pagamentos em Bitcoin e implantações de sites, com Neotoma como memória estruturada por baixo.

Cada recurso que envio no Neotoma é validado aqui primeiro, principalmente no Cursor e secundariamente por meio de agentes de terminal como Claude Code, Codex e Cursor CLI. Cada lacuna que encontro na memória do agente surge aqui primeiro. A pilha é como administro minha vida diária e trabalho. O atrito que encontro, além do feedback dos usuários, é o que impulsiona o roteiro do Neotoma.

Pretendo abrir o código-fonte da pilha. Mas o repositório acumulou meses de dados pessoais, scripts codificados em minhas contas e configurações vinculadas à minha configuração. Antes que ele possa se tornar público, preciso inserir esses dados totalmente no Neotoma e refatorar as ferramentas para serem genéricas. Esse trabalho está em andamento.

Esta postagem explica o que é a pilha, como eu a uso e o que ela revela sobre o que a memória do agente estruturado precisa fazer.

O que é a pilha

A pilha é um monorepo com mais de uma dúzia de servidores e CLIs MCP, cada um conectando agentes de IA a um serviço diferente: Gmail, Google Calendar, WhatsApp, uma carteira Bitcoin, Instagram, Asana, HomeKit, DNSimple, Google Search Console, 1Password, um web raspador e muito mais. Alguns são servidores MCP que os agentes chamam de ferramentas. Outros são CLIs que os agentes invocam no terminal. Ambos oferecem aos agentes a mesma coisa: acesso a serviços externos.

No topo dos servidores MCP estão regras e habilidades. As regras são instruções comportamentais persistentes que residem no repositório, não no Neotoma: sempre armazene contatos no Neotoma antes de responder, nunca comprometa segredos, use maiúsculas e minúsculas nos títulos, execute testes após alterações de código, prefira CLI em vez de painel para logs e configuração, vincule a primeira menção de nomes de produtos. As habilidades são fluxos de trabalho de várias etapas: fazer a triagem da minha caixa de entrada, redigir uma postagem no blog, implantar um site, processar feedback do produto, extrair um pedido da Amazon do e-mail, pagar um empreiteiro em Bitcoin.

E por baixo de tudo fica Neotoma como a camada de memória estruturada. Cada agente lê e escreve nele. É isso que faz com que a pilha se componha ao longo do tempo, em vez de ser redefinida a cada sessão.

Como eu trabalho com isso

Moro em Cursor. Meu dia é uma sequência de sessões de agente. Abro um novo agente, descrevo o que quero que seja feito e o agente executa usando os servidores MCP, regras e habilidades no espaço de trabalho. Algumas sessões são rápidas: “responda a este e-mail”. Alguns são longos: "faça a triagem da minha caixa de entrada, processe o feedback mais recente do testador e, em seguida, elabore uma postagem comparativa sobre o agente de memória do Google."

É coworking com agentes. Sento-me na minha mesa e trabalho ao lado deles o dia todo. Tarefas pessoais: agendar um reparo, pagar um empreiteiro, gerenciar eventos do calendário. Profissionais: escrever posts, processar feedback, implantar sites, gerenciar domínios. Os agentes cuidam da execução. Eu forneço orientação, reviso os resultados e aprovo ações que precisam de um humano no circuito.

Cada sessão do agente possui o contexto completo do espaço de trabalho: cada servidor MCP, cada regra, cada habilidade. O agente pode ler meu Gmail, verificar meu calendário, consultar o contexto anterior do Neotoma, armazenar novos dados, gerar imagens, enviar código e verificar implantações. Minha função é cada vez mais descrever a intenção e revisar os resultados.

Como o Neotoma se encaixa

Sem memória estruturada, cada sessão do agente começa do zero. O agente não sabe quem são seus contatos, quais tarefas você tem em aberto, o que você discutiu ontem ou quanto já pagou a alguém. Você pode colar o contexto em cada prompt, mas isso não passa de algumas sessões. Memória da plataforma armazena sua vibração, não seu trabalho. RAG ajuda com o código, mas não com os fatos estruturados que impulsionam os fluxos de trabalho: a quem você deve dinheiro, que feedback você recebeu na semana passada, quais tarefas ainda estão abertas.

Minha instância do Neotoma armazena mais de 1.000 contatos, 600 tarefas, 140 conversas, 120 postagens de blog e 170 tipos de entidades que os agentes criaram à medida que encontravam novos tipos de informações: transações, regras permanentes, notas de feedback, eventos de calendário, disputas, faturas, habilidades, resultados de implantação. Quando um agente inicia uma nova sessão, ele recupera o que precisa. Quando termina, armazena o que aprendeu.

Aqui estão os 20 principais tipos de entidade em minha instância do Neotoma hoje, com um exemplo de cada:

Nenhum desses esquemas foi projetado antecipadamente. Agentes criam e estendem esquemas conforme necessário à medida que encontram novos tipos de informações. O sistema agora possui um total de 170 tipos de entidade, a maioria com apenas alguns registros. A cauda longa é onde a memória do agente se torna interessante: uma única entidade em disputa com seu histórico completo de negociações, um único compromisso de acompanhar alguém caso a estratégia mude, uma única preferência sobre como lidar com um pagamento específico.

A diferença prática é que os agentes baseiam-se no trabalho anterior. Quando peço a um agente para enviar um e-mail para alguém, ele primeiro procura o contato em Neotoma. Quando peço para processar feedback, ele recupera entidades de feedback existentes e vincula novas. Quando peço para pagar um contratante em Bitcoin, ele conhece a regra permanente (sempre pague essa pessoa em BTC) e inclui o link da transação na confirmação porque outra regra permanente diz para fazê-lo.

Armazenamento e recuperação de perto

O Neotoma MCP expõe ferramentas que os agentes chamam diretamente. Aqui está como é o armazenamento e a recuperação reais na prática.

Quando um agente precisa persistir uma conversa com entidades extraídas, ele chama store com uma única carga útil:

armazenar({
  "entidades": [
    {
      "entity_type": "conversa",
      "title": "Triagem de e-mail em 9 de março"
    },
    {
      "entity_type": "agent_message",
      "função": "usuário",
      "content": "triagem minha caixa de entrada",
      "turn_key": "conv-42:1"
    },
    {
      "entity_type": "contato",
      "nome_completo": "Alex Chen",
      "e-mail": "alex@example.com",
      "source": "chamada de feedback do testador"
    },
    {
      "entity_type": "tarefa",
      "title": "Acompanhe o feedback de Alex",
      "status": "pendente",
      "prioridade": "médio"
    }
  ],
  "relacionamentos": [
    {
      "relationship_type": "PART_OF",
      "índice_fonte": 1,
      "índice_alvo": 0
    },
    {
      "relationship_type": "REFERS_TO",
      "índice_fonte": 1,
      "índice_alvo": 2
    },
    {
      "relationship_type": "REFERS_TO",
      "índice_fonte": 1,
      "índice_alvo": 3
    }
  ],
  "idempotency_key": "conv-42-turn-1-triage"
})

Uma chamada armazena a conversa, a mensagem, um novo contato e uma tarefa, todos vinculados por relacionamentos digitados. O agente não precisava de uma definição de esquema para contato ou tarefa antecipadamente. Neotoma aceita campos arbitrários e infere estrutura.

Quando um agente precisa de contexto antes de responder, ele consulta por identificador:

retrieve_entity_by_identifier({
  "identificador": "Alex Chen"
})

Isso retorna o registro do contato com email, conversas anteriores e a procedência de cada campo. Se o agente precisar de um contexto mais amplo, ele consulta por tipo:

recuperar_entidades({
  "entity_type": "feedback_note",
  "search": "versão do desenvolvedor",
  "limite": 10
})

Isso retorna as dez notas de feedback mais relevantes sobre o lançamento do desenvolvedor, cada uma com seu instantâneo completo e histórico de observações.

Para regras permanentes, o agente as recupera uma vez no início de um fluxo de trabalho:

recuperar_entidades({
  "entity_type": "stand_rule"
})

Minha instância retorna regras como “sempre pague Carlos em Bitcoin” e “forneça mensagens redigidas em blocos de descontos”. O agente aplica-os automaticamente durante o resto da sessão.

Quando os fluxos de trabalho tocam em arquivos (recibos, capturas de tela, documentos), o agente os armazena junto com entidades na mesma chamada usando file_path:

armazenar({
  "entidades": [
    {
      "entity_type": "transação",
      "fornecedor": "Amazônia",
      "valor": 47,99,
      "moeda": "EUR"
    }
  ],
  "file_path": "/caminho/para/recibo.pdf",
  "idempotency_key": "amazon-order-march-9"
})

O caminho de armazenamento não estruturado do Neotoma gerencia o arquivo a partir daí. Os bytes brutos são endereçados ao conteúdo (SHA-256) para que o mesmo arquivo nunca seja armazenado duas vezes. O agente passa o arquivo como está via file_path (ambientes locais como Cursor) ou file_content (base64, para ambientes baseados na web); ele não interpreta ou extrai dados antes de armazená-los. Por padrão, o Neotoma executa automaticamente a interpretação de IA no arquivo armazenado, extraindo entidades estruturadas e vinculando-as de volta à fonte com um relacionamento EMBEDS. Restaurar o mesmo arquivo com interpret: true aciona a reinterpretação sem criar uma duplicata. O recibo torna-se um dado estruturado consultável com o PDF original preservado para procedência. A interpretação também pode ser adiada (interpret: false) para processamento em lote ou gerenciamento de cotas e, em seguida, executada posteriormente com configuração diferente.

Fluxos de trabalho na prática

Alguns fluxos de trabalho mostram o padrão.

Triagem de e-mail. O agente lê e-mails não lidos via Gmail MCP, verifica o Neotoma em busca de registros de contato existentes e contexto anterior com cada remetente, rascunha respostas usando minhas regras de estilo de comunicação, armazena novos contatos e tarefas e arquiva mensagens processadas. Uma única triagem pode armazenar cinco novos contatos, três tarefas e uma dúzia de conversas.

Escrita de postagem no blog. A habilidade em si reside em Neotoma como uma entidade estruturada. O agente o recupera com retrieve_entity_snapshot. Em seguida, ele consulta as postagens existentes para calibração de estilo, escreve o rascunho, armazena a entidade da postagem com todos os metadados, gera imagens principais, cria uma cópia de compartilhamento para Twitter e LinkedIn, regenera o cache do site a partir da exportação do Neotoma e implanta. Este post foi escrito dessa forma.

Pagamentos em Bitcoin. Eu pago um empreiteiro em Bitcoin usando um servidor MCP de carteira BTC. Neotoma armazena a regra permanente, o registro de contato e o histórico de transações. O agente recupera todos os três, executa o pagamento, armazena a nova transação no link da rede e confirma.

Processamento de feedback. Quando os testadores fornecem feedback sobre a versão do desenvolvedor do Neotoma, os agentes extraem entidades de feedback estruturadas, vinculam-nas ao registro de contato do testador, classificam o feedback por grupo e avaliam-no em relação às restrições do estágio de lançamento. O feedback anterior pode ser recuperado por testador, por intervalo ou por data.

Implantação do site. A habilidade de implantação sincroniza edições de markdown locais para o Neotoma, exporta o conjunto de dados completo do site, regenera o cache, envia o repositório do site e monitora Ações do GitHub até que a compilação seja bem-sucedida. Se a compilação falhar, o agente lê os logs, corrige o problema e executa novamente.

Para agentes que funcionam sem mim

Todo fluxo de trabalho começa comigo abrindo um agente Cursor e digitando uma instrução. Estou atualizado para todas as tarefas. Isto é bom para a fase actual, mas não é o estado final.

Estou configurando processos automatizados para que os agentes possam lidar com fluxos de trabalho sem meu envolvimento direto. As peças já estão aí: as habilidades definem todas as etapas do fluxo de trabalho, o Neotoma armazena o contexto e as regras, os servidores MCP fornecem o alcance. O que falta é a orquestração que aciona fluxos de trabalho dentro do cronograma ou em resposta a eventos, e uma interface de aprovação leve para que eu possa revisar e autorizar ações sem precisar ficar sentado em frente ao meu laptop.

A arquitetura em camadas do Neotoma foi projetada exatamente para isso. Ele separa três preocupações:

1. Camada verdade (Neotoma). Origem de evento, orientada por redutor, determinística. Todos os agentes lêem isso. As atualizações de estado fluem apenas através de eventos de domínio processados ​​por redutores. Nenhum agente modifica a verdade diretamente.
2. Camada de estratégia. Lê o estado mundial atual de Neotoma. Avalia prioridades, restrições, riscos, compromissos e tempo. Emite decisões e comandos. Cognição pura: estado dentro, decisões fora. Sem efeitos colaterais.
3. Camada de execução. Recebe comandos da camada de estratégia. Executa efeitos colaterais por meio de adaptadores externos (APIs de e-mail, serviços de pagamento, calendário, mensagens). Emite eventos de domínio descrevendo o que aconteceu. Esses eventos fluem de volta através dos redutores para atualizar o estado. Efeito puro: entrada de comandos, saída de eventos.

O ciclo está fechado:

Sinais de entrada (e-mail, WhatsApp, calendário, dados financeiros)
  -> Normalização -> Estado Neotoma (log de eventos + redutores)
  -> Carrapato de estratégia (avaliar prioridades, decisões de resultados)
  -> Agentes de execução (realizam efeitos colaterais, emitem eventos)
  -> Redutores -> Estado atualizado
  -> Próximo tick

Hoje, sou a camada de estratégia. Eu olho para o estado, decido o que fazer e digo a um agente para executar. A arquitetura torna essa função substituível por software. Um mecanismo de estratégia lê Neotoma, avalia o que precisa de atenção com base em regras e prioridades vigentes e emite comandos para agentes de execução. Esses agentes chamam os servidores MCP, armazenam os resultados e o ciclo se repete.

A invariante crítica é que nenhuma camada grava diretamente no armazenamento de dados subjacente do Neotoma. As atualizações fluem apenas por meio de eventos e redutores de domínio. Isso torna o sistema auditável e reversível. Se um agente autônomo tomar uma decisão errada, posso rastrear o evento que a causou, reverter a atualização do estado e corrigir a regra que levou a isso.

O objetivo é reduzir meu tempo diário no computador. Não eliminá-lo. Mude da execução prática para a revisão e aprovação. Quero acordar com um resumo do que meus agentes trataram durante a noite: e-mails triados, postagens redigidas, implantações verificadas, pagamentos em fila. Quero aprovar um pagamento em Bitcoin do meu Apple Watch. Quero revisar um rascunho de e-mail no meu telefone enquanto caminho e toco para enviar. Os agentes cuidam dos 80% que são repetíveis. Eu cuido dos 20% que precisam de julgamento.

É aqui que a questão do hardware fica interessante. Os telefones e relógios atuais não foram projetados para esse padrão de interação. Você precisa de um dispositivo otimizado para breves gestos de revisão e aprovação, não para digitação ou navegação.

Dos dispositivos que existem hoje, o Apple Watch parece o que mais se aproxima do formato certo: sempre no seu pulso, visível, capaz de interações simples de tocar para aprovar. Mas a camada de software ainda não existe. Não há como encaminhar resumos de agentes e solicitações de aprovação para o relógio de uma forma que pareça nativa.

Essa pode ser uma área para eu experimentar em algum momento, construindo um aplicativo complementar leve que conecta o estado do Neotoma a uma interface no nível do pulso. Quer a superfície certa acabe sendo um aplicativo de observação, um dispositivo de IA dedicado ou algo que ainda não existe, o modelo de interação é claro: os agentes fazem o trabalho, a memória estruturada mantém o estado e o ser humano fornece orientação no ritmo da intenção, e não no ritmo da execução.

Abra o código da pilha

A pilha hoje é privada porque contém minha vida: contatos, finanças, dados de saúde, comunicações pessoais, regras permanentes sobre como administro minha casa. Antes de poder abrir o código-fonte, preciso desembaraçar tudo isso.

O caminho é direto. Os dados pessoais são transferidos integralmente para o Neotoma, que já é a fonte da verdade para a maior parte deles. Os scripts que fazem referência às minhas contas e caminhos específicos são refatorados para serem lidos na configuração. Os wrappers do servidor MCP tornam-se genéricos. As habilidades perdem suas suposições codificadas.

O que resta é uma pilha de agentes reutilizável: um modelo monorepo com estrutura de servidor MCP, uma estrutura de regras e habilidades, integração Neotoma para memória estruturada e exemplos de fluxos de trabalho que qualquer pessoa pode adaptar. A arquitetura é a parte interessante. Meus dados pessoais não são.

Não tenho um cronograma para isso. A refatoração acontece junto com o uso diário. Cada vez que toco em um script, torno-o mais genérico. Cada vez que movo dados para o Neotoma, eu os removo do repositório. A pilha fica mais portátil a cada sessão.

O que isso prova sobre Neotoma

Eu construí esta pilha antes de Neotoma existir. A versão anterior usava arquivos simples e tabelas Parquet. Funcionou até que não funcionou.

Os modos de falha eram específicos: um agente armazenava um contato como “Sarah Kim” em uma sessão e “S. Kim” em outra, criando duplicatas sem nenhuma maneira de mesclá-los. Não havia procedência, então não pude dizer qual agente escreveu um campo ou quando.

As consultas eram limitadas a correspondências exatas em colunas únicas, portanto, perguntar "que feedback recebi na semana passada?" significava verificar cada arquivo manualmente. Ocasionalmente, os registros eram sobrescritos incorretamente ou totalmente excluídos, sem nenhum registro de eventos para recuperação. E nada vinculado entre tipos, portanto, saber que uma tarefa relacionada a um contato relacionado a uma transação exigia que eu mantivesse aquele gráfico em minha cabeça.

Neotoma substituiu essa camada. Ele deu aos agentes uma memória estruturada, consultável e com reconhecimento de relacionamento que funciona em todos os fluxos de trabalho. A pilha agora tem 170 tipos de entidades no Neotoma, não porque eu projetei 170 esquemas antecipadamente, mas porque os agentes criam tipos de entidades à medida que encontram novos tipos de informações. Uma nota de feedback é diferente de uma transação, é diferente de uma regra permanente, e o sistema lida com todas elas.

Esta é a dogfooding que mantém Neotoma honesto. Quando a recuperação é lenta, sinto isso em todas as sessões do agente. Quando a resolução da entidade falha, recebo contatos duplicados. Quando o armazenamento não é confiável, os fluxos de trabalho são interrompidos. Cada bug e cada lacuna aparecem no meu trabalho diário antes de aparecerem no de qualquer outra pessoa.

O problema da memória é universal. Todo desenvolvedor que cria fluxos de trabalho de agentes irá se deparar com o mesmo obstáculo: agentes que não conseguem se lembrar, não conseguem consultar e não conseguem desenvolver trabalhos anteriores. A recuperação por si só não é suficiente; estrutura e proveniência são o que tornam a memória confiável. Essa pilha é a prova de que a memória estruturada muda o que os agentes podem fazer. Neotoma é como estou disponibilizando isso para todos.

A versão do desenvolvedor está aberta para testes. Se você está construindo fluxos de trabalho de agente e deseja memória estruturada por baixo, é por aí que começar.