Esta es la primera edición de un informe que planeamos actualizar cada trimestre: qué le pide la gente a los agentes de programación de otros y qué ocurre cuando lo hace. Los datos proceden de la beta privada de muti, abarcan los treinta días previos al 6 de septiembre de 2026 y la muestra es pequeña: cincuenta y ocho peticiones, seis máquinas y diez salas. Lo publicamos aun así porque nadie más está publicando datos sobre agentes compartidos, y unas cifras modestas y honestas son mejores que cifras astronómicas inventadas.
Todas las cifras son agregadas. Ni texto de peticiones, ni nombres personales, ni nombres de salas.
Las cifras
Cinco cifras de los primeros treinta días, con sus denominadores.
Qué creemos que significan
Un tercio de peticiones de no propietarios es una cifra alta para una beta sin marketing. Los propietarios invitaron a personas y esas personas usaron el agente. Compartir es el producto, y ocurrió de forma espontánea.
Las aprobaciones son rápidas cuando son poco frecuentes. Nueve aprobaciones en cincuenta y ocho peticiones, respondidas en una mediana de 38 segundos. Ese es el comportamiento que persigue el diseño: las cuatro acciones que siempre pausan y los modos de permisos mantienen los avisos al mínimo, de modo que los prompts que quedan se revisan con atención. Consulta cuatro acciones en las que un agente siempre debería pedir permiso antes de ejecutarlas.
Bash pide permiso. La mayoría de las aprobaciones fueron comandos de shell. Las lecturas y ediciones de archivos se ejecutaron en su mayor parte bajo acceptEdits; las situaciones en las que se requirió un humano fueron comandos. Eso encaja con el objetivo para el que se diseñaron los modos de permisos.
Los fallos son en su mayoría errores del runtime, no de permisos. Fallaron diez peticiones; en el timeline se reflejan como fallos en tests, herramientas ausentes y un timeout del runtime. Ninguno se debió a una aprobación denegada.
Cuarenta y un segundos es la duración de la tarea mediana. Por ahora, a los agentes compartidos se les piden tareas pequeñas y concretas: vuelve a ejecutar esto, resume aquello, exporta esto otro. Las refactorizaciones largas son poco comunes y suelen ser iniciativa del propietario.
Qué no significan las cifras
- No son representativas. Seis máquinas, en su mayoría nuestras y de nuestros amigos. La proporción de peticiones de no propietarios caerá a medida que crezca la base de propietarios antes de volver a subir.
- Que se complete no implica que sea correcto. «Done» significa que el runtime terminó sin errores; si el resultado fue bueno o no, no se mide aquí.
- La latencia de aprobación depende del propietario. Nueve puntos de datos, varios propietarios, un solo número. Es mejor interpretarlo como «menos de un minuto» que como «38 segundos».
Qué añadiremos
Próxima edición: categorías de peticiones (código / documentos / datos / archivos), porcentaje de peticiones con archivos adjuntos y latencia de aprobación por hora del día. Todo de forma agregada, todo publicado con sus denominadores.
Metodología
Las cifras proceden de las mismas tablas en las que opera el producto: peticiones, aprobaciones de herramientas, membresías de salas y eventos del timeline, contabilizados por días UTC. Sin muestreo. Las salas y agentes eliminados mediante borrado suave se excluyen de los recuentos «actuales» y se incluyen en los recuentos «históricos». El modelo de auditoría se describe en lo que debe registrar un log de auditoría.
Preguntas frecuentes
¿Puedo acceder a los datos sin procesar? No. Solo publicamos los datos agregados; las peticiones son privadas dentro de sus salas.
¿Por qué publicar con n = 58? Porque la alternativa es no publicar nada y porque indicar el denominador permite a los lectores valorar la muestra. La próxima edición será más amplia o explicará por qué no lo es.
¿Con qué frecuencia? Trimestralmente, con las mismas métricas para poder compararlas, además de las novedades anunciadas en la edición anterior.
Si quieres aparecer en la próxima edición, dale una sala a tu agente.
Publicado el