Los agentes deciden. El código ejecuta. El trabajo es saber dónde está la línea.

Circula una frase por los consejos de administración que suena a futuro y se comporta como una factura: los agentes van a sustituir a las aplicaciones. Vale la pena tomarla en serio, porque la parte que es cierta es genuinamente nueva, y la parte que no lo es la pagará quien construya sobre ella.

La pregunta útil no es si usar agentes. Es dónde cae la línea entre lo que un agente decide y lo que el código ejecuta. Póngala en el sitio equivocado y se queda con un sistema lento, caro, imposible de auditar, y de vez en cuando seguro de algo que nunca ocurrió.

Lo que cambió de verdad

Los modelos se volvieron buenos en tres cosas en las que el software era históricamente malo: leer una instrucción escrita por una persona, partirla en pasos, y elegir la herramienta correcta para cada paso. No es un cambio pequeño. Evita tener que anticipar todas las formas en que alguien puede formular una petición, que es la mayor parte de lo que vuelve rígidas a las interfaces tradicionales.

Lo que no cambió es todo lo que está debajo. Una regla fiscal sigue siendo una regla fiscal. Un pago o se liquida o no se liquida. Una comprobación de permisos tiene una respuesta correcta y ningún margen de interpretación. Esas cosas nunca fueron difíciles por ser tediosas de expresar. Fueron difíciles porque tienen que estar exactamente bien, siempre, y de forma demostrable después.

El cerebro y el esqueleto

La comparación que sobrevive al contacto con un proyecto real es anatómica. El modelo es el cerebro: entiende, sopesa y decide. Las herramientas son los brazos: se extienden y actúan. El código es el esqueleto, y sin él el cerebro no tiene qué mover.

Los esqueletos no dan espectáculo. Nadie demuestra uno en una conferencia. Pero la analogía vale la pena porque predice el modo de fallo: un sistema construido con cerebro y brazos, sin esqueleto, no se cae de forma dramática. Funciona en la demostración, funciona una semana, y luego empieza a producir respuestas plausibles y equivocadas, a un coste por petición que nadie presupuestó.

Resérvame un vuelo

El ejemplo canónico vale la pena recorrerlo, porque la línea cae en un sitio muy concreto.

El agente debe entender que un viaje a Berlín el próximo martes significa salir después de la reunión de la mañana. Debe comparar opciones, notar que ahorrar dos horas cuesta trescientos euros, y preguntar si ese intercambio compensa. Todo eso es criterio sobre una petición ambigua, y es exactamente para eso que sirve un modelo.

El agente no debe cargar la tarjeta. No porque el modelo no sea de fiar, sino porque cargar una tarjeta es una transacción: o ocurre una vez, o la contabilidad queda mal. Necesita idempotencia, política de reintento, camino de reversión y un registro que sobreviva a una auditoría. Nada de eso son decisiones. Son garantías, y las garantías viven en el código.

Dónde cae la línea

El patrón no es arbitrario. La columna de la izquierda es todo lo que tiene que ser idéntico en cada ejecución, demostrable después, y correcto incluso cuando la entrada es extraña. La de la derecha es todo lo que gana con leer el contexto y ejercer criterio.

Lo que uno quiera probar unitariamente pertenece a la izquierda.

El error que seguimos viendo

El error de arquitectura más común es poner la lógica de negocio en el prompt. Funciona enseguida, y eso es lo que lo vuelve peligroso.

Las reglas van al prompt de sistema, luego las excepciones, luego las excepciones a las excepciones. Seis meses después el prompt tiene cuatro mil tokens, cada petición los paga todos, y nadie puede decir con confianza qué hace el sistema con una entrada inusual, porque la respuesta no está escrita en ningún sitio que se lea como lógica. Cambiar una regla arriesga cambiar otras tres, y no hay prueba que lo detecte.

Las mismas reglas escritas en código son más baratas en cada petición, revisadas en un pull request, y comprobables. El prompt pasa a hacer aquello en lo que es bueno: decidir cuál de esas reglas se aplica a esta situación.

El agente nunca toca la base de datos

Si hay una regla que valga la pena guardar de este artículo, es esta.

Una pregunta como "¿qué clientes están sin copia de seguridad?" no debe convertirse en SQL escrito por un modelo. Debe convertirse en una llamada a algo que ya existe:

# La API es el contrato. El agente elige llamarla;
# el código decide qué significa eso y quién puede preguntar.
@router.get("/customers/without-backup")
def clientes_sin_copia(user: User = Depends(current_user)):
    if not user.can("read:customers"):
        raise Forbidden()
    return repositorio.clientes_sin_copia(tenant=user.tenant)

El agente elige la herramienta. El código impone quién puede preguntar, sobre qué cliente puede preguntar, y qué significa la pregunta. Si el modelo de permisos cambia, cambia una función y todos los que la llaman heredan el cambio, incluido el agente.

Escrito al revés, con el modelo generando consultas contra la base de datos, el modelo de permisos pasa a vivir en un prompt, y un prompt es una sugerencia.

Es la misma frontera de la que hablamos en el asistente de IA que solo lee lo que el usuario puede leer: el asistente es tan seguro como la capa que tiene debajo, y nada más.

Para qué sirve el MCP

El Model Context Protocol es la parte de esto que más rápido avanzó, y vale la pena ser preciso sobre qué problema resuelve.

Antes de él, cada asistente hablaba con cada herramienta a su manera. Conectar un modelo a un sistema interno obligaba a escribir un adaptador para aquel modelo, y a escribirlo otra vez para el siguiente. El MCP normaliza esa conversación: la herramienta describe lo que sabe hacer, y cualquier cliente que hable el protocolo puede usarla.

El repositorio de la especificación se hizo público en septiembre de 2024 y la colección de servidores le siguió en noviembre. Esa colección lleva hoy más de ochenta mil estrellas en GitHub, lo que dice menos sobre calidad que sobre la falta que hacía la norma.

Lo que importa en arquitectura es que el MCP es una capa de descripción, no de ejecución. Le dice a un modelo qué hace una herramienta y cómo llamarla. No vuelve la herramienta segura, correcta ni auditable. Eso sigue siendo propiedad de lo que está detrás del endpoint, es decir, propiedad de su código.

Dónde ayuda esto de verdad

La versión honesta del valor es más estrecha que el discurso y más útil.

Un agente se gana su sitio donde la entrada es ambigua y la acción está delimitada. Leer el correo de un proveedor y proponer a qué pedido corresponde. Convertir la descripción de un problema en la consulta correcta a sistemas que no comparten esquema. Leer un contrato y señalar las cláusulas que difieren de la plantilla. En cada caso la parte difícil es la interpretación, y la acción que sigue pasa por código que se ejecutaría de forma idéntica si hubiera sido una persona quien pulsó el botón.

No gana nada donde la entrada ya es estructurada y las reglas ya se conocen. Si un formulario tiene ocho campos y la validación es una lista de condiciones, un agente añade latencia, coste e incertidumbre a cambio de nada.

Qué significa esto para la arquitectura

Los agentes son una capa nueva, no un sustituto de las que están debajo. La pila que construimos es la misma de siempre, con un añadido arriba:

La capa de API es donde esto se gana o se pierde. Ya existía antes de los agentes, y si se construyó bien casi nada necesita para servirlos: ya sabe quién pregunta, qué puede ver esa persona, y qué significa cada operación.

Lo que es la conclusión incómoda para quien espera que los agentes vuelvan innecesario el trabajo antiguo. Lo vuelven más valioso. Una organización con APIs limpias y un modelo de permisos de verdad pone un agente delante de ellas en semanas. Una organización sin eso no está lenta por faltarle agentes. Está lenta porque el cimiento nunca se construyó, y poner un modelo encima lo vuelve más visible, no menos.

La parte que envejece bien

Las herramientas van a cambiar. El modelo que hoy está en producción será sustituido dos veces antes de que esto quede viejo, y el protocolo puede ser sustituido también.

Lo que no va a cambiar es la división del trabajo. El criterio de un lado, las garantías del otro. Los sistemas que los mantienen separados cambian de modelo sin tocar las reglas, y cambian las reglas sin entrenar nada. Los que los mezclan tienen que reconstruir los dos cada vez que uno de ellos se mueve.

Escribimos hace poco que la IA resolvió la sintaxis, pero no el criterio. Esta es la versión arquitectónica de la misma conclusión. Los mejores sistemas que se están construyendo con agentes no son los que sustituyeron su software. Son los que supieron qué mitad valía la pena conservar.