El modelo no es el agente: las capas que faltan

Además del modelo, una aplicación que actúa de forma fiable necesita acciones con un contrato claro, un sitio donde guardar en qué punto va la tarea, permisos, un lugar donde corre el código, una forma de comprobar si salió bien y alguien que responda cuando falla. El modelo piensa. El resto es el sistema. Si solo contratas el motor, no tienes el coche.

Es fácil y vistoso montar una demo: eliges un modelo, le das un poco de contexto y las respuestas salen coherentes. Quien está en la reunión aplaude. A la semana siguiente el copiloto llama a vuestro sistema, se queda a medias y nadie sabe cuántas veces reintentó, qué acciones probó antes de rendirse ni qué decidió para intentar resolver la pregunta. Ahí está la idea: el modelo es la parte visible. El resto es el sistema que lo rodea.

Un modelo grande de lenguaje predice la siguiente pieza de texto. Un agente es una aplicación que usa ese modelo para decidir y actuar: llama acciones, guarda en qué punto va y trabaja sobre la cuenta de un cliente de vuestro SaaS. Google Cloud lo dibuja así: el modelo es el motor que razona, y alrededor hay acciones, memoria, el programa que ejecuta al agente y el sitio donde corre el código. Si solo contratas el motor, no tienes el coche.

Anthropic lo dice más seco. La pieza base no es el modelo solo, sino el modelo con búsqueda, acciones y memoria. También avisan de empezar simple. Un camino fijo suele bastar. El agente que decide solo sale más caro y falla en cadena si las acciones están mal hechas.

Esto es el mapa. No es el detalle de permisos ni la comparativa entre un enchufe común y vuestra propia conexión. Es saber qué capas existen, para qué sirven y cuáles puedes dejar para después sin engañarte.

Lo que la demo oculta

La demo es un chat y una acción que sale bien: la persona escribe, el modelo pide el ticket, sale un resumen y se acaba la reunión.

Lo que no se ve es qué programa llama a vuestro sistema, qué pasa si esa llamada falla dos veces, en la cuenta de qué cliente se guarda el resumen, si el siguiente paso reenvía una cantidad enorme de texto y quién se levanta de noche 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. Se oye "hemos metido un copiloto", y la realidad es una capa fina encima de Claude o de Codex. El comité oye una novedad. El equipo que opera el producto oye un hueco: contrato de las acciones, estado, separación de clientes, registro y una persona a cargo. El modelo no rellena ese hueco. Puedes cambiar de proveedor y seguir con el mismo agujero.

Tres cosas que la demo esconde y que una prueba con un cliente real no puede esconder:

1. La acción. El modelo propone y la acción se ejecuta. Si la acción existe, el riesgo existe.

2. El tiempo. Un mensaje de chat muere al cerrar la pestaña. Un agente deja restos: memoria, tickets a medias y dinero gastado en el modelo.

3. El vecino. En un SaaS hay más de un cliente. La demo suele tener uno.

Si no puedes nombrar esas tres, todavía no tienes un agente en producción. Tienes una conversación conectada a un sistema.

Mapa de capas

Una arquitectura de agentes es la lista de piezas que convierten un modelo en algo que actúa, sin improvisar el sistema cada semana. No es una librería ni una diapositiva de "orquestación". Es esto, de lo que se ve en la demo a lo que te salva cuando falla.

Google Cloud parte el dibujo en modelo, acciones, memoria y dos programas: el que ejecuta al agente y el que ejecuta al modelo. Sirve. Nosotros juntamos el programa y el espacio cerrado, y separamos el estado de la memoria, porque en un SaaS esa confusión cuesta un incidente.

No hace falta montar las siete el primer día. Sí hace falta saber cuáles dejas fuera a propósito. Una prueba que "deja los permisos para después" no los está dejando. Está esperando al primer cliente que no es el vuestro.

Acciones y contratos

Una acción es una puerta de vuestro sistema pensada para que la use un agente. Sin acciones, un asistente solo puede responder con lo que ya lleva dentro. Con acciones puede resolver. Con acciones de vuestro propio sistema es cuando aportáis funciones de inteligencia artificial a vuestros clientes.

El contrato es lo que puedes revisar después: el nombre, qué hace, sobre qué recurso, con qué datos y con qué tope. "Buscar artículos de ayuda de este cliente, máximo 5, sin el HTML crudo" es un contrato. "Consultar la base" no lo es. Anthropic dedica un apéndice a esto y cuenta que, en SWE-bench, les llevó más tiempo pulir las acciones que las instrucciones: el formato, las rutas completas y lo fácil que es equivocarse. Tratan la puerta entre el agente y la herramienta con el mismo cuidado que una pantalla para una persona.

Cómo enseñas esa acción es una decisión de contrato, no de moda. Un enchufe común (MCP, Model Context Protocol) sirve cuando quieres el mismo conector entre varios agentes y varios servidores. Una puerta vuestra sirve cuando esa acción ya existe en el producto como un verbo estable, crear un ticket o leer un pedido, y quieres que los mismos datos produzcan el mismo efecto, sin que el modelo invente el camino. Una línea de comandos sirve en la máquina de alguien o en un trabajo programado. Aquí no elegimos. Exigimos que, elijas lo que elijas, el modelo no vea un menú libre.

Tres reglas del mapa, no de cómo se programa:

• Lista cerrada. Si no está en la lista de ese flujo, no existe.

• Datos estrechos. El identificador de un ticket de ese cliente, no una consulta libre a la base ni una dirección web cualquiera.

• Tope. Filas, importe, número de llamadas. Un bucle sin tope es una factura y un riesgo.

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

Estado, contexto y memoria

Estas tres palabras se usan como si fueran la misma, y no lo son. Si el equipo no las distingue, la prueba mezcla "lo que pasó en esta tarea" con "lo que el modelo leyó" y con "lo que guardamos para el mes que viene".

El estado es lo que el sistema sabe de esta tarea ahora: qué ticket, qué cliente, en qué paso está, qué devolvió la última acción y si está esperando a una persona. Vive fuera de las instrucciones. Lo puede leer un registro y lo puede borrar un interruptor. Si el estado solo existe en el chat, no tienes estado. Tienes un hilo.

El contexto es lo que metes en esta pregunta: instrucciones, la lista de acciones, los últimos mensajes y el trozo de documento que recortaste. Se paga, y se vuelve a pagar en el siguiente paso. No es memoria. Es el maletín de este viaje. Si lo hinchas por si acaso, pagas en cada paso y además puedes mezclar clientes si el recorte es vago.

La memoria es lo que queda entre una tarea y la siguiente: un resumen de preferencias, un índice de artículos, un dato que el cliente ya dejó resuelto. Tiene que estar partida por cliente y tiene que poder olvidarse. Una memoria compartida donde el contrato del cliente B aparece en la respuesta del A no es lista. Es una fuga.

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

En la prueba, el estado explícito (identificadores, paso, resultado) vale más que una memoria elegante. La memoria se añade cuando hay algo que merezca recordar y un sitio donde separarlo por cliente.

Dónde corre, y qué no puede tocar

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

El modelo no corre vuestro servidor. Corre, o dispara, un programa. Ese programa tiene red o no la tiene, puede escribir en disco o no, puede salir a internet o solo a vuestros sistemas, y tiene un tiempo máximo y una cuenta de servicio. Google Cloud llama a eso el programa del agente, distinto del programa del modelo. La distinción importa: puedes cambiar de modelo y seguir con un proceso que llama a cualquier sitio.

La demo suele correr en el portátil de quien presenta, o en un cuaderno con las claves del entorno. La prueba corre al lado de datos de cliente. Si el agente puede ejecutar código, el recinto no es un extra de seguridad. Es la diferencia entre "propuso un programa" y "escribió en el disco de ese cliente".

Tres preguntas que caben en una reunión corta:

1. ¿Este agente sale a internet, o solo a una lista de sitios permitidos?

2. ¿Puede escribir, o solo leer?

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

Si la respuesta es "el modelo ya sabe que no debe", no hay recinto. Hay un deseo. Anthropic recomienda probar agentes que deciden solos en entornos acotados, porque el error se acumula. El recinto es el sitio donde ese error no se come el producto.

Cómo sabes si salió bien, y cómo lo reconstruyes

Comprobar es cómo decides si la tarea fue aceptable. El registro es el rastro para reconstruirla. Sin las dos, "funcionó en la demo" es tu única prueba.

Un texto que se lee bien no es una comprobación. El agente puede haber llamado la acción equivocada, haber mezclado los datos de otro cliente y aun así redactar un párrafo limpio. Eso no se ve en el chat. Se ve en el registro: qué acción, qué datos, qué decisión y qué versión de las instrucciones y del modelo.

En el mapa, esta capa pide lo mínimo para no ir a ciegas.

Un criterio de "correcto" por caso: el ticket se resolvió, el resultado tiene la forma esperada, una persona no tuvo que reescribirlo.

Un registro unido por un identificador de la tarea, que junte a la persona, al agente, al cliente y a las acciones.

La capacidad de repetir el fallo. Si no puedes volver a verlo, no puedes arreglarlo.

No hace falta un laboratorio de pruebas el primer día. Sí hace falta no tirar el rastro. Un registro que junta los datos de dos clientes en el mismo archivo no es visibilidad. Es otra fuga. Si no puedes contar la tarea, no puedes operar el agente.

Qué pasa cuando falla, y quién responde

Recuperar es lo que ocurre cuando la acción falla, el modelo se inventa un identificador o la tarea se queda a medias. El dueño es el nombre de la persona que responde por ese agente en esa cuenta de cliente.

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

Sin dueño, el agente es un proceso huérfano. Cuando salte una alerta, la pregunta será si esto es de plataforma, de producto o del proveedor del modelo. Si no hay dueño, no hay un interruptor con permiso. Hay un debate.

El dueño no es un organigrama de doce casillas. Es una frase que alguien puede decir en voz alta: este copiloto de soporte, en la cuenta de la prueba, lo opera Marta. Si hay que apagarlo, lo apaga Marta. El modelo no opera. La gente sí.

En la prueba, nombra al dueño antes de abrir memoria. Lo que no tiene dueño no necesita más capas. Necesita un responsable.

Cómo priorizar en una prueba

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

El primer día, o no hay prueba. Acciones con contrato y lista cerrada, el cliente en cada llamada, un interruptor y un dueño. Sin eso estás en la demo con un cliente de verdad.

Las dos semanas siguientes. Estado explícito: identificadores, paso y último resultado. Una persona en el medio solo donde el fallo es caro de deshacer, como en permisos. Registro con un identificador de la tarea. Tope de coste y de llamadas.

Después, si el caso aguanta. Memoria separada por cliente. Una comprobación que te deje bajar de modelo sin adivinar. Un recinto más estrecho, sin red y sin disco, si el agente ejecuta código. El enchufe común o una puerta extra, cuando el contrato ya existe y duele repetirlo.

Antes de abrir la cuenta del segundo cliente, el equipo debería poder responder sí a esto.

¿El modelo está separado del programa que lo ejecuta, y puedes cambiarlo sin reescribir las acciones?

¿Cada acción tiene contrato, lista cerrada y tope, o el modelo elige de todo el sistema?

¿El estado, el contexto y la memoria tienen dueño y sitio, o todo vive en las instrucciones?

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

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

¿Puedes reconstruir la última tarea que salió mal?

¿Hay un nombre que apaga esto hoy?

Si faltan dos o más, no tienes una arquitectura de agentes. Tienes un modelo con accesorios. Las instrucciones pueden ser buenas, pero no son el sistema.

Cuando esas líneas existen, el resto es ingeniería. En Devic esas capas, las acciones, las reglas, el registro y el programa que ejecuta, se operan en el sistema alrededor del modelo. El modelo se cambia. El contrato no. Los planes sirven para medir un caso en la cuenta de un cliente 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.