GitHub Agent HQ: qué es, para quién es y qué queda fuera

Describes una funcionalidad, se la encargas a un agente de programación y te alejas mientras abre un pull request. Luego lo repites con un segundo agente, y con un tercero. Al poco tiempo, el verdadero problema ya no es lanzar agentes, sino no perderles la pista. GitHub Agent HQ es la respuesta de GitHub a ese caos: un centro de mando que reúne agentes de programación de varios proveedores en una única sala de control dentro de GitHub. Es una idea genuinamente sólida, y esta guía cubre qué es, para quién encaja y la única línea que traza y que la mayoría de los artículos omite: Agent HQ coordina el trabajo que vive dentro del ecosistema de GitHub, no las herramientas que quedan fuera de él.

Ese límite importa en el preciso momento en que tu equipo no está completamente en GitHub. Si tu gestor de tareas es Jira, tus repos están en GitLab o la mitad de tus agentes se ejecutan en portátiles y terminales que nunca tocan la nube de GitHub, necesitas una capa que esté por encima de todas las herramientas, no dentro de una de ellas. Esa capa es Sharkly, una plataforma integral de gestión y mando de agentes. Este artículo repasa dónde destaca Agent HQ, dónde está exactamente su límite y cómo una capa neutral mantiene visible una flota mixta desde la petición hasta el despliegue.

A lo largo del texto asumiremos la mejor versión de Agent HQ, porque se lo merece. Después trazaremos el límite con claridad, para que en unos dos minutos puedas saber si Agent HQ es suficiente por sí solo o si tu equipo ya ha superado un hub de un único ecosistema.

TL;DR

GitHub Agent HQ es un plano de control dentro de GitHub, con la marca Mission Control, para asignar, dirigir y hacer seguimiento de agentes de programación de varios proveedores (Claude, Codex, Google, Cognition, xAI) como parte de una suscripción de pago a GitHub Copilot. Es agnóstico en cuanto a agentes y modelos, y resulta excelente cuando tu trabajo ya vive en repos, pull requests y Actions de GitHub. Su límite es el ecosistema, no el proveedor de agentes: coordina agentes que trabajan dentro de GitHub, así que no gestiona ejecuciones en GitLab, un tablero de Jira, Bitbucket ni agentes que se ejecutan localmente en Computers fuera de la nube de GitHub. Usa Agent HQ cuando tu empresa esté totalmente volcada en GitHub. Usa una capa neutral como Sharkly cuando tu equipo combine gestores de tareas, hosts y runtimes y necesite un registro compartido único con revisión humana en todos ellos.

Qué es realmente GitHub Agent HQ

GitHub Agent HQ es un centro de mando dentro de GitHub para asignar, dirigir y hacer seguimiento de agentes de programación de varios proveedores, disponible a través de una suscripción de pago a GitHub Copilot. Esa única frase contiene toda la idea. En lugar de que cada agente viva en su propia herramienta con su propia superficie de lanzamiento, Agent HQ los reúne en un único lugar al que GitHub llama Mission Control, accesible desde el propio GitHub, VS Code, la app móvil y la línea de comandos.

El giro que merece la pena nombrar es que Agent HQ no es el agente de un solo proveedor. GitHub lo abrió a agentes de programación de Anthropic, OpenAI, Google, Cognition y xAI, así que puedes elegir Claude para un paso y Codex para otro sin salir del hub. Asignas una tarea a un agente, este trabaja en una rama dentro del entorno de GitHub, ejecuta tus verificaciones y devuelve un pull request que revisas tal como ya revisas el código. Mission Control es donde observas varias de esas ejecuciones a la vez, y funciones como Plan Mode te ayudan a dar forma al trabajo antes de que el agente empiece.

El objetivo del hub es la coordinación. No estás saltando entre cinco herramientas de agentes distintas intentando recordar cuál está haciendo qué. Si has leído nuestro artículo sobre qué significa la orquestación de agentes de IA, Agent HQ es la orquestación en su forma de un solo ecosistema: muchos proveedores de agentes, una única plataforma, y esa plataforma es GitHub.

Qué hace bien Agent HQ

Analicemos la función en su mejor versión, porque su mejor versión es potente. Aquí es donde Agent HQ se gana su sitio.

Elección de agentes neutral respecto al proveedor. La mayoría de los hubs de agentes te atan a un único fabricante de modelos. Agent HQ no. Puedes ejecutar Claude, Codex y otros en paralelo y pasar de la idea a la implementación usando distintos agentes para distintos pasos, sin cambiar de herramienta ni perder el contexto. Es una respuesta real al bloqueo del proveedor de modelos, y es la función con la que abre el lanzamiento, con razón.

Un único centro de mando en todas las superficies. Mission Control te ofrece una vista única de la actividad de los agentes desde GitHub, VS Code, el móvil y la CLI. Asignas, diriges y haces seguimiento desde donde ya estés. Para un equipo que antes malabareaba con ejecuciones paralelas a mano, nuestra guía sobre ejecutar varios agentes de Claude Code en paralelo muestra lo engorrosa que se vuelve la versión de bricolaje. Agent HQ elimina ese malabarismo dentro de GitHub.

Trabajo que aterriza donde ya se hace la revisión. Los agentes trabajan en ramas y devuelven pull requests. El resultado encaja directamente en el flujo de revisión de GitHub en el que tu equipo confía, con la misma revisión de código, verificaciones y reglas de fusión que ya aplicas. Ningún sitio nuevo donde buscar un diff.

Nativo de la plataforma en la que ya viven los equipos. Si GitHub es tu casa, Agent HQ no es un añadido. Comparte tu identidad, tus permisos, tus Actions y tus repos. Las instrucciones y los controles personalizados para agentes están junto al código sobre el que actúan, así que la configuración queda cerca del trabajo en lugar de aislada en una consola aparte.

Para un equipo estandarizado en GitHub de arriba abajo, este es un ciclo ordenado y potente. Describe el trabajo, elige un agente, revisa el pull request, fusiona. Si ese eres tú, puede que Agent HQ sea toda la orquestación que necesitas, y puedes dejar de leer aquí con la conciencia tranquila.

Para quién es Agent HQ

Agent HQ está pensado para la empresa totalmente volcada en GitHub, y a esa empresa la sirve bien. El encaje más claro es este: tu código fuente vive en repositorios de GitHub, tu CI se ejecuta en GitHub Actions, tu equipo revisa y fusiona mediante pull requests de GitHub y tienes una suscripción de pago a Copilot. Todo lo que un agente necesita leer, cambiar, probar y desplegar ya está dentro de una única plataforma, así que un hub dentro de esa plataforma tiene alcance total sobre el trabajo.

El valor se acumula para ese equipo a medida que el despliegue continúa a lo largo de 2026. Cada nuevo proveedor de agentes y cada nueva función de Mission Control aterrizan en el lugar donde ya está tu trabajo. No estás integrando nada. Estás activando más partes de una plataforma que ya usas. Para una organización de ingeniería centrada en GitHub, ese es el camino más corto desde una tarea descrita hasta un cambio revisado y fusionado.

La pregunta no es si Agent HQ es bueno en esto. Es si la realidad de tu equipo cabe dentro de GitHub, toda ella. Ahí es donde entra en juego el límite.

El límite honesto: orquesta el ecosistema de GitHub, no tus otras herramientas

Esta es la línea que los anuncios rara vez trazan por ti, y no es la que la gente espera. El límite no es el proveedor de agentes. En ese terreno Agent HQ es refrescantemente abierto. El límite es el ecosistema. Agent HQ coordina agentes que trabajan dentro de GitHub: repos de GitHub, pull requests de GitHub, GitHub Actions, identidad de GitHub, bajo una suscripción a GitHub Copilot. Cada una de esas partes es una parte de GitHub. Eso no es un defecto. Es el diseño. Pero marca un borde duro el día en que el trabajo de tu equipo deja de vivir por completo en GitHub.

Agent HQ no gestiona trabajo en GitLab ni Bitbucket. Si algunos de tus repositorios o pipelines viven fuera de GitHub, los agentes que coordina Agent HQ no llegan a ellos. Esas ejecuciones viven en un mundo aparte, sin una cronología compartida.

Agent HQ no es tu gestor de proyectos. Coordina agentes en relación con el código y los pull requests. Si tu equipo planifica y asigna trabajo en Jira o Linear, la cuestión de quién es responsable de una tarea, de qué depende y qué está bloqueado vive en un sistema que Agent HQ no ejecuta. Un pull request es una superficie de revisión, no una capa de asignación y contexto.

Agent HQ no coordina agentes que se ejecutan fuera de su nube. Si un compañero ejecuta Claude Code en una terminal local, o Codex en su propio Computer, o un agente en un runtime que alojas tú mismo, ese trabajo no aparece en Mission Control. El hub ve los agentes que lanza dentro de GitHub, no los que tu equipo ejecuta en otro sitio.

Nada de esto es una crítica a GitHub. Digamos lo que una herramienta no es, con claridad, justo donde el lector podría suponer lo contrario: Agent HQ es un plano de control de un único ecosistema, no una capa de coordinación neutral que abarque todos los gestores de tareas, hosts y runtimes que usa tu equipo. Si todo tu stack es GitHub, el límite nunca te muerde. En el momento en que una parte no lo es, sí lo hace.

La decisión binaria: empresa totalmente en GitHub o equipo con herramientas mixtas

La elección no es «hub bueno frente a hub malo», sino «qué forma de coordinación encaja con tu equipo». Aquí está la decisión binaria honesta.

Usa GitHub Agent HQ cuando tu empresa esté totalmente volcada en GitHub. Repos, Actions, pull requests y suscripciones a Copilot, sin trabajo relevante fuera de ese ecosistema. En ese mundo, Agent HQ es el camino más corto desde una tarea hasta una rama revisada, y añadir otra capa sería una sobrecarga que no necesitas. El hub tiene alcance total porque el trabajo tiene un único hogar.

Usa una capa neutral cuando tu equipo combine gestores de tareas, hosts y runtimes. En el momento en que tu realidad incluya un tablero de Jira, un repo de GitLab o agentes ejecutándose en Computers que controlas fuera de la nube de GitHub, lo que te falta no son más agentes. Es un registro compartido. Necesitas una única Tarea que contenga el objetivo, el diff, la conversación y la revisión humana, sin importar qué host, gestor de tareas o runtime hizo el trabajo. Eso es tarea de una capa que esté por encima de todas las herramientas, no dentro de una de ellas.

Es la misma bifurcación con la que se topan los desarrolladores con cualquier hub de un solo proveedor, que tratamos para el caso del editor en agentes en segundo plano de Cursor, explicados, y para los tableros locales en la guía de alternativas a Vibe Kanban. La orquestación de un único ecosistema es cómoda justo hasta que el ecosistema deja de ser toda la historia.

Dónde encaja Sharkly: la capa neutral en torno a cada runtime y gestor de tareas

Sharkly no sustituye a GitHub, Copilot, Claude Code, Codex ni otras herramientas de ejecución. Añade la capa compartida de Tareas, Computers, contexto, control y revisión en torno a las herramientas que tu equipo ya usa. Esa frase es toda la relación, así que léela dos veces. Conservas GitHub. Conservas Agent HQ donde encaje. Sharkly es lo que coordina la flota cuando la flota es más grande que un solo ecosistema.

El reparto de tareas es limpio. GitHub, Copilot, Claude Code, Codex y herramientas similares se encargan de la ejecución. Sharkly gestiona la asignación a nivel de equipo, los Computers conectados, el contexto de las Tareas, el progreso, los bloqueos, los resultados y la revisión humana en todas esas herramientas. Los agentes investigan, ejecutan, prueban e informan. Las personas marcan la dirección, conceden autoridad y aceptan el resultado. La automatización se detiene donde se requiere el criterio del equipo.

En concreto, una Tarea en Sharkly es la unidad principal de trabajo y reúne todo lo relativo a una pieza de trabajo en un solo lugar. La asignas a un agente que se ejecuta en un Computer que controlas, con el Runtime que elijas. La ejecución, los bloqueos, los resultados y la conversación de seguimiento vuelven a la cronología de la Tarea, en lugar de dispersarse entre la nube de una plataforma, un gestor de tareas aparte y un puñado de terminales privadas. El objetivo, el diff, la conversación y la revisión de cada ejecución permanecen juntos, ya sea que esa ejecución haya ocurrido a través de Agent HQ dentro de GitHub, a través de Claude Code en el Computer de un compañero o a través de algo que adoptes el año que viene.

Y no te pide que reconstruyas nada. Conserva los proyectos, tareas, estados y flujos de trabajo que tu equipo ya entiende, conecta Sharkly a los gestores de tareas y hosts que ya usas y empieza a enrutar trabajo sin rehacer el proceso que tu equipo ya utiliza. El uso de modelos continúa a través de las suscripciones o claves de API configuradas en esas herramientas, así que tú aportas tu suscripción y Sharkly añade la coordinación por encima. Si eres nuevo en la plataforma, conoce Sharkly recorre las ideas principales, y el tutorial de la primera tarea muestra la versión útil más pequeña de principio a fin. Puedes descargar Sharkly y conectar un Computer para probarlo con trabajo real.

Errores comunes que conviene evitar

• Suponer que «neutral respecto al proveedor» significa «neutral respecto a las herramientas». Agent HQ es abierto en cuanto a qué agente ejecuta el trabajo, y eso es una fortaleza real. No es abierto en cuanto a dónde vive el trabajo. Los agentes siguen operando dentro de GitHub. Interpreta el límite como ecosistema, no como fabricante de modelos.
• Adoptar el hub de un ecosistema como si fuera toda tu estrategia. Si hoy te estandarizas en Agent HQ y mantienes vivo un repo de GitLab o un tablero de Jira el próximo trimestre, habrás dividido tu superficie de coordinación sin darte cuenta. Decide pronto si de verdad estás totalmente volcado en GitHub o si eres un equipo con herramientas mixtas.
• Tratar los pull requests como la capa de coordinación. Los pull requests son una superficie de revisión, no una capa de asignación y contexto. Quién es responsable de la Tarea, de qué depende y por qué está bloqueada no caben en un diff.
• Olvidar a los agentes que nunca tocan el hub. Cualquier ejecución iniciada fuera de GitHub, en una terminal local o en un Computer que alojas tú, no aparecerá en Mission Control. Cuenta esas ejecuciones antes de declarar que un único hub es tu única fuente de verdad.

GitHub Agent HQ frente a una capa de orquestación neutral

Léelo como un reparto de tareas, no como un marcador.

Ninguna de las dos columnas es «incorrecta». Si tus respuestas, fila a fila, caen mayoritariamente en la columna izquierda, Agent HQ encaja. Si se desplazan hacia la derecha, sobre todo en las filas de dónde vive el trabajo, gestor de tareas y registro compartido, has superado la orquestación de un único ecosistema.

Ideas clave

• GitHub Agent HQ es un plano de control dentro de GitHub, con la marca Mission Control, para asignar, dirigir y hacer seguimiento de agentes de programación de varios proveedores como parte de una suscripción de pago a Copilot.
• Lo hace bien: elección de agentes neutral respecto al proveedor, un único centro de mando en GitHub, VS Code, móvil y CLI, y trabajo que aterriza en el flujo de revisión de pull requests en el que ya confías.
• Su límite es el ecosistema, no el proveedor de agentes: coordina agentes que trabajan dentro de GitHub, así que los repos de GitLab, los tableros de Jira y los agentes que se ejecutan fuera de la nube de GitHub quedan al margen.
• Usa Agent HQ cuando tu empresa esté totalmente volcada en GitHub. Usa una capa neutral cuando tu equipo combine hosts, gestores de tareas y runtimes y necesite un registro compartido único con revisión en todos ellos.
• Sharkly funciona junto a GitHub, no en su lugar: conserva tus herramientas, aporta tu propia suscripción y deja que cada ejecución vuelva a una única Tarea desde la petición hasta el despliegue.

El siguiente paso es pequeño a propósito. Conecta un Computer, crea un agente y asígnale algo aburrido. La documentación cubre cada concepto con más detalle en docs.sharkly.ai.

Preguntas frecuentes

¿Qué es GitHub Agent HQ en una frase? Es un centro de mando dentro de GitHub, con la marca Mission Control, que asigna, dirige y hace seguimiento de agentes de programación de varios proveedores como parte de una suscripción de pago a GitHub Copilot, con los agentes trabajando en ramas y devolviendo pull requests.

¿Qué agentes pueden ejecutarse en Agent HQ? GitHub lo abrió a agentes de programación de Anthropic, OpenAI, Google, Cognition y xAI, así que puedes elegir Claude para un paso y Codex para otro sin salir del hub. La lista exacta va creciendo a medida que el despliegue continúa a lo largo de 2026.

¿GitHub Agent HQ es gratis? No. Se ofrece mediante una suscripción de pago a GitHub Copilot, con disponibilidad ligada a planes como Copilot Pro+ y Copilot Enterprise. Consulta las propias páginas de GitHub para conocer los detalles actuales de los planes, ya que cambian a medida que se despliega.

¿Agent HQ funciona con GitLab o Jira? Agent HQ coordina agentes que trabajan dentro del ecosistema de GitHub: repos, Actions y pull requests de GitHub. El trabajo en GitLab o Bitbucket, y la planificación en Jira o Linear, quedan fuera de su alcance. Una capa neutral por encima de todas las herramientas es lo que conecta esas piezas. Consulta nuestro artículo sobre los agentes en segundo plano de Cursor para ver la versión de ese mismo límite aplicada al editor.

¿Tengo que sustituir GitHub para usar Sharkly? No. Sharkly no sustituye a GitHub ni a ninguna herramienta de ejecución. Añade la capa compartida de Tareas, contexto y revisión en torno a las herramientas que ya usas, así que GitHub, Copilot y Agent HQ siguen funcionando exactamente igual que antes.

¿Cuándo no debería añadir una capa de orquestación sobre Agent HQ? Si todo tu stack es GitHub —repos, Actions, pull requests y Copilot— sin trabajo relevante en otro sitio, puede que Agent HQ sea toda la orquestación que necesitas. Añade una capa neutral solo cuando uses varios hosts, gestores de tareas o runtimes y necesites un registro compartido único entre ellos.

¿Sharkly cambia cómo pago los modelos? No. Tú aportas tu propia suscripción. El uso de modelos continúa a través de las suscripciones o claves de API configuradas en las herramientas que conectes, y la cuota de modelos depende de los planes y cuentas de API que conecte tu equipo.

¿Cómo pruebo el enfoque de capa neutral sin una gran migración? Empieza por el flujo útil más pequeño: conecta un Computer, crea un agente y asígnale una Tarea de bajo riesgo. El tutorial de la primera tarea lo cubre paso a paso, y ejecutar varios agentes de Claude Code en paralelo muestra el lado de la flota.