El modelo no es el agente: las capas que faltan

Además del modelo, una aplicación que actúa de forma fiable necesita tools con contrato, estado, permisos, un sitio donde corre el código, evaluación y alguien que responda cuando falla. El modelo razona; el resto es el sistema. Si solo contratas el motor, no tienes el coche.

Es relativamente sencillo e impresionante crear una demo de un asistente: seleccionas un modelo, le das algo de contexto y las respuestas salen coherentes, y el consejo que ha ido a la reunión aplaude. A la semana siguiente el copiloto llama a tu API, se queda a medias y nadie sabe cuántos reintentos hizo, qué llamadas a herramientas probó antes de rendirse ni qué decisiones tomó para intentar resolver la pregunta. Ahí se ve la tesis: el modelo es el 20% visible; el resto es el sistema que lo rodea.

Un LLM (modelo grande de lenguaje) predice el siguiente token. Un agente es una aplicación que usa ese modelo para decidir y actuar: llama tools, guarda estado y opera sobre la cuenta de un cliente (el tenant) en tu SaaS. Google Cloud lo dibuja así: el modelo es el motor de razonamiento y alrededor hay tools, memoria, runtime y un sitio donde corre el código. Si solo contratas el motor, no tienes el coche.

Anthropic lo dice más seco: el bloque base no es "el modelo", sino el modelo aumentado (retrieval, tools, memoria). También avisan de empezar simple. Un workflow con camino fijo suele bastar; el agente que se dirige solo sale más caro y falla en cascada si las tools están mal hechas.

Esto es el mapa. No es el deep dive de permisos ni la comparativa MCP frente a API. Es saber qué capas existen, para qué sirven y cuáles puedes aplazar en un piloto sin mentirte.

Lo que la demo oculta

La demo es un chat y una tool feliz: el usuario escribe, el modelo llama get_ticket, sale un resumen y se acaba la reunión.

Lo que no se ve es quién es ese runtime cuando llama a tu API, qué pasa si la tool responde 500 dos veces, en qué tenant se guarda el resumen, si el siguiente turno reenvía 40.000 tokens de contexto y quién se levanta a las tres si el bucle no para. Es el mismo salto que ya contamos: una demo no es un agente.

El truco comercial es vender el modelo como si fuera el producto. Lo habitual es oír "hemos metido un copiloto en nuestro producto", cuando la realidad es un wrapper de Claude o de Codex. El comité oye innovación, un producto nuevo y más revenue; el equipo de plataforma oye un hueco: contrato de tools, estado, aislamiento, logs y dueño. El modelo no rellena ese hueco. Puedes cambiar de proveedor y seguir con el mismo agujero.

Tres cosas que la demo esconde y que el piloto no puede esconder:

1. La acción: el modelo propone y la tool ejecuta, así que si la tool existe, el riesgo existe.

2. El tiempo: un turno de chat muere al cerrar la pestaña, pero un agente deja restos (memoria, tickets a medias, tokens gastados).

3. El vecino: en un SaaS hay más de un cliente y la demo suele tener uno.

Si no puedes nombrar esas tres, aún no tienes un agente en producción: tienes una conversación conectada a una API.

Mapa de capas

Una arquitectura de agentes de IA es la lista de piezas que convierten un LLM en algo que actúa sin improvisar el sistema cada martes. No es un framework ni un slide de "orquestación". Es esto, en el orden de "si falta, duele":

Figura. Las siete capas (de la que se ve en la demo a la que te salva cuando falla)

Google Cloud parte el dibujo en modelo, tools, memoria, runtime del agente y runtime del modelo, y sirve. Nosotros juntamos runtime y sandbox, y separamos estado de memoria, porque en un SaaS esa confusión cuesta un incidente.

No hace falta montar las siete el día 1, pero sí saber cuáles dejas fuera a propósito. Un piloto que "aplaza" permisos no está aplazando: está esperando al primer cliente que no es el tuyo.

Tools y contratos

Una tool es un endpoint de una API pensada para agentes. Sin tools, un asistente solo puede responder lo que ya está en su corpus. Con tools puede resolver problemas; con tools de vuestra API es cuando aportáis funciones de IA a vuestros clientes.

El contrato es lo que puedes auditar: nombre, qué hace, sobre qué recurso, con qué argumentos y con qué límite. "Buscar artículos de ayuda del tenant actual, máximo 5, sin HTML crudo" es un contrato; "consultar la base" no lo es. Anthropic dedica un apéndice entero a esto y cuenta que, en SWE-bench, les llevó más tiempo pulir las tools que el prompt: el formato, los paths absolutos y lo difícil que es equivocarse. Tratan la interfaz agente-herramienta con el mismo cuidado que una interfaz humana.

Cómo expones esa tool (API propia, CLI, MCP) es una decisión de contrato, no de moda. MCP (Model Context Protocol) sirve cuando quieres un enchufe reutilizable entre agentes y servidores. Una API tuya sirve cuando esa acción ya existe en tu producto como un verbo estable (crear un ticket, leer un pedido) y quieres que el mismo input produzca el mismo efecto, sin que el modelo improvise el camino. Un CLI sirve en máquina local o en un job. Aquí no elegimos; exigimos que, elijas lo que elijas, el modelo no vea un menú libre.

Tres reglas de mapa, no de implementación:

- Allowlist: si no está en la lista de ese flujo, no existe.

- Argumentos estrechos: un ticket_id de ese tenant, no un SQL ni una URL libre.

- Límite: filas, importe, llamadas. Un bucle sin límite es una factura y un riesgo.

Si la demo abrió admin "para que se viera bien", la demo no está lista. El modelo no es el problema; el menú lo es.

Estado vs contexto vs memoria

Estas tres palabras se usan como sinónimos, y no lo son. Si el equipo no las distingue, el piloto mezcla "lo que pasó este run" con "lo que el modelo leyó" y con "lo que guardamos para el mes que viene".

Estado es lo que el sistema sabe de esta ejecución ahora: ticket_id, tenant, paso del flujo, último resultado de tool y si está esperando a un humano. Vive fuera del prompt. Lo puede leer un log y lo puede borrar un kill switch. Si el estado solo existe en el chat, no tienes estado, tienes un hilo.

Contexto es lo que metes en la ventana de este turno: instrucciones, esquema de tools, últimos mensajes y el trozo de documento que cortaste. Se paga y se vuelve a pagar en el siguiente paso. No es memoria: es el maletín de este vuelo. Si lo hinchas "por si acaso", pagas en cada hop y además mezclas tenants si el corte es vago.

Memoria es lo que persiste entre ejecuciones: un resumen de preferencias, un índice de artículos, un dato que el cliente ya dejó resuelto. Tiene que estar particionada por tenant y tiene que poder olvidarse. Una memoria vectorial global donde el contrato del cliente B aparece en la respuesta del A no es inteligente: es una fuga.

El fallo típico es guardar "memoria" pegando el hilo entero en el siguiente prompt y llamarlo estado. No puedes revocar eso, no puedes auditarlo y no puedes decir qué parte era del tenant. El modelo "se acordaba" porque tú le volviste a contar el secreto.

En el piloto, el estado explícito (ids, paso, resultado) vale más que una memoria elegante. La memoria se añade cuando hay algo que merezca recordar y un sitio donde partirlo.

Sandbox y ejecución

Sandbox es el recinto y ejecución es el hecho de correr código o una tool ahí dentro. Juntos responden dónde corre esto y qué no puede tocar.

El modelo no corre tu backend: corre (o dispara) un runtime. Ese runtime tiene red o no la tiene, puede escribir a disco o no, puede salir a internet o solo a tus APIs, y tiene un tiempo máximo y una cuenta de servicio. Google Cloud llama a eso runtime del agente, distinto del runtime del modelo. La distinción importa: puedes cambiar de LLM y seguir con un proceso que hace curl a cualquier sitio.

La demo suele correr en el portátil del que presenta, o en un notebook con las claves del entorno. El piloto corre al lado de datos de cliente. Si el agente puede ejecutar código (un "code interpreter", un CLI, un MCP que expone el filesystem), el sandbox no es un extra de seguridad: es la diferencia entre "propuso un script" y "escribió en el disco del tenant".

Tres preguntas que caben en una standup:

1. ¿Este agente sale a internet, o solo a una allowlist de hosts?

2. ¿Puede escribir, o solo leer?

3. ¿Cuánto tiempo y cuántas llamadas aguanta antes de morir?

Si la respuesta es "el modelo ya sabe que no debe", no hay sandbox, hay un deseo. Anthropic recomienda probar agentes autónomos en entornos acotados precisamente porque el error se compone. El recinto es el sitio donde ese error no se come el producto.

Evaluación y logs

Evaluación es cómo decides si el run fue aceptable; logs son el rastro para reconstruirlo. Sin las dos, "funcionó en la demo" es tu único test.

Un output que se lee bien no es una evaluación. El agente puede haber llamado la tool equivocada, mezclado el tenant en el contexto y aun así redactar un párrafo limpio. Eso no se ve en el chat: se ve en la traza (qué tool, qué argumentos, qué decisión, qué versión de prompt y de modelo).

En el mapa, esta capa pide lo mínimo para no volar a ciegas:

- Un criterio de "correcto" por caso (ticket resuelto, JSON válido, humano que no reescribió).

- Un log correlacionado: un run_id que una usuario, agente, tenant y tools.

- La capacidad de repetir el fallo. Si no puedes reproducir, no puedes arreglar.

No hace falta un laboratorio de evals el día 1, pero sí no tirar el rastro. Un log que pega el payload de dos clientes en el mismo export no es observabilidad: es otra fuga. Si no puedes contar el run, no puedes operar el agente.

Recuperación y ownership

Recuperación es lo que ocurre cuando la tool falla, el modelo se inventa un id o el run se queda a medias. Ownership es el nombre de la persona (o el rol) que responde por ese agente en ese tenant.

Sin recuperación, el agente reintenta sin tope o se detiene en silencio, y las dos salidas son malas. Un run serio tiene timeout, un número máximo de reintentos y una regla de idempotencia para que la misma petición no se ejecute dos veces.

Sin ownership, el agente es un proceso huérfano. Cuando pite Slack, el hilo será "¿esto es de plataforma, de producto o del vendor del modelo?". Si no hay dueño, no hay kill switch con permiso: hay un debate.

Ownership no es un RACI de 12 celdas. Es una frase que alguien puede decir en voz alta: "Este copiloto de soporte, en el tenant de piloto, lo opera Marta. Si hay que apagarlo, Marta apaga." El modelo no opera; la gente sí.

En el piloto, nombra dueño antes de abrir memoria. El que no tiene dueño no necesita más capas: necesita un responsable.

Cómo priorizar capas en un piloto

No montes el mapa completo para impresionar. Monta lo que evita el primer incidente y lo que te deja medir; el resto se fecha.

Día 1 (o no hay piloto). Tools con contrato y allowlist, tenant en cada llamada, un kill switch y un dueño. Sin eso, estás en la demo con un cliente de verdad.

Las dos semanas siguientes. Estado explícito (ids, paso, último resultado). HITL solo donde el fallo es caro de revertir, como en permisos. Logs con run_id. Límite de coste y de llamadas.

Después, si el caso aguanta. Memoria particionada. Evaluación que te deje bajar de modelo sin adivinar. Sandbox más estrecho (sin red, sin disco) si el agente ejecuta código. El enchufe MCP o la API extra, cuando el contrato ya existe y duele repetirlo.

Antes de abrir el segundo tenant, el equipo debería poder responder sí a esto.

¿El modelo está separado del runtime, y puedes cambiarlo sin reescribir las tools?

¿Cada tool tiene contrato, allowlist y límite, o el modelo elige del backend entero?

¿Estado, contexto y memoria tienen dueño y sitio, o todo vive en el prompt?

¿El agente tiene identidad y tenant, o reutiliza la sesión de María?

¿Sabes dónde corre y qué no puede tocar?

¿Puedes reconstruir el último run que salió mal?

¿Hay un nombre que apaga esto hoy?

Si faltan dos o más, no tienes arquitectura de agentes: tienes un modelo con accesorios. El prompt puede ser bueno, pero no es el sistema.

Cuando esas líneas existen, el resto es ingeniería. En Devic esas capas (tools, policy, traza, runtime) se operan en el harness: el modelo se cambia, el contrato no. Los planes sirven para medir un caso en un tenant antes de fingir que el mapa está completo.

El modelo que convence en la demo habla bien; el agente que aguanta en un SaaS tiene capas.