Montar la demo de un agente es fácil; hacerlo fiable en producción es el trabajo de verdad. Lo que realmente importa (evaluación, observabilidad, seguridad, coste y supervisión humana), según Google.
Yohan Consani · Publicado el
Cualquiera puede montar la demo de un agente de IA en una tarde. Suma un modelo de lenguaje, unas cuantas herramientas y un bucle, y en minutos tienes algo que parece magia: lee un correo, consulta una base, responde, actúa. El problema es que la demo y el producto son animales distintos. Lo que impresiona en una presentación controlada suele desmoronarse ante usuarios reales, datos desordenados y el coste de equivocarse a escala.
El whitepaper Introduction to Agents, publicado por Google en noviembre de 2025, hace explícito ese contraste. Define un agente como «modelos de lenguaje en un bucle, con herramientas, para cumplir un objetivo» y, de forma más reveladora, como «un sistema dedicado al arte de la curaduría de la ventana de contexto». La definición es simple; la ingeniería para llegar a producción, no. Este artículo desgrana lo que separa el prototipo del sistema fiable.
Un agente es un sistema dedicado al arte de la curaduría de la ventana de contexto.Google · Introduction to Agents
¿Qué es un agente de IA, en realidad?
Un agente de IA es un software que usa un modelo de lenguaje para decidir, paso a paso, qué acciones tomar, llamando herramientas, leyendo resultados y siguiendo hasta cumplir un objetivo. Google describe su anatomía en cuatro partes que conviene memorizar, porque cada una se convierte en un punto de fallo en producción:
- El Modelo es el cerebro: razona, planifica y decide la siguiente acción.
- Las Herramientas son las manos: dan al modelo acceso al mundo (APIs, bases de datos, búsquedas, acciones).
- La Orquestación es el sistema nervioso: el bucle que coordina planificación, memoria y razonamiento entre una decisión y la siguiente.
- El Despliegue (deployment) es el cuerpo: la infraestructura que lo pone todo en pie, con escala, seguridad y monitorización.
La demo suele mostrar solo el cerebro y las manos. La producción vive o muere por el sistema nervioso y el cuerpo, y es justo ahí donde la mayoría de los proyectos tropieza.
De prompt engineering a context engineering
El gran cambio de mentalidad, según Google, es abandonar la idea de «ingeniería de prompt» y abrazar la «ingeniería de contexto». No basta con pulir una instrucción: lo que define la calidad de un agente es la curaduría de lo que entra en la ventana de atención (limitada) del modelo en cada paso. Instrucciones, hechos relevantes, herramientas disponibles e historial de la conversación compiten por ese espacio escaso, y elegir bien es la mitad del trabajo.
Aquí la memoria entra como pieza de ingeniería, no como detalle. Google distingue dos tipos: la memoria de corto plazo, que mantiene el hilo de la conversación actual dentro de la ventana de contexto; y la de largo plazo, que persiste conocimiento entre sesiones, en la práctica un sistema de RAG sobre una base de datos vectorial, consultado bajo demanda cuando el agente necesita recordar algo que ya no cabe en la ventana.
¿Cómo medir si un agente funciona?
No puedes mejorar lo que no mides, y medir agentes es más difícil que medir software común, porque la salida no es correcta o incorrecta, es mejor o peor. Google llama a esta disciplina «Agent Ops», la evolución natural de DevOps y MLOps. La receta es instrumentar el comportamiento real del agente, no solo su disponibilidad:
- Cumplimiento del objetivo: ¿el agente resolvió de verdad la tarea del usuario, de principio a fin?
- Satisfacción: ¿la respuesta fue útil y adecuada a ojos de quien preguntó?
- Latencia y coste: ¿cuánto tiempo y cuántos tokens consumió cada interacción?
- Evaluación por «LM como juez»: un modelo puntúa las respuestas del agente contra un conjunto de casos de referencia (golden dataset).
- Trazado (tracing) de cada paso: registrar toda decisión, llamada de herramienta y resultado intermedio para poder depurar cuando algo sale mal.
Con esas métricas en mano, la decisión de lanzar o no una versión deja de ser una corazonada y se convierte en un Go/No-Go guiado por datos. Y hay un hábito que Google trata como innegociable: cada bug que aparece en producción debe convertirse en una prueba permanente, sumada al golden dataset, para que ese fallo nunca vuelva a pasar inadvertido.
¿Qué hace seguro a un agente?
Dar a un modelo de lenguaje el poder de actuar cambia la naturaleza del riesgo. Google señala dos amenazas principales: las «acciones descontroladas» (rogue actions), cuando el agente hace algo dañino o no intencionado, y la «exposición de datos sensibles», cuando filtra información que debería proteger. A diferencia de un chatbot que solo habla, un agente que ejecuta puede causar daño real, por eso la seguridad forma parte del diseño desde el principio.
La respuesta recomendada es la defensa en profundidad, combinando dos capas que se complementan:
- Guardrails deterministas: reglas rígidas, en código, que limitan lo que el agente puede hacer, al margen de lo que el modelo «decida».
- Defensas basadas en razonamiento: el propio modelo (o un modelo supervisor) evaluando si una acción es apropiada antes de ejecutarla.
- Identidad y mínimo privilegio: tratar al agente como una nueva clase de «principal», con identidad propia y permisos mínimos, como se concede a un empleado o a un servicio.
Cómo aplica Charla esto en producción
En Charla, estos principios son cómo está construida la plataforma. Todo asistente corre sobre un mismo bucle agéntico unificado, con recuperación agéntica: en lugar de inyectar pasivamente fragmentos de una base en el prompt (RAG clásico), el agente llama herramientas como kb_search y wiki_search bajo demanda, cuando de verdad necesita la información. Es la «ingeniería de contexto» de Google puesta en práctica: el agente cura su propio contexto, paso a paso.
La capa de confianza aparece en decisiones concretas de producto. Las respuestas se transmiten por SSE (streaming), sin exponer la cadena de razonamiento en bruto al usuario. Cada llamada de herramienta y cada acción privilegiada se graba en un log de auditoría inmutable (append-only). Cada asistente (cada «Charla») está aislado, con su propia base de conocimiento, lista de acceso y prompt. La recuperación se filtra por asistente antes del ranking, reflejando exactamente el principio de identidad y mínimo privilegio.
El coste y la supervisión humana también se tratan como requisitos de primer orden: presupuestos de crédito por asistente limitan el gasto, y una postura de proponer-y-aprobar mantiene a una persona en el circuito para los cambios de conocimiento y configuración. Son las preocupaciones de producción del whitepaper (fiabilidad, observabilidad, seguridad, coste, supervisión) apareciendo en una plataforma real, sin promesas mágicas.
De albañil a director
La conclusión de Google resume el cambio de papel de quien construye estos sistemas: el desarrollador deja de ser un «albañil», colocando cada ladrillo de lógica a mano, y pasa a ser un «director», definiendo objetivos, dando herramientas, estableciendo límites y juzgando resultados. Montar la demo seguirá siendo fácil. El trabajo de verdad, y la ventaja competitiva, está en todo lo que viene después: evaluar, observar, proteger, controlar el coste y mantener al humano al mando. Es justo en ese terreno donde un agente deja de ser un truco y se convierte en un producto.