5 capas del agente IA: lo que un manager necesita saber

«La mayoría de la gente todavía piensa que un agente IA es simplemente ChatGPT con un buen prompt». Con esta frase abre Sunil Ramlochan su artículo «The AI Agent Stack Is Not a Prompt. It’s a Production System», y a continuación califica esta creencia como un «mito reconfortante». La verdad útil, según él, es otra: un agente real se parece más a un pequeño sistema operativo para el trabajo. Tiene cerebro, manos, memoria, reglas, logs, planes de recuperación y alguien que responde cuando el agente hace lo que no debe.

La tesis del artículo cabe en una línea: un agente es un stack completo. Y lo que le da fiabilidad es la arquitectura que lo rodea, mientras que el modelo en sí – o un prompt afortunado – es solo uno de los ingredientes. Es un panorama de ingeniería, así que lo abordaremos desde el otro lado – qué de este stack le importa realmente al manager que no escribe código pero decide si poner en marcha un agente.

Primero despejemos la confusión principal, esa misma contra la que argumenta el autor. Un «agente» funciona de manera fundamentalmente distinta a una interfaz de chat: el prompt da una pregunta y una respuesta. El agente recibe un objetivo y trabaja en un ciclo: comprende la tarea, decide qué hacer a continuación, elige una herramienta, la usa, evalúa el resultado, lo interpreta y continúa, se detiene o llama a un humano. El artículo remite honestamente a la guía de OpenAI para construir agentes, donde un agente se define como un sistema de modelos, herramientas, instrucciones y restricciones. Este ciclo es lo que distingue a un agente de la automatización tradicional: un agente no responde con una sola réplica, lleva la tarea hasta el final.

El autor descompone este «pequeño ordenador para el trabajo» en cinco capas. Recorrámoslas con ojos de manager.

Capa 1: el modelo – el cerebro, pero no todo el cuerpo

El modelo es la parte que razona, planifica y escribe. Acapara toda la atención porque parece magia: modelo más potente – mejor razonamiento, menos errores evidentes. Pero el autor lo formula con dureza: en producción, el modelo a menudo no es la parte más difícil.

Un modelo potente fallará igualmente si tiene acceso a las herramientas equivocadas, no puede obtener el contexto necesario, recuerda información obsoleta, no tiene un perímetro de permisos, sus decisiones no se pueden verificar después en los logs, o simplemente se le ha asignado una tarea que debería haberse resuelto con un algoritmo convencional. La comparación del artículo es precisa: el modelo es el chef de un restaurante. Incluso un chef excelente necesita ingredientes limpios, una cocina en condiciones, pedidos, control de seguridad alimentaria y un gerente que pare la cocina si algo sale mal.

Para el manager, de aquí se extraen dos conclusiones. La primera es sobre dinero: detrás de la palabra «agente» hay un flujo de llamadas al modelo, donde cada una cuesta dinero, y eso no se parece en nada a una suscripción fija. La segunda es sobre expectativas: no espere que un modelo más caro compense una arquitectura débil. «Elija el mejor modelo que pueda justificar», escribe el autor, pero no cuente con que tapará los agujeros de su proceso.

Capa 2: las herramientas – las manos del agente y su mayor riesgo

Las herramientas son aquello con lo que el agente actúa en el mundo exterior: búsqueda, APIs, bases de datos, correo electrónico, calendarios, ejecución de código, archivos, sistemas de pago, aplicaciones de negocio internas. Aquí, escribe el autor, el agente deja de ser un generador de texto y se convierte en un ejecutor. Y aquí es donde el «radio de explosión» crece drásticamente. Es exactamente la transición que hace tres años dio lugar a la tendencia BYOA – Bring Your Own Agent: en cuanto la herramienta obtiene acceso a sistemas reales, las cuestiones organizativas empiezan a adelantar a las técnicas.

Una respuesta incorrecta es un tipo de error. Escribir basura en la base de datos, un email enviado por accidente, un reembolso procesado dos veces, un archivo filtrado – esa es una categoría completamente distinta. Por eso los límites de las herramientas importan tanto. El autor propone una lista de preguntas que debería tener a mano cualquiera que vaya a dar a un agente acceso a sistemas reales: ¿a qué herramientas tiene acceso el agente?, ¿qué acciones son de solo lectura?, ¿cuáles requieren aprobación?, ¿puede el agente escribir en sistemas de producción?, ¿se registran las llamadas?, ¿se puede revertir un error?, ¿puede una entrada maliciosa engañar al agente para que abuse de una herramienta?

La idea clave de esta capa: muchos fallos de los agentes los causa precisamente la frágil interacción con las herramientas – el razonamiento del modelo apenas tiene que ver. En cuanto el agente obtiene el derecho a actuar, necesita disciplina de ingeniería, y con un prompt cuidadoso ya no basta. El principio práctico del autor: tratar las herramientas como APIs de producción – mínimos permisos, esquemas estrictos, pasos de confirmación, precaución con las operaciones de escritura.

Es curioso que todo esto – herramientas, permisos, esquemas de confirmación – suena a conversación sobre arquitectura. Pero debajo de la arquitectura hay algo más simple: la capacidad de formular con claridad qué debe hacer el agente, en qué contexto y con qué restricciones. Sin esa formulación, incluso un agente bien programado empieza a «inventar» – y es precisamente entonces cuando las herramientas se vuelven peligrosas.

Capa 3: la memoria y su ciclo de vida

«La memoria suena simple. Que el agente recuerde lo útil. Fácil, ¿no? No del todo», escribe el autor. La memoria tiene cuatro tipos: a corto plazo (lo que ocurre en la tarea actual), de sesión (lo que se ha dicho en la conversación actual), semántica a largo plazo (conocimiento que se reutiliza en el tiempo) y transaccional (estado que debe ser exacto: pedidos, estados, permisos, aprobaciones). La memoria a corto plazo es, en esencia, la ventana de contexto del modelo, y tiene límites conocidos: los prompts largos pierden información en el medio, y el agente hereda esa particularidad.

Es una de las capas más difíciles, porque la memoria aquí funciona como un juicio constante: qué recordar, qué olvidar, quién puede ver esto, cómo evitar que el contexto de un usuario se filtre en la sesión de otro, cómo impedir que datos obsoletos envenenen decisiones futuras. El autor ilustra el riesgo con ejemplos concretos: un agente de ventas que recuerda la política de descuentos del trimestre anterior; un agente médico que mezcla las notas de dos pacientes; un agente financiero que recuerda una aprobación pero no la condición a la que estaba vinculada. La conclusión se formula en una frase: la memoria en un agente funciona como una base de datos con consecuencias – tratarla como un bloc de notas es peligroso.

Para el manager, esto se traduce en una pregunta incómoda para cualquier proveedor o vendor: ¿qué exactamente recuerda su agente entre interacciones, y quién garantiza que no confundirá a mis clientes? El consejo del autor: dar a la memoria un ciclo de vida – origen de los datos, fecha de caducidad, permisos de acceso, reglas de eliminación y separación entre memoria de usuario, de sesión, de negocio y de sistema.

Capa 4: el runtime – donde el «pensamiento» se convierte en un ciclo

En el centro del stack está el runtime del agente, ese mismo ciclo: comprender el objetivo, decidir qué hacer a continuación, elegir una herramienta, usarla, evaluar el resultado, interpretarlo y continuar, detenerse o pedir ayuda. El autor vincula este patrón con el enfoque ReAct (reasoning and acting) y subraya algo simple: el agente lleva la tarea hasta el final; no se queda en una sola réplica.

Y es precisamente aquí donde todo se rompe. El ciclo puede entrar en bucle. La herramienta puede devolver datos incorrectos. El modelo puede malinterpretar el resultado. Un reintento puede ejecutar accidentalmente la misma acción dos veces. Por eso el runtime es gestión de la ejecución, y la fórmula «el LLM simplemente piensa» no describe ni la mitad del trabajo. El consejo más importante para el manager en todo el artículo está escondido justo aquí: no diseñe el agente como un prompt largo. Diséñelo como un proceso de trabajo con estado, checkpoints, condiciones de parada y revisión humana donde sea necesario.

Esto invierte el marco. «Describir un proceso con estado y checkpoints» es exactamente el trabajo que hace un manager cuando construye un reglamento o asigna una tarea a su equipo. El ciclo del agente se parece sospechosamente a cómo trabaja un empleado real: recibe una tarea, estima los pasos, hace algo, mira el resultado, se corrige. La diferencia es que el empleado tiene sentido común y miedo a equivocarse, mientras que el agente solo tiene las restricciones que usted haya incorporado de antemano.

Capa 5: observabilidad, seguridad y gobernanza

La última capa envuelve todo el stack, y el autor la llama la frontera entre una demo y un sistema en el que se puede confiar. Es la capa que permite al equipo responder: qué hizo el agente, por qué exactamente así, qué herramienta invocó, qué devolvió la herramienta, cuánto costó la ejecución, si cumplió las reglas, si inventó algo, si reveló datos privados, si entró en bucle, si un humano aprobó un paso de riesgo. Sin esta capa, escribe el autor, depurar agentes se convierte en folclore – el equipo discute sobre qué ocurrió en lugar de mirarlo.

Pero después viene la distinción más importante, y es puramente de gestión. «La observabilidad te dice qué ocurrió. La gobernanza decide qué tiene permitido ocurrir». Un dashboard mostrará que el agente está a punto de hacer algo arriesgado. La gobernanza determina quién puede detenerlo, bajo qué condición y quién es dueño de esa decisión. El autor referencia directamente la clasificación de riesgos del OWASP Top 10 para LLM (donde la inyección de prompts se nombra como amenaza principal) y el NIST AI Risk Management Framework como referencias.

Aquí está el punto clave para usted. Cuando los vendors dibujan un futuro donde «los agentes gestionan procesos complejos», desaparece discretamente una pregunta: quién responde si el agente se equivoca. Esta capa responde con honestidad – en los puntos críticos, responde un humano. El consejo del autor: no se quede en los logs. Defina reglas de escalado, procesos de aprobación, registros de auditoría, verificaciones de políticas, límites de presupuesto y condiciones de parada de emergencia.

El punto más débil: las costuras entre capas

Aquí el artículo da un giro que es fácil pasar por alto, y no conviene. El autor escribe que lo más difícil del stack de un agente quizá no es una capa individual, sino el tejido conectivo entre ellas. El runtime elige una herramienta, la herramienta modifica el estado de negocio, la capa de memoria almacena el resultado, el modelo lo interpreta, la capa de observabilidad registra la decisión, la capa de seguridad decide si permite el siguiente paso. Si alguna de estas transferencias está descrita de forma imprecisa, todo el sistema se vuelve frágil.

Y aquí el autor nombra una verdad poco romántica: la fiabilidad la aportan cosas «aburridas» de ingeniería – máquinas de estados finitos, claves de idempotencia, reintentos con protección, límites, ámbitos de permisos, tests, conjuntos de evaluación, logs de auditoría, rutas de rollback y checkpoints con participación humana. El agente puede parecer inteligente, pero en producción la fiabilidad la asegura un diseño disciplinado, y la inteligencia del modelo por sí sola no la garantiza.

Para el manager, esta imagen de transferencias entre capas resulta sospechosamente familiar. Responsabilidad difusa, contexto que se pierde en el traspaso, costes crecientes de coordinación – estos son problemas de cualquier equipo real donde una tarea pasa de mano en mano. Por eso la decisión «un agente o varios» el autor y la guía de OpenAI aconsejan tomarla igual que usted decide si contratar más gente: empezar con uno, exprimir al máximo su capacidad y complicar la estructura solo cuando uno ya no da abasto. La misma lógica está detrás del informe de Google Cloud sobre el nuevo rol del manager como supervisor de un equipo de agentes – solo que el vendor dibuja cinco agentes autónomos ya hoy, mientras que los ingenieros aconsejan honestamente empezar con uno y unas costuras bien descritas entre ellos.

Qué hacer con todo esto en la práctica

El autor cierra el artículo con el lema «Los agentes no son magia. Son autonomía gestionada» y propone una checklist: antes de lanzar un agente, plantear la pregunta a un nivel más profundo que «¿funciona?». Lo que hay que preguntar es otra cosa: «¿se puede confiar en este agente cuando tiene usuarios reales, datos reales, herramientas reales, costes reales y consecuencias reales?». Una demo sobrevive con un prompt afortunado. Producción requiere arquitectura, tests, permisos, disciplina de memoria, observabilidad, protección y un propietario claro.

Traduzcamos esto en pasos para el manager que no escribe código pero quiere entender si tiene una tarea para un agente y si está preparado para ella.

Primero, encuentre un candidato. Repase su semana y anote los procesos que se repiten, constan de varios pasos y contienen bifurcaciones del tipo «depende de la situación». No peticiones puntuales como un borrador de email o un resumen de reunión – para eso no hace falta un agente, basta un prompt normal. Hablamos de procesos: gestión de solicitudes entrantes, informe periódico de varias fuentes, cribado inicial de CVs. Este es el criterio de Benedict Evans: la IA automatiza bien tareas y mal juicios, así que un agente está justificado donde en el proceso hay espacio para el juicio. Un ejemplo concreto de esta transición es el análisis agéntico de datos, donde la diferencia entre un chat y un agente se hace evidente con tres archivos reales de un manager.

Después, describa el proceso exactamente como un flujo de trabajo con múltiples pasos – justo lo que pide el artículo. Un prompt largo no funciona aquí. Desglose la tarea en pasos, vincule a cada uno una acción concreta y la herramienta necesaria, describa los casos excepcionales y, obligatoriamente, marque en qué pasos la decisión debe tomarla un humano. Si no puede describir el proceso con claridad en palabras, ningún agente lo ejecutará. Esta es la prueba de preparación, y puede hacerla ahora mismo, en un chat ordinario.

Aquí tiene un prompt que convierte su reglamento de trabajo en un borrador de flujo de trabajo para un futuro agente – siguiendo la misma lógica de las cinco capas que describe el autor. En el ejemplo se ha incluido un proceso típico de soporte – gestión de solicitudes matutinas; sustitúyalo por el suyo:

Un buen resultado marca los reembolsos y los pagos en disputa como parada obligatoria con traspaso a un humano – si el modelo no lo ha hecho, la tarea está formulada de forma demasiado vaga.

Cuando el borrador esté listo, páselo a revisión a un segundo modelo – que encuentre los fallos antes de que usted lleve la tarea a desarrollo. A continuación se analiza un borrador ya algo «pulido» del mismo proceso de soporte; inserte aquí el suyo:

Un buen revisor se fijará primero en el paso 4: un reembolso inferior a $50 que el agente tramita solo, sin checkpoint – una acción con dinero sin firma humana es el fallo principal de este borrador.

Fíjese: ambos pasos los realiza en un chat ordinario, antes siquiera de que se hable de desarrollar un agente real. El error más costoso es encargar un agente complejo para un proceso que usted mismo no ha sido capaz de describir con claridad.

En resumen

«Autonomía gestionada» – ese es el nombre exacto de lo que un manager realmente implanta: cuanta más libertad recibe el agente, más estructura necesita a su alrededor, y diseñar esa estructura – incluyendo la decisión de dónde es admisible la autonomía y dónde se mantiene la firma humana – es, por naturaleza, un trabajo de gestión. La responsabilidad no se va a ningún lado, se desplaza de la ejecución al diseño de los checkpoints.

Y la habilidad base que subyace a todo es la misma – tanto para un prompt aislado como para un agente. Es la capacidad de formular con precisión qué quiere, sobre qué datos y con qué restricciones – en esencia, los mismos 5 elementos de un buen prompt, solo que aplicados a un proceso completo. Sin esta habilidad no funciona ni un prompt ni un agente. Por ahí es por donde conviene empezar.

Artículos relacionados

Los managers y la IA: los que más la usan – pero no para dirigir

Por qué los pilotos de IA mueren entre la demo y la planta

40 casos de GigaChat: contrastamos las cifras de Sber con un benchmark

Cómo implementar IA en la manufactura: plan paso a paso para directivos