GitHub abre agent apps en Copilot: socios, MCP y flujos delegados sin salir del repo
GitHub activó el 2 de junio de 2026 las agent apps para Copilot. La novedad útil no es otro marketplace: es poder delegar trabajo a agentes de terceros desde issues, PRs y la UI de Agents, con el mismo modelo de AI Credits y autorización por app.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
GitHub lleva meses empujando a Copilot fuera del chat y hacia trabajo más operativo. El paso del 2 de junio de 2026 con agent apps va en esa misma dirección, pero con una diferencia importante: ahora no solo delegas a Copilot, también puedes delegar a agentes de partners dentro del mismo flujo de GitHub.
La idea oficial es simple: una GitHub App puede exponer un agente, entrar al mismo circuito que ya usas para issues y pull requests, y correr sobre la infraestructura de Copilot cloud agent. Leído rápido suena a marketplace. Leído como builder, es otra cosa: GitHub está convirtiendo el repo en un punto de coordinación para agentes especializados que viven fuera de GitHub pero aterrizan dentro del workflow.
Lo nuevo no es solo instalar una app
La documentación de GitHub deja tres puntos claros:
- puedes arrancar un agent app desde asignación de issues;
- puedes invocarlo en comentarios de pull request con
@AGENT-NAME; - también puedes lanzarlo desde la Agents UI con un prompt normal.
Eso importa porque la app no queda flotando en otro panel aparte. Entra al mismo tejido donde ya viven backlog, revisión y seguimiento. Además, GitHub dice explícitamente que cada agent app puede definir su propio prompt, modelo, tools y servidores MCP.
Ahí está la noticia real. La batalla ya no es solo “qué agente programa mejor”. También es qué agente se conecta mejor con el sistema externo que ya usas: feature flags, seguridad, analítica, despliegue o incidentes.
Dónde sí veo intención de búsqueda buena
Estas son las consultas que realmente puede capturar una nota así:
github agent appscopilot agent appsgithub copilot mcp partnersagentes terceros github
La intención detrás no es curiosidad de producto. Es alguien intentando responder una pregunta concreta: si ya tengo herramientas fuera de GitHub, cómo las convierto en agentes accionables dentro del repo sin montar un stack paralelo.
Eso explica por qué GitHub lo conecta con su app de escritorio y con cloud agent. En el blog del producto ya aparece la primera ola de partners y la tesis completa: usar herramientas favoritas “sin salir de GitHub”.
El detalle operativo que no conviene esconder
Agent apps no son “gratis” en sentido de gobernanza. GitHub también deja claras varias implicaciones:
- el primer uso exige flujo OAuth para autorizar la app;
- en organizaciones enterprise hay que habilitar la política de agent apps;
- y el consumo cae sobre la misma suscripción de Copilot, usando AI Credits como cloud agent.
Ese último punto es clave. Si un partner-built agent empieza a meterse en tu flujo, no solo importa si hace bien la tarea. También importa cómo consume presupuesto y quién gobierna ese acceso. Si no tienes claro ese control, el problema deja de ser técnico y pasa a ser operativo.
Mi lectura práctica
Lo valioso de agent apps no es abrir otro catálogo de integraciones. Lo valioso es que GitHub empieza a tratar a los agentes especializados como ciudadanos de primera clase del workflow, no como bots laterales.
Yo lo pondría a prueba cuando se cumplan dos condiciones:
- el equipo ya vive en GitHub para issue, PR y revisión;
- existe una herramienta externa que hoy obliga a cambiar de contexto para hacer trabajo repetible.
Si todavía estás ordenando la base de instrucciones, permisos y revisión humana, primero conviene afinar eso con el curso gratis. Pero si ya estás comparando cómo meter más automatización sin romper el hilo del repo, esta noticia sí importa: GitHub ya no solo quiere alojar código; quiere alojar la orquestación entre varios agentes con especialidades distintas.