Arquitectura de agentes de IA: las piezas que decide un arquitecto

Las cuatro decisiones que son la arquitectura

Ninguna es sobre qué modelo usar, y las cuatro determinan si el agente sirve o es una demo cara.

La tercera es la que más se pospone y la que más caro sale posponer. Un agente sin frontera escrita no es autónomo: es un agente cuyo límite lo va a descubrir alguien un martes por la mañana.

Conviene decir por qué el modelo no está en la lista, porque es la pregunta que llega primero en cualquier reunión.

El modelo se cambia en una tarde si la arquitectura está bien hecha. Las cuatro decisiones de arriba tardan semanas en cambiarse una vez el sistema está en producción, porque hay procesos y personas que dependen de cómo quedaron.

O sea: lo que ocupa el 90 % de la conversación es lo más barato de revertir, y lo que casi no se discute es lo que queda fijo.

1 · De dónde saca el contexto

Un agente sin contexto de la empresa es un modelo genérico con una interfaz bonita. El contexto es lo que lo hace tuyo.

Hay tres fuentes y conviene decidir explícitamente cuál se usa para qué:

• Instrucciones fijas. Lo que siempre es verdad: cómo trabaja la empresa, qué tono, qué no se hace nunca.
• Recuperación. Lo que se busca en el momento según la tarea, que es el patrón de RAG.
• Memoria de la interacción. Lo que pasó antes con este cliente o en esta conversación.

El error más común es meter todo en la primera. Instrucciones de cinco páginas que intentan anticipar cada caso, que el modelo aplica de forma desigual y que nadie se atreve a tocar.

Hay un criterio simple para repartir entre las tres fuentes y evita el prompt de cinco páginas.

Si algo es verdad siempre y para todos los casos, va en instrucciones. Si depende del caso concreto, se recupera. Si depende de lo que pasó antes con esta persona, es memoria.

Cuando una regla no encaja limpiamente en ninguna de las tres, casi siempre es una excepción de negocio que debería vivir fuera del modelo, como una regla explícita que el sistema comprueba.

2 · Qué herramientas puede usar

Aquí se decide la diferencia entre un agente que informa y uno que actúa, y con ella todo el perfil de riesgo.

La regla que sostengo: cada herramienta de escritura se justifica una a una, con su límite de impacto escrito. Un agente con escritura amplia «porque así es más útil» es la forma más común de construir un riesgo.

3 · Dónde se detiene

Es la decisión más importante y la única que no puede tomar el equipo técnico solo, porque no es una decisión técnica.

La frontera se define por escrito en una tabla de tres columnas: qué hace solo, qué propone para aprobación y qué manda directamente a una persona.

Los cuatro disparadores que casi siempre deberían estar en la tercera columna:

• Cuando el agente no está seguro. Un umbral de confianza, no una impresión.
• Cuando toca dinero por encima de un monto definido.
• Cuando la persona lo pide. A la primera.
• Cuando es la primera vez. Un caso sin precedente no tiene con qué compararse.

4 · Qué queda registrado

La capa que nadie construye al principio y que todo el mundo echa de menos el día que hay que explicar algo.

• Qué recibió el agente y qué contexto tenía en ese momento.
• Qué decidió y por qué, con la razón en texto.
• Qué herramientas usó y con qué resultado.
• Si escaló y a quién.

Con esos cuatro campos, reconstruir un caso de hace tres semanas son minutos. Sin ellos, es imposible, y lo que ocurre en la práctica es que la empresa deja de confiar en el sistema porque no puede explicarlo.

Sobre el segundo campo, la razón de la decisión: conviene pedirla en el mismo momento de decidir, no reconstruirla después.

Una razón generada a posteriori es una justificación, no una explicación, y suena igual de convincente aunque no describa lo que pasó.

Los errores de arquitectura que salen caros

Cinco, ordenados por lo que cuesta corregirlos una vez el sistema está en producción.

• Permisos amplios desde el día uno. Corregirlo después implica romper cosas que ya funcionaban con ellos.
• Sin frontera escrita. Se descubre con un incidente y entonces la conversación ya no es de diseño.
• Todo el contexto en el prompt. Crece hasta que nadie lo entiende y cambiar una línea rompe otra.
• Sin registro. No hay forma de saber qué pasó ni de mejorar nada.
• Atado a un proveedor. Cambiar de modelo se convierte en un proyecto.

El desarrollo de los cinco está en errores de arquitectura de IA.

Empezar por lo más simple que funcione

Es el criterio que más veces he visto ignorar y el que más proyectos habría salvado.

La mayoría de los casos empresariales no necesitan un agente autónomo. Necesitan un flujo con un paso de interpretación en el medio, que es más barato, más predecible y más fácil de explicar.

La complejidad se sube cuando el retorno lo justifica, no al principio. Y la señal de que hay que subirla es concreta: cuando el flujo fijo falla porque los casos reales no caben en sus ramas.

Cuando hay más de uno

La arquitectura de un agente y la de tres agentes no son la misma cosa con un multiplicador. Aparecen problemas nuevos.

Choques por el mismo registro, respuestas contradictorias al mismo cliente, bucles entre agentes y un presupuesto de consumo compartido que uno puede vaciar.

Todo eso se resuelve con una capa por encima, que está desarrollada en supervisor de agentes de IA. Lo importante para la arquitectura es que esa capa se prevea antes de tener el segundo agente, no después.

Qué se documenta de todo esto

Una página, y las mismas cuatro decisiones del principio.

• El diagrama de contexto: de dónde sale cada dato que usa.
• La lista de herramientas con su permiso y su límite de impacto.
• La tabla de tres columnas de la frontera.
• Dónde está el registro y quién lo revisa, con qué frecuencia.

Eso es lo que hace que el sistema no dependa de quien lo construyó, y es la diferencia entre un activo y una dependencia. El detalle está en cómo se documenta una arquitectura de IA.