TL;DR
- La forma más rápida de mejorar el trabajo diario con agentes no es agregar más agentes. Es auditar dónde están tus instrucciones y si el agente recibe el contexto adecuado en el momento adecuado.
- Mantén las instrucciones breves, críticas y siempre relevantes en
AGENTS.md,CLAUDE.mdo reglas específicas de cada herramienta. Traslada los procedimientos repetibles a skills. Usa subagentes solo cuando el trabajo se beneficie de contexto aislado, investigación en paralelo o una revisión especializada. - Trata las skills como guías reutilizables: un
SKILL.mdbreve, una descripción clara de cuándo activarla, archivos de apoyo opcionales, scripts para verificaciones repetibles y límites de permisos claros. - Trata a los subagentes como compañeros de equipo con funciones bien delimitadas: investigador, revisor, especialista en depuración, planificador de migraciones o estratega de pruebas. Evita los agentes vagamente definidos como «ingeniero sénior» que hacen de todo.
- Agrega opciones explícitas para «no hacer nada» y «preguntar primero». El artículo de FixedBench de mayo de 2026 encontró que los agentes de programación evaluados proponían cambios no deseados en el 35–65% de las tareas que no requerían cambios, a menos que se planteara la inacción como un resultado exitoso.
- El hábito semanal práctico: revisa los prompts que repites, las correcciones que haces, las ejecuciones fallidas de agentes y las aprobaciones riesgosas que concediste. Cada caso es candidato para una regla, skill, subagente, herramienta o punto de control humano.
Qué aprenderás aquí
- Cómo auditar tu flujo de trabajo diario con agentes de IA sin convertirlo en una ceremonia de gobernanza.
- Cuándo actualizar las instrucciones siempre activas y cuándo crear una nueva skill.
- Cuándo es útil un subagente y cuándo solo agrega trabajo de revisión.
- Un mapa sencillo del flujo de trabajo con agentes que puedes reutilizar con ingenieros, PMs y líderes de equipo.
- Ejemplos concretos de
AGENTS.md,SKILL.mdy la definición de un subagente. - Un pequeño backlog de mejoras de alto impacto para tus agentes que puedes aplicar esta semana.
Este artículo está dirigido a ingenieros y PMs que ya usan agentes de IA en su trabajo cotidiano: programación, planificación, investigación, depuración, revisión, QA, redacción de tickets, resúmenes de PRs o preparación de notas de lanzamiento.
El objetivo no es construir una enorme plataforma de agentes. Es algo mucho más práctico: lograr que la sesión de mañana con un agente sea menos repetitiva, genere menos ruido y sea más fácil de confiar.
Este artículo se centra en el ciclo de auditoría: cómo clasificar los problemas recurrentes en instrucciones siempre activas, skills, subagentes, herramientas y puntos de control humano. Para temas relacionados de la misma serie, consulta Cuándo usar subagentes en lugar del hilo principal de chat para conocer las ventajas y desventajas de delegar, Skills frente a agentes predeterminados para tomar decisiones sobre skills respaldadas por benchmarks, y La evolución de la orquestación de agentes de IA para conocer el modelo de madurez desde prompts hasta plugins.
La idea central: audita lo que se repite
La mayoría de los problemas en los flujos de trabajo con agentes dejan huellas.
Sigues pegando la misma instrucción. El agente sigue olvidando cómo ejecutar el proyecto. Un bot de revisión sigue comentando problemas de estilo de poco valor. Un agente de programación sigue modificando archivos antes de reproducir el bug. Un PM pide un resumen de la hoja de ruta y recibe una respuesta segura de sí misma, pero sin rastro de las fuentes.
No son molestias aleatorias. Son señales sobre el diseño del flujo de trabajo.
Este es el ciclo de auditoría que me gusta usar:
Daily agent friction
|
v
What keeps repeating?
|
+--> Stable fact or team convention? -> always-on instructions
|
+--> Repeatable procedure? ----------> skill
|
+--> Long isolated investigation? ---> subagent
|
+--> Needs external data/action? ----> MCP/tool/integration
|
+--> Risky or ambiguous? ------------> human checkpoint
Esa es la diferencia entre «uso mucho los agentes» y «estoy mejorando mi sistema de agentes».
Comienza con una auditoría de 30 minutos de tu flujo de trabajo
No necesitas un modelo de madurez formal. Abre las conversaciones con agentes, los PRs, los hilos de Slack, las tareas o el historial de terminal de la última semana y responde cinco preguntas.
- ¿Qué repetí al menos tres veces?
- ¿Qué entendió mal el agente más de una vez?
- ¿Qué contexto tuve que pegar manualmente?
- ¿Qué trabajo produjo un diff ruidoso o riesgoso?
- ¿Qué tuve que verificar manualmente?
Luego clasifica cada hallazgo:
| Hallazgo | Lugar más adecuado | Por qué |
|---|---|---|
| «Usa pnpm, no npm» | Instrucción siempre activa | Se aplica a casi todas las tareas. |
| «Ejecuta el build antes de los PRs de artículos» | Instrucción siempre activa | Es una expectativa del repositorio. |
| «Crea un changelog a partir de los PRs integrados» | Skill | Es un procedimiento repetible. |
| «Investiga tres rutas de migración» | Subagente | Es un trabajo largo, exploratorio y que requiere mucho contexto. |
| «Verifica si se pueden compartir estos datos de clientes» | Punto de control humano | Es información sensible y depende de las políticas. |
| «Consulta los logs de producción» | Herramienta/MCP con aprobación | Requiere acceso a sistemas en vivo y límites de seguridad. |
Esta pequeña tabla suele ser suficiente para encontrar las próximas tres mejoras.
Las capas de contexto
Las herramientas modernas para agentes tienen ahora muchas superficies de contexto: AGENTS.md, CLAUDE.md, reglas de Cursor, skills, subagentes, servidores MCP, comandos con barra, hooks, memorias y configuraciones específicas de cada aplicación.
Puede parecer un desorden. El truco es separarlas según su función.
Always-on instructions
Small, stable, critical expectations
Example: setup, test commands, style rules, repo boundaries
Skills
Reusable procedures and domain playbooks loaded when relevant
Example: write an article, review a PR, migrate a component
Subagents
Specialized workers with isolated context and tool boundaries
Example: security reviewer, test planner, debugger, researcher
Tools and MCP
Real capabilities and external systems
Example: GitHub, docs search, browser, database, logs, design APIs
Human checkpoints
Approval, prioritization, judgment, risk acceptance
Example: deploy, delete data, merge risky PR, contact customer
El flujo de trabajo diario mejora cuando cada capa tiene un propósito claro.
Instrucciones siempre activas: mantenlas sencillas y valiosas
Las instrucciones siempre activas son las cosas que el agente debe saber antes de realizar cualquier trabajo.
El formato abierto AGENTS.md se describe como un README para agentes: comandos de configuración, pruebas, estilo de código y convenciones que ayudan a los agentes de programación a trabajar dentro de un repositorio. La documentación de Codex de OpenAI también describe un descubrimiento por capas: instrucciones globales, instrucciones del proyecto y sobrescrituras más específicas a nivel de directorio.
Esto hace que los archivos siempre activos sean ideales para:
- comandos de configuración
- comandos de build y pruebas
- estructura del proyecto
- convenciones que no son evidentes
- límites de seguridad
- áreas que «no se deben tocar»
- cómo validar el trabajo antes de terminar
No son adecuados para:
- documentación extensa de API
- guías de estilo completas
- procedimientos de varios pasos
- todas las preferencias que hayas tenido
- instrucciones que solo se aplican una vez al mes
El matiz importa. En una evaluación de Next.js 16 del 27 de enero de 2026, Vercel encontró que un índice comprimido de documentación en AGENTS.md de 8KB alcanzó una tasa de éxito del 100%, mientras que las skills llegaron como máximo al 79% incluso con instrucciones explícitas para activarlas, porque el agente no tenía que decidir si cargaba el contexto. Sin embargo, un artículo de arXiv de febrero de 2026 sobre archivos de contexto de repositorios encontró que los requisitos innecesarios en archivos del tipo AGENTS.md pueden reducir el éxito de las tareas y aumentar el costo de inferencia en más del 20%.
Mi conclusión: las instrucciones siempre activas deben ser mínimas, específicas y prácticas. Coloca ahí los datos que «no se deben olvidar». Lleva a otro lugar el contenido sobre «cómo hacer algo complejo». El resultado de Vercel corresponde a una evaluación específica de un framework; el artículo de arXiv es una advertencia más amplia contra los archivos de contexto demasiado extensos.
Ejemplo:
# AGENTS.md
## Project Defaults
- Install dependencies with `npm ci`.
- Run `npm run build` before opening a PR that changes source or content.
- Articles live in `content/articles/*.md` and are auto-discovered.
- Keep article frontmatter valid: `title`, `excerpt`, `tags`, and `date`.
## Review Rules
- Do not change unrelated files.
- If no code change is needed, say so and explain the evidence.
- Prefer primary sources for fast-moving AI tooling claims.
Observa lo que falta: un ensayo enorme. El agente necesita restricciones duraderas, no una biblioteca entera.
Skills: convierte los procedimientos repetidos en guías reutilizables
Las skills son el lugar indicado para los procedimientos repetidos.
Anthropic describe Agent Skills como carpetas de instrucciones, scripts y recursos que los agentes pueden descubrir y cargar dinámicamente. La documentación de skills de Claude Code deja muy claro el criterio práctico: crea una skill cuando sigues pegando la misma lista de verificación o cuando una parte de CLAUDE.md ha crecido hasta convertirse en un procedimiento.
Cursor 2.4 también agregó soporte para Agent Skills en el editor y la CLI, con archivos SKILL.md que pueden incluir comandos, scripts e instrucciones. El changelog de Cursor presenta las skills como una mejor opción que las reglas siempre activas para descubrir contexto dinámicamente y ofrecer instrucciones sobre «cómo hacer» algo.
Usa una skill cuando el flujo de trabajo tenga pasos:
- escribir un artículo basado en investigación
- inspeccionar un PR y elaborar una revisión
- migrar de un patrón de componentes a otro
- generar notas de lanzamiento
- depurar una prueba intermitente
- preparar un resumen de incidente para clientes
- realizar una auditoría de analítica de producto
Una skill debe tener un punto de entrada pequeño y abundante contenido de apoyo.
article-research/
SKILL.md # short workflow and triggers
references/
source-policy.md # how to score sources
article-template.md # expected structure
scripts/
check-frontmatter.js
Ejemplo de SKILL.md:
---
description: Research and draft a source-backed engineering article. Use when asked to create or update an article with sources, TL;DR, and practical examples.
disable-model-invocation: false
allowed-tools: Read Grep
---
## Workflow
1. Inspect the article schema and two recent articles.
2. For fast-moving topics, gather primary sources first.
3. Draft with:
- TL;DR
- What You Will Learn Here
- practical examples
- source list
4. Validate frontmatter and run the project build.
## Quality Bar
- Use absolute dates for recent product claims.
- Separate source-backed claims from inference.
- Keep the tone friendly for engineers and PMs.
La skill no necesita contener todos los artículos que se hayan escrito. Necesita iniciar el flujo de trabajo correcto de forma confiable.
Subagentes: úsalos para aislar contexto, no para aparentar
Los subagentes son útiles cuando evitan que la conversación principal se llene de información innecesaria.
La documentación de subagentes de Claude Code describe asistentes especializados con sus propias ventanas de contexto, prompts personalizados, acceso a herramientas y permisos independientes. Cursor 2.4 describe los subagentes como agentes independientes que se ejecutan en paralelo, usan su propio contexto y pueden configurarse con prompts, herramientas y modelos.
Esto hace que los subagentes sean útiles para:
- explorar bases de código grandes
- recopilar fuentes
- depurar problemas con muchos logs
- revisar seguridad o rendimiento
- definir estrategias de pruebas
- comparar enfoques de implementación
- obtener una crítica independiente después de la implementación
Son menos útiles cuando:
- la tarea es muy pequeña
- todos los agentes necesitan editar los mismos archivos
- nadie tiene tiempo para revisar múltiples resultados
- la tarea del subagente es vaga
- el agente principal ya tiene suficiente contexto
Las buenas definiciones de subagentes describen funciones bien delimitadas:
---
name: evidence-reviewer
description: Reviews drafted technical claims against provided sources. Use after a research article draft exists.
tools: Read, Grep
model: sonnet
---
You review source-backed writing for accuracy.
Focus on:
- claims that need a source
- claims that overstate what the source says
- dates that need to be absolute
- missing caveats or unsupported recommendations
Do not rewrite the article. Return a concise list of issues and suggested fixes.
Las malas definiciones de subagentes se basan en impresiones vagas:
---
name: super-engineer
description: Helps with engineering tasks.
---
Be smart and improve everything.
El primero tiene un trabajo. El segundo tiene una capa y ninguna agenda.
Un flujo de trabajo práctico para el uso diario de agentes
Este flujo de trabajo funciona bien para tareas de ingeniería y producto.
1. Frame
User/PM/engineer states the outcome and constraints.
2. Explore
Main agent or research subagent gathers repo/source context.
3. Decide
Human confirms the plan when risk or ambiguity is high.
4. Execute
Main agent implements; skills provide repeatable workflows.
5. Verify
Tests, build, browser checks, source audit, or reviewer subagent.
6. Capture
Update AGENTS.md, a skill, or a subagent if the lesson will repeat.
El último paso es el que la mayoría de los equipos omite.
Si el agente cometió un error y solo corriges el resultado, mejoraste un resultado. Si actualizas el recurso del flujo de trabajo que causó el error, mejoras las sesiones futuras.
Qué agregar o actualizar esta semana
Este es un backlog de mejoras de alto impacto para la mayoría de los equipos que usan agentes de IA a diario.
1. Agrega un README breve para agentes
Si tu repositorio no tiene un AGENTS.md, agrégalo. Si ya tiene CLAUDE.md, .cursor/rules o .github/copilot-instructions.md, decide si AGENTS.md debe convertirse en el índice portable y si los archivos específicos de cada herramienta deben apuntar a él.
Comienza con:
- comandos de configuración
- comandos de pruebas
- estructura del proyecto
- expectativas para los PRs
- límites de seguridad o de datos
- dónde encontrar documentación más detallada
Mantenlo lo suficientemente breve como para que alguien realmente lo revise en un PR.
2. Crea una skill de «Resumen de cambios»
Esta es una skill básica para el trabajo diario. Debe leer el diff actual, resumir el cambio, señalar riesgos y sugerir pruebas.
---
description: Summarize current git changes, identify risk, and suggest validation. Use before committing or opening a PR.
disable-model-invocation: false
---
## Current diff
!`git diff --stat && git diff --name-only`
## Instructions
Return:
1. What changed
2. Why it appears to matter
3. Risk areas
4. Validation still needed
If the diff is empty, say there are no local changes.
3. Crea un subagente de revisión de solo lectura
Crea un revisor que no pueda editar archivos. Su trabajo es encontrar problemas, no «arreglar todo» en segundo plano.
Buenas configuraciones por defecto:
- herramientas de solo lectura
- enfoque estricto en bugs, seguridad, pruebas y regresiones
- permiso explícito para devolver «sin hallazgos»
- resultados concisos
Esto importa porque los agentes de revisión generan más confianza cuando son selectivos.
4. Agrega una regla de inacción
Agrega esto a tus instrucciones siempre activas o a tu skill de revisión:
If no code or content change is needed, treat "no change" as a successful outcome.
Explain the evidence and stop.
Esta pequeña instrucción contrarresta el sesgo hacia la acción. El artículo de FixedBench de mayo de 2026 (Coding Agents Don’t Know When to Act) encontró que los agentes de programación evaluados proponían cambios no deseados en el 35–65% de las tareas que no requerían cambios, a menos que se planteara explícitamente la abstención como un resultado exitoso. No des por hecho que el agente sabe por sí solo que actuar con cautela también es un éxito.
5. Saca la documentación extensa del contexto siempre activo
Si tu archivo de instrucciones se está convirtiendo en un manual, divídelo:
AGENTS.md
short index and must-follow rules
docs/agent/
architecture.md
testing.md
release.md
.claude/skills/
release-notes/SKILL.md
pr-review/SKILL.md
El archivo siempre activo le dice al agente dónde buscar. La skill le dice cómo actuar. La documentación contiene los detalles.
6. Usa worktrees para el trabajo en paralelo con agentes
Cuando varios agentes o sesiones puedan editar archivos, aíslalos.
La documentación de worktrees de Claude Code describe directorios de trabajo separados con sus propias ramas para que las sesiones paralelas no entren en conflicto. Cursor 2.0 también destacó la ejecución de muchos agentes en paralelo mediante worktrees de git o máquinas remotas. Para conocer un patrón más detallado de worktrees con múltiples repositorios, consulta Carpetas de funcionalidades para múltiples repositorios con Git Worktrees y Claude Code.
Usa worktrees para:
- dos implementaciones alternativas
- correcciones de bugs en segundo plano
- borradores de artículos mientras hay una rama de funcionalidad activa
- experimentos con subagentes que puedan modificar archivos
Evítalos cuando la tarea sea únicamente una investigación de solo lectura.
Métricas accesibles para PMs sobre la calidad diaria del trabajo con agentes
Los PMs no necesitan entender cada configuración del modelo para mejorar los flujos de trabajo con agentes. Hagan seguimiento de señales sencillas:
| Señal | Qué indica |
|---|---|
| Cantidad de correcciones repetidas | Instrucciones ausentes o insuficientes |
| Ejecuciones de agentes abandonadas | Definición deficiente de la tarea o demasiada autonomía |
| Aceptación de comentarios de revisión | Si se confía en los agentes de revisión |
| Tiempo hasta obtener un borrador verificado | Si los agentes están acelerando el trabajo útil |
| Cantidad de veces que se pega contexto manualmente | Posibles skills o índices de documentación |
| Tiempo de limpieza después del trabajo del agente | Si los resultados generan demasiado ruido |
El objetivo no es la vigilancia. Es identificar qué flujos de trabajo vale la pena convertir en productos.
Una auditoría mensual sencilla de agentes
Una vez al mes, dedica 45 minutos junto con un ingeniero y un PM.
Inputs:
- last 10 agent-assisted PRs
- last 10 repeated prompts
- last 5 agent failures
- current AGENTS.md / CLAUDE.md / rules
- current skills and subagents
Questions:
- What should be always-on?
- What should become a skill?
- What should become a subagent?
- What should require approval?
- What should be deleted because nobody uses it?
Outputs:
- 1 instruction update
- 1 skill update
- 1 subagent/tooling experiment
- 1 thing removed
Ese último resultado es importante. Los sistemas de agentes se deterioran cuando solo agregas cosas.
Errores comunes
Error 1: convertir las instrucciones en un cajón de sastre
Si tu archivo siempre activo tiene cincuenta reglas, las menos importantes compiten con las más importantes. Mantén el archivo enfocado.
Error 2: crear una skill para información que el agente siempre debe conocer
Si el agente debe saber algo antes de tomar cualquier decisión, coloca una versión breve en el contexto siempre activo. Las skills solo son útiles cuando el agente las activa en el momento adecuado o tú las invocas directamente.
Error 3: crear subagentes antes de tener capacidad de revisión
El trabajo en paralelo no es gratis. Cada resultado adicional de un agente requiere revisión, integración o rechazo.
Error 4: dar acceso a herramientas sin límites
MCP y las integraciones de herramientas son útiles porque conectan a los agentes con sistemas reales. Ese también es el riesgo. La propia especificación de MCP enfatiza el consentimiento, la privacidad de los datos y la seguridad de las herramientas. Trata los permisos de las herramientas como acceso a producción, no como configuraciones de autocompletado.
Error 5: olvidar registrar la lección
Cuando un agente comete un error, pregúntate: ¿debería convertirse en una regla, una skill, un cambio en un subagente, una prueba o un punto de control humano?
Mi stack inicial recomendado
Si empiezas desde cero, yo lo mantendría sencillo:
Repo root:
AGENTS.md
setup, tests, conventions, safety rules, docs index
Skills:
summarize-changes
pr-review
research-article
release-notes
Subagents:
read-only-code-reviewer
source-auditor
debugger
test-strategist
Tools:
GitHub
browser
docs search
issue tracker
Human gates:
dependency additions
destructive commands
production data access
deploys
Eso basta para mejorar notablemente el uso diario de agentes sin construir una plataforma interna sobrediseñada.
Limitaciones
Este artículo es intencionalmente práctico, pero vale la pena dejar claros algunos límites desde el principio:
- No compara directamente herramientas específicas mediante benchmarks. Cursor, Claude Code, Codex, Copilot y otras herramientas evolucionan rápidamente.
- No cubre en profundidad la gobernanza empresarial: los logs de auditoría, la configuración administrada, la retención de datos y la aplicación de políticas merecen un artículo propio. Para conocer los controles de seguridad en torno a la programación con agentes, consulta Generación segura de código con agentes.
- No incluye una lista de verificación completa de seguridad de MCP para producción.
- Se centra en flujos de trabajo de conocimiento y software, no en agentes autónomos orientados a clientes.
- El stack inicial es una plantilla. Los equipos deben evaluar cada recurso según sus propios patrones de fallos, en lugar de copiarlo íntegramente.
Lecturas relacionadas
- Cuándo usar subagentes en lugar del hilo principal de chat — ventajas y desventajas de delegar, costo y carga de revisión.
- Skills frente a agentes predeterminados — cuándo las skills superan al contexto siempre activo, con evidencia de benchmarks.
- La evolución de la orquestación de agentes de IA — modelo de madurez desde prompts de sistema hasta plugins.
- Cómo crear un agente de ingeniero sénior — ingeniería de ciclos y orquestación más allá de las auditorías diarias.
- Carpetas de funcionalidades para múltiples repositorios con Git Worktrees y Claude Code — aislamiento de agentes en paralelo entre repositorios.
Fuentes
- Documentación de Claude Code: crear subagentes personalizados - subagentes, contexto aislado, acceso a herramientas, trabajo en primer y segundo plano, y alcance de proyecto y usuario.
- Documentación de Claude Code: ampliar Claude con skills - cuándo crear skills, estructura de
SKILL.md, controles de invocación, archivos de apoyo y contexto dinámico. - Documentación de Claude Code: ejecutar sesiones paralelas con worktrees - aislamiento mediante worktrees para sesiones paralelas y subagentes.
- Changelog de Cursor 2.4: subagentes, skills y generación de imágenes - notas de lanzamiento de Cursor del 22 de enero de 2026 sobre subagentes y skills.
- Anuncio de Cursor 2.0 - interfaz multiagente y trabajo paralelo de agentes con worktrees.
- Anthropic: preparar a los agentes para el mundo real con Agent Skills - Agent Skills como paquetes de instrucciones, scripts y recursos.
- Anthropic: ingeniería de contexto eficaz para agentes de IA - el contexto como recurso finito y por qué importa seleccionarlo cuidadosamente.
- Sitio oficial de AGENTS.md - formato abierto para instrucciones de repositorio dirigidas a agentes.
- Documentación de OpenAI Codex: instrucciones personalizadas con AGENTS.md - descubrimiento de instrucciones de Codex, alcance global y de proyecto, y sobrescrituras anidadas.
- Vercel: AGENTS.md supera a las skills en nuestras evaluaciones de agentes - evaluación de Next.js 16 del 27 de enero de 2026 que compara el contexto pasivo con la documentación activada mediante skills.
- Especificación de Model Context Protocol - herramientas, recursos y prompts de MCP, y principios de consentimiento, privacidad y seguridad de herramientas.
- Evaluación de AGENTS.md: ¿son útiles los archivos de contexto a nivel de repositorio para los agentes de programación? - artículo de febrero de 2026 sobre archivos de contexto; los requisitos innecesarios redujeron el éxito y aumentaron el costo de inferencia en más del 20%.
- Los agentes de programación no saben cuándo actuar - artículo de FixedBench de mayo de 2026 sobre el sesgo hacia la acción; tasa de cambios no deseados del 35–65% en tareas que no requerían cambios, entre cinco modelos y cuatro harnesses.