# De agentes que generan respuestas a organizaciones que aprenden Durante los últimos años hemos visto una evolución bastante rápida de la inteligencia artificial. Primero aprendimos a conversar con modelos. Después empezamos a utilizarlos para escribir código, analizar documentos, generar contenido y consultar información. Ahora estamos entrando en una etapa diferente: **los agentes**. Un agente no solamente responde. Puede consultar sistemas, utilizar herramientas, ejecutar procesos, modificar información y coordinarse con otros agentes. Y aquí aparece una pregunta que considero mucho más importante que simplemente preguntar qué tan inteligente es nuestro modelo: > **¿Cómo hacemos para que un agente pueda actuar con autonomía sin perder el contexto, la trazabilidad, la seguridad y el control humano?** Porque poner un LLM detrás de una API y darle permisos para ejecutar acciones no convierte automáticamente nuestro sistema en una arquitectura agentic. De hecho, probablemente sea una receta bastante rápida para tener problemas. Lo interesante es que, cuando empezamos a pensar seriamente en agentes, aparecen una serie de capacidades que antes podían parecer secundarias: memoria, conocimiento, herramientas, autorización, auditoría, verificación y aprendizaje. Y todas terminan conectándose. # El problema no es que la IA produzca poco Durante mucho tiempo el objetivo fue conseguir que la IA produjera más. Más código. Más documentos. Más análisis. Más respuestas. Pero cuando tenemos varios agentes trabajando en paralelo aparece un problema diferente. Supongamos que tenemos: ```plaintext Agente A → analiza incidencias Agente B → revisa código Agente C → actualiza documentación Agente D → ejecuta pruebas Agente E → prepara cambios ``` La capacidad de producción puede crecer rápidamente. Pero el humano sigue siendo uno. Y ese humano tiene que: * revisar resultados; * tomar decisiones; * validar información; * aprobar acciones; * investigar errores. Entonces el cuello de botella cambia. Ya no es necesariamente: > "¿Cuánto puede producir la IA?" Sino: > **"¿Cuánto trabajo puede absorber y verificar una persona?"** Esto cambia completamente la arquitectura que necesitamos. # 1\. Un agente no puede empezar desde cero Imaginemos que tenemos un agente excelente. Tiene un buen modelo, buenas herramientas y acceso a nuestros sistemas. Pero cada vez que iniciamos una sesión no sabe: * qué ocurrió ayer; * qué decisiones tomamos; * qué aprendimos; * qué solución fue descartada; * qué procedimiento funciona actualmente; * qué tiene permitido hacer. Tenemos un agente muy capaz que todos los días parece ser su primer día de trabajo. Por eso necesitamos diferentes tipos de conocimiento. Una forma sencilla de verlo es: ```plaintext Episódico ¿Qué ocurrió? ↓ Conocimiento ¿Qué creemos que es cierto? ↓ Skills ¿Cuál es el método validado? ↓ Playbooks ¿Cómo combinamos esos métodos? ↓ Gobernanza ¿Qué puede hacer el agente? ``` Esto cambia el ciclo de trabajo. Ya no sería simplemente: ```plaintext pregunta → respuesta ``` sino: ```plaintext orientar ↓ recuperar contexto ↓ ejecutar ↓ verificar ↓ decidir ↓ aprender ↺ ``` La siguiente ejecución comienza con lo aprendido en la anterior. Ahí empieza a aparecer algo mucho más interesante que un chatbot: **memoria institucional.** # 2\. Una respuesta no es conocimiento Este punto parece obvio, pero se vuelve fundamental cuando dejamos que los agentes actúen. Que un agente diga: > "El problema está en el servicio de pagos." no significa que sea cierto. Tenemos que poder distinguir: ```plaintext Afirmación ↓ Fuente ↓ Evidencia ↓ Verificación ↓ Conocimiento confiable ``` Esto nos lleva al concepto de **provenance** o trazabilidad. Cuando un agente toma una decisión importante deberíamos poder responder: * ¿qué información utilizó? * ¿de dónde salió? * ¿qué regla aplicó? * ¿qué versión del conocimiento utilizó? * ¿quién autorizó la acción? * ¿qué ocurrió finalmente? Por ejemplo: ```plaintext Agente: billing-agent Acción: actualizar factura Fuente: ERP Regla: billing-update-v3 Autorización: policy-17 Resultado: success Evidencia: ... ``` Esto convierte una acción del agente en algo que podemos reconstruir posteriormente. Pero hay una distinción importante: > **Tener trazabilidad no significa tener razón.** Una firma puede demostrar que una acción ocurrió y quién la produjo. No demuestra que la acción fuera correcta. Por eso necesitamos combinar: ```plaintext Provenance + Autorización + Evidencia + Verificación ``` # 3\. No hagamos que el agente descubra lo que el sistema ya sabe Aquí aparece otro problema. Imaginemos un agente interactuando con una aplicación web: ```plaintext Agente ↓ abre página ↓ busca botón ↓ interpreta texto ↓ hace clic ↓ comprueba resultado ``` El agente está intentando descubrir cómo funciona nuestro sistema a través de su interfaz. ¿Por qué no declarar directamente las capacidades? Por ejemplo: ```plaintext getCustomer(customerId) createInvoice(customerId, items) cancelInvoice(invoiceId) approveRefund(refundId) ``` Ahora el agente sabe exactamente qué puede hacer y qué parámetros necesita. La arquitectura cambia: ```plaintext ANTES Agente → UI → DOM → interpretación → acción DESPUÉS Agente → capacidad declarada → contrato → acción ``` Esto no solamente facilita el trabajo del agente. También facilita: * testing; * autorización; * auditoría; * documentación; * observabilidad; * reutilización. Y aparece una idea interesante: > **La interfaz deja de ser necesariamente la fuente principal de información sobre lo que un sistema puede hacer.** Las capacidades pueden declararse explícitamente. # 4\. El agente necesita brazos, no solamente voz Un chatbot tiene voz. Un agente necesita brazos. Es decir, necesita poder actuar: ```plaintext Leer información ↓ Usar API ↓ Modificar información ↓ Ejecutar procesos ↓ Interactuar con otros sistemas ``` Pero aquí aparece un problema: **¿Qué acciones puede ejecutar?** No deberíamos responder: > "Las que permita su API key." Eso es demasiado grueso. La pregunta debería ser mucho más específica: > **¿Este agente puede realizar esta acción, sobre este recurso, en este contexto y en este momento?** Por ejemplo: ```plaintext crear PR → automático ejecutar tests → automático modificar documentación → automático desplegar producción → supervisión eliminar base de datos → aprobación explícita transferir dinero → aprobación explícita ``` La autonomía debería estar asociada a la **acción**, no solamente al agente. # 5\. La autonomía es un dial Uno de los errores más comunes es pensar: ```plaintext NO AUTÓNOMO ←→ AUTÓNOMO ``` En realidad necesitamos algo mucho más gradual: ```plaintext Manual ↓ Automático con aprobación ↓ Automático con verificación ↓ Agente supervisado ↓ Agente autónomo ``` Y la posición depende de factores como: * riesgo; * reversibilidad; * alcance; * historial; * calidad de la evidencia; * autorización. Un agente puede tener autonomía completa para limpiar ejecuciones de pruebas y necesitar aprobación humana para modificar producción. No hay contradicción. **Son dos acciones diferentes.** # 6\. Human-in-the-loop no significa aprobar todo Aquí creo que aparece una de las ideas más importantes. Durante mucho tiempo hemos pensado en *Human-in-the-loop* como: ```plaintext Agente ↓ Humano ↓ Approve ``` Pero si hacemos esto para cada acción: ```plaintext acción 1 → aprobar acción 2 → aprobar acción 3 → aprobar acción 4 → aprobar ... ``` tenemos un problema. El humano termina haciendo clic en "Approve" sin leer. La seguridad se convierte en una ilusión. Una arquitectura más interesante es: ```plaintext ACCIÓN ↓ ¿Necesita juicio humano? ↙ ↘ NO SÍ ↓ ↓ automático humano correcto ↓ decisión ``` Por ejemplo: ```plaintext 100 acciones ↓ 95 → automáticas 5 → revisión humana ``` El objetivo no es sacar al humano del sistema. Es **sacar del camino del humano todo lo que no necesita su juicio**. # 7\. Permiso no significa relevancia Esto también cambia la forma en que pensamos las notificaciones. Una persona puede tener permiso para acceder a un proyecto. Pero eso no significa que tenga que recibir todas las notificaciones de ese proyecto. Tenemos dos conceptos diferentes: ```plaintext PERMISSION ¿Puede verlo? RELEVANCE ¿Necesita recibirlo? ``` Podemos agregar una tercera dimensión: ```plaintext URGENCY ¿Necesita saberlo ahora? ``` Entonces: ```plaintext Permission + Relevance + Urgency ↓ Delivery ``` Esto permite construir sistemas donde la mayoría de las cosas llegan como un resumen: ```plaintext Digest "Hay 27 elementos para revisar." ``` Y solamente las situaciones realmente importantes interrumpen: ```plaintext Alert "Esta acción requiere tu decisión." ``` Esto es importante porque la atención humana es un recurso limitado. Si todo genera una alerta, ninguna alerta termina siendo realmente importante. # 8\. La confianza no se declara, se construye Si queremos aumentar la autonomía de un agente necesitamos saber cuándo podemos confiar en él. No basta con decir: > "Este modelo es muy bueno." Necesitamos observar su comportamiento. ```plaintext Historial ↓ Resultados ↓ Verificación ↓ Desviaciones ↓ Confianza ↓ Autonomía permitida ``` Y esa confianza tampoco debería ser permanente. Si cambiamos: * el modelo; * las herramientas; * los datos; * las reglas; * el contexto; * el alcance; tenemos que preguntarnos nuevamente: > **¿La autorización y el nivel de autonomía siguen siendo válidos?** Un agente confiable para una tarea no necesariamente es confiable para otra. # 9\. Pero aparece una pregunta incómoda: ¿quién verifica al verificador? Podemos construir: ```plaintext Agente ↓ Decisión ↓ Evidencia ↓ Auditor ↓ Resultado ``` Y sentirnos bastante tranquilos. Hasta que descubrimos que el auditor tiene un bug. Esto es importante porque introduce un nivel adicional: > **Nuestra infraestructura de verificación también necesita ser verificada.** Podemos tener todos los logs del mundo y aun así interpretarlos mal. Por ejemplo: ```plaintext Evento A ↓ Evento B ↓ Auditor ↓ "No están relacionados" ``` cuando en realidad sí pertenecen a la misma ejecución y simplemente estamos utilizando una clave de correlación incorrecta. La lección es poderosa: > **Los datos pueden ser correctos y nuestra interpretación de esos datos puede ser incorrecta.** # 10\. 1.500 tests pasando tampoco significa que todo esté bien Este problema también aparece en testing. Podemos tener cientos o miles de pruebas pasando y descubrir un error en producción. ¿Por qué? Porque podemos estar probando una representación simplificada del sistema real. Por ejemplo: ```plaintext Test ↓ Mock ↓ OK ``` mientras que: ```plaintext Producción ↓ Restricción real ↓ FAIL ``` La cantidad de tests no es suficiente. La pregunta importante es: > **¿Qué propiedad del sistema estoy demostrando con este test?** Esto es especialmente relevante para gobernanza. No basta con probar: ```plaintext "El botón de aprobación funciona." ``` Tenemos que probar: ```plaintext "Sin la aprobación requerida, la acción realmente no puede ejecutarse." ``` Eso es mucho más cercano a una garantía real. # 11\. Las políticas deben ser ejecutables Supongamos que nuestra documentación dice: > "Los cambios en producción requieren aprobación." Perfecto. Pero nuestro pipeline permite: ```plaintext git push ↓ deploy ``` sin comprobar ninguna aprobación. Entonces tenemos una política documentada, pero no una política efectiva. Una política realmente importante debería poder convertirse en una regla ejecutable: ```plaintext Cambio ↓ Pipeline ↓ ¿Cumple política? ↙ ↘ Sí No ↓ ↓ Deploy BLOCK ``` La diferencia es enorme. Una política escrita expresa una intención. Una política ejecutada por el sistema controla el comportamiento. Y cuanto más autónomos sean nuestros agentes, más importante será esta distinción. # 12\. También tenemos que guardar nuestros errores Normalmente almacenamos el conocimiento actual: ```plaintext "Esta es la forma correcta de hacerlo." ``` Pero también sería útil conservar: ```plaintext "Esta era nuestra hipótesis anterior." "Esto fue lo que observamos." "Esto la contradijo." "Por eso cambiamos." ``` Por ejemplo: ```plaintext Hipótesis ↓ Evidencia ↓ Decisión ↓ Falsificación ↓ Nuevo conocimiento ``` Esto es especialmente importante para los agentes. Si descubrimos que una determinada estrategia falla bajo ciertas condiciones, no queremos que el siguiente agente vuelva a descubrirlo desde cero. Queremos que pueda recuperar: > "Esta estrategia se utilizó anteriormente y falló cuando X estaba presente." Los errores dejan de ser simplemente errores. Se convierten en **memoria institucional**. # 13\. El objetivo no es hacer más. Es aprender más rápido. Aquí creo que está el verdadero cambio de paradigma. La primera generación de sistemas de IA buscaba: ```plaintext Pregunta ↓ Respuesta ``` Los sistemas agentic buscan: ```plaintext Objetivo ↓ Plan ↓ Herramientas ↓ Acciones ↓ Resultados ``` Pero podemos ir un paso más allá: ```plaintext Trabajo ↓ Agente ↓ Resultado ↓ Verificación ↓ Aprendizaje ↓ Mejor conocimiento ↓ Mejor agente ↓ Mejor resultado ↺ ``` Aquí la IA deja de ser únicamente una herramienta de producción. Empieza a convertirse en parte del **sistema de aprendizaje de la organización**. # 14\. Una arquitectura de referencia Si juntamos todas estas ideas, podemos imaginar una arquitectura bastante sencilla: ```plaintext ┌──────────────┐ │ HUMANO │ └──────┬───────┘ │ decisiones críticas │ ↓ ┌──────────────┐ ┌──────────────┐ │ CONTEXTO Y │ ─────→ │ AGENTE │ │ CONOCIMIENTO │ └──────┬───────┘ └──────────────┘ │ ↓ ┌───────────────┐ │ HERRAMIENTAS │ │ Y CAPACIDADES │ └───────┬───────┘ ↓ ┌───────────────┐ │ GOBERNANZA Y │ │ AUTORIZACIÓN │ └───────┬───────┘ ↓ ACCIÓN ↓ EVIDENCIA ↓ VERIFICACIÓN ↓ LEDGER ↓ APRENDIZAJE │ └────────→ CONTEXTO ``` Cada componente responde una pregunta diferente. ### Contexto > ¿Qué sabemos y qué ocurrió? ### Herramientas > ¿Qué puede hacer el agente? ### Gobernanza > ¿Qué está autorizado a hacer? ### Evidencia > ¿Cómo sabemos qué ocurrió? ### Verificación > ¿Podemos confiar en el resultado? ### Ledger > ¿Podemos reconstruirlo después? ### Aprendizaje > ¿Qué deberíamos hacer diferente la próxima vez? # 15\. ¿Cómo lo llevaría a producción? Y aquí está la parte práctica. No empezaría construyendo una plataforma gigantesca de agentes. Empezaría mucho más simple. ### Fase 1 — Agente + contexto Un agente que pueda recuperar información confiable. ```plaintext Agente ↓ Knowledge ↓ Contexto ``` ### Fase 2 — Herramientas Definir claramente qué puede hacer. ```plaintext Agente ↓ Tools ↓ APIs ``` ### Fase 3 — Autorización Decidir qué herramientas puede utilizar y bajo qué condiciones. ```plaintext Agent ↓ Policy ↓ Tool ``` ### Fase 4 — Evidencia Registrar las acciones importantes. ```plaintext Action ↓ Evidence ↓ Audit ``` ### Fase 5 — Verificación Comprobar automáticamente los resultados cuando sea posible. ```plaintext Action ↓ Result ↓ Verifier ``` ### Fase 6 — Autonomía gradual Permitir más autonomía solamente cuando exista evidencia suficiente. ```plaintext Manual ↓ Approval ↓ Supervised ↓ Autonomous ``` ### Fase 7 — Aprendizaje Capturar lo que funcionó y lo que no. ```plaintext Execution ↓ Verification ↓ Learning ↓ Knowledge ``` Y volver a comenzar. * * * # Conclusión Creo que estamos entrando en una etapa donde construir un agente ya no significa simplemente elegir un buen modelo y conectarlo a algunas herramientas. El verdadero desafío aparece cuando queremos que ese agente pueda **actuar en el mundo real**. En ese momento necesitamos responder preguntas mucho más difíciles: > ¿Qué sabe? > ¿De dónde lo sabe? > ¿Qué puede hacer? > ¿Qué está autorizado a hacer? > ¿Por qué confiamos en él? > ¿Qué evidencia produjo? > ¿Quién verifica esa evidencia? > ¿Cuándo necesitamos a un humano? > ¿Qué aprendimos después de equivocarnos? Y todas esas preguntas nos llevan a una conclusión: **La autonomía no es el punto final de la arquitectura agentic.** Es una consecuencia de haber construido suficiente contexto, confianza, evidencia, gobernanza y mecanismos de verificación. Podemos resumirlo así: ```plaintext CONTEXTO ↓ CAPACIDADES ↓ AUTORIZACIÓN ↓ ACCIÓN ↓ EVIDENCIA ↓ VERIFICACIÓN ↓ CONFIANZA ↓ AUTONOMÍA ↓ APRENDIZAJE │ └──────────→ CONTEXTO ``` Y quizá el objetivo final no sea conseguir que la IA haga todo por nosotros. Quizá sea algo mucho más interesante: > **Construir organizaciones que sean mejores cada vez que hacen algo.** Una organización donde los agentes no solamente producen resultados, sino que ayudan a conservar el contexto, aprender de los errores, verificar las decisiones y aumentar gradualmente su autonomía. Porque al final, el verdadero salto no es pasar de: **humano → IA** sino pasar de: **IA que responde** a: **sistemas que actúan, verifican y aprenden.**