Cada pocos meses, la industria acuña un nuevo término para el software que supuestamente piensa por sí mismo. Ahora mismo, esa palabra es "IA Agéntica" (Agentic AI). Los proveedores se apresuran a pegarla en sus páginas de destino y presentaciones de ventas. Pero una etiqueta es solo lenguaje de marketing hasta que el sistema sobrevive al contacto con su entorno, sus datos y sus modos de fallo. La palabra en sí no dice nada sobre la seguridad, la fiabilidad o la adecuación.

Es hora de dejar de leer listas de funciones y empezar a medir capacidades.

El problema de la etiqueta

Los ingenieros de ventas le mostrarán paneles de control, menús desplegables multimodelo y acceso móvil como prueba de una arquitectura "agéntica". Esas son elecciones de interfaz, no garantías de comportamiento. Un producto puede parecer vanguardista y aun así desmoronarse en el momento en que necesita revisar un plan tras un tiempo de espera agotado de una API (API timeout).

Lo que importa es si el sistema se comporta realmente como un agente autónomo. ¿Divide el trabajo en pasos? ¿Interactúa con sistemas reales dentro de límites estrictos? Cuando algo falla, ¿se adapta o simplemente falla y espera? Hasta que responda a estas preguntas con evidencia específica para su stack, estará comprando un concepto, no un producto.

Cinco pruebas de capacidad que realmente importan

Evalúo cada afirmación agéntica frente a cinco capacidades específicas. Para cada una, planteo una sencilla pregunta de triaje: ¿está el comportamiento documentado, verificado en un piloto o sigue siendo desconocido? Lo desconocido es el valor por defecto. La responsabilidad de demostrar lo contrario recae en el producto.

Planificación. ¿Descompone el sistema un objetivo ambiguo en pasos ordenados y verificables? Cualquiera puede generar una lista de tareas. La verdadera prueba es gestionar un objetivo complejo como "reducir nuestro gasto en la nube en un quince por ciento este trimestre". Un agente auténtico traza una auditoría del uso actual, identifica recursos inactivos, redacta recomendaciones de ajuste de tamaño (rightsizing) y programa las solicitudes de cambio en la secuencia adecuada. Si le entrega un ensayo genérico de cinco puntos y da el trabajo por terminado, no es planificación. Es un resumen.

Herramientas. ¿Actúa sobre sistemas reales dentro de un alcance definido? Llamar a una API simulada (mock API) en una demostración pulida es fácil. Autenticarse en su CRM de producción con credenciales de mínimo privilegio, escribir un registro y registrar la transacción es difícil. Necesita saber exactamente qué sistemas toca, qué claves porta y dónde termina el radio de impacto (blast radius). El alcance debe estar delimitado. Si el agente tiene acceso de escritura a producción por defecto, no tiene un agente. Tiene un riesgo de responsabilidad.

Corrección. ¿Cambia su siguiente movimiento tras un fallo? Aquí es donde mueren la mayoría de los prototipos. Cuando el tercer paso devuelve un error 503 o un desajuste de esquema (schema mismatch), ¿el agente entra en un bucle infinito, alucina un mensaje de éxito o ajusta su trayectoria? La verdadera corrección significa observar el fallo, replanificar el resto del flujo de trabajo y ejecutar una nueva ruta sin abandonar las restricciones. Un bucle de reintento envuelto en optimismo no es corrección.

Contexto. ¿Mantiene las restricciones activas en cada paso? La memoria no es suficiente. Si el primer paso establece una regla estricta como "no exceder un presupuesto de quinientos dólares" o "excluir datos de clientes de la UE", el séptimo paso no puede ignorar ese límite porque el contexto del prompt haya cambiado. Esto se aplica a las reglas de cumplimiento, la voz de la marca, las jerarquías de aprobación y los controles de acceso. La preservación del contexto es donde los modelos de contexto largo y la gestión de estado clásica deben encontrarse.

Supervisión. ¿Puede un humano detener o reanudar el proceso? Necesita interruptores de seguridad (circuit breakers) que sean granulares, no solo un interruptor de apagado (kill switch) en la máquina virtual. ¿Puede alguien inspeccionar el plan después del segundo paso y aprobar el tercero? Si falla una dependencia externa, ¿puede un humano arreglarla y reanudar el flujo de trabajo sin perder el estado? La supervisión no es un registro de auditoría que se lee después de que ocurre un desastre. Es un mecanismo de intervención en vivo.

La evidencia vence a las casillas de verificación

Una demostración no es una tasa de fiabilidad. Una casilla de verificación en una hoja comparativa de proveedores no es una prueba. Cuando un ejecutivo de cuentas dice que el producto "revisa tras un fallo de prueba", su siguiente paso es pedir la tarjeta de evidencia.

Una tarjeta de evidencia sustituye la casilla de verificación por especificidad. Se ve así:

  • Capacidad: Corrección
  • Afirmación: Revisa tras un fallo de prueba
  • Evidencia: Pendiente de entorno controlado (controlled fixture)
  • Responsable: Equipo de experiencia del desarrollador (Developer-experience team)
  • Detener si: La revisión cambia una interfaz aprobada

Este formato impone claridad. Separa la promesa de marketing de la prueba. Asigna la responsabilidad para que, cuando el agente rompa una interfaz aprobada durante su intento de revisión, sepas exactamente a qué equipo se debe llamar. Sin un responsable, no hay rendición de cuentas. Sin condiciones de parada, no hay rieles de seguridad.

Antes de lanzar cualquier piloto, define tres cosas por escrito. Primero, tus tareas. Estas deben extraerse de la lógica de negocio real, no de benchmarks sintéticos. Segundo, tus pruebas de fallo. Revoca una clave API a mitad de la