Cuando la herramienta deja de sugerir y empieza a actuar

Cierre de la serie: qué es técnicamente un agente, los patrones que le dan forma, el protocolo que los interconecta, y los riesgos de gobernanza que ya están documentados.

por Camilo — Agosto 15 2026 · LinkedIn

---

La Parte 2 de esta serie terminó con una pregunta pendiente: ¿qué cambia cuando una herramienta deja de sugerir y empieza a actuar por su cuenta? Ya vimos la diferencia entre un chatbot (gestiona una conversación) y un copiloto (te asiste dentro de un flujo de trabajo, pero vos aprobás cada acción). Lo que queda del otro lado de esa frontera tiene nombre propio, y es el tema que cierra esta serie: agentic AI, sistemas agénticos, o simplemente “agentes” — el término que, sospecho, es de los que más rebotan sin definición precisa en esas reuniones que mencionábamos al principio de la serie.

Qué es, técnicamente, un agente

Un agente de IA es un sistema que combina un modelo de lenguaje con una capa de orquestación capaz de percibir contexto, planificar una secuencia de acciones, ejecutarlas usando herramientas, y ajustar esa secuencia según los resultados que va obteniendo — todo esto sin que un humano apruebe cada paso individual. Esa última cláusula es la que marca la frontera real. Un copiloto te sugiere una línea de código y esperás tu aprobación antes de aceptarla. Un agente de codificación puede leer un ticket, decidir qué archivos tocar, escribir el cambio, correr los tests, y solo entonces mostrarte el resultado — vos revisás el final, no cada paso intermedio.

Esto no es una mejora incremental sobre el copiloto. Es un salto de categoría: el copiloto asiste una decisión que seguís tomando vos; el agente toma la decisión y actúa, dentro de un margen de autonomía que vos le definiste de antemano. La calidad de ese margen —qué tan bien definiste los límites de lo que el agente puede hacer sin consultarte— es, en la práctica, el factor que separa un sistema agéntico útil de uno peligroso. Vamos a volver sobre esto en la última sección.

Vale la pena, ya que estamos precisando vocabulario, distinguir un agente de otro término con el que se lo confunde seguido en entornos corporativos: la automatización robótica de procesos (RPA). Un sistema de RPA también ejecuta tareas sin supervisión constante, y a primera vista puede parecer lo mismo. La diferencia está en la naturaleza de lo que sigue: RPA ejecuta un guion fijo, escrito de antemano paso por paso, y si las condiciones cambian por fuera de ese guion, simplemente falla o se detiene. Un agente, en cambio, razona sobre el objetivo y adapta la secuencia de acciones cuando las condiciones cambian a mitad de camino. RPA automatiza lo que ya sabés hacer exactamente igual todas las veces; un agente está pensado para lidiar con la parte del trabajo que no se deja reducir a un guion fijo.

Los patrones que le dan forma al comportamiento agéntico

Que un modelo de lenguaje pueda, en principio, actuar de forma autónoma no significa que sepamos automáticamente construir un buen agente. Acá es donde entran los patrones de diseño que popularizó Andrew Ng en 2024, y que se convirtieron rápido en el vocabulario de referencia del campo: Reflection, Tool Use, Planning y Multi-Agent Collaboration.

Reflection es el patrón más simple de los cuatro: en vez de que el modelo genere una respuesta final de una sola pasada, se le pide que revise su propio trabajo, identifique errores o huecos, y lo corrija — varias veces si hace falta, antes de entregar el resultado. Tool Use es la capacidad, que ya introdujimos en la Parte 2, de que el agente decida por sí mismo qué herramienta externa invocar (buscar en la web, correr código, consultar una base de datos) para completar una tarea que el modelo no puede resolver solo con lo que tiene en la cabeza. Planning es la descomposición de una tarea grande en subtareas manejables — y vale la pena decirlo con la misma honestidad con que lo dijo el propio Ng: de los cuatro patrones, este es el que él mismo calificó como el menos maduro y menos predecible, algo que cualquiera que haya visto a un agente perderse a mitad de un plan complejo puede confirmar de primera mano. Multi-Agent Collaboration, finalmente, es coordinar varios agentes especializados —cada uno con su propio rol, sus propias herramientas, a veces su propio modelo— para resolver en conjunto un problema que excede la capacidad de un agente solo.

Si estos cuatro patrones te resultan familiares es porque ya los desarrollé en profundidad en Raise the Level of Abstraction, con un caso real de una célula de agentes (Architect, Full-Stack, Technical Writer) construyendo un proyecto bajo Clean Architecture y TDD. No voy a repetir ese desarrollo acá — si te interesa el detalle técnico de implementación, ese artículo lo tiene con nivel de producción. Lo que quiero que te lleves de esta sección es más simple: estos cuatro patrones no son teoría abstracta, son las piezas de Lego con las que hoy se construye, en la práctica, cualquier sistema agéntico serio.

MCP: la pieza que faltaba para que esto escale

Hay un problema práctico que aparece apenas empezás a combinar estos patrones: si cada agente necesita conectarse a cada herramienta —tu calendario, tu base de datos, tu repositorio de código, una API externa— con una integración hecha a medida para cada combinación, el trabajo de ingeniería crece de forma insostenible. Con N agentes y M herramientas, terminás necesitando, en el peor caso, N por M integraciones distintas.

En noviembre de 2024, Anthropic publicó una respuesta a ese problema: el Model Context Protocol (MCP), un estándar abierto para que cualquier agente se conecte a cualquier herramienta o fuente de datos a través de un mismo protocolo, en vez de una integración artesanal por cada par. La propia Anthropic usa una analogía que resulta bastante precisa: MCP funciona como el puerto USB-C de las aplicaciones de IA — un solo conector físico que sirve para cualquier dispositivo, en vez de un cable distinto para cada marca. Con MCP, la cuenta deja de ser N por M y pasa a ser N más M: cada agente implementa el protocolo una vez, cada herramienta lo expone una vez, y a partir de ahí cualquier combinación funciona sin trabajo adicional.

Lo interesante —y esto es un hecho verificable, no una proyección— es que competidores directos de Anthropic en el desarrollo de modelos, como OpenAI, Microsoft y Google DeepMind, adoptaron el mismo protocolo en sus propias herramientas. Cuando una pieza de infraestructura logra que empresas que compiten entre sí en casi todo lo demás coincidan en usarla, generalmente es una señal de que resolvió un problema real y no solo el problema de quien la publicó. MCP es, hoy, la respuesta más concreta que existe a la pregunta con la que arrancó esta serie: cómo se interconectan entre sí todos estos conceptos que empezamos a desglosar.

La cara B: lo que ya está saliendo mal

Ahora bien — sería una simplificación irresponsable cerrar esta serie sin hablar de la otra cara de la autonomía. Y acá quiero ser preciso con el registro: lo que sigue no es especulación alarmista, es lo que ya está documentado en despliegues reales de 2026.

El problema que más se repite en los reportes de adopción empresarial tiene nombre: agent sprawl. Ocurre cuando distintos equipos, dentro de la misma organización, despliegan agentes función por función —uno para atención al cliente, otro para procesamiento de tickets, otro para reportes— sin coordinación central, sin contexto compartido, sin observabilidad unificada. Cada agente individual puede funcionar razonablemente bien en su tarea puntual. El problema aparece en la interacción: cuando un agente comete un error y ese error se propaga hacia otro agente que confía ciegamente en su salida, el error se compone en silencio a través del sistema completo, y para cuando alguien lo detecta, ya viajó varios pasos.

Si esto te suena conocido es porque ya lo planteé, con otras palabras, en ¿Quién gobierna el desgobierno de la IA? — un artículo que escribí antes de que “agent sprawl” fuera un término establecido de industria, a partir de una experiencia concreta con equipos trabajando con sistemas de agentes en paralelo sin coordinación. La razón por la que lo traigo de vuelta acá no es autopromoción: es que la evidencia de 2026 terminó validando externamente algo que en ese momento era, sobre todo, una intuición de práctica de campo. El patrón de orquestación federada que propuse ahí como resolución narrativa es, esencialmente, la misma respuesta que hoy proponen los frameworks de gobernanza de agentes: coordinación central, visibilidad compartida, límites de autonomía explícitos por agente.

Los números que acompañan este diagnóstico son elocuentes. Reportes de adopción empresarial de mediados de 2026 muestran que una proporción significativa de los agentes ya desplegados operan sin supervisión de seguridad ni registro de auditoría, y que la mayoría de las organizaciones todavía no tienen visibilidad completa sobre qué permisos, qué acceso a datos y qué acciones puede tomar cada agente que corre en su infraestructura. No es un problema de si la tecnología funciona — funciona, y cada vez mejor. Es un problema de gobernanza que la velocidad de adopción dejó atrás.

Hay un detalle técnico concreto detrás de ese diagnóstico, y no es abstracto: la mayoría de los agentes desplegados hoy tienen bastante más acceso del que su tarea puntual requiere. Un agente de soporte al cliente que, para responder consultas de facturación, termina con permiso de lectura sobre toda la base de conocimiento, capacidad de consultar el sistema de cobros completo y acceso de escritura sobre configuraciones de cuenta, no es una rareza — es, según varios reportes de seguridad de este año, más bien la norma. El problema es de diseño de permisos, no de mala intención: es mucho más simple, al construir un agente, darle acceso amplio “por las dudas” que modelar con precisión el mínimo necesario para cada tarea. Pero esa comodidad de diseño tiene un costo directo: si ese agente se ve comprometido —por una instrucción maliciosa inyectada en un documento que procesa, por ejemplo—, el radio de daño posible es tan amplio como los permisos que le diste, no como la tarea que realmente cumple. La recomendación que más se repite en la literatura de seguridad de agentes es otorgar permisos justo a tiempo, acotados a la duración de una tarea específica, y revocarlos apenas termina — el mismo principio de mínimo privilegio que ya conocés de cualquier sistema de identidad y accesos, aplicado ahora a un actor que decide por sí mismo qué hacer con esos permisos.

El mapa completo — y hacia dónde, honestamente, vamos

Si juntás las tres partes de esta serie, tenés un mapa que empieza en 1956 y termina, por ahora, acá. La inteligencia artificial es el campo, nacido en un verano en Dartmouth, con dos inviernos de fracaso público en el medio. Machine learning y deep learning son subconjuntos progresivamente más específicos dentro de ese campo. El Transformer es la arquitectura que hizo viable escalar el deep learning al lenguaje. Un LLM es un modelo entrenado con esa arquitectura, en su forma base o afinada por instrucciones. Un chatbot o un copiloto son productos de ingeniería construidos alrededor de ese modelo, con un costo medible en tokens. Y un agente es el siguiente escalón: ese mismo modelo, equipado con patrones de diseño —reflexión, uso de herramientas, planificación, colaboración multi-agente— y conectado al mundo a través de un protocolo como MCP, operando con un grado de autonomía que vos definís y que, si no lo definís con cuidado, se convierte en el problema que acabamos de describir.

¿Hacia dónde va esto? Acá conviene separar con cuidado lo que ya es hecho consumado de lo que todavía es apuesta razonable. Es un hecho que la adopción de sistemas agénticos en entornos empresariales creció de forma sostenida durante 2025 y 2026, y que la inversión y el interés de la industria siguen esa misma curva. Es también un hecho, no una opinión mía, que la brecha de gobernanza —quién audita qué hace cada agente, con qué permisos, con qué límites— está documentada y es real hoy, no una preocupación teórica para el futuro. Lo que todavía es una apuesta, y no un hecho, es cuánto de la adopción actual va a sobrevivir a la próxima ronda de escrutinio regulatorio y de gobernanza corporativa, y cuánto era, en el fondo, entusiasmo apurado por delegar de más antes de tiempo.

Mi lectura personal —y la marco explícitamente como eso, no como pronóstico objetivo— es que los próximos años de este campo se van a definir menos por cuánto más autónomos se vuelven los agentes, y más por cuánto mejor aprendemos a gobernarlos. La tecnología de percibir, planificar y actuar ya está razonablemente resuelta. Lo que todavía no está resuelto es la disciplina organizacional para decidir, con criterio, cuánta autonomía delegarle a cada sistema — y esa es, casualmente, una decisión que ningún modelo, por más grande que sea, puede tomar en tu lugar.

Así que la próxima vez que en una reunión alguien mencione “agentes” en la misma frase que “LLM” y “costo por token”, ya tenés el mapa completo para separar cada pieza: de dónde viene el campo, qué es realmente el modelo, qué es la herramienta que construyeron alrededor, y qué distingue a un agente de todo lo anterior. No hace falta que lo digas en voz alta en esa reunión. Alcanza con saberlo con precisión.