Cómo diseñar routing automático de capacidades sin convertir la interfaz unificada en una caja negra

Paso 1: define un catálogo de capacidades antes de escribir el router. Enumera lo que el sistema realmente puede hacer: responder, buscar, leer archivos, editar, generar un documento, usar navegador, enviar mensajes o ejecutar código. Para cada capacidad registra costo esperado, permisos requeridos, datos que puede tocar y si produce efectos reversibles. El router no debería elegir herramientas individuales a ciegas; debería seleccionar una capacidad con un contrato conocido. Esta capa convierte un conjunto creciente de integraciones en una superficie que producto y seguridad pueden entender sin leer la implementación de cada conector.

Paso 2: clasifica intención y riesgo por separado. La intención responde “qué quiere conseguir la persona”; el riesgo responde “qué consecuencias tendría ejecutar esa ruta”. Una solicitud puede parecer simple pero requerir escribir en un sistema externo. Usa dos salidas distintas: taskclass y riskclass. Así una mejora en la clasificación semántica no altera automáticamente la política. El router puede proponer una ruta; una capa de autorización independiente decide si se permite, si necesita confirmación o si debe degradarse a un modo de solo lectura.

Paso 3: crea una política de escalada entre capacidades. Empieza por la ruta mínima que pueda resolver la tarea y permite escalar cuando aparecen señales concretas: falta una fuente, se necesita un artefacto editable, hay demasiadas dependencias o la solicitud requiere acción externa. Evita que “más agentic” sea el default. Cada escalada debería registrar un motivo corto y estructurado. Esto ayuda a optimizar costo y a detectar tareas que sistemáticamente activan capacidades más pesadas de lo necesario. El usuario no tiene que elegir el modo; el sistema sí debe justificar internamente por qué lo cambió.

Paso 4: separa autorización de ejecución. Antes de llamar una herramienta sensible, evalúa identidad, rol, recurso, acción y contexto. Una aprobación puede ser válida para editar un documento específico, no para cualquier archivo del usuario. Si la política requiere confirmación, presenta exactamente el efecto pendiente. Cuando llegue la respuesta, vincúlala a la acción concreta y expírala después de usarla. Este patrón evita permisos abiertos derivados de una intención antigua y permite que un flujo largo continúe con autonomía dentro de límites que fueron aprobados explícitamente.

Paso 5: emite un routereceipt al cerrar cada ejecución. Incluye identificador, clase de tarea, capacidades activadas, policy checks, herramientas invocadas, artefactos creados, costo estimado y real, y estado final. No guardes razonamiento privado; guarda hechos operativos. Para el usuario final puedes mostrar una versión resumida. Para soporte y administración conserva detalle técnico suficiente para reconstruir el flujo. El recibo se vuelve una pieza compartida por observabilidad, facturación y cumplimiento, reduciendo la cantidad de logs desconectados que un equipo necesita correlacionar.

Paso 6: prueba el router con casos contrafactuales. Construye pares de solicitudes parecidas donde una debe quedarse en lectura y otra necesita acción. Mide escaladas innecesarias y escaladas omitidas. Simula conectores caídos, permisos insuficientes y cambios de intención durante el flujo. Luego ejecuta políticas nuevas sobre trazas históricas antes de habilitarlas. Un router no es bueno porque acierta en demos felices; es bueno cuando sabe degradar capacidades, pedir aprobación y detenerse sin inventar una ruta alternativa que viole el contrato del entorno.

Implementación Goatify. Podemos representar cada habilidad como capabilitymanifest y cada ejecución como routereceipt. El frontend mantiene una sola conversación, mientras el runtime compone capacidades con reglas claras. En enterprise, el administrador configura políticas por equipo y tipo de dato; el usuario sigue hablando normal. Esto crea una arquitectura escalable: agregar una herramienta nueva no requiere rediseñar la interfaz, solo declarar su contrato, conectarla a la política y ampliar las pruebas del router. La simplicidad visible se convierte en consecuencia de una estructura interna más disciplinada.