En resumen: agency-agents es la colección curada más grande de personas de agentes de IA en GitHub, con 149,312 estrellas a partir del 1 de septiembre de 2026. Incluye más de 300 archivos de definición de agentes en aproximadamente 20 carpetas de categorías y los instala en Claude Code, Cursor, Codex, Gemini CLI, OpenCode, Windsurf, Aider y una docena de otras herramientas con un solo comando. Lo que obtienes es un marco, no una capacidad. Las personas cambian la forma en que tu agente aborda una tarea; no le proporcionan hechos que no tiene, y no persisten más allá de la sesión.
Esto es un análisis en profundidad de una herramienta de nuestro resumen de cinco herramientas de agentes de IA de código abierto que vale la pena instalar en 2026.
Tu agente de codificación tiene una personalidad: generalista útil. Pídele que revise un flujo de autenticación y obtendrás consejos sensatos, pero olvidables. Pídele a un revisor de seguridad con un modelo de amenazas y una lista de verificación, y obtendrás hallazgos.
Esa brecha es lo que agency-agents llena. Comenzó como un hilo de Reddit sobre la especialización de agentes y creció hasta convertirse en una lista tan grande que instalarlo todo rompe al menos un tiempo de ejecución de agente popular. Esto es lo que hay realmente dentro, cómo instalar las partes que deseas y las dos cosas que una biblioteca de personas no puede hacer por ti.
Lo que realmente estás instalando
Cada agente es un archivo markdown. No es un prompt de sistema de una línea, ni un plugin con código. Un archivo contiene una identidad y personalidad, una misión principal, un proceso de trabajo, entregables técnicos con ejemplos y métricas de éxito.

Contando los archivos markdown en el árbol del repositorio el 1 de septiembre de 2026, hay 312 distribuidos en 20 carpetas de categorías de nivel superior, o 306 una vez que excluyes el directorio examples/. La distribución está desequilibrada hacia la construcción de cosas:
| División | Archivos de agente |
|---|---|
| ingeniería | 59 |
| especializado | 58 |
| marketing | 36 |
| desarrollo de juegos | 21 |
| integraciones | 18 |
| estrategia | 16 |
| gis | 13 |
| seguridad | 12 |
| diseño | 10 |
| ventas | 9 |
| pruebas | 9 |
| medios de pago | 7 |
| gestión de proyectos | 7 |
| académico | 6 |
| computación espacial | 6 |
| soporte | 6 |
| finanzas | 5 |
| producto | 5 |
| salud | 3 |
Cabe señalar que el README del repositorio todavía anuncia "más de 230 agentes". Esa línea está obsoleta. El árbol ha superado los 300.
La división de ingeniería es donde la mayoría de los desarrolladores comenzarán, y la especificidad es mayor de lo que cabría esperar de una colección de prompts. Junto a las entradas obvias de Desarrollador Frontend y Arquitecto Backend, hay un Ingeniero de Redes enfocado en Cisco IOS-XE, Juniper Junos y Palo Alto PAN-OS, un Ingeniero de Firmware Embebido para objetivos ESP32, STM32 y Nordic, un Comandante de Respuesta a Incidentes para post-mortems y preparación para guardias, y un Ingeniero de Integración de Codebase escrito para explorar un repositorio de solo lectura y declarar hechos sobre él en lugar de proponer cambios.
Ese último es un buen ejemplo de que el patrón funciona. Una persona de solo lectura con un mandato explícito de no edición es una herramienta genuinamente diferente de tu agente predeterminado, y no cuesta nada más que un archivo.
Instalación sin romper tu configuración
El repositorio incluye scripts de conversión e instalación. La ruta interactiva detecta lo que tienes instalado y pregunta qué quieres:
git clone https://github.com/msitarzewski/agency-agents.git
cd agency-agents
./scripts/install.sh
Dirigirse a una herramienta específica y a un subconjunto de divisiones es la opción predeterminada más sensata:
# todo, en Claude Code
./scripts/install.sh --tool claude-code
# solo dos divisiones
./scripts/install.sh --tool claude-code --division engineering,security
# solo agentes nombrados
./scripts/install.sh --tool cursor --agent frontend-developer,ui-designer
# ver lo que existe antes de confirmar
./scripts/install.sh --list teams
./scripts/install.sh --tool opencode --division engineering --dry-run
Los objetivos compatibles incluyen Claude Code, Cursor, Codex, Gemini CLI, OpenCode, GitHub Copilot, Windsurf, Aider, Kimi Code, Hermes, Antigravity, Osaurus y Mistral Vibe. También hay una aplicación de escritorio nativa en agencyagents.app para macOS, Linux y Windows que permite explorar la lista, instalar con un clic y se actualiza automáticamente, además de un cask de Homebrew.
Lee esto antes de instalarlo todo. El tiempo de ejecución de OpenCode actualmente solo registra alrededor de 119 agentes y descarta silenciosamente el resto, lo cual el repositorio documenta como un error de origen. Instalar un subconjunto con --division te mantiene por debajo del límite, y el instalador te advierte cuando una selección lo superaría. La truncación silenciosa es el peor modo de fallo que existe, porque el agente que querías falta y nada te lo dice.
Incluso fuera de ese error específico, instalar 300 personas es una mala idea. Una lista que no puedes recordar es una lista que no usarás. Instala las dos divisiones en las que trabajas, lee cuatro o cinco de los archivos y elimina los que no coincidan con la forma en que tu equipo realmente opera.
Lo que una persona cambia y lo que no
Una persona es un marco. Establece lo que el agente busca, el formato que produce y lo que considera terminado. Eso vale más de lo que parece, porque gran parte de la mala salida del agente no es que el modelo esté equivocado, sino que el modelo optimiza para la forma de respuesta incorrecta.
Lo que una persona no puede hacer es proporcionar información que el modelo no tiene. Este es el límite que la gente descubre a la semana, y se manifiesta con mayor dificultad en torno a las APIs.
Carga el Arquitecto Backend y pídele que escriba un cliente para tu servicio de facturación interno. Producirá código limpio e idiomático contra una forma de respuesta que inventó. No tiene forma de saber que tu servicio devuelve un 409 con un sobre de error diferente cuando una clave de idempotencia se repite, o que el cursor de paginación es opaco en lugar de un desplazamiento. La persona hizo que el código estuviera mejor organizado. No lo hizo correcto.
El mismo límite se aplica a la división de pruebas. Una persona de QA escribe pruebas exhaustivas contra su propio modelo mental de la API, por lo que las pruebas pasan y no prueban nada. Cubrimos por qué ese bucle específico es peligroso en pruebas de agentes de IA no deterministas, y qué se rompe cuando la forma real cambia en qué sucede cuando los cambios de API rompen los agentes de IA.
La solución es darle al agente el contrato en lugar de esperar que la persona compense. Si tu API está diseñada en Apidog, la especificación OpenAPI es la fuente de la verdad: esquemas reales, códigos de estado reales, sobres de error reales. El agente los lee en lugar de reconstruirlos a partir de sitios de llamada. Los mocks se generan a partir de esa misma especificación, incluyendo las ramas de error que una persona nunca pensaría en simular, y el conjunto de pruebas falla ruidosamente en CI cuando la realidad y la especificación divergen.

Ese emparejamiento es el modelo mental útil. La persona decide cómo trabaja el agente. La especificación decide qué es verdad. Lecturas relacionadas: usar tu especificación OpenAPI como herramientas para agentes y diseñar esquemas de herramientas de API para agentes. Si deseas integrar una especificación en vivo en el contexto de tu agente, descarga Apidog y apúntalo a tu proyecto existente.
El segundo límite: una persona no es un equipo
Aquí está lo que la metáfora de la lista promete y no cumple.
La propuesta es una agencia completa a tu alcance. En la práctica, activas una persona en una sesión, realiza una tarea y la sesión termina. Mañana vuelves a teclear la activación. No hay equipo, porque no hay nada persistente: ninguna asignación, ningún registro de lo que el revisor de seguridad encontró el martes pasado, y ninguna forma para que un colega vea nada de eso. Nueve de las divisiones en este repositorio describen roles que solo tienen sentido dentro de una organización, y la herramienta que las instala no tiene concepto de una.
Si quieres que la idea de la lista sobreviva más allá de una única sesión de terminal, la capa que falta es la gestión del trabajo. Sharkly está construido precisamente para eso, y el mapeo con agency-agents es lo suficientemente cercano como para que valga la pena detallarlo.

- Un Agente en Sharkly es una configuración guardada, no un prompt que vuelves a escribir. Contiene instrucciones, tiempo de ejecución, habilidades, repositorios y entorno. Una persona que ajustaste una vez se reutiliza, que es la versión duradera de lo que busca un archivo
.mden~/.claude/agents/. - Una Tripulación es un agente líder más otros agentes y personas. Este es el concepto de división con mecánicas reales. Las tripulaciones operan primero con el líder: el líder lee el contexto de la tarea, decide qué miembros incorporar y combina sus resultados en un solo lugar, en lugar de que cada especialista comience a la vez y corra.
- El trabajo se asigna, no se invoca. Le das una tarea a un Agente de la misma manera que se la das a un compañero de equipo. Vive en un espacio, un proyecto y un sprint, con sincronización de Jira si tu equipo ya trabaja allí.
- La ejecución es de tu parte. Conectas una Computadora, que puede ser tu portátil, un servidor o un contenedor, y Sharkly usa el Tiempo de Ejecución ya instalado en ella. Tu suscripción a Claude Code o Codex hace el trabajo; nada te revende tokens.
- La salida es revisable. El progreso, las llamadas a herramientas y los resultados se transmiten de vuelta a la tarea, y la salida del agente aparece como comentarios a los que puedes responder. Una tarea en el Backlog no inicia una ejecución, por lo que puedes preparar el trabajo antes de que se ejecute algo.
En pocas palabras: agency-agents te da las descripciones de los puestos de trabajo, y Sharkly te da el lugar donde esos trabajos se asignan, ejecutan y revisan. Usa el repositorio como una biblioteca de definiciones de roles para sembrar Agentes reales en lugar de como una carpeta que instalas y olvidas.
Escribe el tuyo propio, usando el suyo como plantilla
Lo más duradero que este repositorio te ofrece es un formato. Una vez que hayas leído algunos archivos, escribir una persona para tu propia pila toma unos quince minutos, y una específica de la casa siempre supera a una genérica.
La estructura que se repite en los archivos buenos:
- Identidad y voz. Quién es este agente y cómo se comunica. Suena cosmético, y es la parte que impide que el agente vuelva al modo de asistente genérico a la mitad de una tarea larga.
- Misión principal. Una frase sobre lo que significa el éxito. El archivo del Ingeniero de Integración de Codebase es un ejemplo claro: explorar de solo lectura, rastrear rutas de código, declarar hechos sobre la estructura y el comportamiento, no proponer nada.
- Proceso de trabajo. Pasos ordenados que sigue el agente. Esta es la sección que vale la pena robar. Una persona de revisión con un proceso de siete pasos produce una salida consistente en todas las sesiones; una sin él produce lo que el modelo haya sentido ese día.
- Entregables. Los artefactos concretos, con formato. Di “una tabla markdown de hallazgos con severidad, ruta de archivo y número de línea” en lugar de “un informe”.
- Métricas de éxito. Cómo el agente sabe que ha terminado, lo que también sirve como el criterio con el que verificas su trabajo.
Una versión propia para el trabajo de API podría verse así:
# Revisor de Contratos de API
## Misión
Verificar que los endpoints nuevos o modificados coincidan con la especificación OpenAPI en este
repositorio antes de que lleguen a revisión. Reportar las discrepancias. No editar código.
## Proceso
1. Leer la especificación de cada endpoint afectado por el diff actual.
2. Para cada uno, comparar el manejador con la especificación: códigos de estado,
esquema de respuesta, sobre de error, encabezados requeridos, estilo de paginación.
3. Ejecutar las pruebas de contrato. Registrar los fallos textualmente.
4. Comprobar que se añadieron nuevos endpoints a la especificación, no solo al enrutador.
5. Marcar cualquier campo de respuesta presente en el código y ausente en la especificación.
## Entregables
Una tabla: endpoint, método, tipo de discrepancia, línea de especificación, línea de código, severidad.
Sin resumen en prosa. Sin soluciones sugeridas a menos que se solicite.
## Hecho cuando
Cada endpoint en el diff aparece en la tabla con un veredicto, y la
salida de la prueba de contrato se incluye como evidencia.
Ese archivo es corto y hace más por un equipo de backend que cualquiera de las 59 personas de ingeniería incluidas en el repositorio, porque nombra tu especificación, tus pruebas y tu definición de lo que está hecho. El tercer paso es la parte que importa: la persona recibe instrucciones de producir evidencia en lugar de una opinión, lo que es la diferencia entre una revisión sobre la que puedes actuar y un párrafo de tranquilidad.
El mismo truco funciona para la respuesta a incidentes, el trabajo de migración, las actualizaciones de dependencias y la integración. Toma la estructura del archivo, mantén la disciplina del proceso, reemplaza el contenido genérico con el tuyo. Cuando la salida del agente tiene que sobrevivir a una entrega a un humano o a otro agente, el contrato de formato hace la mayor parte del trabajo, que es el punto que señalamos en entrega de agente y paso de contexto.
¿Son significativos los recuentos de estrellas aquí?
149,312 estrellas es mucho, y merece una advertencia. Los repositorios de personas acumulan estrellas más rápido que casi cualquier otra categoría porque son fáciles de entender, fáciles de compartir y no cuestan nada probarlos. Una estrella significa que alguien pensó que era una buena idea, no que todavía la use.
Lo que hace creíble a este repositorio es la forma del trabajo más que el número. Tiene un historial de contribuciones real desde octubre de 2025, tiene licencia MIT, documenta sus propios límites incluyendo el tope de registro de OpenCode, y los archivos de agente contienen contenido de dominio específico en lugar de información genérica de roles. Compara eso con los muchos repositorios de “prompts impresionantes” que alcanzaron su punto máximo y se detuvieron.
Júzgalo abriendo tres archivos en una división que conozcas bien. Si el archivo de Desarrollador Frontend dice cosas que diría un buen desarrollador frontend, el resto probablemente está bien. Si parece una oferta de trabajo, omite el repositorio.
Cómo obtener valor real de ello
Un flujo de trabajo que se sostiene:
- Instala una división. Elige la que coincida con tu trabajo diario. Ingeniería para la mayoría de los lectores.
- Lee los archivos. Cuatro o cinco, de principio a fin. Estás buscando las secciones de proceso, que son la parte que vale la pena conservar.
- Edítalos. Añade tu pila, tus convenciones, tu definición de lo que está hecho. Una persona que describe una tienda React genérica vale menos que el mismo archivo con tus reglas de prueba.
- Da entradas reales a las personas editadas. Un revisor de seguridad con tu especificación OpenAPI encuentra problemas de contrato. El mismo revisor sin ella produce una lista de verificación.
- Promueve los que se mantengan. Cualquier persona a la que recurras dos veces por semana debería convertirse en un Agente guardado en un sistema de gestión del trabajo en lugar de un archivo que copias entre máquinas.
Ese último paso es donde los equipos o escalan esto o lo abandonan silenciosamente.
Preguntas Frecuentes
- ¿Funciona agency-agents con Cursor y Codex, o solo con Claude Code? Con todos ellos. El script
convert.shgenera archivos de integración por herramienta yinstall.sh --toolapunta a una específica. Se admiten Claude Code, Cursor, Codex, Gemini CLI, OpenCode, Copilot, Windsurf, Aider, Kimi Code y varios otros. Si estás comparando clientes de agentes para trabajar con APIs, consulta nuestro análisis de los clientes de API en Cursor y Copilot. - ¿Debería instalar los 300 agentes? No. En OpenCode no puedes, porque el tiempo de ejecución registra aproximadamente 119 y descarta el resto silenciosamente. En otras herramientas técnicamente puedes, y nunca usarás la mayoría de ellas. Instala por división.
- ¿Las personas hacen que el agente sea más inteligente? Lo hacen mejor dirigido. La precisión en preguntas de hecho, incluyendo lo que tu API devuelve, no cambia. Eso necesita una especificación real, que es el argumento en ¿todavía necesitas una herramienta API en la era de los agentes de IA?
- ¿Es seguro ejecutar el script de instalación? Escribe archivos de definición de agentes en los directorios de configuración de tu herramienta. Ese es su propósito. Tiene licencia MIT con la fuente completa disponible, y
--dry-runte muestra lo que haría antes de hacerlo. Ejecuta la prueba en seco primero. El principio general sobre lo que dejas que los agentes toquen está en barreras de seguridad de los agentes de IA. - ¿Cuál es la diferencia entre esto y un framework de agentes? Si quieres que las personas se ejecuten varias a la vez en lugar de una por sesión, eso es Orca. Un framework como Strands o AgentKit te proporciona orquestación en tiempo de ejecución en código. agency-agents te da archivos markdown que cambian cómo se comporta un agente existente. Una capa diferente, sin superposición.
Conclusión
agency-agents es la mejor versión de una idea específica: tu agente hace un mejor trabajo cuando sabe qué papel está desempeñando. Instala una división, lee los archivos, edítalos para que coincidan con tu equipo y obtendrás un valor real con unos veinte minutos de configuración.
Luego, sé honesto sobre las dos cosas que no resuelve. Las personas no saben lo que devuelve tu API, para lo cual está Apidog, y no persisten en nada que un equipo pueda ver o revisar, para lo cual está Sharkly. Una lista es un buen comienzo. No es una organización, y no es una fuente de verdad.
