Construí uma empresa de agentes de IA no Paperclip. Veja o que quebrou.

Meu time de conteúdo é MrBeast, Gary Vaynerchuk e Neil Patel. Minhas ofertas passam pelo Alex Hormozi. O Russell Brunson monta os funis, e o Richard Feynman revisa qualquer coisa que tenta ensinar algo. Nenhum deles jamais ouviu falar de mim. São agentes, treze deles, rodando no Hermes Agent dentro do Paperclip, numa VPS que eu pago por mês.

Já expliquei essa organização para dezenas de engenheiros e líderes de engenharia. Todos fazem as mesmas três perguntas. O que é o Paperclip, de fato. Funciona. O que quebra. Essa é a resposta longa, desde a semana em que instalei em junho até 22 de julho, o primeiro dia em que o loop fechou sem eu empurrar.

A organização, em números

13

agentes1 CEO, 1 chief of staff, 5 heads, 6 especialistas

~6

semanasda instalação a um loop que fecha sozinho

2

pacotes npmadapters que eu mesmo tive que escrever

1

gate humanopublicação, de propósito

O que é o Paperclip AI?

O Paperclip é um app open source, licenciado em MIT, para rodar agentes de IA como uma organização. Você ganha um organograma com linha de reporte, issues que os agentes atribuem entre si, orçamento mensal, aprovações, uma trilha de auditoria e um heartbeat que acorda cada agente num timer ou no momento em que o trabalho chega até ele. O repositório chama isso de “o app open source que todo mundo usa para gerenciar agentes no trabalho”, e está em torno de 95k estrelas no GitHub.

Aqui está a parte que as landing pages pulam. O Paperclip não pensa. Ele não tem loop de agente próprio. Cada agente se conecta por um adapter a um runtime que de fato faz o trabalho: Claude Code, Codex, OpenCode, OpenClaw, um endpoint HTTP simples, ou, no meu caso, o Hermes Agent.

Essa divisão decide a maioria dos seus problemas. Quando algo dá errado, a primeira pergunta é sempre de que lado do adapter isso aconteceu. A maioria dos meus bugs vivia exatamente no adapter.

Por que um dev acaba rodando uma empresa de agentes

Eu não comecei aqui. Subi até aqui, e cada degrau removeu o atrito que o anterior deixou.

A escada que terminou numa empresa de agentes

1. 1

   Vibe coding

   "Copia do ChatGPT, cola no editor, espera dar certo."

   → O medo passa. O contexto nunca chega.

2. 2

   Um produto real com agentes

   "Uma fintech cripto de 13 apps em 70 dias, especificada antes, construída por agentes."

   → Desenvolvimento novo ancorado em IA. Toda sessão ainda começa em branco.

3. 3

   Um second brain

   "Uma wiki em LLM mais skills que capturam o que cada sessão aprende."

   → O contexto sobrevive. A execução ainda espera por mim.

4. 4

   Persona skills

   "Um especialista que eu estudei, empacotado como skill que o modelo carrega."

   → Precisão. Eu ainda sou quem dirige toda sessão.

5. 5

   Agentes autônomos

   "Hermes mais Paperclip: contexto mais MCP é igual a execução sem babá."

   → O trabalho anda enquanto eu não estou lá.

A escada é cumulativa. A organização do Paperclip lê o second brain, roda nas persona skills, e alcança o mundo por servidores MCP. Pula um degrau e o topo não tem onde se apoiar. O estudo de caso da fintech é o degrau dois, em detalhe.

O motivo pelo qual eu precisei do degrau cinco é chato. Meu trabalho mudou de dev para negócio de uma pessoa só. Uma pessoa que precisa de um blog, um canal no YouTube, ofertas e funis, num número fixo de horas por semana, com uma família que fica com o resto delas. Agentes que esperam eu digitar não resolvem isso. Agentes que acordam por conta própria resolvem.

A organização: um CEO, um chief of staff, cinco heads, seis especialistas

O organograma, como roda no Paperclip

• agente CEO// escala para mim, o humano, quando algo está além do cargo dele
  • Gwynne Shotwellchief of staff// transforma cinco heads num só resumo
    • MrBeasthead// Library: conteúdo e atenção
    • Sal Khanhead// Academy: ensino
    • Marc Louhead// Arsenal: produtos self-serve
    • DHHhead// Build: trabalho feito para o cliente
    • Pieter Levelshead// Ventures: meus próprios produtos
  • Gary Vaynerchukespecialista// conteúdo
    • Arthur Miller// revisão de narrativa
    • Richard Feynman// revisão didática
  • Neil Patelespecialista// inteligência editorial e SEO
  • Alex Hormoziespecialista// ofertas
  • Russell Brunsonespecialista// funis

Três papéis, três trabalhos diferentes.

Heads são donos de um resultado ligado a um número, um head por linha de negócio. Eles nunca fazem o trabalho manual. Escolhem a aposta, abrem uma issue para um especialista com a régua de aceite escrita direto nela e um prazo, e julgam o que volta. Se um head está escrevendo copy ou puxando dado cru, a régua dele não estava afiada o suficiente.

Especialistas são donos de um ofício só. Cada um carrega uma persona skill e os próprios servidores MCP. Um especialista tem uma função só: pensar, e consultar dado real por MCP.

O chief of staff recolhe as vitórias aprovadas dos cinco heads e entrega ao CEO um resumo pronto para decisão. Esse papel existe por causa de uma falha. Meu primeiro agente CEO tentou ler o board inteiro numa execução só e deu timeout carregando tudo.

Os heads também carregam nomes reais, no próprio SOUL.md. O mesmo roteamento por persona que afia um especialista funciona uma camada acima. Um head chamado MrBeast julga uma aposta de conteúdo diferente de um head chamado “Gerente de Conteúdo”, e essa diferença é o ponto.

Heads julgam, especialistas pensam

A divisão entre os dois é a decisão de design mais importante da organização. É também a que a maioria das demos de multi-agente pula, porque dão o trabalho e a nota para o mesmo agente.

Head

1. 01É dono de um resultado ligado a um número
2. 02Começa ciclos no próprio timer
3. 03Escreve a régua de aceite direto na issue
4. 04Aceita o retorno ou devolve
5. 05Nunca faz o trabalho manual

Especialista

1. 01É dono de um ofício só
2. 02Só acorda quando recebe trabalho atribuído
3. 03Lê dado real pelos próprios servidores MCP
4. 04Entrega contra a régua
5. 05Nunca julga se o próprio trabalho passa

O especialista não julga se o trabalho passa. Quem sabia o que queria é quem julga.

Três coisas decorrem dessa regra. O viés de confirmação cai, porque o agente que produziu o trabalho não é quem aprova. Cada contexto fica estreito, um ofício por especialista. E contextos estreitos rodam bem em modelos menores e mais baratos, o que importa quando treze agentes acordam numa agenda.

O mesmo harness, dois propósitos

Todo agente desse setup roda no mesmo harness. Mesmos modelos, mesmo contexto, mesmos servidores MCP, mesmas skills. A única coisa que muda é o propósito a que o agente responde.

O Paperclip é a camada estratégica e tática: os ciclos semanais dos heads, onde o trabalho é planejado, roteado e julgado. O Hermes no Telegram é a camada operacional: “faz isso para mim agora”. Eu falo com ele pelo celular, geralmente por voz, e ele tem o board do Paperclip conectado como servidor MCP. Quando algo não pode esperar o ciclo de um head, eu falo “um script sobre o tema X” no Telegram e ele abre a issue no board por mim.

Esse é o modelo mental completo. O Paperclip é onde eu decido. O Telegram é onde eu opero. O Hermes é a memória que os dois consultam.

Os quatro arquivos que todo agente lê

Skills roteiam um agente por tema. Esses quatro arquivos definem o trabalho. Todo agente da organização recebe o mesmo formato de pacote, injetado antes de cada wake.

O pacote de instruções de um agente

• agents/<agente>/instructions/
  • SOUL.mdquem// persona, princípio organizador, postura, anti-padrões
  • AGENTS.mdonde// lugar na organização, delegação, gates, segurança
  • HEARTBEAT.mdloop// o que fazer em todo wake, passo a passo
  • TOOLS.mdcomo// API do Paperclip, skills, scoreboard, para quem rotear

O adapter nativo do Hermes ignorava os quatro. O Paperclip vem com um adapter hermes_local que inicia a CLI do Hermes com a tarefa como prompt e faz parse do que sai. Ele nunca mandava o pacote de instruções. Meus agentes acordavam com uma tarefa e nenhuma identidade.

Então eu escrevi o adapter de que precisava e publiquei: @felipefontoura/paperclip-adapter-hermes-local-plus, um substituto drop-in que se registra sob o mesmo tipo de adapter. Ele prefixa o pacote em todo wake, mantém a pasta references/ de cada skill (o build de runtime do Paperclip removia tudo exceto o SKILL.md), lê o contexto de wake do objeto que o Paperclip de fato preenche, recupera execuções que voltaram em branco, e reporta contagem real de tokens e custo na página da execução.

Ele também corrigiu um vazamento que nenhuma pessoa adivinharia. O Hermes faz auto-discovery de um AGENTS.md no diretório de trabalho dele, e os agentes rodavam dentro da própria pasta do app do Paperclip. Todo wake estava injetando o AGENTS.md interno do Paperclip no prompt. Dar a cada agente o próprio diretório de trabalho baixou o input de 9.044 para 6.992 tokens. Isso é 22 por cento de todo wake, embora.

Eu tentei corrigir o adapter nativo primeiro. As correções foram se acumulando sem versão e sem lugar para compartilhar, e é por isso que hoje eu sou dono dessa costura em vez disso. Também construí a outra forma: o Hermes atrás de HTTP, por um adapter de gateway e uma pequena ponte de skills que serve as skills do Paperclip para o Hermes via HTTP, sem a CLI do Hermes dentro do container do Paperclip. A organização roda no adapter local hoje.

O que quebrou, em ordem

Nada nessa lista é exótico. Cada uma é o tipo de falha que você só encontra quando uma frota roda por dias em vez de uma demo de um minuto.

Seis semanas de uma empresa de agentes

1. Primeira execuçãoA produção funcionou. A publicação não.

   Neil e Gary rodaram cerca de cinquenta heartbeats e entregaram uma síntese, uma linha de base do canal e três pacotes de vídeo completos. Todo pacote parou no único passo que precisa de um humano: publicar no canal. O gargalo se moveu de mim como produtor para mim como aprovador.

2. Primeira execuçãoUm agente escalou sobre um board silencioso

   O board humano ficou quieto por cerca de cinco dias. Gary percebeu que só tinha mandado ping no board e nunca escalado pela cadeia, então abriu uma issue para o agente CEO. O agente CEO autorizou uma solução paliativa e reajustou a semana. Essa issue sozinha desbloqueou o ciclo.

3. Primeira execuçãoDois agentes fizeram o mesmo trabalho

   Neil criou três issues três minutos depois de o board ter criado as mesmas três, o que deixou seis issues para três vídeos. Depois uma instância paralela de Gary rodou o mesmo heartbeat e produziu a entrega duas vezes. Ele pegou o próprio duplicado e marcou como obsoleto.

4. ReconstruçãoA organização foi zerada e a documentação não percebeu

   Uma reconstrução do adapter e da stack do servidor resetou o banco de dados. Minhas notas diziam cinco chiefs em produção. O Postgres dizia um agente, o CEO, ocioso. A fundação funcionando não é a mesma coisa que a organização existir.

5. Ajuste finoO mesmo modelo pontuou até 26 por cento mais baixo

   No meu próprio shootout de design de oferta, o GLM-5.1 pontuou 9,55 pelo OpenCode e 7,0 a 7,9 pelo Paperclip mais Hermes. Mesmo modelo, mesma persona. O runtime tinha enviado duas identidades para ele.

6. Ajuste finoQuatro minutos de silêncio mataram um agente

   O liveness era inferido pelo stdout. Uma síntese longa e silenciosa parecia morta, o orquestrador gerou um duplicado, o duplicado roubou o lock, e o write-back da execução real quicou. Um keepalive de quinze linhas corrigiu isso.

7. Ajuste fino157 ferramentas, zero chamadas

   Os agentes juravam que as ferramentas deles não existiam. O log de execução dizia que os backends de MCP estavam fazendo cold-spawn além da janela de descoberta de menos de um segundo. Um pooler com cache na frente do gateway corrigiu isso.

8. Organização v2Um head redelegava para sempre

   Quando um especialista devolvia o trabalho pronto, o head via uma tarefa de sensor atribuída a ele mesmo e delegava de novo. Em loop. A correção foi uma regra só: uma issue em revisão atribuída a você é um retorno. Julgue e avance, nunca redelegue.

9. 22 de julhoO loop fechou por conta própria

   MrBeast orientou a semana. Neil leu os sensores e devolveu um ranking de oito ângulos. MrBeast aceitou e avançou para Gary. Gary produziu os hooks. Um relatório separado subiu para o chief of staff e MrBeast fechou a issue pai. Zero loops, zero órfãos, uma lista pronta esperando no gate humano.

Três dessas merecem mais que uma linha.

O runtime mandou duas identidades para o modelo

A queda parecia um problema de modelo. Era um problema de encanamento. Eu extraí o prompt exato do banco de dados de sessão do Hermes. O papel de system era um prompt de 14 mil caracteres que abre com o Hermes se apresentando como Hermes Agent. A persona, “Você é o Alex Hormozi, Chief Offer Architect”, chegava depois como mensagem de usuário. A persona nunca aparecia no system prompt.

Modelos são treinados para dar mais peso ao papel de system. Então o modelo recebia “generalista prestativo” do system e “closer agressivo” do usuário, e escolhia a média segura. Correto, genérico, e sem nada que fazia a persona valer a pena carregar. A correção foi dar a cada agente uma identidade, num lugar só, carregada onde o runtime trata aquilo como identidade.

A lição que eu levei: testar modelo sem testar onde o seu prompt cai é medir só metade do sistema.

O gargalo se moveu para mim

Uma empresa de agentes não te remove. Ela te move de produtor para aprovador. Meus agentes produziram três pacotes de vídeo e depois esperaram no único gate que precisa de um humano, que era eu, e eu não estava lá. Se você não redesenha o passo de aprovação, a organização produz para uma fila. É o mesmo mergulho que times enfrentam quando a IA move o gargalo para a revisão.

Eu mantive o gate assim mesmo. Agentes produzem. Eu publico. Uma lista curta esperando um sim é um problema muito melhor que um agente postando no meu canal sozinho.

O agente é um narrador não confiável

Quando as ferramentas somem, os agentes me contam uma história detalhada e confiante sobre upstreams que nunca conectaram. Eu acreditei neles por uma hora. O log de execução contava outra história: uma corrida de cold-spawn. A mesma coisa aconteceu com o agente que morreu em silêncio. O próprio relatório dele não dizia nada útil. O código do heartbeat dizia.

A regra que eu sigo agora: nunca debugue o relato do agente sobre uma falha. Leia o log. As duas correções foram publicadas: o pooler é o mcp-pooler, e o keepalive é um pull request aberto contra o adapter da Nous Research.

O loop que finalmente fechou

O Paperclip acorda um agente de três formas: quando uma issue é atribuída a ele, quando algo de que ele depende resolve, e num timer. O design que funciona usa as três com uma disciplina só. Só heads começam ciclos num timer. Especialistas nunca começam nada. Eles acordam quando recebem trabalho atribuído e em nenhum outro momento.

Um ciclo do head da Library

Entrada

MrBeast acorda no próprio timer

↓

1. ORIENTLer o motor, escolher a lente

   Lê o objetivo, as issues abertas e o último ranking. Escolhe por qual sentido olhar essa semana: self, competidor, tendência, fronteira, comunidade ou cliente.

   ↓
2. ROUTEAbrir uma issue para um especialista

   Atribui, escreve a régua de aceite e o prazo direto na issue, e já cria ela aberta. Trabalho nascido fechado não acorda ninguém.

   ↓
3. WORKO especialista lê o mundo

   Neil lê os sensores pelos próprios servidores MCP e entrega. Depois marca a issue como em revisão e devolve para o head, o que acorda o head.

   ↓
4. JUDGEAceitar e avançar, ou devolver

   Um retorno é julgado, nunca redelegado. O trabalho aceito se torna a próxima demanda para o próximo especialista da cadeia, aqui o Gary.

   ↓
5. REPORTReportar para cima, fechar a issue pai

   O head abre uma nova issue de relatório para o chief of staff e fecha a issue pai do ciclo ele mesmo. A issue pai nunca saiu das mãos do head.

↓

Saída

Uma lista curta pronta para decisão, no único gate humano: publicar

Cada passo desse pipeline é uma cicatriz. “Já criar aberta” existe porque trabalho nascido done acordava um responsável que não tinha nada para fazer. “Devolver para o head” existe porque o Paperclip só deixa o responsável mudar uma issue, então o retorno de um especialista nunca acordava ninguém. “Nunca redelegado” é o loop. “A issue pai nunca saiu das mãos do head” é a vez em que um head passou o ciclo inteiro para o chief of staff na metade do caminho.

Onde isso está hoje

O loop fechou em 22 de julho. O board está quieto desde aquela tarde: o último heartbeat em qualquer parte da organização é daquele dia. Eu assumi um papel maior no meu trabalho, e essa organização existia para fazer um negócio de uma pessoa só rodar nas horas que me sobravam. Quando essas horas foram para outro lugar, a organização ficou quieta com elas. Essa é a propriedade honesta de uma empresa de agentes com um gate humano só. Sem humano no gate, sem empresa.

Só um dos cinco heads, MrBeast, já rodou um ciclo, e isso é de propósito. Library era o motor com demanda real por trás. Os outros quatro gerenciam linhas de negócio que eu ainda não validei, uma SaaS entre elas. Acordar um head para rodar um negócio que ainda não existe é teatro. Cada um entra em produção quando o negócio dele entra, nos próximos meses.

Estou ligando de novo à medida que meus canais no YouTube e contas sociais voltam a ficar ativos. Dessa vez a organização ganha um trabalho mais estreito: rodar a operação de um criador, a cadência diária de canais e posts, comigo de volta no gate toda manhã.

Quando o Paperclip vale a pena

Antes de construir uma empresa de agentes

• ✓Obrigatório:
  Você tem mais de uma frente que precisa de um julgamento diferente.Conteúdo, ofertas e funis são três julgamentos. Uma pessoa com uma tarefa só não precisa de hierarquia. Só adiciona latência.
• ✓Obrigatório:
  Duas ou três persona skills já funcionam numa sessão simples.A organização multiplica skills que você já tem. Ela não cria elas.
• ✓Obrigatório:
  Seu contexto vive em arquivos que os agentes conseguem ler.Um second brain, um AGENTS.md, um cânone do que você nunca faz. Conhecimento que se repete pertence ali, não dentro de um agente.
• ✓Obrigatório:
  Todo especialista alcança dado real por MCP.Um agente sem sensor está cego e chutando. O servidor MCP é a ponte do sensor até o dado.
• ✓Obrigatório:
  Você sabe exatamente onde fica o gate humano, e você aparece nele.O meu é publicação. Se você não está ali toda manhã, a organização produz para uma fila.
• ✓Obrigatório:
  Você começa com o menor loop que fecha.Uma entrada que você digita na mão, um agente que pensa e propõe, você decide, ele publica. Automatize a coleta de dado por último, não primeiro.

Paperclip, respostas rápidas

O que é o Paperclip AI?+

O Paperclip é um app open source, licenciado em MIT, para rodar agentes de IA como uma organização: um organograma, issues que os agentes atribuem entre si, orçamentos, aprovações e heartbeats que acordam agentes num timer ou quando o trabalho chega. Ele não roda um modelo sozinho. Cada agente se conecta por um adapter a um runtime como Claude Code, Codex, OpenClaw ou Hermes Agent.

O Paperclip roda os agentes?+

Não. O Paperclip agenda, roteia e registra. O raciocínio acontece no runtime atrás do adapter de cada agente.

É por isso que a maioria dos bugs de produção vive no adapter: identidade, contexto de wake, liveness e contagem de tokens cruzam essa fronteira.

Qual a diferença entre o Paperclip e o Hermes Agent?+

O Paperclip é a camada de organização. O Hermes Agent é um agent runtime com próprias ferramentas, memória, skills e gateways de mensagens.

No meu setup todo agente do Paperclip roda no Hermes, e um Hermes separado no Telegram é meu assistente pessoal, conectado ao board do Paperclip para eu abrir issues por voz.

O Paperclip é uma empresa sem humanos?+

A minha não é, de propósito. Agentes produzem, roteiam e julgam o trabalho uns dos outros, mas a publicação passa por um gate humano só. Uma lista curta esperando um sim é um problema melhor que um agente postando no seu canal sem supervisão.

Qual modelo os agentes do Paperclip devem usar?+

Deixe o runtime ser dono do modelo, não o orquestrador. Meu adapter parou de passar um modelo e lê ele direto da configuração do Hermes. Ao longo dessas semanas a frota rodou GLM-5.1 pela Z.AI e depois DeepSeek V4 Flash pelo OpenRouter.

Especialistas estreitos rodam bem em modelos menores. Teste onde a sua persona cai no prompt antes de culpar o modelo: o mesmo modelo pontuou até 26 por cento mais baixo no meu setup porque o runtime enviou duas identidades para ele.