Proactividad acotada: activar agentes por eventos sin ceder el control

Del agente reactivo al agente atento

La conversación es una interfaz adecuada para formular una intención, pero no es la única situación en la que puede comenzar un trabajo. En una organización también existen tareas vinculadas al tiempo y a cambios de estado:

• revisar periódicamente una cola de soporte;
• preparar documentación antes de una reunión;
• continuar un proceso cuando se resuelve una aprobación;
• analizar una novedad recibida por webhook;
• comprobar una fuente conectada y actuar solo si cumple una condición.

El paso desde el chat hacia estas activaciones plantea una dificultad arquitectónica. Si cada fuente despierta al agente mediante su propio mecanismo, aparecen rutas paralelas con distintas reglas de autenticación, reintento, coste, auditoría y control humano. La proactividad deja entonces de ser una capacidad del sistema y se convierte en una colección de excepciones.

La propuesta evita esa fragmentación. Las fuentes producen eventos; las suscripciones deciden qué eventos interesan; una política decide si la activación está permitida; y el buzón deposita una solicitud en la misma ruta de ejecución que utiliza el resto del sistema.

Proactividad no es autonomía total

El diseño distingue tres formas de iniciativa:

1. Una persona programa a un agente. Por ejemplo, le encarga una revisión recurrente o una preparación relativa a una fecha.
2. Un agente propone o crea una suscripción regulada. Puede programarse a sí mismo o solicitar la activación de otro agente, sujeto a permisos y, en su caso, aprobación humana.
3. El entorno emite una señal. Un sistema empresarial, una fuente conectada o un webhook informa de un cambio que puede ser relevante.

En los tres casos sigue existiendo una instrucción previa y atribuible. El agente no decide libremente qué observar ni transforma cualquier novedad en una acción. Escucha únicamente las fuentes autorizadas, bajo una suscripción visible, con una tarea y unos límites explícitos.

No se incluyen en esta propuesta la formación autónoma de objetivos, la negociación abierta de trabajos entre agentes ni la asignación oportunista por carga. Esas capacidades podrían estudiarse en otros contextos, pero no son un requisito para una automatización empresarial útil.

Extracto. El evento no contiene autoridad para actuar. Solo aporta una causa posible; la autoridad procede de la suscripción, la identidad, la política y, cuando corresponde, la aprobación humana.

El patrón evento-condición-acción, revisado para agentes

Las reglas de tipo evento-condición-acción —ECA, por sus siglas en inglés— separan tres preguntas: qué ha sucedido, si se cumplen los criterios y qué debe hacerse. La literatura sobre bases de datos activas formalizó este patrón mucho antes de los agentes basados en modelos de lenguaje [1]. Su utilidad permanece, pero la condición ya no siempre es una expresión determinista.

En un sistema agéntico pueden coexistir dos clases de condición:

• declarativa, cuando basta con comparar el tipo, el origen o determinados atributos normalizados;
• semántica, cuando hay que estimar si un texto o un conjunto de novedades cumple una intención expresada en lenguaje natural.

La condición semántica introduce incertidumbre. Por ello no debe confundirse su veredicto con un hecho probado ni su confianza con una probabilidad calibrada. El resultado es una decisión operacional que necesita trazabilidad, pruebas con casos reales y límites de impacto.

Una sola vía de activación

El principio central es deliberadamente sencillo:

Todo disparo termina en un mensaje persistente depositado en el buzón del agente destino.

El sistema de eventos no constituye un segundo motor de ejecución. Funciona como productor de mensajes con causa. Después de la entrega, el trabajo sigue el ciclo normal del agente: adquisición de la tarea, control de concurrencia, aplicación de políticas, medición, reintentos y registro del resultado.

Esta decisión concentra varios invariantes en un único límite:

• una activación puede reclamarse mediante un lease y recuperarse si el ejecutor desaparece;
• la entrega y el procesamiento conservan identidades idempotentes;
• la genealogía de la solicitud permite detectar reentradas y ciclos;
• el contexto de usuario, tenant, modelo y coste no se reconstruye de forma distinta para cada origen;
• las pausas, aprobaciones y fallos siguen siendo observables desde las mismas superficies operativas.

Un lease no garantiza por sí solo una ejecución exactamente una vez. Reduce el solapamiento y permite reclamar trabajo abandonado, pero un poseedor obsoleto puede continuar después de una partición o una expiración. Por eso el diseño asume entrega al menos una vez y exige comprobación de propiedad antes del efecto, tokens de cercado o confirmaciones condicionales cuando la tecnología lo permita e idempotencia de extremo a extremo [9].

Un sobre común para fuentes diferentes

Cada productor traduce su señal a un sobre normalizado. CloudEvents ofrece un precedente consolidado para expresar metadatos comunes —identificador, fuente, tipo y momento— con independencia del transporte [2]. La propuesta de ALLAN se alinea conceptualmente con esa separación, sin afirmar compatibilidad formal hasta que exista una implementación y una prueba de conformidad.

El sobre necesita, como mínimo:

Campo conceptual	Función
Identidad del evento	Diferenciar una ocurrencia y sostener la trazabilidad.
Ámbito	Identificar tenant y, cuando corresponda, contexto de usuario.
Fuente y tipo	Clasificar quién produjo la señal y qué significa.
Momento de ocurrencia	Distinguir el hecho de su recepción o procesamiento.
Carga normalizada	Transportar los datos mínimos necesarios para evaluar y actuar.
Evidencia	Conservar los fragmentos que justificaron una condición semántica.
Clave de deduplicación	Reconocer reenvíos de la misma ocurrencia lógica.
Genealogía	Mantener la causa cuando el evento procede de actividad agéntica.

La carga debe ser pequeña. Los artefactos voluminosos se referencian, no se copian. Esta regla reduce duplicación, limita la exposición de datos y permite que las políticas de acceso sigan aplicándose en el repositorio de origen.

Familias de eventos

La taxonomía se organiza por espacios de nombres estables. El nombre concreto puede evolucionar, pero la separación de fuentes facilita políticas y pruebas específicas.

Tiempo

Incluye ocurrencias únicas y recurrencias. Una programación debe conservar la zona horaria y definir cómo trata los cambios de horario estacional. Para intercambio de calendarios, RFC 5545 especifica iCalendar y sus reglas de recurrencia [3]. Adoptar sus conceptos evita inventar una semántica temporal incompatible, aunque una implementación inicial pueda exponer un subconjunto más limitado.

Calendario

Una activación puede quedar anclada a un objeto fechado —por ejemplo, una tarea o una reunión— con un desplazamiento anterior o posterior. Si cambia la fecha del ancla, la programación debe recalcularse; si desaparece, el sistema no debería ejecutar silenciosamente una tarea huérfana.

Plataforma

Los cambios internos ya conocidos por el sistema pueden producir señales: la finalización de un run, un hito de flujo, la resolución de una aprobación o un cambio en el espacio de trabajo. Son eventos de dominio, no llamadas directas al agente.

Webhook

Un sistema externo puede enviar una notificación autenticada. La autenticidad del transporte no convierte el contenido en una instrucción fiable: confirma quién envió el mensaje, no que todos sus datos sean benignos o correctos.

Fuentes MCP

Una conexión MCP puede consultar periódicamente operaciones que la allow-list y la policy del conector limitan a solo lectura, y transformar las novedades en candidatos. Una anotación MCP ayuda a describir la operación, pero no constituye por sí sola una frontera de autorización [8]. La suscripción no amplía los derechos del conector ni los de la persona propietaria. Correo, archivos u otras fuentes pueden incorporarse más adelante mediante el mismo contrato, sin crear otra ruta de activación.

La suscripción es el contrato operativo

El componente de escucha —listener en el diseño de origen— observa y produce eventos. La suscripción conecta esos eventos con un agente y explica para qué se le despierta. Debe expresar:

• quién la creó y a quién se atribuye;
• qué fuente y tipos acepta;
• qué agente recibirá el trabajo;
• cuál es la instrucción asociada;
• si pertenece a una sesión o espacio de trabajo;
• sus límites temporales y de frecuencia;
• su estado de aprobación y operación.

Los límites pueden incluir enfriamiento entre activaciones, agrupación de novedades, caducidad y un máximo de ocurrencias. Sus valores dependen del caso de uso y del plan operativo; no existe una cuota universal válida para todos los agentes empresariales.

La suscripción no debe ocultarse dentro de un prompt o de una tarea ya ejecutada. Es un objeto de control con identidad, ciclo de vida e historial propios.

Condiciones semánticas en dos etapas

Algunas señales se pueden filtrar por atributos. Otras requieren responder a preguntas como «¿alguno de estos mensajes reclama una devolución?» o «¿ha aparecido una incidencia relevante para este proyecto?». Ejecutar el agente completo ante cada elemento nuevo sería caro y ampliaría innecesariamente la superficie de acción.

La propuesta separa dos etapas:

1. Recogida acotada. El componente de escucha consulta únicamente operaciones de lectura previamente autorizadas, conserva un cursor y selecciona las novedades.
2. Veredicto estructurado. Un evaluador de menor coste recibe el criterio y las novedades delimitadas como datos. Devuelve un booleano, una confianza y la evidencia seleccionada. Solo un veredicto positivo produce el evento que puede activar al agente completo.

Si no hay novedades, no se invoca el evaluador. Si la salida no cumple el esquema, el sistema registra un fallo; no interpreta texto libre ni dispara por defecto. Compartir la observación de una misma fuente entre varias suscripciones también puede evitar consultas duplicadas, siempre que no mezcle ámbitos de identidad o privacidad.

Extracto. Un modelo rápido puede reducir el coste de vigilancia, pero no transforma una condición ambigua en una regla determinista. La prueba manual y el historial de falsos positivos y negativos forman parte del producto.

Todo contenido externo es no confiable

Un correo, una página, un comentario o una respuesta de herramienta puede incluir texto que intente modificar el comportamiento del modelo. OWASP clasifica la inyección de prompt como un riesgo principal y advierte también sobre la agencia excesiva: una salida inesperada resulta más dañina cuanto más amplios son los permisos y las acciones disponibles [4][5].

La separación entre datos e instrucciones debe mantenerse en las dos etapas:

• el criterio pertenece a la suscripción y el contenido observado se delimita como evidencia externa;
• el evaluador no utiliza herramientas y solo puede producir un esquema limitado;
• la allow-list y la policy restringen las fuentes MCP del componente de escucha a lecturas permitidas;
• la evidencia llega al agente marcada como no confiable;
• la activación no concede permisos nuevos al agente destino;
• las acciones de mayor impacto siguen sujetas a política y aprobación.

Estas medidas reducen exposición, pero no demuestran inmunidad. El esquema estructurado puede limitar la forma de salida y aun así contener un veredicto sesgado. Las defensas requieren evaluación adversarial periódica y revisión cuando cambien los modelos, conectores o fuentes.

Idempotencia, ciclos y tormentas

La secuencia de guardas importa. Conviene rechazar pronto una activación que no debe consumir recursos:

1. Deduplicación. Una clave natural identifica la misma ocurrencia lógica aunque el transporte la entregue más de una vez.
2. Guarda de ciclos. La genealogía permite detectar que una cadena vuelve a activar al mismo destinatario; una guarda o policy rechaza la nueva emisión salvo autorización explícita.
3. Presupuesto y derechos de uso. Se comprueba que la activación está permitida y dispone de capacidad.
4. Enfriamiento. Eventos demasiado próximos pueden descartarse o pasar a una agrupación.
5. Agrupación. Varias novedades equivalentes se condensan en una sola solicitud.
6. Entrega. El mensaje entra en el buzón persistente.
7. Detección de tormenta. Un patrón anómalo suspende la suscripción, avisa a su propietario y exige reactivación consciente.

La deduplicación no depende de un único identificador técnico. Una recurrencia puede usar su intervalo temporal; un webhook, una clave aportada por el origen o un resumen estable; una fuente conectada, la identidad del elemento; y un evento de plataforma, la identidad del objeto causante.

Los leases permiten que varias réplicas cooperen sin poseer indefinidamente el mismo trabajo. Tras un fallo, el lease expira y otro ejecutor puede continuar; la deduplicación absorbe la posible repetición lógica. Los efectos sensibles requieren además comprobar que el ejecutor conserva la propiedad —por ejemplo, con un token de cercado (fencing token) o una confirmación condicional— o ser idempotentes. Suspender y avisar es preferible a seguir gastando o a detener una automatización sin explicación.

Plano de control y ejecución

Las definiciones, políticas, estados, estadísticas y auditoría pertenecen al plano de control. La observación de fuentes, la evaluación semántica y la entrega al buzón pertenecen al plano de ejecución. Separarlos impide que el servicio de catálogo tenga que interpretar contenido o llamar a modelos para administrar una suscripción.

Esta separación también aclara los fallos. Una interrupción temporal del plano de control puede impedir cambios administrativos sin detener de inmediato la observación de bajo riesgo que ya estaba autorizada. Esa continuidad debe tener vigencia acotada, fijar una versión de policy y revalidarse antes de un efecto sensible; no puede convertir una caída en autorización indefinida. A la inversa, disponer del catálogo no garantiza que una fuente externa o un evaluador estén operativos. Cada plano necesita un estado visible y una recuperación propia.

La programación temporal debería ser derivable desde las suscripciones. Así, si se pierde el índice operativo de próximas ejecuciones, puede reconstruirse sin alterar la fuente de verdad. Los cursores de fuentes externas requieren un tratamiento más cuidadoso: perderlos puede provocar repeticiones o una ventana de datos no observada, y esa limitación debe quedar documentada.

Gobernanza: quién puede despertar a quién

La capacidad de crear suscripciones no debe equivaler a acceso universal a los agentes. El diseño parte de estas reglas:

• una persona puede suscribir un agente cuando dispone del grant específico de uso o suscripción, del derecho de uso aplicable y de capacidad; la mera visibilidad no basta;
• un agente puede solicitar una suscripción para sí mismo si tiene la capacidad habilitada;
• la suscripción de un agente a otro nace denegada por defecto y requiere una política explícita del tenant;
• crear una escucha semántica exige, además, acceso al conector y a sus operaciones de lectura;
• una suscripción creada por un agente puede nacer pendiente de aprobación según el nivel de autonomía y el riesgo de la tarea.

La aprobación convierte la escalada de autonomía en una decisión de política, no en un cambio improvisado del runtime. Rechazarla también debe producir un resultado visible y explicable para el agente solicitante.

Este enfoque coincide con el principio de limitar permisos y autonomía que OWASP formula frente a la agencia excesiva [5], y con el tratamiento continuo del riesgo que propone NIST AI RMF 1.0 mediante las funciones de gobernar, mapear, medir y gestionar [6]. No implica conformidad automática con ninguno de esos marcos: son referencias para evaluar el diseño y sus controles.

La automatización tiene que poder verse y probarse

Una automatización invisible parece autónoma incluso cuando nació de una orden humana. La superficie de gestión debería mostrar, por agente:

• estado y origen de cada suscripción;
• próxima activación cuando pueda calcularse;
• últimos eventos, veredictos y evidencias;
• resultado de la entrega y enlace al run causado;
• causa de suspensión o caducidad;
• acciones para pausar, reanudar, editar y eliminar.

La opción probar ahora es especialmente importante para condiciones semánticas. Ejecuta la observación y muestra el veredicto con su evidencia, pero no activa al agente. Permite ajustar el criterio antes de incurrir en acciones, coste o notificaciones. La prueba también debe medirse: que no produzca un run no significa que carezca de consumo.

El trabajo sobre ambient agents de LangChain describe agentes que escuchan flujos de eventos y solicita intervención humana mediante patrones de notificación, pregunta o revisión [7]. Es una referencia de práctica industrial y un blog de proveedor, no un estándar ni evidencia independiente de eficacia. Su principal coincidencia con esta propuesta es de interacción: la actividad en segundo plano necesita una interfaz explícita para conservar la confianza.

Fallar de forma visible

La proactividad multiplica los fallos que pueden ocurrir sin una persona ante la pantalla. El diseño debe convertirlos en estados operativos:

Fallo	Respuesta esperada
La fuente o el evaluador falla	Reintento acotado con backoff; suspensión y aviso tras fallos persistentes.
El veredicto no cumple el esquema	Error de evaluación; nunca activación por defecto.
El ejecutor desaparece	Expiración del lease, recuperación por otra réplica y deduplicación.
Se pierde un índice temporal derivado	Reconstrucción desde las suscripciones.
Se supera el presupuesto	Suspensión explicada, no consumo silencioso.
Se detecta una tormenta	Pausa automática, historial causal y reactivación manual.
El mensaje no puede procesarse	Estado terminal visible y notificación al propietario.

La observabilidad debe unir suscripción, evento, evaluación, mensaje y run. Un contador agregado es útil para capacidad, pero no basta para explicar por qué se despertó un agente ni qué evidencia vio.

Límites de la propuesta

Este cuaderno edita un borrador arquitectónico local, no una descripción de funcionalidad disponible. No se ha verificado una implementación completa, su rendimiento ni su comportamiento bajo ataques reales. En particular:

• un evaluador semántico puede producir falsos positivos y falsos negativos;
• separar datos e instrucciones reduce riesgo, pero no elimina la inyección de prompt;
• un webhook autenticado no demuestra la veracidad de su carga;
• la entrega al menos una vez exige que las acciones posteriores también sean idempotentes o compensables;
• las zonas horarias, recurrencias y modificaciones de calendario requieren pruebas específicas;
• la evidencia almacenada puede contener datos personales o confidenciales y necesita minimización, retención y controles de acceso;
• los umbrales de tormenta, enfriamiento y presupuesto deben calibrarse con uso real, no copiarse entre organizaciones;
• la disponibilidad del sistema de eventos no equivale a cumplimiento de un objetivo de negocio.

Antes de considerar la propuesta consolidada, sería necesario ensayar al menos repeticiones de entrega, caídas durante la renovación de leases, ciclos entre agentes, cambios de zona horaria, pérdida de cursores, inyección indirecta, agotamiento de presupuesto y revocación de permisos.

Conclusión

Un agente empresarial puede estar atento sin volverse soberano. La condición es que la plataforma no confunda escuchar con obedecer, ni un evento con una autorización. El sobre normalizado permite integrar fuentes heterogéneas; la suscripción conserva intención y límites; el buzón unifica la activación; y la política mantiene a la persona dentro del sistema de decisión.

La aportación principal no es una nueva clase de agente, sino una disciplina de operación: proactividad visible, acotada, medible, recuperable y revocable.

Referencias internas

1. ALLAN. Sistema de eventos y triggering de agentes — Diseño arquitectónico. Platform Server/docs/event-triggering-design.md, borrador local no versionado consultado el 20 de julio de 2026. Fuente principal de esta edición pública; su estado documental no constituye evidencia de implementación.
2. ALLAN. Agent-to-agent communication — Architectural design. Platform Server/docs/agent-communication-design.md. Contratos de buzón, genealogía, política y comunicación entre agentes.
3. ALLAN. Agent Registry Service — Technical design. Platform Server/docs/agent-registry-service-design.md. Separación entre catálogo, gobernanza y ejecución.
4. ALLAN. Metering and subscriptions design. Platform Server/docs/metering-and-subscriptions-design.md. Medición, atribución y límites de uso.
5. ALLAN. Intelligent wait and supervision design. docs/intelligent-wait-supervision-design.md. Leases, espera recuperable y supervisión de trabajo persistente.

Referencias externas

1. Tan, C. W. y Goh, A. E. S. (1999). «Implementing ECA rules in an active database». Knowledge-Based Systems, 12(4), 137–144. doi:10.1016/S0950-7051(99)00028-3.
2. Cloud Native Computing Foundation (2022). CloudEvents Specification, versión 1.0.2. Repositorio oficial de la versión 1.0.2 y sitio del proyecto.
3. Desruisseaux, B. (ed.) (2009). Internet Calendaring and Scheduling Core Object Specification (iCalendar). RFC 5545, IETF. RFC 5545.
4. OWASP GenAI Security Project (2025). LLM01:2025 Prompt Injection. Ficha oficial.
5. OWASP GenAI Security Project (2025). LLM06:2025 Excessive Agency. Ficha oficial.
6. National Institute of Standards and Technology (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. Publicación oficial.
7. LangChain (2025). «Introducing ambient agents». Blog de proveedor. Publicación original.
8. Model Context Protocol (2025). Tools, especificación estable 2025-11-25. Las anotaciones se describen como indicios que no deben considerarse fiables salvo que también lo sea el servidor. Especificación oficial.
9. Gray, C. y Cheriton, D. (1989). «Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency». Proceedings of the 12th ACM Symposium on Operating Systems Principles. Publicación original.