Catálogo de agentes por capacidad: comparar, clasificar, monitorear y aprobar
Por Equipo Quantum Developers
Resumir:
Un catálogo útil describe la operación, entradas, autoridad, evidencia y fallos de una capacidad reutilizable; llamar a todo “agente de finanzas” oculta que comparar y aprobar requieren controles radicalmente distintos. Dos agentes con la misma etiqueta sectorial pueden tener poco en común, mientras un comparador de facturas y uno de eventos logísticos comparten un contrato operativo.
El costo de catalogar por industria
Las categorías compras, finanzas y logística ayudan a ubicar patrocinadores, pero no explican qué hace el sistema. “Agente de compras” puede buscar proveedores, clasificar solicitudes, comparar ofertas o aprobar órdenes. Cada verbo implica datos, evaluación y riesgo diferentes.
El catálogo sectorial también duplica componentes. Tres equipos construyen su propia extracción, cola y aprobación porque creen que sus agentes son únicos. La reutilización correcta no está en el prompt; está en la primitiva con un contrato estable.
Qué debe contener una ficha de capacidad
Cada entrada registra:
| Campo | Pregunta |
|---|---|
| primitive_id/version | ¿Qué contrato exacto usa la ejecución? |
| operation | ¿Compara, clasifica, monitorea o prepara aprobación? |
| business_object | ¿Qué objeto recibe y qué estado puede cambiar? |
| input_contract | ¿Qué campos, derechos, frescura y procedencia exige? |
| output_contract | ¿Qué resultado, razón, candidatos y evidencia entrega? |
| authority | ¿Recomienda, ejecuta una acción reversible o requiere aprobación? |
| evaluation | ¿Contra qué verdad y casos se valida? |
| failure_modes | ¿Qué no encontrado, ambigüedad, política o dependencia produce? |
| telemetry | ¿Qué evento, latencia, costo y resultado registra? |
| owner/retire_at | ¿Quién opera y cuándo se revisa o retira? |
El AI RMF de NIST pide inventario, responsabilidades diferenciadas, documentación de riesgos y gestión durante el ciclo de vida. Una ficha por capacidad hace esos controles comparables sin asumir que NIST prescribe esta arquitectura.
Primitiva 1: MATCH — comparar relaciones
Entrada: dos o más registros con identificadores, campos normalizados y política de comparación. Salida: coincidencia, candidatos, diferencias y código de razón. Autoridad: puede cerrar automáticamente solo reglas exactas o tolerancias aprobadas; la ambigüedad va a revisión.
Casos: factura contra orden, pago contra liquidación, evento contra plan. La evaluación separa falsos positivos de falsos negativos por tipo de caso. Un porcentaje global puede ocultar que el error grave está en un segmento pequeño.
Primitiva 2: CLASSIFY — asignar una política o ruta
Entrada: objeto y evidencia permitida. Salida: clase, razones, versión del esquema y nivel de confianza. Autoridad: la clase puede enrutar trabajo reversible; no debe convertir por sí sola una etiqueta en rechazo, pago o sanción.
Casos: tipo de solicitud, motivo de excepción, categoría documental. Incluya “desconocido” y “múltiple” como resultados válidos. Forzar una clase en cada caso fabrica certeza.
Primitiva 3: MONITOR — detectar cambio accionable
Entrada: plan, estado actual y eventos ordenados. Salida: diferencia, prioridad, reloj y dueño. Autoridad: abre, actualiza o cierra una excepción según reglas; no repite alertas por el mismo estado.
Casos: embarque retrasado, SLA en riesgo, fuente de datos vencida. La evaluación mide eventos útiles y duplicados, no cantidad bruta de notificaciones.
La especificación CloudEvents define un sobre interoperable con atributos requeridos como id, source, specversion y type, y separa contexto de payload. No dicta la lógica de monitoreo, pero muestra cómo una primitiva puede recibir eventos de varios motores sin acoplarse a su formato interno.
Primitiva 4: APPROVE — preparar y registrar autoridad
Entrada: acción propuesta, objeto, evidencia, política y consecuencias. Salida: aprobado, rechazado, devuelto o vencido, con actor y razón. Autoridad: la primitiva registra la decisión; el agente que prepara el caso no se autoaprueba.
Casos: liberar orden, aceptar diferencia, publicar contenido, cambiar acceso. El contrato incluye separación de funciones, sustitución, vencimiento y reapertura. “Human in the loop” sin permiso y contexto definidos es solo una pantalla.
Cómo componer sin crear una cadena opaca
La especificación BPMN 2.0 de OMG ofrece vocabulario para tareas, eventos, gateways, errores, escalamiento y compensación. Use un modelo de proceso para mostrar cómo las primitivas cambian estado; no esconda toda la orquestación dentro de un agente general.
Un flujo de cuentas por pagar podría ser:
- CLASSIFY identifica documento y política;
- MATCH compara factura, orden y recepción;
- MONITOR abre excepción si faltan datos o vence el plazo;
- APPROVE presenta diferencias materiales a la autoridad;
- una automatización determinística publica la acción autorizada.
Cada paso emite un evento con objeto, versión, resultado y evidencia. Si falla MATCH, el estado no avanza como si toda la cadena hubiera fallado; la excepción identifica capacidad y razón.
Ejemplo de reutilización entre dominios
Ejemplo ilustrativo: compras usa MATCH para comparar oferta y requisitos; finanzas lo usa para pago y liquidación; logística, para evento y plan. Comparten motor de candidatos, códigos básicos de exacto/ambiguo/no encontrado y sobre de evidencia. No comparten reglas de negocio ni tolerancias.
MONITOR comparte deduplicación, reloj y propiedad de excepción, pero cada dominio define qué cambio es accionable. APPROVE comparte identidad, política, evidencia y decisión; los permisos siguen perteneciendo al proceso.
El objetivo no es maximizar reutilización de código. Es reutilizar contratos y controles donde el significado coincide.
Catálogo visible en Quantum
En Quantum Automation Center, el catálogo puede distinguir agente, automatización y capacidad; las ejecuciones y líneas de tiempo muestran qué versión actuó; artefactos y logs guardan referencias permitidas; permisos y aprobación humana aplican autoridad; y las analíticas comparan uso, excepción y resultado. La ontología de Quantum enlaza capacidades con objetos de negocio.
Una tarjeta ejecutiva debería mostrar operación, dueño, nivel de autoridad, dominios que la reutilizan, estado y evidencia de evaluación. Evite títulos como “agente inteligente avanzado”.
El contrapunto: demasiadas primitivas fragmentan el resultado
La crítica es correcta cuando cada verbo se convierte en producto, equipo y cola independientes. La orquestación puede ser más costosa que el problema, y el usuario termina saltando entre microagentes.
Componga primitivas alrededor de un objeto, un estado y un dueño de resultado. Permita que una implementación ejecute varias capacidades cuando sea simple, pero conserve contratos y evidencia separados. La modularidad es conceptual antes que organizacional.
Cuándo no usar este enfoque
No divida un flujo pequeño, determinístico y de bajo riesgo en múltiples agentes. Una función o regla puede ser más clara. No use CLASSIFY probabilístico donde un campo confiable ya determina la clase, ni APPROVE como capa decorativa cuando la política permite ejecución automática reversible.
Tampoco cree un catálogo sin dueños y casos reales. Una biblioteca de nombres abstractos se vuelve inventario muerto.
Prueba de calidad del catálogo
Tome dos entradas de industrias distintas. Oculte sus nombres comerciales y compare contrato, autoridad y fallos. Si no puede explicar por qué son la misma capacidad, sepárelas. Si sí puede, pruebe que comparten evaluación y evidencia antes de anunciar reutilización. El catálogo vale cuando mejora una decisión de diseño, no cuando aumenta el número de tarjetas.
Sources
- OMG Business Process Model and Notation (BPMN) 2.0 — omg.org
- CloudEvents Specification — github.com
- NIST AI Risk Management Framework Core — nist.gov
Temas del artículo
