Paperclip

Hasta ahora, el uso de la IA normalmente seguía un modelo sencillo: una persona trabajaba con un agente, le planteaba una tarea y el agente la ejecutaba hasta completarla.

Pero con el desarrollo de los AI Coding Agents y los Autonomous Agents, el modelo de trabajo está empezando a cambiar:

Humano
 ↓
Agent Manager
 ↓
Múltiples agentes especializados
 ├─ Developer
 ├─ Designer
 ├─ Researcher
 ├─ Marketer
 └─ Reviewer

Cuando aumenta el número de agentes, el problema deja de ser simplemente “¿es suficientemente inteligente el modelo?”.

¿Quién distribuye el trabajo? ¿Quién sabe qué está haciendo cada agente? ¿Quién controla el coste de los tokens? ¿Quién retoma una tarea cuando un agente falla? ¿Qué operaciones requieren aprobación humana?

Ese es precisamente el problema que Paperclip intenta resolver.

¿Qué es exactamente Paperclip?

Paperclip se define oficialmente como un “control plane for autonomous AI companies”. No es un nuevo modelo de IA, tampoco un Agent Framework ni un simple gestor de tareas. Se sitúa por encima del Agent Runtime como una capa de organización y control.

Podemos entenderlo así:

                 Paperclip
                    │
       ┌────────────┼────────────┐
      Goals       Agents       Tasks
       │            │            │
    Budgets      Org Chart    Governance
       │            │            │
       └────────────┼────────────┘
                    ↓
             Agent Execution
        ┌───────────┼───────────┐
     Claude       Codex       Cursor

Aquí existe un límite arquitectónico muy importante: Paperclip gestiona los agentes, pero no sustituye a los propios agentes.

Los agentes se conectan mediante Adapters, mientras que la ejecución real continúa siendo responsabilidad de Claude Code, Codex, Cursor, OpenCode u otros Runtime. La documentación oficial de Adapters ya contempla diferentes tipos de integraciones locales mediante CLI, HTTP, Process y Gateway.

Por tanto, lo que Paperclip intenta construir es una separación entre Control Plane y Execution Plane dentro del ecosistema de agentes.

¿Por qué un solo agente no es suficiente?

Cuando solo existe un agente, el flujo es muy sencillo:

Usuario → Agent → Resultado

Pero cuando el sistema empieza a tener CEO, CTO, ingenieros, diseñadores e investigadores trabajando simultáneamente, el problema se convierte rápidamente en una cuestión organizativa.

Por ejemplo, después de que un Developer Agent termine el código, ¿quién lo revisa? Cuando un Research Agent encuentra información, ¿quién la utiliza? Si un agente se queda bloqueado, ¿quién lo detecta? Y si hay diez o veinte agentes funcionando simultáneamente, ¿cómo se evita que trabajen dos veces sobre el mismo problema?

Los Multi-Agent Frameworks tradicionales suelen centrarse en una pregunta:

¿Cómo pueden comunicarse los agentes?

Paperclip se sitúa en un nivel superior:

¿Cómo debería funcionar como organización un grupo de agentes?

Ese es uno de los aspectos más interesantes del proyecto.

Tratar a los agentes como “empleados”

Uno de los principales conceptos de Paperclip es modelar cada Agent como un Employee dentro de una organización.

Cada agente puede tener un rol, una relación jerárquica, determinadas capacidades, un presupuesto, un estado y un Adapter correspondiente. Además, puede formar parte de una estructura organizativa definida, desde un CEO hasta diferentes responsables y equipos de ingeniería.

Esto es claramente diferente del modelo habitual:

Agent A ↔ Agent B ↔ Agent C

Paperclip se acerca más a:

Company
  ↓
CEO
  ↓
CTO
  ↓
Engineering
  ↓
Engineer

En la práctica, esto introduce una serie de restricciones organizativas en la coordinación entre agentes.

Su importancia no está necesariamente en que la IA tenga que imitar a una empresa humana, sino en que los sistemas autónomos complejos realmente necesitan responsabilidades, permisos y límites claros.

Pero aquí también aparece una de las principales hipótesis de producto de Paperclip: ¿la estructura de una empresa realmente es adecuada para todos los flujos de trabajo de agentes?

Para determinadas tareas, una estructura como Planner → Worker → Reviewer puede ser más natural que CEO → CTO → Engineer.

Por tanto, la idea de una “AI company” es al mismo tiempo una de las principales abstracciones de Paperclip y una decisión de diseño que tendrá que demostrar su utilidad a largo plazo.

Goal Alignment: no solo “qué hacer”, sino también “por qué hacerlo”

Otro diseño importante de Paperclip es la Goal Hierarchy.

Las tareas no existen necesariamente de forma aislada. Pueden estar vinculadas a objetivos organizativos de mayor nivel. El modelo oficial plantea que el trabajo puede remontarse finalmente hasta los objetivos de la compañía.

Por ejemplo:

Objetivo de la empresa
 ↓
Objetivo de producto
 ↓
Objetivo de ingeniería
 ↓
Tarea concreta
 ↓
Ejecución del Agent

Un Task Manager convencional intenta responder:

¿Quién es responsable de esta tarea?

Pero un sistema de agentes autónomos necesita responder también:

¿Por qué hay que hacer esta tarea?

Esto puede influir en la interpretación de prioridades, la asignación de recursos y las acciones posteriores del agente.

Sin embargo, conviene mantener cierta cautela: transmitir objetivos a un agente no significa que este haya desarrollado una comprensión estratégica estable. Las decisiones finales siguen dependiendo del razonamiento del modelo, el estado de la tarea y la calidad del contexto disponible.

Heartbeat es uno de los mecanismos clave del sistema

Paperclip no intenta mantener a los agentes funcionando permanentemente.

Utiliza un modelo de Heartbeat: el agente se despierta cuando ocurre un determinado evento, ejecuta un ciclo de trabajo y después termina. Entre los posibles activadores se encuentran los horarios programados, la asignación de tareas, las menciones, las activaciones manuales y los resultados de aprobaciones.

Podemos entenderlo así:

Wake Up
 ↓
Leer la tarea
 ↓
Ejecutar el trabajo
 ↓
Actualizar el estado
 ↓
Registrar el resultado
 ↓
Esperar el siguiente Heartbeat

Este diseño es importante.

Si varias decenas de agentes estuvieran funcionando 24/7, el coste de tokens y de infraestructura podría crecer rápidamente fuera de control. Heartbeat convierte al agente de un “proceso permanente” en un trabajador digital que funciona bajo demanda.

Además, en la arquitectura actual, Heartbeat actúa principalmente como un protocolo de activación. La ejecución concreta continúa dependiendo del Adapter. Un ciclo de Heartbeat pasa por distintas fases: activación, llamada al Adapter, ejecución del agente, captura del resultado y registro del Run Record.

Esto también introduce un desafío: el estado de las tareas debe ser suficientemente fiable. De lo contrario, cada vez que el agente se despierte podría tener que reconstruir de nuevo el contexto.

Budget y Governance son fundamentales para llevar los agentes autónomos a producción

Uno de los principales problemas reales de los sistemas Multi-Agent es el coste.

Si varios agentes funcionan automáticamente:

Número de agentes
×
Número de Heartbeats
×
Consumo de tokens

el gasto puede crecer rápidamente.

Por eso Paperclip ofrece presupuestos tanto a nivel de compañía como de agente y realiza un seguimiento de los costes. Con los mecanismos actuales, alcanzar determinados umbrales presupuestarios puede provocar la pausa automática de un agente.

Esto significa que Budget no es simplemente una función financiera adicional, sino uno de los límites de seguridad de un sistema autónomo.

Governance aborda otra cuestión fundamental:

¿Hasta dónde puede actuar un agente de forma autónoma?

Paperclip incorpora actualmente mecanismos de aprobación, pausa, reanudación, terminación y auditoría. Su MCP Access Governance también añade políticas a nivel de herramienta, como allow, block, require approval y rate limit.

Esto diferencia claramente a Paperclip de una simple demostración Multi-Agent:

Qué puede hacer el agente
+
Cuánto dinero puede gastar
+
Por qué está haciendo algo
+
Cuándo puede intervenir un humano

Son precisamente estas cuestiones las que un sistema autónomo de larga duración necesita resolver.

Adapter: uno de los diseños arquitectónicos más interesantes de Paperclip

Paperclip no obliga al usuario a reconstruir sus agentes desde cero.

Utiliza Adapters para conectar diferentes Runtime al Control Plane. La documentación oficial contempla actualmente integraciones con Claude Code, Codex, Cursor, OpenCode, Pi, HTTP, Process, OpenClaw Gateway y otros métodos de conexión.

La arquitectura queda así:

Paperclip
   ↓
Adapter
   ↓
Agent Runtime

Esto ofrece una ventaja importante: el Control Plane queda desacoplado del Agent Runtime concreto.

Hoy puedes utilizar Claude Code, mañana cambiar a Codex o incluso conectar un Agent HTTP personalizado. En teoría, la estructura organizativa, las tareas, los presupuestos y la capa de gobernanza pueden mantenerse sin cambios.

Esto se acerca más a una filosofía de infraestructura que una plataforma Multi-Agent completamente vinculada a un único modelo.

¿Dónde está realmente el valor de Paperclip?

Lo más interesante de Paperclip no es simplemente que tenga un “Org Chart” o un “CEO Agent”.

Su verdadero objetivo parece ser llevar los sistemas Multi-Agent desde:

varios agentes que se llaman entre sí

hacia:

una fuerza de trabajo de agentes que puede organizarse, programarse, auditarse y controlarse.

Paperclip intenta cubrir aspectos que muchos Agent Frameworks tradicionales no priorizan:

Agent
 ↓
Organization
 ↓
Goals
 ↓
Tasks
 ↓
Budget
 ↓
Governance
 ↓
Audit

Especialmente interesantes son el modelo de Heartbeat, la gestión presupuestaria, el estado de las tareas y la separación entre Control Plane y Adapter, porque todos ellos están relacionados con problemas de ingeniería que aparecen al ejecutar sistemas autónomos durante largos periodos.

Pero “AI company” también puede ser simplemente una buena metáfora de producto

El principal riesgo de Paperclip es que trasladar el modelo de gestión de una empresa humana a los agentes de IA podría hacer que la propia estructura organizativa se convierta en una carga.

Una tarea sencilla que originalmente solo requería:

Agent → Completar

podría transformarse en:

CEO
 ↓
Manager
 ↓
Engineer
 ↓
Reviewer

generando más tokens, latencia, comunicación y costes de gestión del estado.

Tener más agentes tampoco significa automáticamente conseguir una mayor eficiencia.

Además, cuanto más sofisticado sea el sistema de Governance, mayores serán los costes de configuración y mantenimiento. Para un desarrollador que solo utiliza Claude Code o Codex ocasionalmente, un Control Plane de este tipo probablemente añadiría complejidad innecesaria.

La propia documentación de Paperclip establece claramente sus límites en torno al control y la orquestación, en lugar de convertirlo en un chatbot o una herramienta de revisión de código.

Paperclip frente a otras herramientas de agentes

Por tanto, Paperclip no necesariamente tiene que sustituir a estas herramientas.

Su función es añadir una capa superior:

Agent Organization Control Plane

Esta es probablemente su propuesta más clara.

¿Cuándo tiene sentido utilizar Paperclip?

Si solo existe un agente y utilizas ocasionalmente Claude Code o Codex para completar tareas de desarrollo, Paperclip probablemente represente una complejidad adicional innecesaria.

Pero la situación cambia cuando empiezan a aparecer:

• múltiples agentes funcionando durante largos periodos;
• diferentes Agent Runtimes;
• asignación automática de tareas;
• relaciones jerárquicas entre agentes;
• control continuo de presupuestos;
• sistemas de aprobación y auditoría;
• ejecución autónoma durante periodos prolongados.

En ese punto, simplemente “conectar varios agentes” empieza a resultar insuficiente.

El valor de Paperclip aumenta precisamente a medida que crecen el número de agentes, el nivel de autonomía y el tiempo de ejecución.

Valoración final

Conclusión

Paperclip no intenta resolver “cómo hacer que un Agent sea más inteligente”. Está abordando una cuestión diferente que será cada vez más importante:

Cuando un Agent deja de ser una herramienta individual y se convierte en una Workforce, ¿quién gestiona esa Workforce?

Heartbeat resuelve cómo despertar a los agentes y permitirles trabajar de forma recurrente; Budget controla el coste de la autonomía; Goal Alignment conecta las tareas con los objetivos de la organización; Governance establece los límites de autonomía; y Adapter desacopla estas capacidades de control del Agent Runtime concreto.

Por eso, el concepto de “AI company” no es únicamente una idea de marketing. Desde el punto de vista de la arquitectura, Paperclip intenta reunir organización, tareas, costes, permisos y ejecución dentro de un mismo Control Plane.

Pero todavía queda por comprobar hasta qué punto este modelo resulta adecuado para todos los sistemas Multi-Agent. Para tareas sencillas puede convertirse en una arquitectura excesiva. En cambio, cuando decenas de agentes funcionan de forma autónoma durante largos periodos, el problema deja de ser simplemente “cómo hacer que los agentes colaboren”.

Pasa a ser una cuestión mucho más amplia:

cómo conseguir que todo un sistema de agentes pueda funcionar de forma observable, controlable y gobernable.

Y probablemente ahí es donde está la parte más interesante de Paperclip.