¿Necesitas un agente de IA? En la mayoría de los casos, no.

Si te estás preguntando si necesitas un agente de IA, la respuesta honesta es: probablemente no. La mayoría de las funciones de producto que los fundadores quieren volver "agénticas" quedan mejor construidas como un flujo determinista, un simple formulario o un pequeño modelo de clasificación — más barato de operar, testeable en CI, explicable a un cliente y libre del no-determinismo que convierte un fallo de un martes en una investigación forense. Recurre a un agente solo en ese estrecho límite donde la apertura es realmente el requisito.

Ya escribimos un argumento parecido sobre machine learning: la mayoría de los problemas que la gente enmarca como ML son en realidad una consulta SQL y un umbral. La misma enfermedad tiene ahora un nombre nuevo. La cura es la misma: define el problema con precisión y luego elige la herramienta más simple que lo resuelva.

Agente de IA vs automatización: qué es de verdad un agente

Un agente de IA son tres cosas atornilladas: un gran modelo de lenguaje, un conjunto de herramientas que puede invocar (búsqueda, una base de datos, una API, un ejecutor de código) y un bucle — el modelo decide qué hacer, lo hace, lee el resultado y decide de nuevo, hasta que cree que terminó. Ese bucle es todo el propósito. Es también todo el problema.

La automatización determinista, en cambio, es una secuencia fija de pasos que escribiste. Un webhook se dispara, se crea un registro, sale un correo, se actualiza una fila. Misma entrada, misma salida, siempre, para siempre. Puedes leerla, testearla y razonar sobre cada rama.

La diferencia que importa no es inteligencia. Es control. La automatización hace exactamente lo que especificaste. Un agente hace lo que decida, lo que significa que cada ejecución puede diferir, y los modos de fallo son abiertos: puede entrar en bucle, inventar un argumento de herramienta, llamar a la API equivocada o producir con confianza una respuesta errónea que parece correcta. Estás cambiando determinismo por flexibilidad. La mayoría de las funciones no necesita ese cambio.

La versión corta

• Formulario o flujo cuando las entradas y los pasos son conocidos. Es la mayor parte de lo que estás construyendo.
• Modelo pequeño / ranker cuando necesitas puntuar, ordenar, clasificar o recomendar sobre señales estructuradas.
• Agente solo cuando la entrada es genuinamente no estructurada, el camino es genuinamente abierto y una respuesta errónea es barata de recuperar.

Por qué "agéntico" suele perder ante un flujo programado

Este es el patrón incómodo que vemos. Un fundador describe una función — "el usuario pide un reembolso y el sistema se encarga" — y alguien recurre a un agente porque la petición llega como una frase. Pero la lógica subyacente es una tabla de decisión: ¿fue dentro de 14 días?, ¿se envió el artículo?, ¿el importe está por debajo del umbral de aprobación del gestor? Son cuatro ramas. Un if lo resuelve. Es correcto el 100% de las veces, no cuesta nada por llamada y, cuando un cliente discute el resultado, puedes señalar la regla exacta que se activó.

Envuelve esa misma lógica en un agente y heredas cuatro facturas nuevas:

• Latencia y coste. Cada paso es una llamada al modelo. Un bucle de tres pasos son tres idas y vueltas, de cientos de milisegundos a segundos cada una, pagadas por token, siempre — frente a una lectura de base de datos que devuelve en milisegundos de un dígito, gratis.
• No-determinismo. La misma entrada puede producir salidas distintas entre ejecuciones. Es una pesadilla para el soporte, para los reembolsos, para cualquier cosa que un regulador o un cliente enfadado pueda examinar.
• Colapso del testing. No puedes escribir una aserción contra "el modelo suele hacer lo correcto". Acabas con suites de evaluación y tasas de aprobación estadísticas en lugar de un CI verde — y una tasa del 96% significa que 1 de cada 25 clientes recibe la respuesta equivocada.
• Inexplicabilidad. Cuando sale mal, la respuesta al "por qué" es una transcripción del razonamiento del modelo, que es una historia que se contó a sí mismo, no una causa que arregles con un parche de una línea.

Nada de esto es culpa del modelo. Es del bucle. Tomaste un problema de forma conocida y se lo entregaste a un sistema cuya característica definitoria es inventar la forma cada vez.

Dónde los agentes sí se ganan su lugar

No somos anti-agente. Hay trabajo real y valioso que solo un LLM-en-bucle hace bien, y fingir lo contrario es simplemente el error opuesto. Un agente se justifica cuando se cumplen las tres condiciones:

• La entrada es genuinamente no estructurada. Un montón de PDFs en formatos inconsistentes, una bandeja de soporte en texto libre, un hilo de correo confuso donde la petición real está enterrada en tres párrafos de cortesías. Cuando no puedes escribir el parser, un modelo que lee vale la pena.
• El camino es genuinamente abierto. Investigación abierta en la que no sabes de antemano qué fuentes importan, o un asistente de depuración que tiene que mirar el código, ejecutarlo, leer el error e intentarlo de nuevo. La ramificación es real, no imaginada.
• Una respuesta errónea es barata. Borradores de bajo riesgo — un primer correo, un resumen, una sugerencia de código que un humano revisa antes de que llegue a producción. El humano en el bucle es la red de seguridad, y el agente le ahorra el problema de la página en blanco.

Fíjate en el patrón: los agentes brillan donde de otro modo necesitarías un humano para leer, juzgar e improvisar — y donde un error cuesta una repetición, no un reembolso ni una demanda. Síntesis de investigación, triaje de entrada no estructurada, borradores bajo revisión. Es una categoría real y en crecimiento. Solo que es mucho más pequeña de lo que sugiere el hype del "hagámoslo agéntico".

Una checklist de decisión

Antes de construir cualquier cosa agéntica, recorre esta lista de arriba abajo. Detente en el primer sí.

1. ¿Lo resuelve un formulario o un flujo fijo? ¿Las entradas y los pasos se conocen de antemano? Construye el flujo. Listo.
2. ¿Es puntuar, ordenar, clasificar o recomendar sobre señales estructuradas? Construye un modelo pequeño o un ranker basado en reglas. Explicable, rápido, testeable.
3. ¿La entrada es no estructurada Y el camino es abierto Y una respuesta errónea es barata de recuperar? Ahora un agente se justifica. Mantén pocas herramientas, el bucle acotado y un humano sobre el resultado si el riesgo es real.
4. ¿Sigues tentado de volver "agéntico" el paso 1 o 2 de todos modos? Escribe qué te aporta el agente que la opción más barata no aporta. Si la respuesta honesta es "se siente más moderno", ya tienes tu respuesta.

Qué hace realmente Amplified Creations

En Amplified Creations nuestra opción por defecto es la automatización determinista y modelos pequeños y explicables — y solo añadimos un LLM en el límite donde la apertura es el requisito genuino. Nuestro stack es aburrido a propósito: PHP 8.3 en alojamiento compartido, páginas renderizadas en el servidor, un Cockpit CMS con SQLite, sin paso de build. Cuando un cliente necesita comportamiento "inteligente", preguntamos en cuál de los tres cubos cae antes de escribir una línea de código.

En concreto: el recomendador dentro de la app de bienestar Jofit es un pequeño ranker explicable, no un LLM en bucle. Puntúa y ordena opciones sobre señales estructuradas, así que podemos testearlo, razonar por qué sacó a la luz una sugerencia dada y ponerlo en producción sin costes de token por petición ni salida no determinista. Para los sitios de clientes, la "automatización" es abrumadoramente lógica simple en el servidor y tareas programadas: envíos de formulario enrutados por Resend, contenido extraído del CMS, JSON-LD generado a partir de los mismos datos — determinista, cacheable y lo bastante rápido para mantener el Lighthouse en torno a 95. Usamos LLMs donde corresponde — redactar y traducir contenido extenso bajo revisión humana, el tipo de trabajo no estructurado, de bajo riesgo y verificado por humanos en el que los agentes son buenos. No ponemos un modelo en el camino crítico de un checkout, un reembolso o cualquier cosa que pueda perjudicar a un cliente al fallar. Esto no es cautela por sí misma; es el mismo instinto de ingeniería que dice que no implementas tu propia criptografía. Usa la herramienta poderosa e impredecible solo donde su poder es el punto.

El resultado es software en el que nuestros clientes pueden confiar y que podemos depurar a las 2 de la madrugada. Un agente en producción es algo que supervisas. Un flujo determinista es algo que olvidas porque simplemente funciona. La mayoría de las veces, "simplemente funciona" es la función.

Preguntas frecuentes

¿Cuál es la diferencia entre un agente de IA y la automatización?

La automatización ejecuta una secuencia fija de pasos que escribiste, así que la misma entrada produce siempre la misma salida. Un agente de IA es un LLM que decide sus propios pasos en un bucle usando herramientas, así que su comportamiento puede variar de una ejecución a otra. La automatización cambia flexibilidad por control; un agente cambia control por flexibilidad.

¿Vale la pena un agente de IA para mi producto?

Normalmente no, para los flujos centrales. Los agentes valen la pena solo cuando la entrada es genuinamente no estructurada, el camino es abierto y una respuesta errónea es barata de recuperar — como investigación, triaje de entrada confusa o borradores de bajo riesgo que un humano revisa. Para entradas y pasos conocidos, un flujo o formulario es más barato, más rápido y testeable.

¿Cuándo debería usar un modelo pequeño en lugar de un agente LLM?

Usa un modelo pequeño siempre que estés puntuando, ordenando, clasificando o recomendando sobre señales estructuradas. Un ranker o clasificador enfocado es explicable, corre en milisegundos, no cuesta nada por llamada y puede testearse en CI — nada de eso es cierto para un LLM-en-bucle. Reserva el LLM para el lenguaje no estructurado que el modelo pequeño no puede leer.

¿Por qué el no-determinismo es un problema en producción?

Porque la misma entrada puede dar salidas distintas, lo que rompe el testing, el soporte y la rendición de cuentas. No puedes escribir una aserción limpia contra "normalmente correcto" y, cuando un cliente discute un resultado, solo puedes mostrarle la transcripción del modelo, no una regla que señalar y arreglar. Para reembolsos, facturación o cualquier cosa regulada, eso es inaceptable.

¿Amplified Creations está en contra de usar LLMs?

No. Usamos LLMs donde la apertura es el requisito real — redactar y traducir contenido bajo revisión humana. Nuestra objeción es poner un modelo no determinista en el camino crítico de funciones que un flujo determinista o un pequeño ranker resolverían de forma más barata, más fiable y más explicable.