Llevo tiempo usando agentes de IA en proyectos reales. No como experimento, sino como parte del flujo de trabajo diario. Y cuanto más los uso, más claro tengo algo: la brecha entre lo que se vende y lo que realmente aporta valor en el día a día es enorme.
Actualmente estoy desarrollando una API de más de 600K líneas de código, un proyecto de varios meses, grande, con múltiples integraciones externas complejas, arquitectura no trivial y mucha lógica de negocio. Sin orquestadores sofisticados, sin subagentes paralelos, sin memoria persistente entre sesiones, sin ninguna de las capas de infraestructura agéntica que se presentan ahora mismo como imprescindibles. Solo un agente bien configurado, un contexto de proyecto sólido y skills puntuales cuando tenían sentido. Cobertura de tests del 80%, asegurando los procesos más críticos.
Lo cuento al principio porque es el contexto desde el que escribo todo lo que sigue. No es teoría.
El contexto es todo. Literalmente.
Antes de hablar de subagentes, orquestadores o memoria persistente, hay algo más fundamental que marca la diferencia entre un agente que produce resultados útiles y uno que genera ruido: la calidad del contexto que le das.
Un agente que entiende tu arquitectura, tus patrones, tus restricciones y el problema concreto que tiene que resolver produce resultados consistentes. Un agente sin ese contexto, por muy sofisticada que sea la infraestructura que lo rodea, va a improvisar. Y la improvisación de un agente en un proyecto real tiene un coste que no siempre es inmediato pero siempre aparece: deuda técnica, inconsistencias de arquitectura, decisiones que nadie tomó conscientemente pero que están ahí en el código.
El fichero de contexto del proyecto es la pieza más importante de todo el ecosistema agéntico. No porque sea una idea nueva o sofisticada, sino porque funciona. Define el stack, los patrones que usas, las convenciones que importan, lo que no se debe hacer y por qué. Cuando eso está bien escrito, cada conversación con el agente arranca desde un punto sólido.
El Laravel AI Boilerplate es un ejemplo real de cómo estructurar esto en la práctica.
Hay un límite práctico importante aquí: a partir de cierto tamaño, ese fichero empieza a ser contraproducente. El modelo no ignora lo que no le cabe, lo mezcla todo y la calidad baja. La solución no es añadir infraestructura para gestionarlo dinámicamente. La solución es escribir mejor: más conciso, más preciso, sin repetir lo que ya está implícito en el código.
Las skills: cuándo tienen sentido real
La idea de dividir el conocimiento en ficheros especializados que se cargan según la tarea tiene lógica técnica. Si estás trabajando en un componente de frontend, no necesitas que el agente cargue las reglas de cómo gestionar migraciones de base de datos. Contexto limpio, respuestas más precisas.
Donde las skills aportan valor real es en proyectos con dominios claramente diferenciados: frontend, backend, infraestructura, tests. Cada dominio con sus propias convenciones, sus propios patrones, sus propias restricciones. Cargar solo lo relevante para la tarea que tienes entre manos es una buena decisión.
Donde no tienen tanto sentido es en proyectos más pequeños o enfocados donde el contexto total es manejable. Añadir un sistema de skills a un proyecto donde un fichero de contexto bien escrito es suficiente es añadir complejidad sin añadir valor.
Los MCPs: útiles cuando el agente necesita salir de tu código
Los servidores MCP resuelven un problema concreto: conectar al agente con sistemas que están fuera de tu proyecto. Base de datos, documentación externa, herramientas de gestión. Cuando el agente necesita contexto de algo que no está en tus ficheros, un MCP bien configurado lo aporta directamente.
El criterio para usarlos es simple: ¿hay información relevante para la tarea fuera del código que el agente no puede ver? Si la respuesta es sí y esa información mejora la calidad del output, tiene sentido. Si estás instalando MCPs porque "hay que tenerlos", no.
Subagentes: el paralelismo tiene un precio
Aquí es donde más divergo de la narrativa dominante ahora mismo.
Los subagentes que trabajan en paralelo tienen un caso de uso legítimo: tareas verdaderamente independientes donde el paralelismo aporta velocidad sin riesgo de colisión. Analizar documentación, revisar código sin modificarlo, procesar secciones aisladas. En esos casos, funciona bien.
El problema es cuando se aplica a desarrollo real, con código que tiene dependencias cruzadas, decisiones de arquitectura que se afectan entre módulos y contexto de negocio que no está escrito en ningún sitio. Ahí, el paralelismo no supervisado introduce un riesgo que rara vez se menciona: varios agentes tomando decisiones inconsistentes entre sí, generando código que funciona por separado pero que no encaja.
Y aquí aparece la contradicción que más me llama la atención en todo este ecosistema: se habla mucho de que el desarrollador tiene que mantener el control, de que la IA amplifica pero no reemplaza el criterio humano. Pero supervisar subagentes que trabajan en paralelo en tiempo real es prácticamente imposible. Puedes revisar el resultado cuando terminan, pero eso no es lo mismo que supervisar el proceso.
Para un desarrollador individual trabajando en un proyecto con arquitectura propia, un agente bien configurado con sesiones enfocadas produce mejores resultados que un sistema de subagentes paralelos con toda la infraestructura que conlleva. Más control, menos complejidad, menos tokens, menos superficie de error. Mi experiencia este año lo confirma.
El mundo que nadie menciona en las demos
Hay algo que brilla por su ausencia en todas las presentaciones sobre IA agéntica: las demos siempre parten de un proyecto limpio, con una arquitectura conocida, resolviendo un problema que el modelo ya ha visto miles de veces. Un CRUD, un componente de UI, una refactorización de código bien estructurado.
Eso está muy lejos de una parte importante del desarrollo real.
¿Qué pasa cuando tienes que integrarte con la API de un proveedor que lleva quince años sin actualizar su documentación, donde el comportamiento real difiere de lo que dice la especificación, donde los códigos de error no siguen ningún estándar y donde la única forma de entender qué está pasando es leer respuestas crudas y deducir la lógica por ensayo y error? El agente no tiene base de conocimiento para eso. No hay patrones que aplicar. No hay ejemplos entrenados. Y añadir más subagentes o más memoria persistente no cambia nada, porque el problema no es de contexto, es de opacidad.
Lo mismo ocurre con proyectos legacy. Código de hace diez años sin documentación, con lógica de negocio enterrada en capas que nadie entiende del todo, con decisiones de diseño que se tomaron por razones que ya nadie recuerda. El agente puede leer ese código, puede intentar explicarlo, puede sugerir cambios. Pero cada modificación en un sistema así es una navegación en territorio desconocido donde el único mapa real es la experiencia de haber roto cosas antes y haber aprendido por qué.
O los sistemas de terceros mal diseñados por definición: integraciones donde la autenticación funciona de forma no estándar, donde los contratos de datos cambian sin previo aviso, donde hay comportamientos no documentados que solo descubres en producción a las tres de la mañana. Ahí no hay prompt que valga. No hay skill que te salve. No hay orquestador que resuelva que el sistema con el que te estás integrando simplemente está mal hecho y tienes que adaptarte a ello.
En todos estos escenarios, el agente puede ser útil, pero de una forma completamente diferente a como se presenta habitualmente. No como ejecutor autónomo que resuelve el problema por ti, sino como interlocutor mientras tú navegas lo desconocido. Alguien con quien pensar en voz alta, que te ayuda a procesar información ambigua, que te sugiere hipótesis mientras tú las validas contra la realidad del sistema. El trabajo sigue siendo tuyo. El criterio sigue siendo tuyo. La experiencia de haber visto ese tipo de problemas antes sigue siendo irremplazable.
Esto es lo que no aparece en ninguna demo: la IA agéntica resuelve muy bien los problemas predecibles. Los problemas opacos, mal documentados, heredados o simplemente mal diseñados por un tercero siguen requiriendo algo que ningún sistema de agentes tiene: años de haber resuelto exactamente ese tipo de problemas y haber aprendido a leer las señales correctas.
La memoria persistente: para quién y para qué
La idea de que el agente recuerde entre sesiones tiene sentido en un contexto específico: proyectos largos, con varios desarrolladores, donde el conocimiento acumulado se pierde entre personas y entre sesiones. Decisiones de arquitectura que se tomaron hace semanas, bugs resueltos con un root cause no obvio, patrones que se establecieron por razones que ya nadie recuerda.
Para ese problema, una memoria persistente bien implementada aporta valor real. No es magia, es gestión de conocimiento aplicada al contexto del agente.
Pero para trabajo individual con sesiones enfocadas, la mayor parte de ese conocimiento ya está en el código, en la estructura del proyecto, en el historial de git. El agente puede leer todo eso directamente. Añadir una capa de memoria persistente encima es, en muchos casos, resolver un problema que no tienes. Y cada consulta a memoria externa son tokens adicionales y latencia adicional que en sesiones cortas pueden superar el beneficio.
La pregunta que vale la pena hacerse
Antes de adoptar cualquiera de estos patrones, me hago siempre la misma pregunta: ¿qué problema concreto de mi flujo de trabajo actual resuelve esto? No si parece avanzado, no si es lo que usan los que saben. Qué fricción elimina. Qué me permite hacer que hoy no puedo hacer.
Si la respuesta es concreta, adelante. Si no lo es, la complejidad que añades va a ser un lastre, no un multiplicador.
Llevamos décadas en desarrollo viendo el mismo patrón: tecnología nueva, adopción masiva independientemente del contexto, sistemas sobrediseñados que son más difíciles de mantener que el problema que intentaban resolver. Con la IA agéntica está pasando lo mismo, solo que más rápido y con más ruido alrededor.
Lo que realmente multiplica tu productividad
Después de todo lo que he probado, lo que más impacto tiene en mi trabajo diario es lo más simple: un contexto de proyecto bien definido, sesiones enfocadas en tareas concretas, supervisión real de cada cambio antes de aplicarlo y criterio para saber cuándo el agente está acertando y cuándo está improvisando.
Eso no vende tan bien como un sistema de orquestación con subagentes paralelos y memoria persistente. Pero es lo que funciona en proyectos reales, con arquitectura real, integraciones reales y estándares de calidad reales.
La IA agéntica es una herramienta genuinamente poderosa. Pero como cualquier herramienta, su valor depende de usarla para lo que sirve, en el contexto en el que tiene sentido, con el criterio suficiente para saber cuándo estás resolviendo un problema y cuándo estás construyendo infraestructura para impresionar.
Ese criterio no te lo da ninguna herramienta. Te lo da la experiencia de haber visto qué pasa cuando el código llega a producción, cuando la integración falla en un caso que nadie documentó, cuando el sistema legacy hace algo que nadie esperaba. Y eso, por ahora, sigue siendo exclusivamente humano.
Rutas de aprendizaje
