GitHub Copilot Agéntico: La Guía Definitiva para Controlarlo al Máximo

Imagina que contratas a un ingeniero senior para que trabaje en tu proyecto. Llega el primer día, revisa el código durante horas, entiende la arquitectura, aprende tus convenciones. Al tercer día ya anticipa lo que necesitas.

Ahora imagina que cada mañana ese ingeniero llega sin recuerdo del día anterior.

Eso es Ghost Copilot: un modelo de lenguaje sin estado, sin memoria persistente, que resetea su contexto con cada conversación. Pero también es la herramienta de desarrollo más potente disponible hoy, si sabes cómo usarla.

La diferencia entre un desarrollador que le saca el 20% y uno que le saca el 90% no es el modelo. Es entender cómo funciona la IA por dentro: qué es un token, qué es el contexto, cómo piensan los modelos, y cómo diseñar tu flujo de trabajo para que el agente tenga exactamente la información que necesita, ni más ni menos.

Esta guía cubre eso. De punta a punta.

---

Cómo Funciona Realmente un Modelo de Lenguaje

Antes de hablar de agentes, modos, o configuraciones, necesitas entender qué está pasando adentro. No en términos matemáticos, sino en términos prácticos que cambiarán cómo usas la herramienta.

La ventana de contexto: la memoria de trabajo del modelo

Un modelo de lenguaje (LLM) no tiene memoria. Lo que tiene es una ventana de contexto: una cantidad máxima de texto que puede procesar en una sola solicitud. Todo lo que el modelo “sabe” durante una conversación vive en esa ventana.

Esa ventana contiene:

• Las instrucciones del sistema (quién es el agente, qué reglas sigue)
• Tu mensaje actual
• El historial de la conversación
• El contenido de los archivos que has referenciado
• Los resultados de las herramientas que el agente ejecutó
• Tus instrucciones personalizadas

Cuando la ventana se llena, VS Code comprime automáticamente las partes más antiguas. Los detalles del inicio de la conversación se pierden o se resumen.

Esto tiene una consecuencia directa: cada token que pones en el contexto es espacio que le quitas a la respuesta y al razonamiento. Agregar un archivo de 3,000 líneas cuando solo necesitas una función de 20 líneas es desperdiciar contexto y dinero.

Tokens: la moneda del modelo

Los modelos no ven texto, ven tokens. Un token es aproximadamente 3-4 caracteres en inglés, o 2-3 en español. “GitHub Copilot” son 3 tokens. Un archivo de 500 líneas de código Go puede ser 2,000-4,000 tokens.

Cada solicitud tiene un costo medido en tokens: los que entran (input) y los que salen (output). Los modelos gratuitos en Copilot tienen límites en solicitudes premium por período. Los modelos con multiplicador 0 (como GPT-4.1, GPT-5 mini, GPT-4o, Raptor mini) no consumen cuota premium.

Esto importa porque en modo agente, el agente lee archivos, ejecuta herramientas, itera. Una sola tarea compleja puede involucrar docenas de turnos, cada uno con su propio costo en tokens. Si usas un modelo costoso para tareas simples, quemas cuota rápido.

Nondeterminismo: por qué el modelo parece inconsistente

El mismo prompt puede producir resultados diferentes en cada ejecución. Esto es intencional: el modelo muestrea de distribuciones de probabilidad, no ejecuta lógica determinista. No es un bug. Es la naturaleza estadística del aprendizaje profundo.

Lo que sí puedes controlar: la calidad del contexto que le das. Un prompt vago con contexto pobre produce resultados caóticos. Un prompt preciso con contexto relevante produce resultados consistentemente buenos.

---

Los Tres Modos: Agent, Plan y Ask

VS Code con GitHub Copilot te da tres agentes incorporados. Elegir el correcto para cada tarea marca la diferencia entre una sesión productiva y una que consume el doble de tokens para llegar al mismo resultado.

Ask: preguntar sin modificar

El modo Ask responde preguntas sobre conceptos de código, tu repositorio o VS Code mismo. No hace modificaciones a archivos.

Incluye automáticamente el archivo activo en el contexto. Es el modo más económico en tokens porque no itera, no ejecuta herramientas, no abre archivos adicionales.

Úsalo cuando:

• Quieres entender cómo funciona un fragmento de código
• Necesitas que te expliquen un patrón o una API
• Buscas una respuesta conceptual antes de implementar
• Quieres explorar opciones sin comprometerte todavía

# Buenos casos para Ask
"¿Cómo funciona el sistema de autenticación en este proyecto?"
"Explícame este algoritmo de caché."
"¿Qué diferencia hay entre `useEffect` y `useLayoutEffect`?"

Lo que no hace: no abre archivos adicionales, no ejecuta comandos, no modifica nada.

Plan: diseñar antes de escribir código

El modo Plan es el más infravalorado de los tres. Su propósito es uno solo: entender el problema a fondo y construir un plan de implementación detallado antes de tocar una sola línea de código.

El agente de Plan sigue cuatro fases:

1. Discovery: usa herramientas de solo lectura para explorar el codebase, entender la arquitectura existente, identificar dependencias
2. Alignment: hace preguntas de aclaración para resolver ambigüedades
3. Design: produce un plan estructurado paso a paso
4. Refinement: itera sobre el plan basado en tu retroalimentación

No puede hacer cambios en archivos hasta que tú apruebes el plan. Cuando lo haces, puedes pasárselo al agente o al Copilot CLI para la implementación.

He visto equipos que saltan directo al modo Agent para tareas arquitectónicas complejas y terminan con implementaciones a medias, inconsistentes, que mezclan patrones. El modo Plan existe precisamente para eso: cuando el costo de equivocarse en el “qué hacer” es más alto que el costo de planear bien.

Úsalo cuando:

• Vas a implementar una nueva feature de múltiples archivos
• Necesitas refactorizar una parte del sistema
• La tarea tiene dependencias cruzadas que no están del todo claras
• Quieres alinear el enfoque antes de ejecutar

# Buenos casos para Plan
"Agrega autenticación JWT al sistema de usuarios. Revisa la arquitectura actual y
propón cómo integrarlo sin romper los tests existentes."

El agente usa subagentes internamente para investigar distintos aspectos en paralelo, luego consolida en el plan. Más sobre subagentes abajo.

Agent: ejecución autónoma

El modo Agent es el más poderoso y el que consume más tokens. Es el agente completo: planea, implementa, ejecuta comandos, corre tests, lee archivos, busca en el codebase, corrige errores y vuelve a iterar hasta completar la tarea.

Cada vez que el agente llama a una herramienta (leer un archivo, ejecutar un comando), el resultado se agrega al contexto. Una cadena de 10 acciones en un codebase mediano puede acumular 20,000-40,000 tokens fácilmente.

Úsalo cuando:

• La tarea está bien definida y tiene alcance claro
• Necesitas cambios en múltiples archivos coordinados
• Quieres que el agente itere hasta que los tests pasen
• El contexto necesario está documentado (no tienes que improvisar en el chat)

# Buenos casos para Agent
"Implementa el endpoint POST /users que valide el schema del body, hashee el password,
persista en PostgreSQL y retorne 201 con los datos creados. Los tests están en /tests/users."

Cuanto más precisa y completa sea la tarea, menos iteraciones necesita el agente, menos tokens consume, y mejor es el resultado.

---

El Agent Loop: Cómo Piensa y Actúa un Agente

Entender el loop del agente te da una ventaja inmediata para escribir mejores prompts y saber cuándo intervenir.

Tu prompt
    ↓
[Razonamiento del modelo]
    ↓
¿Necesito más información?
    → Sí → Herramienta (leer archivo, buscar código, ejecutar comando)
    → No → Generar respuesta o edición de código
    ↓
El resultado de la herramienta vuelve al contexto
    ↓
[Nuevo ciclo de razonamiento]
    ↓
¿La tarea está completa?
    → No → Otro ciclo
    → Sí → Respuesta final al usuario

Cada ciclo es una llamada al modelo con el contexto acumulado. Si el agente lee 5 archivos, ejecuta 2 tests y corrige 3 errores, eso son al menos 10 ciclos, cada uno más costoso que el anterior porque el contexto crece.

Las tres fases del loop

Entender. El agente lee archivos, busca en el codebase, revisa la documentación. En VS Code tiene acceso a un índice semántico de tu workspace que le permite encontrar código relevante sin leer todo. Si tu repositorio está en GitHub con un índice remoto activo, esta fase es considerablemente más rápida y precisa.

Actuar. El agente modifica archivos, ejecuta comandos de terminal, instala dependencias, llama servicios externos a través de herramientas. Aquí es donde suceden los cambios reales.

Validar. El agente corre tests, verifica errores del compilador, revisa sus propios cambios. Si algo sale mal, vuelve a iterar. Tú puedes enviar un mensaje en cualquier momento para redirigir, agregar contexto, o sugerir un enfoque distinto.

Niveles de permiso

El permiso controla cuánta autonomía tiene el agente para ejecutar herramientas sin pedirte confirmación:

Nivel	Comportamiento
Default Approvals	Solo aprueba automáticamente herramientas seguras de solo lectura. Pide confirmación para comandos y escritura.
Bypass Approvals	Aprueba todos los tool calls automáticamente. El agente puede hacer preguntas.
Autopilot (Preview)	Aprueba todo, responde preguntas automáticamente, ejecuta hasta completar sin interrupciones.

Para tareas exploratoras o cuando estás aprendiendo cómo el agente aborda un problema, usa Default Approvals. Para tareas bien definidas con alcance claro, Bypass Approvals o Autopilot. Para trabajo crítico o en producción, nunca uses Autopilot sin leer cada cambio.

---

Subagentes: Delegar para No Saturar el Contexto

Cuando el agente principal trabaja en una tarea compleja, puede delegar subtareas a subagentes. Esto no es un detalle menor. Es una de las arquitecturas más inteligentes del sistema y tiene implicaciones directas en costo y calidad.

Por qué existen los subagentes

Sin subagentes, todo lo que el agente explora durante la fase de investigación se acumula en el contexto principal. Si investigas tres aspectos del codebase (seguridad, rendimiento, compatibilidad), cada lectura de archivo, cada resultado de búsqueda, cada análisis intermedio se apila en la misma ventana de contexto.

El resultado: un contexto saturado que entierra la información relevante bajo capas de pasos intermedios. El modelo tiene que razonar sobre todo ese ruido simultáneamente.

Los subagentes resuelven esto con aislamiento de contexto:

• Cada subagente tiene su propia ventana de contexto independiente
• El subagente recibe solo el prompt de la tarea, no el historial de la conversación principal
• Solo el resultado final vuelve al agente principal, no todos los pasos intermedios

El agente Plan lo usa exactamente así: lanza subagentes en paralelo para investigar distintas facetas del problema y recibe solo sus hallazgos consolidados.

Características clave

Ejecución paralela. VS Code puede lanzar múltiples subagentes simultáneamente. Un análisis de seguridad, uno de rendimiento y uno de accesibilidad pueden correr al mismo tiempo.

Ejecución síncrona. El agente principal espera los resultados antes de continuar. Los subagentes no son procesos fire-and-forget; sus hallazgos informan el siguiente paso.

Reducción de tokens en el contexto principal. Solo el resumen llega al agente principal. Todo el trabajo intermedio de los subagentes se descarta. Esto puede reducir el consumo de contexto principal en un orden de magnitud en tareas de investigación complejas.

Patrón práctico: investigación distribuida

Cuando tengas una tarea que requiere entender múltiples sistemas o partes del codebase antes de actuar, considera describir el problema en términos que inviten al agente a usar subagentes:

"Necesito agregar rate limiting al API. Antes de implementar, analiza:
1. La estructura actual del middleware de Express
2. Los casos de uso en producción (qué endpoints necesitan límites distintos)
3. Las librerías existentes en package.json que podrían usarse"

El agente planeará investigar estos tres aspectos, potencialmente en paralelo, y te dará una visión consolidada antes de escribir código.

---

Memoria: Cómo Persistir Contexto Entre Sesiones

El modelo no tiene memoria nativa entre conversaciones. Pero VS Code sí tiene sistemas de memoria que el agente puede leer y escribir para persistir contexto relevante.

Hay dos sistemas complementarios.

Memory Tool: tres alcances de persistencia

El Memory Tool es una herramienta incorporada que almacena notas de forma local en tu máquina, organizadas en tres alcances:

User memory (/memories/): persiste entre todos los workspaces y conversaciones. Las primeras 200 líneas se cargan automáticamente en cada sesión. Es donde viven tus preferencias generales, patrones que funcionan, lecciones aprendidas.

Repository memory (/memories/repo/): alcance del workspace actual, persiste entre conversaciones. Hechos específicos del codebase que el agente debe recordar: convenciones de arquitectura, comandos de build, decisiones técnicas clave.

Session memory (/memories/session/): alcance de la conversación actual, se borra cuando termina. Notas de trabajo en progreso, contexto de la tarea actual.

El agente puede escribir y leer estas memorias. Si en una sesión le enseñas que tu proyecto usa bun en lugar de npm, puedes pedirle que lo anote en memoria de repositorio y nunca más tendrás que repetirlo.

Copilot Memory: memoria sincronizada con GitHub

Copilot Memory es un sistema de memoria alojado en GitHub que captura insights del repositorio a través de varias superficies de Copilot: el agente de coding, el code review, el CLI. Se comparte entre todas tus sesiones de GitHub Copilot, no solo VS Code.

Mientras el Memory Tool es local y controlado por ti, Copilot Memory se actualiza automáticamente conforme el agente interactúa con el repositorio.

Cómo estructurar la memoria del repositorio

La forma más precisa de preparar contexto persistente para el agente es combinar el Memory Tool con archivos de instrucciones permanentes. En lugar de explicar tu stack en cada sesión:

# /memories/repo/proyecto-stack.md

- Runtime: Bun (no npm, no pnpm)
- Framework: Astro 5 + TypeScript strict
- Build: `bun build` (no `npm run build`)
- Tests: Vitest, comando `bun test`
- Deployment: Netlify, main branch auto-deploys
- No usar console.log en producción — usar el logger en src/utils/logger.ts
- Archivos de blog en src/content/blog/{es,en}/ formato Markdown

Esto es contexto que el agente lee, no que tú tienes que repetir.

---

Modelos Disponibles: Cuál Usar y Cuándo

GitHub Copilot te da acceso a docenas de modelos. La pregunta no es “¿cuál es el mejor?” sino “¿cuál es el correcto para esta tarea?”

Los modelos difieren en cuatro dimensiones prácticas:

• Velocidad de respuesta
• Calidad de razonamiento para tareas complejas
• Tamaño de ventana de contexto
• Costo en tokens premium (multiplicador)

Tabla de modelos actuales (Abril 2026)

Modelo	Proveedor	Multiplicador	Agente	Plan	Ask
GPT-4.1	OpenAI	0 (gratis)	✅	✅	✅
GPT-5 mini	OpenAI	0 (gratis)	✅	✅	✅
Raptor mini	Fine-tuned GPT-5 mini	0 (gratis)	✅	✅	✅
GPT-4o	OpenAI	0 (gratis)	✅	✅	✅
Grok Code Fast 1	xAI	0.25	✅	✅	✅
Claude Haiku 4.5	Anthropic	0.33	✅	✅	✅
Gemini 3 Flash	Google	0.33	✅	✅	✅
GPT-5.4 mini	OpenAI	0.33	✅	✅	✅
Claude Sonnet 4.6	Anthropic	1	✅	✅	✅
Gemini 2.5 Pro	Google	1	✅	✅	✅
GPT-5.2	OpenAI	1	✅	✅	✅
GPT-5.3-Codex	OpenAI	1	✅	✅	✅
GPT-5.4	OpenAI	1	✅	✅	✅
Claude Opus 4.6	Anthropic	3	✅	✅	✅
Claude Opus 4.6 fast (preview)	Anthropic	30	✅	✅	✅

Multiplicador: cuánto se descuenta de tu cuota premium por solicitud. Multiplicador 0 = no consume cuota premium. Multiplicador 30 = consume 30x la cuota de una solicitud normal.

Estrategia de selección por tarea

Para completions inline y preguntas rápidas (Ask):
GPT-4.1, GPT-5 mini, o Raptor mini. Multiplicador 0. No consumen cuota. Para preguntas que no requieren razonamiento profundo, son suficientemente buenos.

Para debugging y análisis de código (Agent con alcance limitado):
Claude Haiku 4.5 (0.33x) o Grok Code Fast 1 (0.25x). Buena velocidad, buen costo.

Para tareas complejas de implementación (Agent o Plan):
Claude Sonnet 4.6 (1x) o Gemini 2.5 Pro (1x). Son los de mejor balance calidad/costo para trabajo serio.

Para arquitectura compleja, refactoring masivo o análisis de sistemas:
Claude Opus 4.6 (3x). Reservar para cuando la profundidad de razonamiento justifica el costo.

Para Go específicamente:
GPT-5.3-Codex o GPT-5.4 tienen excelente comprensión de Go idiomático. Claude Sonnet 4.6 es igual de bueno y tiene mayor contexto de concurrencia.

Para Flutter/Dart:
Claude Sonnet 4.6 o Gemini 2.5 Pro. Gemini tiene mayor cobertura del ecosistema Flutter por ser de Google.

Para SQL y bases de datos:
Claude Sonnet 4.6 o GPT-5.4. Ambos tienen excelente comprensión de query optimization y schemas relacionales.

Para DevOps, YAML, Terraform:
GPT-5.3-Codex o Claude Sonnet 4.6. Grok Code Fast 1 también funciona bien para infraestructura.

Auto-selección de modelo

VS Code también tiene un modo Auto que selecciona el modelo óptimo automáticamente según la disponibilidad y aplica un descuento en solicitudes para usuarios de pago. Es una buena opción cuando no tienes una preferencia fuerte, ya que balancea rendimiento y cuota.

---

Sistema de Instrucciones: Programar el Comportamiento del Agente

Las instrucciones personalizadas son la forma más eficiente de ahorrar tokens y mejorar la calidad de respuestas. En lugar de repetir en cada prompt “usa TypeScript strict”, “no uses console.log”, “el proyecto sigue arquitectura hexagonal”, lo defines una vez y el agente lo aplica siempre.

VS Code soporta varios tipos de instrucciones, y entender cuál usar evita duplicación y conflictos.

.github/copilot-instructions.md: instrucciones siempre activas

El archivo más importante. Se aplica automáticamente a todas las solicitudes en el workspace. No necesitas referenciarlo, no necesitas activarlo. Solo existe y el agente lo lee.

Úsalo para:

• Estándares de código que aplican a todo el proyecto
• Stack tecnológico y versiones preferidas
• Patrones arquitectónicos a seguir o evitar
• Requisitos de seguridad y manejo de errores
• Estándares de documentación

# .github/copilot-instructions.md

## Stack

- Runtime: Bun (usa `bun` nunca `npm run`)
- Framework: Astro 5 + TypeScript strict mode
- Styling: Tailwind CSS 3, no styled-components
- Testing: Vitest

## Convenciones

- Funciones puras cuando sea posible
- No mutación directa de estado
- Errores como valores, no excepciones para flujo de control
- Comentarios solo cuando el código no puede ser auto-descriptivo

AGENTS.md y CLAUDE.md: compatibilidad multi-agente

Si trabajas con múltiples herramientas de IA (GitHub Copilot, Claude Code, otros), AGENTS.md en la raíz del workspace es reconocido por todas ellas. CLAUDE.md es específico para Claude pero VS Code también lo detecta.

La ventaja de AGENTS.md sobre copilot-instructions.md: une tu configuración para todos los agentes en un solo lugar, y soporta archivos en subcarpetas para aplicar reglas específicas por módulo (experimental).

.instructions.md: instrucciones condicionales por contexto

Los archivos *.instructions.md en .github/instructions/ se aplican dinámicamente según el patrón de archivos que el agente está editando.

---
# .github/instructions/go.instructions.md
name: "Go Standards"
description: "Convenciones para archivos Go"
applyTo: "**/*.go"
---

- Usa `errors.New` o `fmt.Errorf` con `%w` para wrapping, nunca `panic` en handlers
- Interfaces definidas en el paquete que las usa, no en el que las implementa
- Goroutines solo con contexto cancelable
- `defer` para cleanup, siempre
- Exporta solo lo necesario: si no sale del paquete, no debe empezar con mayúscula

Puedes tener instrucciones separadas por lenguaje, por módulo, por tipo de archivo:

.github/instructions/
  go.instructions.md          # applyTo: **/*.go
  react.instructions.md       # applyTo: **/*.{tsx,jsx}
  tests.instructions.md       # applyTo: **/*.test.*
  docs.instructions.md        # applyTo: docs/**

Agentes personalizados (.agent.md): personas específicas por rol

Los custom agents son la siguiente capa de customización. Donde las instrucciones definen reglas, los agentes definen un rol completo: qué herramientas tiene disponibles, qué modelo usa, cómo se comporta.

Un agente personalizado se define en .github/agents/nombre.agent.md:

---
# .github/agents/reviewer.agent.md
name: Code Reviewer
description: Revisa código para calidad, seguridad y adherencia a patrones
tools: ["readFile", "search", "web"]
model: Claude Sonnet 4.6 (copilot)
handoffs:
  - label: Implementar correcciones
    agent: agent
    prompt: Implementa las correcciones del review anterior.
    send: false
---

Eres un revisor de código senior. Tu objetivo es identificar:

1. Problemas de seguridad (OWASP Top 10, inyección, auth bypass)
2. Problemas de rendimiento (N+1 queries, memory leaks, algoritmos O(n²))
3. Violaciones de los patrones del proyecto
4. Código no testeado o difícil de testear

No hagas cambios. Solo reporta hallazgos con referencias a archivos y líneas.

Observa: este agente solo tiene herramientas de lectura (readFile, search, web). No puede modificar archivos. Eso es principio de menor privilegio aplicado a IA.

Con handoffs, al terminar el review aparece un botón “Implementar correcciones” que pasa el contexto al agente principal. Flujo guiado sin perder el historial.

Agent Skills (SKILL.md): capacidades portables y reutilizables

Las Agent Skills son el nivel más sofisticado. Una skill es una carpeta con un SKILL.md y recursos adicionales (scripts, templates, ejemplos). Se carga progresivamente: el agente primero lee la descripción, luego las instrucciones, luego los recursos según los necesita.

Clave: las skills son un estándar abierto (agentskills.io). Funcionan en VS Code, GitHub Copilot CLI, y Copilot cloud agent.

.github/skills/
  testing-go/
    SKILL.md
    test-template_test.go
    examples/
      table-driven-test.go
      mock-setup.go

---
# .github/skills/testing-go/SKILL.md
name: testing-go
description: Genera tests en Go con table-driven tests, mocks, y benchmarks.
  Úsame cuando necesites tests para código Go nuevo o existente.
---

# Testing en Go

Siempre usa table-driven tests. Template base en [./test-template_test.go](./test-template_test.go).

Pasos:

1. Identificar el comportamiento a probar (no la implementación)
2. Definir casos: happy path, edge cases, errores esperados
3. Usar subtests con `t.Run` para cada caso
4. Mocks solo con interfaces, ver [./examples/mock-setup.go](./examples/mock-setup.go)

El agente carga el SKILL.md cuando detecta que la tarea está relacionada con testing en Go, y solo accede al template si lo necesita. Contexto mínimo necesario, nada más.

Jerarquía de prioridad

Cuando múltiples instrucciones conviven, el orden de prioridad es:

1. Instrucciones de usuario (perfil personal) — máxima prioridad
2. Instrucciones de repositorio (.github/copilot-instructions.md, AGENTS.md)
3. Instrucciones de organización — mínima prioridad

Esto significa que tus preferencias personales siempre pueden sobreescribir las del proyecto, y las del proyecto pueden sobreescribir las de la organización.

---

MCP Servers: Extender el Agente con Herramientas Externas

Model Context Protocol (MCP) es el estándar abierto para conectar modelos de IA con herramientas y servicios externos. En VS Code, un servidor MCP provee herramientas que el agente puede invocar: acceso a bases de datos, navegador web, sistemas de archivos remotos, APIs externas.

La arquitectura es simple: el servidor MCP corre en tu máquina (o en un endpoint HTTP remoto). VS Code lo descubre, lista sus herramientas, y el agente las llama cuando son relevantes.

Configurar MCP en .vscode/mcp.json

{
  "servers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    },
    "playwright": {
      "command": "npx",
      "args": ["-y", "@microsoft/mcp-server-playwright"]
    },
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp"
    }
  }
}

El archivo .vscode/mcp.json en el workspace se comparte con el equipo si está en control de versiones. Para servidores personales usa MCP: Open User Configuration.

Los mejores MCP servers gratuitos

Context7 (@upstash/context7-mcp)
Herramienta más valiosa si trabajas con librerías de terceros. Provee documentación actualizada de librerías directamente al contexto del agente. En lugar de que el modelo adivine la API de Astro 5 o Go 1.25 basado en su training data, Context7 trae la documentación real del momento. Previene hallucinations sobre APIs que cambiaron.

# En el prompt
"Migra este componente React a Astro, usa la API más reciente #context7"

Playwright (@microsoft/mcp-server-playwright)
Controla un navegador real desde el agente. Útil para testing E2E automatizado, scraping, o debugging de problemas de UI. El agente puede navegar a URLs, tomar screenshots, interactuar con formularios.

GitHub MCP (https://api.githubcopilot.com/mcp)
Acceso directo a tu cuenta de GitHub: repositorios, issues, pull requests, code search. El agente puede crear PRs, leer issues, buscar en el codebase de GitHub sin salir del editor.

Serena (mcp_oraios_serena_*)
Herramientas de análisis semántico de código a nivel de símbolos. En lugar de leer archivos completos, el agente puede buscar clases, funciones, relaciones entre símbolos. Reducción masiva de tokens en análisis de codebases grandes.

Sequential Thinking (@modelcontextprotocol/server-sequential-thinking)
Fuerza al modelo a razonar paso a paso antes de responder. Mejora la calidad en problemas complejos sin aumentar el tamaño del modelo usado.

Filesystem (@modelcontextprotocol/server-filesystem)
Acceso controlado al sistema de archivos más allá del workspace actual. Útil para proyectos monorepo o cuando el agente necesita acceder a archivos de configuración del sistema.

Recursos MCP: contexto bajo demanda

Más allá de herramientas, los servidores MCP pueden exponer Resources: datos que adjuntas al contexto de un prompt específico. Tablas de base de datos, respuestas de API, archivos específicos.

En el chat: Add Context > MCP Resources para adjuntar recursos de servidores instalados.

Permisos y seguridad

Cada nuevo servidor MCP requiere confirmación de confianza antes de arrancar. Esto es intencional: los servidores MCP ejecutan código arbitrario. Solo instala servidores de fuentes confiables.

En macOS/Linux puedes habilitar sandboxing para restringir qué archivos y dominios puede acceder un servidor:

{
  "servers": {
    "mi-servidor": {
      "command": "npx",
      "args": ["-y", "@example/mcp-server"],
      "sandboxEnabled": true,
      "sandbox": {
        "filesystem": { "allowWrite": ["${workspaceFolder}"] },
        "network": { "allowedDomains": ["api.example.com"] }
      }
    }
  }
}

Sandboxing no está disponible en Windows por el momento.

---

Copilot CLI: Ejecución Autónoma en Segundo Plano

El Copilot CLI es la capa más autónoma del sistema. Corre en tu máquina de forma independiente, fuera del editor, y puede ejecutarse mientras sigues trabajando en otra cosa.

Es diferente del agente local de VS Code en aspectos clave:

• Continúa corriendo cuando cierras VS Code
• Puedes lanzar múltiples sesiones en paralelo para tareas independientes
• Soporta aislamiento con Git worktrees para que los cambios no toquen tu rama activa

Cuándo usar Copilot CLI vs agente local

Situación	Usa
Tarea exploratoria, quiero ver el progreso	Agente local (interactivo)
Primero necesito un plan aprobado	Plan agent → handoff a CLI
Implementar una feature mientras trabajo en otra	Copilot CLI (background)
Explorar varias implementaciones posibles	Varias sesiones CLI en paralelo
Crear un PR para review del equipo	Cloud agent

Modos de aislamiento

Worktree isolation: VS Code crea un Git worktree separado para la sesión. Todos los cambios del agente van al worktree, no a tu rama activa. Cuando termina, revisas y aplicas los cambios que quieres. El nivel de permiso se fija automáticamente en Bypass Approvals porque el agente trabaja en un ambiente aislado.

Workspace isolation: el agente trabaja directamente en tu workspace actual. Útil cuando quieres los cambios aplicados de inmediato. Puedes elegir cualquier nivel de permiso.

Comandos especiales en CLI

El Copilot CLI soporta comandos slash propios:

• /compact: comprime el historial de conversación largo. Libera espacio en la ventana de contexto. Acepta instrucciones adicionales: /compact enfócate en las decisiones de API design
• /yolo o /autoApprove: activa aprobación automática de todas las herramientas sin confirmación
• /delegate: delega la sesión al cloud agent para crear un PR

Todos los prompt files, agent skills, y hooks configurados en el workspace también están disponibles en las sesiones CLI.

Flujo Plan → CLI: el patrón más productivo

El flujo más potente para features complejas:

1. Abre Plan agent: describe la feature o el cambio
2. El agente investiga el codebase con subagentes, te hace preguntas, genera un plan detallado
3. Revisas y apruebas el plan en el chat
4. “Start Implementation → Continue in Copilot CLI”: VS Code crea una sesión CLI con el plan completo como contexto
5. Sigues trabajando mientras CLI implementa autónomamente
6. Revisas los cambios cuando termina

El agente Plan nunca escribe código. El CLI implementa contra el plan aprobado. Tú tienes control en los dos puntos que importan: el “qué” (el plan) y el “qué acepto” (el review final).

---

Ahorro de Tokens: Principios y Patrones Concretos

Reducir el consumo de tokens no es solo ahorrar dinero en cuota. Un contexto más chico produce razonamiento más limpio. El modelo piensa mejor cuando no tiene que procesar ruido.

Principio 1: Contexto selectivo, no exhaustivo

El error más común: adjuntar archivos completos cuando solo necesitas una función.

# ❌ Caro y ruidoso
"Lee src/services/users.ts y arregla el bug del login"
# → El agente lee 800 líneas para encontrar 30 relevantes

# ✅ Preciso y eficiente
"El método #authenticate en src/services/users.ts falla cuando el usuario
está inactivo. Debería retornar 403 en ese caso."
# → El agente va directo al punto

El #file syntax agrega archivos completos al contexto. El agente puede buscar en el workspace indexado sin adjuntar todo. Usa #file solo cuando el agente necesita el archivo completo, no para orientarlo.

Principio 2: Sesiones nuevas para tareas distintas

Una sesión es una conversación con su propia ventana de contexto. Cuando mezclas tareas no relacionadas en la misma sesión, el historial de la primera tarea contamina el contexto de la segunda y consume espacio valioso.

La regla es simple: nueva tarea, nueva sesión (Ctrl+Alt+I → New Chat).

Principio 3: /compact antes de que el contexto explote

Usa /compact manualmente cuando una sesión se alarga. El comando comprime el historial de conversación en un resumen. Puedes guiar qué se retiene: /compact mantén las decisiones de arquitectura y los endpoints definidos.

Si no lo haces, VS Code lo hace automáticamente, pero sin tus instrucciones sobre qué preservar.

Principio 4: Modelos gratuitos para tareas simples

Los modelos con multiplicador 0 (GPT-4.1, GPT-5 mini, Raptor mini) no consumen cuota premium. Para tareas donde la velocidad importa más que la profundidad del razonamiento, son suficientemente buenos:

• Preguntas rápidas sobre sintaxis o APIs
• Completar código repetitivo (CRUD, DTOs, tests unitarios simples)
• Generar documentación o comentarios
• Formatear o refactorizar código con reglas claras

Reserva Claude Sonnet 4.6 (1x) o superior para lo que realmente lo necesita: análisis arquitectónico, debugging complejo, tasks de múltiples archivos con dependencias intrincadas.

Principio 5: Instrucciones persistentes en lugar de repetir contexto

Cada vez que repites “este proyecto usa bun”, “sigue arquitectura hexagonal”, “no uses any en TypeScript” estás gastando tokens en contexto que podrías cargar una sola vez. Las instrucciones en .github/copilot-instructions.md son gratis desde la perspectiva del flujo: no las escribes en el prompt, el sistema las inyecta.

Invierte tiempo en escribir buenas instrucciones una vez. El ROI en tokens ahorrados es inmediato.

Principio 6: Skills sobre contexto manual para tareas recurrentes

Si tienes una tarea que haces frecuentemente (escribir tests en Go, hacer reviews de seguridad, generar migrations de base de datos), un Agent Skill carga el contexto necesario solo cuando es relevante.

Sin skill: tienes que agregar contexto manual en cada prompt.
Con skill: el agente detecta la tarea y carga las instrucciones automáticamente.

Principio 7: Subagentes para investigación distribuida

Cuando el agente necesita entender múltiples partes del sistema antes de actuar, los subagentes lo hacen en ventanas de contexto separadas y te devuelven solo los resúmenes. El contexto principal permanece limpio.

Esto aplica especialmente al modo Plan: diseña las tareas complejas como preguntas de investigación antes de ejecutarlas, para que el agente naturalmente delegue.

---

La Configuración Óptima: Todo Junto

Esta es la estructura de archivos que yo recomendaría como punto de partida para cualquier proyecto:

.
├── .github/
│   ├── copilot-instructions.md    # Reglas siempre activas para Copilot
│   ├── agents/
│   │   ├── reviewer.agent.md      # Agente de review (solo lectura)
│   │   ├── planner.agent.md       # Agente de planificación
│   │   └── docs.agent.md          # Agente para documentación
│   ├── instructions/
│   │   ├── backend.instructions.md  # applyTo: src/api/**
│   │   ├── frontend.instructions.md # applyTo: src/components/**
│   │   └── tests.instructions.md    # applyTo: **/*.test.*
│   └── skills/
│       ├── deploy/
│       │   └── SKILL.md
│       └── testing/
│           └── SKILL.md
├── AGENTS.md                      # Instrucciones compartidas con otros agentes
├── .vscode/
│   └── mcp.json                   # Servidores MCP del workspace
└── .claude/
    └── rules/                     # Compatibilidad con Claude Code

.vscode/mcp.json recomendado

{
  "servers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    },
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp"
    },
    "playwright": {
      "command": "npx",
      "args": ["-y", "@microsoft/mcp-server-playwright"]
    }
  }
}

Settings de VS Code que marcan la diferencia

{
  // Habilitar agentes
  "chat.agent.enabled": true,

  // Detectar AGENTS.md
  "chat.useAgentsMdFile": true,

  // Detectar CLAUDE.md
  "chat.useClaudeMdFile": true,

  // Para monorepos: buscar instrucciones en el repo padre
  "chat.useCustomizationsInParentRepositories": true,

  // Reiniciar MCP automáticamente cuando cambia la config
  "chat.mcp.autoStart": true,

  // Habilitar subagentes anidados para workflows complejos
  "chat.subagents.allowInvocationsFromSubagents": true
}

---

Patrones de Trabajo Probados

Después de usar este sistema en proyectos reales, estos son los patrones que funcionan:

Para una feature nueva: Plan → revisión del plan → Copilot CLI con worktree → review del PR → merge.

Para un bug difícil: Ask (entender el contexto) → Agent con Default Approvals (reproducir y entender) → Agent con Bypass Approvals (corregir y verificar).

Para refactoring de módulos: Plan agent con instrucciones de arquitectura → subagentes investigando dependencias → plan detallado → CLI implementando → reviewer.agent.md validando.

Para documentación: docs.agent.md (solo lectura, instrucciones específicas para el estilo de docs del proyecto) → generate y revisar.

Para onboarding de un nuevo servicio: /init en el chat para que el agente analice el proyecto y genere copilot-instructions.md automáticamente. Punto de partida que puedes refinar.

---

Lo que Cambia tu Flujo de Trabajo

El cambio más profundo que trae este sistema no es la automatización. Es la separación de preocupaciones en el desarrollo:

• Las reglas del proyecto viven en instrucciones, no en tu cabeza
• El conocimiento recurrente vive en skills, no en prompts copiados
• Las tareas de investigación se delegan a subagentes, no saturan el contexto principal
• Las tareas largas corren en background, no bloquean tu sesión principal
• La memoria persiste entre sesiones, no se pierde con cada ventana cerrada

El desarrollador que entiende esto no pasa tiempo repitiendo contexto. Pasa tiempo diseñando trabajo que el agente puede ejecutar con precisión.

La precisión de tu output es directamente proporcional a la precisión de tu input. Un prompt vago con cero contexto produce código genérico. Un prompt específico respaldado por instrucciones, skills, memoria y el modelo correcto produce exactamente lo que necesitas.

Eso es entender la herramienta.