Desarrollo de agentes de IA que sobreviven a producción

Desarrollar agentes de IA es construir software donde un modelo de lenguaje decide qué paso dar, llama a herramientas reales para darlo, lee el resultado y vuelve a decidir, hasta cumplir un objetivo o hasta que un límite lo detiene. El producto no es el modelo: es el bucle que lo rodea. Ahí vive la ingeniería: qué puede invocar el agente, cómo le vuelven los errores, cómo se arrastra el estado entre pasos, qué ocurre cuando se desvía y cómo sabes después si hizo el trabajo. Un chatbot responde. Un agente actúa, y esa acción es lo que convierte esto en un proyecto de software y no en un prompt.

Un prototipo funcional para una tarea estrecha suele llevar de una a tres semanas. Llevar ese prototipo a un estado que pondrías delante de clientes lleva bastante más — de dos a cuatro meses — y casi nada de ese tiempo se va en prompts. Se va en integraciones que fallan de formas que el modelo debe absorber, en un conjunto de evaluación que detecte regresiones, en permisos, en registros con los que se pueda depurar y en la ruta de traspaso a una persona para los casos que el agente no debería decidir solo. Los equipos que presupuestan la demo y no la segunda fase son los que nunca salen del piloto.

Empieza por lo más ligero que resuelva la tarea. Para un solo agente con un puñado de herramientas, el SDK del proveedor del modelo y un bucle escrito por ti suelen ser todo el trabajo, y te dejan capaz de depurar cada paso. Recurre a un framework de orquestación cuando necesites de verdad estado duradero, control de flujo con ramas, reintentos sobre pasos largos o varios agentes coordinados. El coste de un framework no es la API: es que justo las piezas que necesitas inspeccionar en un mal día quedan dentro de la abstracción de otro. Elijas lo que elijas, mantén prompts, definiciones de herramientas y conjunto de evaluación fuera del framework: así cambiar cuesta un día y no una reescritura.

Hay dos costes y los equipos suelen planificar el equivocado. Coste de construcción: un agente interno estrecho suele situarse entre 8.000 y 30.000 $ de ingeniería; uno de cara al cliente con integraciones reales, evaluación y monitorización está más bien entre 30.000 y 120.000 $. Coste de operación: el gasto en tokens suele ser la línea menor y la más fácil de reducir — enrutar pasos simples a un modelo más barato, cachear y recortar contexto lo bajan a la mitad con frecuencia. La línea que se olvida es el mantenimiento: los modelos se retiran, las API cambian y el conjunto de evaluación hay que volver a pasarlo. Reserva alrededor del 15–25 % del coste de construcción al año.

Restringiendo lo que puede hacer en lugar de esperar que se porte bien. En la práctica: fundamenta las respuestas en documentos recuperados y haz que cite la fuente usada; da a las herramientas argumentos estrictos y tipados y valídalos antes de ejecutar; permite que una herramienta devuelva un honesto «no encontrado» y enseña al agente que no devolver nada es un resultado aceptable; limita el número de pasos y el gasto por ejecución; y pon una aprobación humana delante de todo lo irreversible: pagos, borrados, mensajes salientes a clientes. Y luego mide. Un conjunto de evaluación con cincuenta casos reales, incluidos los incómodos, dice más sobre fiabilidad que cualquier ajuste de prompt.

Usa una plataforma no-code cuando la tarea sea estándar, el volumen moderado y el coste de una respuesta equivocada bajo: enrutar preguntas internas, triaje de contactos, redactar primeras respuestas. Llegan de verdad más rápido a un resultado y te enseñan qué necesita realmente la tarea. Construye a medida cuando el agente deba tocar tus sistemas con permisos reales, cuando la latencia o el coste unitario importen a tu volumen, cuando necesites tu propia evaluación y traza de auditoría, o cuando el agente forme parte del producto que vendes. El camino habitual tiene sentido: prueba el flujo en una plataforma y luego reconstruye las partes que se lo hayan ganado.