Wrapper de IA vs agente de IA: dónde acaba el chatbot

Llevo unos meses revisando proyectos que se autodenominan "producto con IA" y la mayoría son la misma cosa repetida. Un formulario, un prompt fijo, una llamada a OpenAI o a un gateway, y el resultado se pinta tal cual en pantalla. A eso lo llamo wrapper, sin ánimo despectivo. Es una arquitectura legítima cuando encaja, pero confundirlo con un producto agéntico de verdad es lo que hace que muchos equipos se queden atascados.

Esta serie va de cómo se cruza esa frontera. Antes de meterme con frameworks, observabilidad o pricing, quiero fijar el mapa.

La pregunta que separa wrapper de agente

Hay una pregunta sencilla que aclara casi siempre de qué lado estás. ¿Quién decide cuántos pasos hacen falta para resolver la petición del usuario, tu código o el modelo?

Si la respuesta es tu código, tienes un wrapper. El flujo es lineal, la lógica está fuera del modelo, el LLM hace una transformación de texto a texto y el resto del sistema se parece bastante a una API tradicional. Pongamos un generador de descripciones de producto. El usuario sube una foto, tu backend manda la imagen y un prompt al modelo, recibe el texto y lo guarda. Eso es un wrapper, y está perfecto si el problema cabe en ese molde.

Si la respuesta es el modelo, tienes algo distinto. El LLM decide qué herramienta llamar, en qué orden, cuándo parar, cuándo pedir más contexto, cuándo abandonar. Tu código se reduce a darle el bucle, las herramientas y los límites. Eso es un agente, aunque sea pequeño.

La diferencia parece sutil sobre el papel pero rompe casi todo lo que sabes de programación clásica. La latencia deja de ser predecible. El coste por petición varía un orden de magnitud entre dos sesiones idénticas en apariencia. Los logs dejan de servir y necesitas trazas. Los tests de toda la vida no detectan regresiones porque la salida no es determinista. Y tienes que protegerte de cosas que en un wrapper ni se plantean, como que el agente entre en un bucle, agote presupuesto en una sola sesión o ejecute una herramienta destructiva por una inyección de prompt.

Cuándo basta con un wrapper

No quiero pintar al wrapper como una arquitectura inferior. Hay tres situaciones donde es la decisión correcta.

La primera, cuando el problema es transformar una entrada en una salida y nada más. Resumir un texto, traducir, clasificar, extraer entidades, reescribir un correo. No hay decisión sobre el camino, solo sobre el resultado.

La segunda, cuando el flujo de pasos es estable y conocido. Un sistema RAG sencillo donde busco contra una base de embeddings, meto el contexto en un prompt y devuelvo respuesta. El orden de los pasos lo defino yo. El modelo solo redacta.

La tercera, cuando la tolerancia al error es alta y la responsabilidad es del usuario. Un autocompletado, una sugerencia de tag, un placeholder mejorable. Si el modelo se equivoca, el coste es nulo.

Si tu proyecto cae en cualquiera de estos tres, ahórrate la complejidad de un agente. Vas a sufrir mucho montando lo que no necesitas y no vas a obtener nada a cambio.

Cuándo el wrapper se queda corto

El problema aparece cuando empiezas a parchear el wrapper para que haga cosas que no le tocan. Síntomas que conozco bien.

El prompt crece sin parar. Cada caso nuevo añade dos párrafos de instrucciones, un ejemplo, una excepción. Llegas a 4.000 tokens de system prompt y el modelo se confunde más, no menos.

Empiezas a parsear la respuesta para decidir qué hacer luego. Si dice "X" llama a esta API, si dice "Y" haz lo otro. Eso es un agente cutre escondido, donde el bucle de control vive dispersamente entre tu código y el prompt.

El usuario te pide que "lo haga solo". Quiere subir un fichero, decir lo que necesita y volver veinte minutos después con el resultado. Tu wrapper no puede esperar, retomar contexto, encadenar tareas. Necesitas un sistema que mantenga estado entre turns y decida sobre la marcha.

Cuando aparecen dos o más de esos síntomas, has pasado de wrapper a agente sin querer y de la peor manera posible, con la lógica fuera de control y sin observabilidad.

Definición operativa de agente

Para no quedarme en la abstracción, fijo una definición que voy a usar el resto de la serie.

Un agente es un sistema con cuatro componentes mínimos que voy a desgranar uno a uno en posts siguientes:

Bucle de control. El código repite invocaciones al modelo hasta que se cumple una condición de parada. Esa condición puede ser una respuesta final, agotar un presupuesto de turns, o un timeout.

Herramientas. El modelo no transforma texto, sino que decide qué función externa llamar. Una función puede ser una búsqueda, una query a base de datos, un POST a una API, una operación de fichero. Las define tu código y las describe en un esquema que el modelo entiende.

Memoria. El estado de la conversación más allá del prompt actual. Mensajes previos, resultados de herramientas anteriores, hechos extraídos durante la sesión. Esa memoria persiste durante toda una sesión y, en sistemas más avanzados, a través de sesiones distintas.

Salvavidas. Límites duros que el bucle respeta sin pedir permiso al modelo. Presupuesto en tokens, número máximo de turns, lista de herramientas permitidas, validación de salidas. Sin estos, un agente en producción es una bomba.

Cualquiera de los cuatro es suficiente para distinguir un agente de un wrapper. Tener los cuatro es lo que separa un agente de juguete de uno que aguanta producción.

El precio de cruzar al lado agéntico

Esto no es gratis. Antes de embarcarte conviene saber qué pierdes al pasar de wrapper a agente.

Pierdes determinismo. Dos sesiones con la misma entrada pueden tomar caminos distintos. Eso te obliga a montar evals, no tests, y a aceptar que no vas a tener verde-rojo binario nunca más.

Pierdes predictibilidad de coste. Un agente puede gastar 0,02 USD o 4 USD en la misma tarea según cuánto contexto acumule, cuántas herramientas llame y si entra en un razonamiento extendido. Sin presupuestos por sesión, un usuario puede quemarte cien veces el plan en una tarde.

Pierdes la capacidad de depurar como antes. Un stack trace no te dice por qué el agente decidió llamar tres veces a la herramienta de búsqueda antes de responder. Necesitas trazas con spans, anotar inputs y outputs de cada turn y de cada herramienta, y revisar sesiones enteras como si fueran replays.

Ganas, a cambio, capacidad real. Tareas que no caben en un prompt fijo. Productos que un usuario delega y vuelve a recoger. Defensibilidad frente a la próxima feature gratuita que saque OpenAI, porque tu valor no está en la llamada al modelo sino en el sistema alrededor.

Por qué empiezo esta serie ahora

El catálogo del blog tiene ya unos cuantos posts sobre lo que llamaría infraestructura de IA. Comparativas de gateways como OpenRouter o Vercel AI Gateway, hardening de chats con presupuesto y rate limit, generación de imágenes con Replicate, narración de posts con TTS. Todos son piezas válidas, y casi todas son wrappers en sentido estricto. La mayoría está bien resuelta como wrapper porque el problema cabía ahí.

Lo que falta en el blog es la conversación sobre qué pasa cuando el problema no cabe. Cuándo conviene saltar a un sistema agéntico, qué framework elegir, cómo se observa, cómo se evalúa, qué pricing soporta y qué moat te queda cuando los wrappers se comodifican capa a capa.

Esto va a ser un recorrido de tres ejes en paralelo. El primero, conceptual, va al fondo de cada componente. El segundo, una hoja de ruta práctica de un agente que voy a construir y voy a contar como bitácora pública mientras lo hago. El tercero, estratégico, mira al producto y al mercado, porque elegir bien la arquitectura técnica no sirve si el ángulo de producto no aguanta seis meses.

El próximo post abre con la anatomía mínima de un agente, sin framework, en TypeScript a pelo, para que quede claro qué hay debajo antes de elegir abstracciones.

Otra entrega de la serie Del wrapper al agente. El siguiente post es Construir un agente desde cero en TypeScript.