Construí una empresa de agentes de IA en Paperclip. Esto fue lo que se rompió.

Mi equipo de contenido es MrBeast, Gary Vaynerchuk y Neil Patel. Mis ofertas pasan por Alex Hormozi. Russell Brunson arma los funnels, y Richard Feynman revisa cualquier cosa que intente enseñar algo. Ninguno de ellos escuchó hablar de mí en su vida. Son agentes, trece, corriendo sobre Hermes Agent dentro de Paperclip, en un VPS que pago todos los meses.

Guié a decenas de ingenieros y líderes de ingeniería por esta org. Todos hacen las mismas tres preguntas. Qué es Paperclip, en serio. Funciona. Qué se rompe. Esta es la respuesta larga, desde la semana que lo instalé en junio hasta el 22 de julio, el primer día que el loop se cerró sin que yo lo empujara.

La org, en números

13

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

~6

semanasdesde la instalación hasta un loop que cierra solo

2

paquetes de npmadapters que tuve que escribir yo mismo

1

gate humanopublicar, a propósito

Qué es Paperclip AI

Paperclip es una app open-source, con licencia MIT, para correr agentes de IA como una organización. Tienes un organigrama con líneas de reporte, issues que los agentes se asignan entre ellos, presupuestos mensuales, aprobaciones, un registro de auditoría, y un heartbeat que despierta a cada agente con un timer o en el momento en que le cae trabajo encima. El repo lo llama “la app open-source que todos usan para manejar agentes en el trabajo”, y está en unas 95k estrellas en GitHub.

Esta es la parte que las landing pages se saltean. Paperclip no piensa. No tiene ningún agent loop propio. Cada agente se conecta a través de un adapter a un runtime que hace el trabajo de verdad: Claude Code, Codex, OpenCode, OpenClaw, un endpoint HTTP cualquiera, o, en mi caso, Hermes Agent.

Esa separación decide la mayoría de tus problemas. Cuando algo sale mal, la primera pregunta siempre es de qué lado del adapter pasó. La mayoría de mis bugs vivían exactamente en el adapter.

Por qué un desarrollador termina corriendo una empresa de agentes

No empecé acá. Subí hasta acá, y cada escalón sacó la fricción que dejó el de abajo.

La escalera que terminó en una empresa de agentes

1. 1

   Vibe coding

   "Copiar de ChatGPT, pegar en el editor, esperar que funcione."

   → El miedo se va. El contexto nunca llega.

2. 2

   Un producto real con agentes

   "Una fintech cripto de 13 apps en 70 días, especificada primero, construida por agentes."

   → Desarrollo nuevo anclado en IA. Cada sesión sigue arrancando en blanco.

3. 3

   Un second brain

   "Una wiki de LLM más skills que capturan lo que aprende cada sesión."

   → El contexto sobrevive. La ejecución sigue esperándome a mí.

4. 4

   Persona skills

   "Un experto que estudié, empaquetado como un skill que el modelo puede cargar."

   → Precisión. Sigo siendo yo quien maneja cada sesión.

5. 5

   Agentes autónomos

   "Hermes más Paperclip: contexto más MCP es igual a ejecución sin que nadie los cuide."

   → El trabajo avanza cuando yo no estoy.

La escalera es acumulativa. La org de Paperclip lee el second brain, corre sobre las persona skills, y llega al mundo a través de MCP servers. Te saltas un escalón y el de arriba se queda sin nada donde apoyarse. El caso de estudio de la fintech es el escalón dos en detalle.

La razón por la que necesité el escalón cinco es aburrida. Mi trabajo cambió de desarrollador a negocio unipersonal. Una sola persona que necesita un blog, un canal de YouTube, ofertas y funnels, con una cantidad fija de horas a la semana, y una familia que se queda con el resto. Agentes que esperan a que yo escriba no resuelven eso. Agentes que se despiertan solos sí.

La org: un CEO, un chief of staff, cinco heads, seis especialistas

El organigrama, tal como corre en Paperclip

• Agente CEO// escala hacia mí, el humano, cuando algo le queda grande
  • Gwynne Shotwellchief of staff// convierte cinco heads en un solo resumen
    • MrBeasthead// Library: contenido y atención
    • Sal Khanhead// Academy: enseñanza
    • Marc Louhead// Arsenal: productos self-serve
    • DHHhead// Build: trabajo hecho para el cliente
    • Pieter Levelshead// Ventures: mis propios productos
  • Gary Vaynerchukespecialista// contenido
    • Arthur Miller// revisión narrativa
    • Richard Feynman// revisión didáctica
  • Neil Patelespecialista// inteligencia editorial y SEO
  • Alex Hormoziespecialista// ofertas
  • Russell Brunsonespecialista// funnels

Tres roles, tres trabajos distintos.

Los heads son dueños de un resultado atado a un número, un head por línea de negocio. Nunca hacen el trabajo de oficio. Eligen la apuesta, abren un issue para un especialista con la vara de aceptación escrita ahí mismo y una fecha límite, y juzgan lo que vuelve. Si un head está escribiendo copy o sacando datos crudos, su vara no estaba lo bastante afilada.

Los especialistas son dueños de un oficio. Cada uno carga un persona skill y sus propios MCP servers. Un especialista tiene una sola función: pensar, y consultar datos a través de MCP.

El chief of staff junta las victorias aprobadas de los cinco heads y le entrega al CEO un solo resumen listo para decidir. Ese rol existe por una falla. Mi primer agente CEO intentó leer todo el tablero en una sola corrida y se quedó colgado sosteniendo todo.

Los heads también tienen nombres propios, en su SOUL.md. El mismo ruteo por persona que afina a un especialista funciona un escalón más arriba. Un head llamado MrBeast juzga una apuesta de contenido distinto a como lo haría un head llamado “Gerente de Contenido”, y esa diferencia es justamente el punto.

Los heads juzgan, los especialistas piensan

La separación entre los dos es la decisión de diseño más importante de la org. También es la que la mayoría de las demos de multi-agentes se saltea, porque le dan a un solo agente el trabajo y la nota.

Head

1. 01Es dueño de un resultado atado a un número
2. 02Arranca ciclos con su propio timer
3. 03Escribe la vara de aceptación en el issue
4. 04Acepta lo que vuelve o lo devuelve
5. 05Nunca hace el trabajo de oficio

Especialista

1. 01Es dueño de un oficio
2. 02Se despierta solo cuando le asignan trabajo
3. 03Lee datos reales a través de sus MCP servers
4. 04Entrega contra la vara
5. 05Nunca juzga si su propio trabajo pasa

El especialista no juzga si su trabajo pasa. Lo juzga el que sabía lo que quería.

De esa regla salen tres cosas. El sesgo de confirmación baja, porque el agente que hizo el trabajo no es el que lo aprueba. Cada contexto se mantiene acotado, un oficio por especialista. Y los contextos acotados corren bien en modelos más chicos y baratos, lo cual importa cuando trece agentes se despiertan con un horario.

Mismo harness, dos propósitos

Cada agente de este setup corre sobre el mismo harness. Mismos modelos, mismo contexto, mismos MCP servers, mismos skills. Lo único que cambia es a qué propósito le responde el agente.

Paperclip es la capa estratégica y táctica: los ciclos semanales de los heads, donde el trabajo se planea, se enruta y se juzga. Hermes en Telegram es la capa operativa: “haz esto por mí ahora”. Le hablo desde mi teléfono, casi siempre por voz, y tiene el tablero de Paperclip conectado como MCP server. Cuando algo no puede esperar al ciclo de un head, digo “un script sobre el tema X” en Telegram y me abre el issue en el tablero.

Ese es todo el modelo mental. Paperclip es donde decido. Telegram es donde opero. Hermes es la memoria que consultan los dos.

Los cuatro archivos que lee cada agente

Los skills enrutan a un agente por tema. Estos cuatro archivos definen el trabajo. Cada agente de la org recibe el mismo paquete, inyectado antes de cada wake.

El paquete de instrucciones de un agente

• agents/<agente>/instructions/
  • SOUL.mdquién// persona, principio organizador, postura, antipatrones
  • AGENTS.mddónde// lugar en la org, delegación, gates, seguridad
  • HEARTBEAT.mdloop// qué hacer en cada wake, paso a paso
  • TOOLS.mdcómo// API de Paperclip, skills, scoreboard, a quién enrutar

El adapter de Hermes que viene incluido ignoraba los cuatro. Paperclip trae un adapter hermes_local que levanta el CLI de Hermes con la tarea como prompt y parsea lo que sale. Nunca mandaba el paquete de instrucciones. Mis agentes se despertaban con una tarea y ninguna identidad.

Así que escribí el adapter que necesitaba y lo publiqué: @felipefontoura/paperclip-adapter-hermes-local-plus, un reemplazo drop-in que se registra bajo el mismo tipo de adapter. Antepone el paquete en cada wake, conserva la carpeta references/ de cada skill (el build del runtime de Paperclip le sacaba todo salvo SKILL.md), lee el contexto del wake desde el objeto que Paperclip en verdad llena, recupera corridas que volvieron vacías, y reporta conteos de tokens y costo reales en la página de la corrida.

También arregló una fuga que nadie hubiera adivinado. Hermes hace auto-discovery de un AGENTS.md en su working directory, y los agentes corrían dentro de la propia carpeta de la app de Paperclip. Cada wake estaba inyectando el AGENTS.md interno de Paperclip en el prompt. Darle a cada agente su propio scratch directory bajó el input de 9.044 tokens a 6.992. Eso es 22 por ciento de cada wake, desaparecido.

Primero intenté parchar el adapter incluido. Los parches se apilaron sin versión y sin ningún lugar para compartirlos, que es por qué ahora soy dueño de la costura en vez de pelear con eso. También construí la otra forma: Hermes detrás de HTTP, a través de un adapter de gateway y un pequeño puente de skills que le sirve los skills de Paperclip a Hermes por HTTP, sin ningún CLI de Hermes dentro del container de Paperclip. La org corre hoy sobre el adapter local.

Qué se rompió, en orden

Nada en esta lista es exótico. Cada una es el tipo de falla que solo te encuentras cuando una flota corre durante días en vez de una demo que corre un minuto.

Seis semanas de una empresa de agentes

1. Primera corridaLa producción funcionó. La publicación no.

   Neil y Gary corrieron unos cincuenta heartbeats y entregaron una síntesis, un baseline del canal y tres paquetes de video completos. Cada paquete se detuvo en el único paso que necesita a un humano: publicar en el canal. El cuello de botella se movió de mí como productor a mí como aprobador.

2. Primera corridaUn agente escaló por un tablero en silencio

   El tablero humano estuvo callado unos cinco días. Gary notó que solo había hecho ping al tablero y nunca había escalado por la cadena, así que abrió un issue para el agente CEO. El agente CEO autorizó un parche temporal y reorganizó la semana. Ese único issue destrabó el ciclo.

3. Primera corridaDos agentes hicieron el mismo trabajo

   Neil creó tres issues tres minutos después de que el tablero había creado los mismos tres, lo que dejó seis issues para tres videos. Después, una instancia paralela de Gary corrió el mismo heartbeat y produjo el entregable dos veces. Él mismo detectó su duplicado y lo marcó como obsoleto.

4. ReconstrucciónLa org se borró y el documento no se dio cuenta

   Una reconstrucción del adapter y del stack del servidor reseteó la base de datos. Mis notas decían cinco chiefs en producción. Postgres decía un agente, el CEO, idle. Que la base funcione no es lo mismo que que la org exista.

5. AjustesEl mismo modelo sacó hasta un 26 por ciento menos

   En mi propio shootout de diseño de ofertas, GLM-5.1 sacó 9,55 vía OpenCode y entre 7,0 y 7,9 vía Paperclip más Hermes. Mismo modelo, misma persona. El runtime le había mandado dos identidades.

6. AjustesCuatro minutos de silencio mataron a un agente

   La liveness se inferia desde el stdout. Una síntesis larga y silenciosa parecía muerta, el orchestrator generaba un duplicado, el duplicado robaba el lock, y el write-back de la corrida real rebotaba. Un keepalive de quince líneas lo arregló.

7. Ajustes157 herramientas, cero llamadas

   Los agentes juraban que sus herramientas no existían. El log de ejecución decía que los MCP backends arrancaban en frío más allá de la ventana de discovery de menos de un segundo. Un pooler con caché delante del gateway lo arregló.

8. Org v2Un head re-delegaba para siempre

   Cuando un especialista devolvía un trabajo terminado, el head veía una tarea de sensor asignada a sí mismo y la delegaba de nuevo. En loop. El arreglo fue una sola regla: un issue en revisión asignado a ti es una devolución. Júzgalo y avanza, nunca lo re-delegues.

9. 22 de julioEl loop se cerró solo

   MrBeast orientó la semana. Neil leyó los sensores y devolvió un ranking de ocho ángulos. MrBeast aceptó y avanzó hacia Gary. Gary produjo los hooks. Un reporte separado subió al chief of staff y MrBeast cerró el issue padre. Cero loops, cero huérfanos, una shortlist esperando en el gate humano.

Tres de estos merecen más que una línea.

El runtime le mandó dos identidades al modelo

La caída parecía un problema de modelo. Era un problema de plomería. Saqué el prompt exacto de la base de datos de sesiones de Hermes. El rol de sistema era un prompt de 14 mil caracteres que arranca con Hermes presentándose como Hermes Agent. La persona, “Eres Alex Hormozi, Chief Offer Architect”, llegaba después como mensaje de usuario. La persona nunca apareció en el system prompt.

A los modelos los entrenan para pesar más el rol de sistema. Así que el modelo recibió “generalista servicial” del sistema y “cerrador agresivo” del usuario, y eligió el promedio seguro. Correcto, genérico, y sin nada de lo que hacía valiosa la persona. El arreglo fue darle a cada agente una sola identidad, en un solo lugar, cargada donde el runtime la trata como identidad.

La lección que me llevé: probar modelos sin probar dónde cae tu prompt es medir solo la mitad del sistema.

El cuello de botella se movió hacia mí

Una empresa de agentes no te saca de la ecuación. Te mueve de productor a aprobador. Mis agentes produjeron tres paquetes de video y después esperaron en el único gate que necesita un humano, que era yo, y yo no estaba. Si no rediseñas el paso de aprobación, la org produce hacia una cola. Es la misma caída que sufren los equipos cuando la IA mueve el cuello de botella a la revisión.

Dejé el gate de todas formas. Los agentes producen. Yo publico. Una shortlist esperando un sí es un problema mucho mejor que un agente publicando en mi canal por su cuenta.

El agente es un narrador poco confiable

Cuando las herramientas desaparecieron, los agentes me contaron una historia detallada y segura sobre upstreams que nunca se conectaron. Les creí durante una hora. El log de ejecución contaba otra historia: una carrera de cold-spawn. Lo mismo pasó con el agente que murió en silencio. Su propio reporte no decía nada útil. El código del heartbeat sí.

La regla con la que opero hoy: nunca depures el relato del agente sobre una falla. Lee el log. Los dos arreglos se hicieron públicos: el pooler es mcp-pooler, y el keepalive es un pull request abierto contra el adapter de Nous Research.

El loop que finalmente se cerró

Paperclip despierta a un agente de tres formas: cuando le asignan un issue, cuando algo de lo que depende se resuelve, y con un timer. El diseño que funciona usa las tres con una sola disciplina. Solo los heads arrancan ciclos con un timer. Los especialistas nunca arrancan nada. Se despiertan cuando les asignan trabajo y en ningún otro momento.

Un ciclo del head de Library

Entrada

MrBeast se despierta con su timer

↓

1. ORIENTARLeer el motor, elegir el lente

   Lee el objetivo, los issues abiertos y el último ranking. Elige a través de qué sentido mirar esta semana: self, competidor, tendencia, frontera, comunidad o cliente.

   ↓
2. ENRUTARAbrir un issue para un especialista

   Lo asigna, escribe la vara de aceptación y la fecha límite ahí mismo, y lo crea abierto. Un trabajo que nace cerrado no despierta a nadie.

   ↓
3. TRABAJAREl especialista lee el mundo

   Neil lee los sensores a través de sus MCP servers y entrega. Después pone el issue en revisión y se lo devuelve al head, lo que despierta al head.

   ↓
4. JUZGARAceptar y avanzar, o devolver

   Una devolución se juzga, nunca se re-delega. El trabajo aceptado se vuelve la próxima demanda para el siguiente especialista de la cadena, aquí Gary.

   ↓
5. REPORTARReportar hacia arriba, cerrar el padre

   El head abre un nuevo issue de reporte para el chief of staff y cierra él mismo el issue padre del ciclo. El padre nunca sale de las manos del head.

↓

Salida

Una shortlist lista para decidir en el único gate humano: publicar

Cada paso de ese pipeline es una cicatriz. “Crearlo abierto” existe porque un trabajo que nació done despertaba a un asignado que no tenía nada que hacer. “Devolverlo al head” existe porque Paperclip solo deja que el asignado cambie un issue, así que la devolución de un especialista nunca despertaba a nadie. “Nunca re-delegado” es el loop. “El padre nunca sale de las manos del head” es la vez que un head le pasó todo el ciclo al chief of staff a mitad de camino.

Dónde está hoy

El loop se cerró el 22 de julio. El tablero está en silencio desde esa tarde: el último heartbeat en toda la org es de ese día. Asumí un rol más grande en mi trabajo, y esta org existía para hacer que un negocio unipersonal funcionara con las horas que me quedaban. Cuando esas horas se fueron a otro lado, la org se quedó en silencio con ellas. Esa es la propiedad honesta de una empresa de agentes con un solo gate humano. Sin humano en el gate, no hay empresa.

Solo uno de los cinco heads, MrBeast, corrió alguna vez un ciclo, y eso es a propósito. Library era el motor con demanda real detrás. Los otros cuatro manejan líneas de negocio que todavía no validé, un SaaS entre ellas. Despertar a un head para manejar un negocio que todavía no existe es teatro. Cada uno entra en vivo cuando su negocio también lo hace, en los próximos meses.

Lo estoy volviendo a prender a medida que mis canales de YouTube y mis cuentas sociales se reactivan. Esta vez la org recibe un trabajo más acotado: manejar la operación de un creador, la cadencia diaria de canales y publicaciones, conmigo de vuelta en el gate cada mañana.

Cuándo vale la pena Paperclip

Antes de construir una empresa de agentes

• ✓Obligatorio:
  Tienes más de un frente que necesita un juicio distinto.Contenido, ofertas y funnels son tres juicios. Una persona con una sola tarea no necesita una jerarquía. Solo le agrega latencia.
• ✓Obligatorio:
  Dos o tres persona skills ya funcionan en una sesión simple.La org multiplica skills que ya tienes. No los crea.
• ✓Obligatorio:
  Tu contexto vive en archivos que los agentes pueden leer.Un second brain, un AGENTS.md, un canon de lo que nunca haces. El conocimiento que se repite va ahí, no dentro de un agente.
• ✓Obligatorio:
  Cada especialista llega a datos reales a través de MCP.Un agente sin sensor está ciego y adivinando. El MCP server es el puente del sensor al dato.
• ✓Obligatorio:
  Sabes exactamente dónde está el gate humano, y apareces en él.El mío es publicar. Si no estás ahí cada mañana, la org produce hacia una cola.
• ✓Obligatorio:
  Empiezas con el loop más chico que cierra.Un input que escribes a mano, un agente que piensa y propone, decides tú, se publica. Automatiza la recolección de datos al final, no primero.

Paperclip, respuestas rápidas

¿Qué es Paperclip AI?+

Paperclip es una app open-source, con licencia MIT, para correr agentes de IA como una organización: un organigrama, issues que los agentes se asignan entre ellos, presupuestos, aprobaciones y heartbeats que despiertan a los agentes con un timer o cuando llega trabajo. No corre un modelo por sí mismo. Cada agente se conecta a través de un adapter a un runtime como Claude Code, Codex, OpenClaw o Hermes Agent.

¿Paperclip corre los agentes?+

No. Paperclip programa, enruta y registra. El pensamiento pasa en el runtime detrás del adapter de cada agente.

Por eso la mayoría de los bugs de producción viven en el adapter: identidad, contexto del wake, liveness y conteo de tokens cruzan todos esa frontera.

¿Cuál es la diferencia entre Paperclip y Hermes Agent?+

Paperclip es la capa de org. Hermes Agent es un runtime de agentes con sus propias herramientas, memoria, skills y gateways de mensajería.

En mi setup, cada agente de Paperclip corre sobre Hermes, y un Hermes separado en Telegram es mi asistente personal, conectado al tablero de Paperclip para poder abrir issues por voz.

¿Paperclip es una empresa sin humanos?+

La mía no, a propósito. Los agentes producen, enrutan y se juzgan entre ellos, pero publicar pasa por un solo gate humano. Una shortlist esperando un sí es un problema mucho mejor que un agente publicando en tu canal sin supervisión.

¿Qué modelo deberían usar los agentes de Paperclip?+

Deja que el runtime sea dueño del modelo, no el orchestrator. Mi adapter dejó de pasar un modelo y lo lee de la propia config de Hermes. En estas semanas la flota corrió sobre GLM-5.1 vía Z.AI y después DeepSeek V4 Flash vía OpenRouter.

Los especialistas acotados andan bien con modelos más chicos. Prueba dónde cae tu persona en el prompt antes de culpar al modelo: el mismo modelo sacó hasta un 26 por ciento menos en mi setup porque el runtime le mandó dos identidades.