Um usuário cola o prompt de avaliação conduzido pelo agente em seu editor. O agente lê a [página de avaliação do Neotoma](https://neotoma.io/evaluate), verifica o fluxo de trabalho local, decide que o ajuste é forte, executa a instalação e armazena as primeiras entidades. Algum tempo depois, ocorre um bug real: um envio de entidade descarta silenciosamente um campo que o esquema aceita claramente. Um pouco mais tarde, ele percebe outra coisa: a recuperação em um gráfico de entidade grande é mais lenta do que deveria ser para o fluxo de trabalho que suporta. E mais tarde ainda, ao construir um loop de recuperação personalizado, ele percebe que está faltando na superfície do MCP uma operação em lote que tornaria o padrão que ele repete muito mais limpo. O usuário nunca perguntou sobre nada disso. O agente percebeu isso no caminho para fazer outra coisa.

A antiga forma daqueles momentos era o fim do ciclo. O usuário pode abrir o GitHub, colar o erro ou a solicitação, escrever um parágrafo de contexto e aguardar. A maioria não. Eles contornam o problema, o mantenedor nunca o vê e o próximo usuário atinge a mesma parede.

Neotoma agora possui um subsistema de problemas de primeira classe que opera através da mesma superfície MCP que cada agente já usa para armazenar e recuperar. O agente registra bugs, observações de desempenho e solicitações de melhorias sem sair da sessão e sem parar para perguntar por problema. Os agentes do mantenedor os coletam, fazem a triagem, geralmente resolvem e enviam. O agente do repórter lê o status e informa ao usuário quando algo acontece. Toda a troca acontece por meio de chamadas de ferramentas.

A avaliação liderada pelo agente descrita na [postagem de pesquisa do cliente](/posts/customer-research-through-agents) foi a metade inicial desse ciclo. O subsistema de problemas é a metade posterior. Ambas as metades são executadas no [substrato do sistema nervoso](/posts/from-memory-to-nervous-system) que descrevi anteriormente, e a capacidade de problemas é o exemplo mais claro da finalidade desse substrato.

## Por que o loop tem que fechar no lado do agente

O atrito é o assassino silencioso do feedback. O modelo antigo presumia que o usuário traduziria sua experiência em um relatório em um sistema separado: mudaria de contexto, encontraria o repositório, analisaria um modelo de problema, escreveria antecedentes suficientes para que um mantenedor pudesse agir, anexar logs, esperar. Cada passo é uma chance de desistir. A maioria sim. E esse modelo cobre apenas problemas que o usuário percebeu. Não há caminho algum para problemas que o agente percebeu e que o usuário nunca apareceu.

O agente de um avaliador identificou que a ativação produziu um erro de hidratação quando a configuração do substrato apontava para uma instância auto-hospedada atrás de um túnel Cloudflare. O agente escreveu um resumo preciso, incluindo o endpoint com falha e os cabeçalhos de resposta. O usuário me encaminhou o resumo como uma mensagem. Reconstruí o contexto, encaminhei-o para meus agentes, enviei uma versão e enviei uma mensagem de volta ao usuário. O usuário pediu ao agente para verificar. Essa verificação levou cerca de noventa segundos. As etapas de retransmissão humana levaram dias.

O resumo original do agente era bom. Foi o contexto de reconstrução que comeu o tempo. Cada transferência entre um agente e um humano perde fidelidade. Cada transferência entre um humano e outro agente reconstrói o contexto do zero. Os ricos detalhes de autoria do agente são compactados em uma prosa concisa de autoria humana e, em seguida, um agente downstream precisa expandi-los novamente.

Quando o agente do usuário é aquele que bateu na parede — ou percebeu a lentidão, ou queria a capacidade que faltava — a etapa de tradução é gratuita. O agente já tem o contexto: em qual ferramenta ele estava sendo executado, a chamada exata do MCP que falhou ou pareceu estranha, a carga útil da resposta, o git SHA ou a versão do aplicativo da instalação do Neotoma, o tipo de entidade envolvida. Compõe um relatório coerente em uma chamada de ferramenta. As instruções do MCP dizem aos agentes para registrarem via `submit_issue` imediatamente quando um problema relatável ou oportunidade de melhoria for confirmado, sem parar para perguntar por problema – o prompt por problema não adiciona novas informações e interrompe o que o usuário estava fazendo. Os arquivos do agente. O usuário descobre isso mais tarde, ou nunca, dependendo se a mudança será enviada.

Do lado do mantenedor, o loop precisa ser fechado sem que eu leia todos os relatórios manualmente. Eu administro cerca de uma dúzia de agentes entre editores e daemons. Eles já processam o estado estruturado recebido. A forma natural é: chega um novo problema, o substrato sinaliza na gravação, um daemon de triagem capta o evento, lê o problema, decide se pode agir, abre uma árvore de trabalho, executa uma sessão de agente na base de código e resolve o bug ou pede esclarecimentos ao repórter através do mesmo thread.

Ambas as metades do loop funcionam como trabalho agente sobre o mesmo substrato. O agente do usuário usa o MCP para enviar. Os agentes do mantenedor usam o MCP para ler e responder. Ninguém precisa abrir um navegador.

## O que o agente faz no envio

A superfície do MCP é pequena o suficiente para ser enumerada. A ferramenta `submit_issue` leva um título, um corpo, um tipo de entidade se o problema for sobre um tipo específico de registro e um bloco de ambiente do repórter - o git SHA que o usuário está executando ou a versão do aplicativo, com o último preenchido automaticamente no lado do servidor quando o agente omite ambos. O ambiente do repórter tem mais peso do que parece; a próxima seção revela o porquê.

Os relatórios raramente chegam sem contexto. Um bug faz referência a entidades concretas: o registro específico que não foi armazenado, seu esquema, uma observação upstream. Uma solicitação de melhoria faz referência ao padrão de chamada que simplificaria ou ao tipo de entidade que tornaria a recuperação mais rápida. `submit_issue` e `add_issue_message` aceitam um array `entity_ids_to_link`, e o servidor cria relacionamentos `REFERS_TO` do novo problema para cada entidade referenciada atomicamente como parte da mesma chamada. O problema já está conectado ao gráfico de que se trata. O agente de triagem que lê o problema pode ir direto para a entidade que falhou.

O envio flui através do mesmo protetor de PII `scanAndRedact` que protege todas as superfícies públicas. Se o agente colar acidentalmente um token ou endereço de e-mail no corpo, ele será editado antes da persistência. As instruções do MCP exigem que os agentes apliquem a lista de verificação de PII ao título e ao corpo antes da chamada, mas a guarda do lado do servidor é a verdadeira linha de defesa. O repórter obtém um identificador numérico do problema e um token de leitura de convidado com um TTL explícito, com escopo definido para o thread que acabou de abrir. Esse token é como o agente do repórter lê o status posteriormente, sem autenticar novamente todas as vezes.

Da perspectiva do usuário: uma chamada de ferramenta, um identificador para rastrear e geralmente nenhuma solicitação de aprovação. Do ponto de vista do substrato: uma entidade estruturada foi escrita, os relacionamentos de entidade vinculada foram criados na mesma transação, uma linha de origem foi criada, uma concessão de convidado foi emitida e o pipeline de gravação emitiu um evento.

## Proveniência é o herói desconhecido

O requisito do ambiente do repórter parece um pequeno detalhe. É a mudança mais importante.

Antes da existência do subsistema de problemas, um relatório poderia ser enviado sem nenhuma referência à compilação em que foi criado. Isso é bom para um bilhete de papel. É catastrófico para um ciclo de triagem automatizado. Se um agente envia um bug no commit `abc1234` e meus agentes o corrigem no commit `def5678`, o agente do usuário precisa saber qual compilação verificar. Se um thread de depuração abrange três compilações, cada comentário deve registrar em qual compilação ele foi testado. O mesmo se aplica a uma solicitação de aprimoramento: saber qual versão o agente estava executando quando identificou a operação em lote ausente informa se a lacuna já foi abordada em uma compilação posterior ou se está genuinamente aberta. Sem procedência, o fio vira arqueologia.

`submit_issue` rejeita qualquer envio que não contenha `reporter_git_sha` e `reporter_app_version`. O envelope de rejeição lista explicitamente as alternativas:

```json
{
  "error_code": "ERR_REPORTER_ENVIRONMENT_REQUIRED",
  "detalhes": {
    "grupos_de_campos aceitáveis": [
      ["reporter_git_sha"],
      ["reporter_app_version"]
    ]
  }
}
```

`add_issue_message` aceita os mesmos campos e emite um aviso do servidor em threads públicos quando ambos estão faltando. Cada mensagem criada por um agente de depuração registra o build em teste.

A razão pela qual isso é importante para o tratamento entre agentes é que permite que o lado receptor classifique o relatório antes de realizar qualquer trabalho. Para um bug: o usuário executou uma versão publicada? Ramifique de `main` e abra um PR. Um commit específico em um branch de recurso? Crie uma árvore de trabalho nesse commit, reproduza e relate as descobertas sem modificar a linha principal. Seu próprio garfo? Publique um acompanhamento estruturado solicitando a fonte do patch. Para uma melhoria: o recurso solicitado já está em uma filial ou está realmente faltando? Isso entra em conflito com uma restrição de design que o agente que o preenche não consegue ver? A classificação determina a resposta – e nada disso é possível sem proveniência.

A proveniência é o que transforma um relatório de formato livre em um evento roteável, seja ele descrevendo algo quebrado ou faltando.

## O que acontece do lado do mantenedor

Meu daemon de triagem se inscreve para emitir eventos de criação por meio das mesmas ferramentas de “assinatura” que qualquer outro consumidor usaria. Os webhooks vêm em primeiro lugar porque funcionam para daemons remotos em um VPS, bem como para processos locais em meu laptop; SSE é aditivo. O substrato mantém o registro, entrega o evento e esquece. O daemon decide.

O daemon que executo para isso se chama Formica. Gênero _Formica_, formigas. Cada subagente é um trabalhador que transporta uma parte do trabalho do log de eventos para uma correção.

O que faz, na prática: leia a edição. Puxe as entidades vinculadas pelo agente do repórter no momento do envio, pois os relacionamentos já estão no gráfico. Espelhe para o repositório GitHub upstream se ele justificar uma trilha pública, com redação de PII aplicada no limite da API e qualquer problema cujo título ou corpo ainda corresponda a um padrão de redação rejeitado antes de cruzar a linha. Classifique se o relatório é um bug ou uma melhoria. Para bugs: decida se ele é reproduzível apenas no ambiente do repórter e, em seguida, passe para uma habilidade `/process-issues` que abre uma árvore de trabalho, executa uma sessão de agente e tenta uma correção. Para melhorias: sintetize uma entidade de plano que agregue a solicitação com quaisquer questões abertas relacionadas e apresente-a para revisão humana, em vez de tentar uma implementação autônoma. Se for necessário mais contexto para qualquer tipo, poste uma pergunta esclarecedora através de `add_issue_message` para que o agente do repórter a receba na próxima leitura de status.

A habilidade `/process-issues` impulsiona a correção real. O contrato é curto. Para cada questão em aberto:

- Carregue o instantâneo, o tópico de conversa e o ambiente do repórter.
- Classifique o ambiente de reprodução como `public_release`, `local_commit`, `local_branch` ou `unknown`.
- Se desconhecido ou conflitante, chame `add_issue_message` com uma solicitação estruturada para o detalhe faltante e marque o plano como `awaiting_input`.
- Caso contrário, sintetize uma entidade de `plano` vinculada ao problema de origem e às linhas relevantes da mensagem de conversação.
- Se o plano abordar esquema, segurança, documentos básicos ou um limite arquitetônico ambíguo, pare e pergunte. Não execute.
- Se a execução for segura e permitida pelo modo de relatório: ramifique de `main` para uma reprodução de lançamento público e abra um PR, ou crie uma árvore de trabalho git desanexada para uma reprodução local e relate o caminho.

Os subagentes se distribuem com um limite de simultaneidade de quatro, um problema por subagente. A habilidade respeita `reporting_mode`: `off` gera e armazena apenas planos, `consent` pergunta antes de executar, `proactive` executa planos seguros de forma autônoma. Nunca pressione para `main`. Nunca use `--no-verify`. Nunca altere um commit enviado. A proteção contra vazamento de redação é executada antes de qualquer artefato público ser criado a partir de um problema privado.

Os padrões seguros permanecem ativados:

- `dry_run: true` para a primeira execução de qualquer novo tipo de problema, então posso ver o que aconteceria antes de qualquer coisa ser escrita.
- `auto_fix: false` então nada empurra ou abre um PR até que eu confirme através do transporte do operador.
- `max_prs_per_hour: 5` para que uma enxurrada de problemas relacionados não possa se transformar em uma enxurrada de ramificações.
- `dirty_tree_policy: abort` para que um checkout obsoleto nunca seja usado como base.
- Um kill switch por meio de uma entidade `daemon_config` no Neotoma com `active: false`, para que eu possa pausar todo o processamento de uma única gravação do Neotoma sem tocar na máquina host.

A peça de transporte do operador merece destaque. Formica suporta um back-end do Telegram que apresenta transferências `human_needed` e comandos `/shipit` para retomar quando `auto_fix` está desativado. As mensagens do Telegram na lista de permissões são espelhadas no Neotoma como linhas `conversation_message`, portanto, até mesmo minhas idas e vindas do lado humano com o daemon são capturadas no mesmo substrato. A trilha de auditoria é de ponta a ponta.

O caminho `add_issue_message` foi o que me surpreendeu quando comecei a usá-lo. Não é um sistema de comentários. É um canal de mensagens estruturado entre o relator de um problema e o mantenedor, encadeado através das mesmas primitivas de conversação que já existem para encadeamentos de agente para agente. O agente do repórter pode responder a uma pergunta esclarecedora sem que o humano tenha que lê-la no meio. Threads públicos carregam a mesma redação de PII, e casos de sucesso parcial (espelho do GitHub aceito, falha no acréscimo local ou vice-versa) aparecem como um erro estruturado na resposta, em vez de produzir silenciosamente comentários duplicados.

Quando uma correção ocorre, o mesmo daemon que fez a triagem do relatório encerra o problema ou fecha vários de uma vez em massa se um único PR resolver um cluster.

## O que o agente do repórter faz na releitura

O outro lado do loop é a leitura. O agente do repórter chama `get_issue_status` com o número do problema ou ID da entidade. Ele recebe o status atual, as mensagens no thread, a resolução, se houver, e o link para o espelho upstream se o lado do mantenedor optar por escalá-lo. O token convidado autentica a leitura sem que o usuário precise fazer login em nada. Se o token expirou, o substrato retornará um 401 limpo em vez de fazer downgrade silenciosamente para acesso anônimo.

O agente decide se exibirá o status ao usuário. Se nada mudou desde a última verificação, ele permanece silencioso. Se chegar uma pergunta esclarecedora, ele pergunta ao usuário. Se a correção for enviada, ela informa ao usuário, opcionalmente extrai a nova versão e se oferece para executar novamente o que quebrou na primeira vez.

O modelo de leitura atual para o lado do repórter é o pull — o agente verifica quando tem motivo para fazê-lo — mas o push está disponível hoje através das mesmas ferramentas de assinatura que o daemon do mantenedor usa. As assinaturas podem ter como escopo um ID de entidade específico, para que o agente do repórter possa registrar interesse no problema que acabou de registrar e receber eventos `entity.updated` e `observation.created` à medida que o tópico avança. O que falta é a cola ergonômica: as instruções do MCP ainda não dizem aos agentes para se inscreverem automaticamente após o retorno de `submit_issue`. Até que isso aconteça, o lado repórter permanece acionado por padrão; os agentes do mantenedor já acordam em eventos de substrato. Totalmente reativo em ambas as metades está a uma mudança de instrução de distância.

## Por que este é o sistema nervoso em ação

O substrato emite eventos após cada gravação. Essa é a única coisa que o substrato precisa fazer para que tudo isso funcione. Todo o resto é lógica da camada operacional em execução: o daemon de triagem, o espelho do GitHub, a leitura do convidado, a desduplicação entre threads, a redação de PII.

Esta é a linha que defendi na postagem sobre sistema nervoso](/posts/from-memory-to-nervous-system) e se mantém no caso de uso de problemas. O substrato não decide quais questões são importantes, não tenta novamente as entregas com escalonamento, não assina seus próprios eventos. Ele sinaliza. O daemon de triagem é um consumidor, o agente do repórter é um consumidor, o espelho do GitHub é um consumidor. Cada consumidor registra interesse, decide o que fazer e age. Se eu quiser adicionar um segundo daemon de triagem que lide com relatórios de segurança de maneira diferente, ele assinará os mesmos eventos com um filtro diferente. Nenhum novo comportamento do substrato.

O enquadramento biológico é válido. O substrato é o cérebro mais os nervos sensoriais: ele armazena o problema, transmite o sinal de que um problema chegou. O daemon de triagem e o agente do repórter são o sistema motor: eles decidem o que fazer com o sinal. Uma versão do Neotoma que tentasse ser todos os três seria mais difícil de raciocinar e mais difícil de estender. Uma versão que pára na sinalização permanece neutra.

## Herdando o loop

A forma que descrevi é construída em torno dos próprios problemas de Neotoma, mas o substrato não se importa. Qualquer coisa construída sobre ele herda a maior parte do mesmo maquinário.

O lado genérico da submissão já está em vigor. `submit_entity` aceita relatórios contra tipos de entidade arbitrários quando o operador tiver propagado uma linha `submission_config` autorizando-o. A mesma concessão de token de convidado, o mesmo encadeamento de conversa e o mesmo canal de acompanhamento `add_entity_message` se aplicam. `subscribe` aceita qualquer tipo de entidade como filtro, para que um operador terceirizado possa executar seu próprio daemon de triagem registrando interesse em seus tipos personalizados e reagindo aos eventos `entity.created` e `entity.updated` exatamente da mesma forma que o Formica reage aos problemas.

O que isso significa na prática: se você estiver executando um pipeline de conteúdo, um serviço de reconciliação ou qualquer produto cujos usuários executem agentes, você pode permitir que esses agentes arquivem relatórios estruturados contra entidades que você possui – uma execução de pipeline com falha, um registro classificado incorretamente, uma solicitação de reconciliação – e buscá-los para você por meio do mesmo mecanismo de assinatura. O fio é geral.

Algumas peças são específicas dos problemas atuais de Neotoma. O protetor de redação de PII está atualmente vinculado ao caminho `submit_issue`, não ao caminho genérico `submit_entity`. O espelhamento do GitHub é específico para cada problema. Ambos são acréscimos à camada operacional que um operador terceirizado conectaria por conta própria. O substrato lida com as partes que precisam ser uniformes – aplicação de proveniência, criação de relacionamento atômico, acesso de convidado ao thread, emissão de eventos em cada gravação. As partes que dependem do assunto do relatório *sobre* são onde o operador ganha seu sustento.

O subsistema de questões é o primeiro consumidor completo de um padrão mais geral. O mesmo formato se aplica a qualquer sinal estruturado que um agente queira enviar de volta ao sistema em que está sendo executado.

## Por que a revisão humana permanece

Duas coisas me tentam a conectar `auto_fix: true` e enviar tudo o que o daemon produz.

A primeira é a conveniência. Um pipeline verde que resolve problemas enquanto durmo é satisfatório. A segunda é o fato de que, para uma fração significativa de questões, o plano de agência e a diferença estão corretos. Já assisti o suficiente deles para saber que o modo de falha geralmente não é uma "solução errada". Geralmente é uma “correção para o escopo errado”, que uma revisão de código detecta em trinta segundos.

Estou deixando a revisão humana porque os agentes ocasionalmente estão errados sobre decisões com consequências posteriores que eles não podem ver. Uma migração de esquema que satisfaz o teste com falha, mas interrompe uma integração não relacionada. Um ajuste de redação que corrige o vazamento imediato, mas afrouxa uma proteção relacionada. Um aumento de dependência que resolve o erro de compilação e altera silenciosamente o comportamento padrão de uma consulta.

As solicitações de aprimoramento aprimoram isso ainda mais. Um bug tem uma verdade básica - ou o campo foi descartado ou não. Uma melhoria é uma afirmação de design que carrega suposições sobre padrões de uso, restrições de arquitetura e compensações que o agente inquirido não pode ver completamente. O sinal é valioso; ele revela atrito real, não atrito imaginado. Mas a decisão sobre o que fazer com isso pertence a um ser humano que pode ver o quadro completo.

As decisões que precisam de um ser humano são aquelas em que o custo de estar errado é alto e o custo de ser lento é baixo. Essas são as fusões – não os planos, os patches, os testes ou as descrições de relações públicas. Os agentes cuidam de todo o resto. Os agentes propõem; os humanos decidem.

## O loop agente, de ponta a ponta

Leia junto com a postagem de pesquisa do cliente, o formato agora está legível. A metade frontal: o agente do usuário avalia o Neotoma em relação ao seu fluxo de trabalho real e o instala se for adequado. A metade posterior: o agente registra bugs, observações de desempenho e solicitações de melhorias à medida que os encontra, e o lado do mantenedor os resolve — muitas vezes antes que o usuário se lembre de que algo foi arquivado.

Ambas as metades operam em agentes conversando com agentes por meio de uma superfície estruturada. O atrito que historicamente matou tanto o ciclo de aquisição quanto o ciclo de feedback desapareceu porque cada etapa de tradução foi absorvida em uma chamada de ferramenta. Nenhuma das metades seria possível sem o substrato subjacente: a avaliação liderada pelo agente precisa de um estado estruturado sobre o fluxo de trabalho do usuário, e o subsistema de problemas precisa de sinalização de eventos, além de acesso de convidados através dos limites de confiança. Ambos dependem das mesmas primitivas.

## O que não estou construindo

A tentação no subsistema de problemas é migrar para a orquestração: um modelo de priorização, rastreamento automático de SLA, um roteador “inteligente” que decide qual daemon lida com qual tipo de problema. Cada um parece razoável isoladamente. Nenhum deles pertence ao substrato. O daemon de triagem prioriza. Os agentes do mantenedor rastreiam seus próprios tempos de resposta. O roteamento é um filtro de assinatura.

O mesmo se aplica à semântica de repetição. Se a entrega de um webhook falhar, o substrato registra a falha e segue em frente. Ele não escala para um canal de backup, não armazena buffer para reprodução, não coloca o consumidor em um estado degradado. Os corretores de mensagens fazem tudo isso e são bons nisso; o substrato não é um intermediário de mensagens. Os consumidores que desejam entrega garantida envolvem o sinal em sua própria infraestrutura.

A restrição é o recurso. Uma camada de estado que sinaliza problemas, mas não decide quais questões são importantes, é uma camada de estado em que qualquer consumidor pode confiar para se comportar de maneira previsível.

## Sobre o que desejo feedback

O subsistema de problemas está ativo. Se você tiver o Neotoma instalado e seu agente encontrar algo difícil – um bug, uma falha de desempenho, um recurso ausente que ele gostaria que existisse – você não precisará mais solicitar que ele registre um problema. Para obter isso em uma instalação existente, atualize com `npm install -g neotoma@latest`. Não há alternância de consentimento por usuário para configurar; o consentimento é a instalação. Se esta for uma instalação nova, `neotoma reporter setup` percorre a configuração única do lado do repórter para que o primeiro problema dos arquivos do seu agente tenha um lugar para pousar.

Se você ainda não possui o Neotoma instalado, peça ao seu agente para executar a página de avaliação. Se concluir que o Neotoma se encaixa, ele pode ser instalado e ativado sem você ler um documento de configuração. Se concluir que o Neotoma não se encaixa, esse também é um resultado válido e mais honesto do que a maioria das páginas de destino produz.

Se você estiver criando um produto cujos usuários executam agentes, o modelo será portátil. O trabalho interessante não está em nenhum dos lados do fio; é o próprio fio.