Cursos/Agentes y automatización/Mapa real de agentes en 2026

Mapa real de agentes en 2026

Un agente no es magia: es un sistema que recibe una entrada, decide pasos, usa herramientas y deja evidencia. Esta lección te da el mapa para elegir la pieza correcta sin montar una fábrica cuando solo necesitas un temporizador.

Objetivos de aprendizaje
  • Distinguir agente, automatización, workflow y asistente.
  • Saber cuándo usar subagentes, hooks, skills, MCP, GitHub Actions o routines.
  • Diseñar cualquier agente con entrada, herramientas, límites, memoria y verificación.
En cristiano: agente. Es un ayudante con herramientas y un objetivo. La diferencia con un chatbot normal es que puede actuar: leer archivos, ejecutar comandos, abrir issues, llamar APIs o pedir datos a un MCP. La diferencia con un script es que decide parte del camino, no solo ejecuta una lista fija.

La taxonomía que importa

  • Prompt repetible: una receta que copias y pegas. Barato, simple, manual.
  • Skill: conocimiento empaquetado para que Claude sepa hacer una tarea concreta.
  • Subagente: otro Claude especializado que trabaja con su propio contexto y te devuelve una conclusión.
  • Hook: una regla determinista que se ejecuta en momentos concretos. No decide: obedece.
  • MCP: un puente a herramientas externas: GitHub, bases de datos, dashboards, ficheros, APIs.
  • GitHub Actions: automatización alrededor de issues y pull requests.
  • Routine: automatización en cloud gestionada por Anthropic. Útil, pero en research preview: no diseñes un negocio crítico dependiendo de que su API no cambie.
Idea clave. Regla de arquitectura: si la acción debe ocurrir siempre igual, usa un hook o un script. Si necesita criterio, usa un agente. Si necesita datos externos, añade MCP. Si necesita repetirse sin ti, súbelo a GitHub Actions, cron o routines.

El lienzo de diseño de un agente

Antes de escribir código, rellena esto. Es el antídoto contra agentes que hacen cosas raras:

Terminal
Nombre:
Objetivo:
Entrada:
Herramientas permitidas:
Herramientas prohibidas:
Memoria que puede leer:
Acciones que requieren confirmación:
Criterio de éxito:
Prueba mínima:
Registro de evidencia:
Cuidado. Si no puedes escribir el criterio de éxito en una frase, no tienes un agente: tienes una esperanza. Empieza con una versión pequeña, observable y fácil de apagar.

Ejemplo: agente revisor de PR

Mal planteado: “revisa mi código”. Bien planteado: “cuando se abra un PR, revisa solo seguridad, regresiones obvias y tests ausentes; comenta con archivo y línea; no cambies código; ignora estilo”. Eso ya se puede convertir en workflow.

Comprueba que funciona. Elige una tarea repetitiva de tu semana y clasifícala: ¿prompt, skill, subagente, hook, MCP, GitHub Action, routine o cron? Si dudas entre dos, elige la pieza menos poderosa. Los sistemas pequeños se arreglan; los sistemas demasiado ambiciosos se esconden.
Guardar y reabrir el proyecto.
Quédate con este orden de madurez: manual primero, semiautomático después, automático al final. Una automatización mala a escala es peor que hacer la tarea a mano.