La palabra «agente» se usa hoy para describir desde un chatbot con memoria hasta un sistema autónomo que despliega código en producción — y esa ambigüedad le hace daño a los equipos que intentan tomar decisiones técnicas reales. Esta es la definición sin hype: lo que un agente realmente es, cuándo tiene sentido construir uno y cuándo es sobreingeniería.
Qué diferencia a un agente de un chatbot
Un chatbot recibe un input y produce un output. Un agente recibe un objetivo y ejecuta los pasos necesarios para alcanzarlo — tomando decisiones en el camino, usando herramientas externas y ajustando su plan cuando los resultados intermedios no coinciden con lo esperado. El ciclo de un agente real tiene cuatro fases: planificar (descomponer el objetivo), actuar (ejecutar usando herramientas), observar (evaluar el resultado) e iterar (ajustar el plan). Un chatbot no tiene fase de observación ni iteración — responde y termina.
Plan, Act, Observe, Iterate: el ciclo en la práctica
Un agente de revisión de PRs puede recibir el objetivo «revisar este PR y comentar todos los posibles errores de seguridad». El agente planifica qué archivos revisar, lee cada uno usando herramientas de acceso al repositorio, observa si encontró patrones problemáticos, genera comentarios específicos por línea e itera si hay dependencias entre archivos. Un chatbot haría algo parecido si le pegas el código — pero no puede acceder al repositorio por sí mismo, ni iterar sobre su propia revisión.
«Un agente no es un chatbot más inteligente — es un sistema con un bucle de retroalimentación que le permite actuar en el mundo, no solo responder preguntas sobre él.»
Cuándo construir un agente y cuándo es sobreingeniería
Construye un agente cuando: el objetivo requiere múltiples pasos que dependen de resultados intermedios impredecibles y el costo de supervisión humana paso a paso supera el riesgo de autonomía. No construyas un agente cuando: el flujo es predecible y siempre sigue los mismos pasos (usa un pipeline determinista), o cuando un prompt bien diseñado hace el trabajo en una sola llamada. El AI-TDA más común hoy es construir agentes para problemas que un buen prompt resuelve en segundos. El equipo maduro no pregunta «¿podemos construir un agente para esto?» — pregunta «¿el problema realmente requiere un agente, o estamos añadiendo complejidad para sentirnos modernos?»
La tentación de los sistemas multi-agente es la misma que la de los microservicios hace diez años: resolver problemas de escala que todavía no tienes, añadiendo complejidad que sí tienes desde el primer día. Saber cuándo un sistema multi-agente es la respuesta correcta — y cuándo es sobreingeniería — es una de las decisiones técnicas más importantes de 2025.
La decisión real: pipeline determinista vs sistema agentivo
Un pipeline determinista ejecuta siempre los mismos pasos en el mismo orden: predecible, auditable, rápido. Un sistema multi-agente toma decisiones en tiempo de ejecución sobre qué agente activa y en qué orden. La regla de oro: si puedes mapear el flujo completo en un diagrama antes de construir, probablemente necesitas un pipeline. Si el flujo depende de resultados que no puedes predecir hasta que la ejecución empieza, entonces un agente agrega valor real.
El patrón Orchestrator-Worker: cuándo usarlo
El orquestador recibe el objetivo, lo descompone en subtareas y las delega a agentes especializados. Este patrón tiene sentido cuando las subtareas son paralelizables, especializadas y tienen fronteras claras. Ejemplo: un sistema de revisión de código donde el orquestador recibe el PR, delega la revisión de seguridad a un agente especializado, la revisión de performance a otro y las convenciones a un tercero, y consolida los resultados.
«Un sistema multi-agente bien diseñado es invisible para el usuario final — solo se nota su ausencia cuando el flujo se vuelve demasiado complejo para un agente solo.»
Cuándo parar y entregar con un enfoque más simple
En FAST Delivery, la decisión de arquitectura de agentes debe estar subordinada a la cadencia semanal. Si diseñar el sistema multi-agente correcto toma más de una semana, probablemente hay una solución más simple que entrega valor ahora. Los indicadores de sobre-ingeniería: el sistema tiene más de tres agentes para un flujo que un humano haría en cuatro pasos, o el equipo dedica más tiempo a coordinar los agentes entre sí que a construir el valor que el usuario necesita. El equipo que entiende cuándo parar de añadir complejidad es el que entrega valor semana tras semana — y esa disciplina es la ventaja competitiva real.
Construir un agente con Claude no es difícil; construirlo de forma que sea confiable en producción requiere exactamente el tipo de disciplina que distingue al AI-TDA del desarrollo serio. Este tutorial cubre el camino completo: desde la primera llamada a la API hasta un agente con herramientas reales, contexto persistente y una política de error que no deja el sistema en estado indefinido.
Un agente con Claude es un loop donde tú controlas la ejecución y el modelo controla las decisiones. Cuatro pasos: envías un mensaje con una lista de herramientas disponibles; el modelo responde con una acción de tool_use especificando qué herramienta llamar y con qué parámetros; tú ejecutas esa herramienta y obtienes el resultado; devuelves ese resultado como tool_result y el ciclo continúa hasta que el modelo produce una respuesta de texto final. La descripción de cada herramienta no es documentación para humanos: es el contexto que Claude usa para decidir cuándo y cómo usarla. Escríbela como si estuvieras instruyendo a un junior.
Memoria y contexto persistente
Claude no tiene memoria entre llamadas. Si tu agente necesita recordar decisiones anteriores, esa memoria debe vivir en tu código y ser inyectada en el contexto de cada nueva llamada. La forma más pragmática: un JSON o estructura en memoria con las acciones tomadas en la sesión actual, los resultados obtenidos y el estado acumulado. Mantén este contexto compacto: resumir en lugar de acumular verbatim evita que la ventana de contexto se sature en sesiones largas.
«El agente es tan bueno como las herramientas que le das y tan confiable como la política de error que defines para cuando esas herramientas fallan.»
Reintentos, errores y cuándo detener el loop
Define antes de escribir una sola línea: ¿cuántos ciclos máximos puede ejecutar el agente? ¿Qué pasa si una herramienta falla dos veces consecutivas? El patrón recomendado: máximo N iteraciones configurables, reintento con backoff exponencial para errores transitorios, escalada inmediata para errores de autorización, y log completo de cada iteración antes de cualquier acción. Si el agente llega al límite sin completar el objetivo, produce un informe del estado actual y escala — nunca silencia el fallo.
De prototipo a producción
Un agente que funciona en local no es un agente de producción. Antes de desplegar: cada herramienta debe tener validación de inputs y manejo de excepciones propio, el agente debe tener un modo dry-run donde razona y registra pero no actúa, y debe existir observabilidad completa de cada llamada al modelo y cada invocación de herramienta. En SFD, ningún agente entra a producción sin al menos una semana de operación en modo observación con revisión diaria de logs. El agente que resiste la primera semana en producción no es el más inteligente, sino el mejor diseñado para fallar de forma segura.
