Copilot Agent Mode: qué hace, qué no y con qué compite en GitHub

GitHub Copilot ya no tiene una sola forma de actuar como agente: tiene tres, y las tres comparten un recurso que antes no existía por separado: un saldo de créditos que se gasta igual sin importar cuál elijas. Agent mode edita tu entorno local en una sesión síncrona dentro del editor; cloud agent trabaja de forma asíncrona en un runner remoto sin que tengas el IDE abierto; Copilot CLI vive en la terminal, interactiva o vía script. Tratarlas como sinónimos ya no es solo un problema de nomenclatura, es un problema de presupuesto: cada una consume del mismo saldo mensual, y elegir la equivocada para una tarea cuesta dinero real, no solo tiempo.

Tres superficies, un solo nombre de familia

La confusión más común en 2026 es tratar "agente de Copilot" como una sola cosa. La documentación oficial distingue explícitamente cloud agent frente a agent mode: agent mode edita directamente tu entorno local durante una sesión síncrona en el editor, mientras que cloud agent (el nombre que sustituyó a "coding agent" tras su disponibilidad general en septiembre de 2025) trabaja de forma asíncrona en un runner de GitHub Actions, sin que tengas el IDE abierto, y puede abrir un pull request cuando termina.

A esas dos se suma una tercera: GitHub Copilot CLI, con una sesión interactiva (con un submodo de plan que construye una propuesta estructurada antes de tocar código) y un modo programático de un solo prompt vía el flag -p. El propio selector de agentes dentro del chat de Copilot en el editor confirma la separación: Agent mode, Ask mode, Plan mode, Copilot CLI y Custom agents aparecen como opciones distintas del mismo desplegable, no como sinónimos.

Antes de comparar las tres conviene tener claro qué separa a un agente real de un simple prompt encadenado, porque las tres superficies presumen ese salto y no todas lo dan con el mismo grado de autonomía: la diferencia está en si el sistema planifica y ejecuta por su cuenta, no solo en si responde bien a un prompt.

Los criterios antes de mirar la tabla

Elegir entre las tres no es una preferencia estética. Depende de cuatro preguntas:

• ¿Dónde necesitas que viva el contexto? Si la tarea depende de que tengas el proyecto abierto, breakpoints puestos o un servidor local corriendo, solo agent mode tiene sentido.
• ¿Puedes esperar sin mirar? Cloud agent es la única superficie pensada para delegar y volver más tarde: no bloquea tu editor ni tu terminal mientras trabaja.
• ¿Quién dispara la tarea? Un issue de GitHub o un comentario @copilot en un PR solo llegan a cloud agent. Un prompt de terminal o un script solo llegan a la CLI.
• ¿Necesitas revisar el plan antes de que se ejecute algo? Plan mode, disponible tanto en el chat del editor como en la CLI, inserta una revisión explícita antes de la ejecución; agent mode por defecto no la pide.

Tabla de decisión

Un matiz que la tabla resume pero conviene subrayar: los hooks, la pieza más potente de personalización, solo están disponibles para cloud agent y Copilot CLI, no para agent mode en el editor. Si tu plan es interceptar cada tool call con un script de seguridad antes de que se ejecute, agent mode todavía no es la superficie correcta; para ese caso, agent mode en VS Code sigue apoyándose en el hub de MCP y Agent Skills del propio editor en lugar de en hooks.

Y si la decisión de fondo no es entre las tres superficies de Copilot sino entre Copilot y otras herramientas de agente de código, esa comparación -Claude Code, Cursor, Copilot y Codex una junto a otra- responde a una pregunta distinta a la de esta tabla.

Cómo se paga esto desde junio de 2026

Este es el cambio que más rompe lo que decía la versión anterior de este artículo, centrada en licencias Business/Enterprise a precio fijo. GitHub movió Copilot a facturación por uso el 1 de junio de 2026: el precio de cada plan de pago no cambió, pero lo que ese precio cubre sí: ahora incluye un saldo mensual de AI Credits (1 crédito = 0,01 $) que se consume con chat, agentes, code review y CLI, y que se agota si lo usas mucho. No hay un modelo base ilimitado en el sentido de sin tope: lo único que sigue sin consumir créditos, y por tanto sin límite práctico, son las finalizaciones de código y las next-edit suggestions.

Para equipos, Copilot Business cuesta 19 $/usuario/mes con 19 $ en créditos incluidos, y Enterprise 39 $/usuario/mes con 39 $ incluidos, ambos con un refuerzo promocional (30 $ y 70 $ respectivamente) que cubre junio-agosto de 2026 mientras dura la transición. En el lado individual, Pro cuesta 10 $/mes con 15 $ de crédito, Pro+ 39 $/mes con 70 $, y el nuevo plan Max 100 $/mes con 200 $, pensado explícitamente para flujos de agente sostenidos y de alto volumen. Cada prompt en agent mode consume de ese saldo igual que una llamada a cloud agent o a la CLI: no existe una superficie "gratis" una vez agotado el modelo base incluido.

La consecuencia práctica para un equipo: antes de estandarizar cloud agent para tareas delegadas masivas, mide cuántos AI Credits consume un ciclo completo de research → plan → cambios → intento de PR, y compáralo con el saldo del plan elegido. Si el equipo agota el saldo a mitad de mes, GitHub permite fijar un presupuesto adicional en dólares o cambiar a un modelo más ligero para estirarlo, en vez de bloquear el flujo de golpe.

Personalizar cada superficie sin escribir un LLM propio

La personalización real en 2026 tiene tres piezas, y no las tres están disponibles en todas partes:

• Custom agents: perfiles especializados definidos en .github/agents/NOMBRE.md a nivel de repositorio, o en el .github/.github-private de la organización o empresa para alcance más amplio. Disponibles en cloud agent, en la CLI, y en los IDEs, y la documentación oficial confirma vista previa pública para JetBrains, Eclipse y Xcode de forma explícita; para VS Code no afirma disponibilidad general en ningún sitio, así que no lo asumas y confirma el estado exacto en las notas de versión antes de depender de ello.
• Hooks: comandos de shell que se ejecutan en puntos fijos del ciclo de vida del agente (sessionStart, preToolUse, postToolUse, agentStop, subagentStop, errorOccurred), definidos en .github/hooks/*.json del repositorio para cloud agent, o en ~/.copilot/hooks/*.json para hooks personales de la CLI.
• MCP: los ajustes de servidores MCP de un repositorio aplican tanto a cloud agent como a code review. No está confirmado que el servidor MCP de GitHub o el de Playwright vengan activados por defecto en toda cuenta o plan: verifica la configuración de servidores MCP de tu organización antes de asumir que ya están disponibles.

Un hook mínimo pero real, con el esquema exacto que documenta GitHub, para registrar cada sesión y bloquear comandos de shell peligrosos antes de que el agente los ejecute. Autocontenido de verdad: crea su propio directorio de logs y trae el script al que llama, no asume que ya existen.

{
  "version": 1,
  "hooks": {
    "sessionStart": [
      {
        "type": "command",
        "bash": "mkdir -p logs && echo \"Sesión iniciada: $(date)\" >> logs/copilot-session.log",
        "cwd": ".",
        "timeoutSec": 10
      }
    ],
    "preToolUse": [
      {
        "type": "command",
        "bash": "./scripts/security-check.sh",
        "cwd": ".",
        "timeoutSec": 15
      }
    ],
    "postToolUse": [
      {
        "type": "command",
        "bash": "mkdir -p logs && cat >> logs/tool-results.jsonl",
        "cwd": "."
      }
    ]
  }
}

Guarda ese archivo como .github/hooks/project-hooks.json en la raíz del repositorio. El cwd de los tres hooks es la raíz del repo ("."), así que ./scripts/security-check.sh resuelve donde debe; el error habitual es fijar un cwd distinto para el hook y luego seguir escribiendo la ruta del script como si el cwd siguiera siendo la raíz, con lo que el path acaba duplicado y el import se rompe. El script que falta, sin el cual este hook no arranca:

#!/usr/bin/env bash
# scripts/security-check.sh
# Recibe el payload de preToolUse por stdin (JSON con toolName/toolArgs) y
# deniega el tool call si detecta un patrón de comando peligroso.
# preToolUse es fail-closed: cualquier salida distinta de 0 ya deniega,
# así que un fallo del propio script también bloquea, no lo deja pasar.
set -euo pipefail

payload="$(cat)"
tool_name="$(echo "$payload" | jq -r '.toolName // .tool_name // empty')"

if [ "$tool_name" != "bash" ] && [ "$tool_name" != "powershell" ]; then
  exit 0
fi

command_text="$(echo "$payload" | jq -r '.toolArgs.command // .tool_input.command // empty')"

if echo "$command_text" | grep -Eiq 'rm -rf /|curl .*\| *sh|git push .*--force'; then
  echo '{"permissionDecision": "deny", "permissionDecisionReason": "Bloqueado por security-check.sh: patron de comando peligroso"}'
  exit 2
fi

exit 0

Guárdalo como scripts/security-check.sh en la raíz del repositorio y dale permiso de ejecución (chmod +x scripts/security-check.sh) antes de hacer commit; sin eso, cloud agent lo intenta ejecutar y falla por permisos, no por lógica. Con los tres archivos en el repo -el hook, el script y nada más-, cloud agent lo ejecuta automáticamente en cada sesión; no hace falta registrarlo en ningún panel de administración.

Qué no ha cambiado, y sigue siendo la parte que falla

El agente delega el trabajo mecánico, no el criterio. Sigue siendo cierto lo que ya era cierto en marzo: un prompt como "mejora el rendimiento" produce un resultado tan vago como el prompt. La diferencia en 2026 es que ese prompt vago ahora consume créditos reales en tres superficies distintas, así que el coste de la ambigüedad subió. Cloud agent, en particular, castiga los prompts imprecisos con más fuerza que agent mode: al trabajar sin supervisión activa, un plan mal encaminado puede recorrer varios pasos (research, plan, cambios, intento de PR) antes de que alguien lo revise, y cada paso consume saldo. La disciplina de ser específico con el prompt no es un consejo genérico de productividad: es la misma que separa un agente que funciona en producción de uno que solo funciona en la demo, como ya vimos al analizar qué hace falta para llevar agentes de IA a producción.

Tampoco cambió la responsabilidad final. GitHub sigue siendo explícito en que el producto se llama Copilot, no Autopilot, y no está pensado para generar código sin supervisión: las mismas salvaguardas que aplicarías a código de terceros de origen desconocido siguen aplicando aquí, en cualquiera de las tres superficies.

El criterio que sobrevive a las tres superficies

Ninguna de las tres piensa por ti, y ese límite importa más que cuál elijas. Si el cambio es de una línea y ya sabes exactamente qué escribir, escríbelo tú: formular el prompt, esperar la respuesta y revisar el diff cuesta más que teclearlo directamente. Si el repositorio maneja secretos o datos sensibles y tu política de seguridad no permite que el código salga hacia un runner externo, agent mode local sigue siendo viable aunque cloud agent quede descartado de raíz, porque agent mode no envía tu código a un runner de GitHub Actions. Y si la tarea depende de un conocimiento tácito que nadie ha escrito en ningún sitio (una decisión de arquitectura de hace dos años que solo vive en la cabeza de una persona del equipo), ninguna de las tres lo va a adivinar correctamente: van a producir algo plausible, no necesariamente lo correcto, y ahí la revisión humana sigue sin ser negociable. El saldo de créditos hace que equivocarse de superficie ahora también salga caro, no solo lento.