Há alguns meses, escrevi sobre [my agentic stack](/posts/what-my-agentic-stack-actually-does): um monorepo privado onde agentes de IA lidam com meus e-mails, pagamentos e implantações, com [Neotoma](https://neotoma.io) como a memória estruturada abaixo. Essa postagem terminou com uma promessa. Eu disse que era a camada estratégica e que a arquitetura foi projetada para tornar essa função substituível por software. Este é o post sobre como fazer isso.

[Ateles](https://github.com/markmhendrickson/ateles) é meu segundo produto, depois do Neotoma, e é construído diretamente sobre ele. É um enxame de agentes pessoais. Enquanto a pilha antiga era um agente por sessão comigo no circuito para cada tarefa, Ateles é uma frota permanente de agentes definidos por função, coordenados pelo Neotoma, funcionando diariamente sob lançamento. É a diferença entre eu dirigir cada agente e dirigir uma equipe que já conhece o seu trabalho.

Esta postagem explica por que eu o construí, como funciona e para onde está indo.

## Por que a pilha parou de escalar

O gatilho foi o volume. Após o [lançamento do desenvolvedor](/posts/neotoma-developer-release) no final de fevereiro, minha atenção se dividiu em três modos que não compartilham muito: construir o produto, comercializá-lo e gerenciar relacionamentos com os primeiros usuários. Eu também estava alimentando Neotoma com cada vez mais contexto sobre minha vida, profissional e pessoalmente, e quanto melhor essa memória ficava, mais qualquer agente poderia fazer com ela. Isso não removeu a restrição, apenas a moveu. O limite não era mais o que os agentes conheciam. Fui eu, o único a transformar o que eles sabiam em ação, uma sessão de cada vez.

A abordagem antiga era um conjunto de regras e habilidades específicas do repositório. Eles me permitiram evitar me repetir no procedimento. Uma habilidade definia as etapas para triagem de e-mail ou implantação de site, e qualquer sessão poderia executá-la no contexto já existente no Neotoma. Isso funcionou até as sessões ficarem ocupadas.

A falha foi específica. Quando um agente genérico exerce todas as regras e todas as funções ao mesmo tempo, ele não exerce todas elas de maneira uniforme. A qualquer momento, ele se inclina para um tipo de trabalho e deixa o resto passar. Ele redige bem o e-mail e esquece a regra vigente sobre como eu assino. Ele corrige o bug e ignora o teste de regressão. Também não houve verificação contraditória. Um agente planejou, executou e revisou seu próprio trabalho, sem nada para detectá-lo quando estava confiantemente errado.

Mais duas coisas seguiram na mesma direção. Mudei minhas operações de produto para o GitHub por padrão, usando problemas e pull requests em vez de confirmar diretamente no main. Isso foi parcialmente forçado pelo [pipeline de problemas que construí](/posts/agent-to-agent-issue-resolution-with-humans-at-the-edges), que começou a encaminhar relatórios reais de usuários e seus agentes para o Neotoma e para o GitHub. E eu queria que meu processo de desenvolvimento fosse legível em público, para que as pessoas que usavam o Neotoma pudessem ver exatamente o que estava sendo feito. Ambos desejam uma sequência de agentes especializados em design, gerenciamento de produtos, controle de qualidade e lançamento. Um agente fazendo tudo isso anula a questão.

Então Ateles é a decisão de criar uma frota e definir essa frota na própria Neotoma.

## Neotoma como tecido, não apenas como memória

O movimento que diferencia Ateles é que Neotoma segura duas coisas ao mesmo tempo. Ele contém o contexto operacional que o enxame precisa, os mesmos fatos que minha antiga pilha lia e escrevia. E mantém o próprio enxame.

Os agentes são entidades Neotoma. Cada um é uma `agent_definition` com um prompt, uma lista de permissões de ferramentas e um conjunto de concessões de capacidade. Atualizar o comportamento de um agente é uma chamada `correct()` contra essa entidade, com histórico completo da versão e atribuição do autor. Sem confirmação, sem reimplantação. Os arquivos SKILL.md no disco são espelhos gerados dessas entidades, não da origem.

Seus relacionamentos também são entidades Neotoma. O enxame possui uma hierarquia, expressa como uma árvore, de modo que um coordenador sabe quais agentes ele despacha e uma tarefa sabe qual agente o possui. E o trabalho em si são entidades do Neotoma: tarefas, planos, definições de fluxo de trabalho, registros de participação. Um agente pega uma tarefa, executa-a e escreve o resultado como uma observação atribuída à sua identidade.

O resultado é um gráfico mundial para tudo. Os fatos sobre os quais o enxame atua, a definição do enxame que atua sobre eles e o registro do que ele fez residem no mesmo armazenamento somente de anexos. Isso dá ao todo três propriedades que me interessam. É transparente, porque cada ação é uma observação atribuída que você pode ler. É auditável porque você pode reproduzir as ações de qualquer agente em qualquer janela. E é reversível, porque nada substitui a verdade no lugar. Se um agente fizer uma chamada incorreta, posso rastrear o evento que a causou, reverter o estado e corrigir a regra que levou a isso, uma vez.

A identidade é a peça que torna a atribuição real, em vez de aspiracional. Cada agente tem um par de chaves [AAuth](/posts/know-what-of-your-agents-wrote-what) e assina cada chamada de ferramenta. O chicote verifica a assinatura antes de agir e registra quem afirmou agir ao lado de quem realmente agiu no GitHub. Um agente criador de códigos não age mais apenas como eu. Ele age como ele mesmo, e o log diz isso.

## Os agentes, por função

O enxame é organizado em camadas. T1 é o host: o processo que possui um canal e gera os agentes, atualmente OpenClaw para aqueles com quem converso e launchd para os de segundo plano. É uma infraestrutura, não um agente com uma função. Os próprios agentes funcionam em três níveis. Os agentes T2 estão sempre disponíveis e têm uma personalidade: o próprio Ateles é com quem converso e é o único agente que me chama. Daemons T3 são processos em segundo plano orientados a eventos sem persona, cada um inscrito em eventos Neotoma ou em um webhook externo. Os agentes T4 são apátridas, gerados por tarefa, com identidade e memória estáveis ​​que obtêm ao consultar Neotoma.

Algumas das funções que funcionam hoje:

**Produto.** Um daemon coordenador lê as definições de fluxo de trabalho do Neotoma e despacha os portões na ordem: design, gerenciamento de produto, controle de qualidade, lançamento. O trabalho do código vai para um trabalhador de problema que abre solicitações pull em repositórios. Cada solicitação pull recebe uma revisão básica de um agente revisor separado, com especialistas de domínio analisando os caminhos que possuem. O objetivo de separá-los é a verificação contraditória que o agente único nunca teve. Quem escreve o código não é quem o limpa.

**Finanças.** Um daemon de pagamento recorrente executa transferências Wise e Bitcoin acionadas por eventos de calendário e datas de vencimento de tarefas, com cada destinatário e valor carregado de entidades de perfil de pagamento em vez de código. Adicionar um novo pagamento recorrente é uma nova entidade, não um compromisso. Uma função de consultor financeiro e uma função fiscal e de arquivamento são definidas para orçamento e reconciliação.

**Jurídico e de conformidade.** Uma função jurídica abrange avaliação de riscos e revisão de termos. Uma função de conformidade abrange privacidade e governança de dados. Isso é mais importante no momento em que um enxame pode agir sobre os dados das pessoas, o que acontece com o meu.

**Estratégia.** Este é o papel que descrevi como meu no último post, e é aquele que estou entregando mais deliberadamente. Essa transferência é a versão concreta de um argumento que apresentei em [The Human Inversion](/posts/series/the-human-inversion): à medida que os agentes absorvem o meio de execução, a alavancagem do humano move-se para os fins, padrões mais nítidos entram e um julgamento mais denso sai. A autonomia é calibrada por plano, não globalmente. Uma entidade de política de execução declara, para um determinado plano, o que um agente está autorizado a fazer por conta própria, quais barreiras de qualidade ele deve superar e onde deve parar e verificar comigo antes de prosseguir. A cadeia de escalonamento vai do agente interino a um especialista de domínio, a um guardião da constituição e a mim, e cada resolução é escrita de volta como uma entidade para que a próxima instância herde o julgamento.

Atrás deles estão os daemons de ingestão e suporte que mantêm o gráfico alimentado: triagem de e-mail, importação de áudio, preparação de calendário, saúde e condicionamento físico, triagem de problemas. Cada um é um pequeno processo que transforma um sinal de entrada em entidades Neotoma nas quais o restante do enxame pode atuar.

## A espinha dorsal da tarefa

O que une a frota é o gerenciamento de tarefas, e é deliberadamente enfadonho. Uma tarefa é uma entidade. Tem um proprietário, um estado, uma prioridade e um registro de quem foi executado. Planeja tarefas de grupo e executa suas próprias decisões e próximos passos. As definições de fluxo de trabalho declaram as fases e os portões pelos quais um trabalho passa.

Como tudo isso está no mesmo armazenamento que todo o resto, o enxame é coordenado sem um banco de dados de orquestração separado. Um daemon assina eventos de tarefas no fluxo de eventos do Neotoma. Quando uma tarefa aparece, ela é encaminhada para o agente certo por domínio, atrás de um portão que avalia a confiança do agente em relação ao dano que uma ação errada poderia causar. Baixo raio de explosão e alta confiança funcionam por conta própria. Um alto raio de explosão espera por mim.

Esta é a espinha dorsal em torno da qual estou construindo o resto da experiência.

## Aonde isso vai dar

A interface que desejo é simples de indicar. Eu dou uma entrada ao enxame, através de qualquer transporte que esteja mais próximo, e o enxame a absorve e age. Um prompt em um terminal. Um e-mail. Uma mensagem de telegrama. Um memorando de áudio gravado em uma caminhada, que foi assim que começaram as notas deste post. Tudo isso deve cair no mesmo gráfico, e o enxame deve ser proativo em relação ao trabalho que isso implica, sem que eu segure a mão de nenhum agente.

Duas propriedades tornam isso possível. O enxame deve evoluir sozinho. À medida que assume novos contextos e novos tipos de trabalho, deverá fornecer as capacidades e desenvolver as competências de que necessita, adaptando-se às minhas correções em vez de esperar que eu o reconfigure manualmente. E a minha contribuição, ainda necessária em momentos que realmente necessitam de julgamento, nunca deveria ser dada duas vezes. Corrijo uma maneira de fazer as coisas uma vez, ela se torna uma entidade e a correção se mantém.

O roteiro mais próximo é sobre alcance. O Ateles foi construído para meu próprio uso, então boa parte dele ainda pressupõe um operador, eu. Estou [conduzindo-o para ser instalável e multioperador](https://github.com/markmhendrickson/ateles/blob/main/docs/multi_tenant.md): um enxame que outra pessoa pode bifurcar, apontar para seu próprio Neotoma, fornecer suas próprias entidades de contexto e executar. Como os agentes são independentes do operador por política e nada específico do operador está incluído no código, o caso da bifurcação é principalmente uma questão de contexto, não de reescrita. O trabalho genuinamente novo é apoiar mais de um ser humano dentro de um único inquilino, e é por isso que o limite do inquilino é projetado agora, em vez de adaptado posteriormente.

Neotoma fez agentes que lembram, e Ateles é o que essa memória tornou possível: um enxame que pode agir sobre ele sem que eu esteja no meio de cada passo. Os dois sobem juntos. Melhor memória não é um problema resolvido que superei. É o substrato sobre o qual todo o enxame se apoia, e cada ganho no que Neotoma pode manter e resolver é um ganho no que o enxame pode fazer. A memória continua melhorando e o enxame continua melhorando com ela.