Agentes de sondeo en asistentes de IA: 11 patrones de implementación

Los agentes de sondeo (polling agents) son una de las partes menos glamurosas de la arquitectura de asistentes de IA, pero también son una de las más útiles.

Un asistente de chat normal espera a que el usuario haga una pregunta. Un agente de sondeo mantiene la vigilancia. Verifica una fuente, nota los cambios, decide si algo es importante y luego actúa. Esa acción puede ser una notificación, un resumen, un borrador, una llamada a una herramienta o un flujo de trabajo completo.

Así es como un asistente pasa de «responde mi pregunta» a «mantén un ojo en esto por mí». En lugar de ser reactivo, se convierte en un proceso en segundo plano que nota cosas en nombre del usuario y actúa cuando se cumplen las condiciones.

El punto de diseño importante es simple: no hagas responsable al modelo de lenguaje del tiempo, el estado, los reintentos o el bloqueo. Usa la infraestructura de backend normal para eso. Usa el modelo donde es valioso: interpretando contextos desordenados, tomando decisiones semánticas y produciendo lenguaje útil.

¿Qué es un Agente de Sondeo?

Un agente de sondeo es un proceso en segundo plano que verifica repetidamente una fuente y desencadena una acción del asistente cuando se cumple una condición. En el conjunto más amplio de Sistemas de IA — donde el asistente combina un LLM, memoria, herramientas, enrutamiento y observabilidad — la capa de sondeo es lo que hace que el asistente sea proactivo en lugar de puramente reactivo. Para ver el panorama completo de cinco capas, consulta Arquitectura de Asistentes de IA: LLM, Memoria, Herramientas, Enrutamiento, Observabilidad.

Ejemplos:

• Verificar una bandeja de entrada cada mañana y resumir los mensajes importantes.
• Vigilar una lista de tareas de Notion y ejecutar el siguiente elemento pendiente.
• Monitorear un problema de GitHub hasta que cambie de estado.
• Realizar sondeo a un trabajo de IA de larga ejecución hasta que el resultado esté listo.
• Verificar una franja de reserva hasta que haya una disponible.
• Vigilar un portal de proveedores hasta que aparezca un documento.
• Escanear nuevos papers de investigación una vez por semana y resumir los relevantes.

Un agente de sondeo práctico tiene cinco responsabilidades:

1. Despertarse en el momento adecuado.
2. Leer de la fuente.
3. Recordar lo que ya ha visto.
4. Decidir si el nuevo estado importa.
5. Actuar una vez, de forma segura, sin repetirse.

Un flujo de producción típico se ve así:

programador
  -> trabajador de sondeo
  -> sistema fuente
  -> almacén de estado
  -> filtros deterministas
  -> evaluación de LLM opcional
  -> acción del asistente

Esta estructura es aburrida de la mejor manera posible. Los sistemas aburridos son más fáciles de depurar a las 2 de la madrugada.

El Estado que Todo Agente de Sondeo Necesita

Los agentes de sondeo necesitan un estado duradero. El historial de conversación no es suficiente. El asistente puede recordar la conversación, pero el sistema necesita un registro operativo fiable.

Un buen registro de estado de sondeo suele contener:

{
  "poll_id": "poll_123",
  "user_id": "user_456",
  "source_type": "notion",
  "source_ref": "database_tasks",
  "condition": "tomar una tarea en estado Pendiente y ejecutarla",
  "interval_seconds": 600,
  "last_run_at": "2026-06-19T01:00:00Z",
  "next_run_at": "2026-06-19T01:10:00Z",
  "last_seen_cursor": "cursor_o_timestamp",
  "last_result_hash": "b64e8a...",
  "failure_count": 0,
  "status": "active"
}

El esquema exacto depende de la fuente, pero la mayoría de los sistemas necesitan estos conceptos.

Definición de Sondeo

Esto describe qué está observando el agente y por qué.

poll_id
user_id
workspace_id
source_type
source_ref
condition_text
priority
status

Por ejemplo:

source_type: notion
source_ref: base de datos de tareas
condition_text: Encontrar una tarea Pendiente, reclamarla, ejecutarla y marcarla como Completada.

Programación

Esto describe cuándo debe ejecutarse el agente.

interval_seconds
cron_expression
timezone
last_run_at
next_run_at
jitter

Para un agente de Hermes que verifica Notion cada 10 minutos:

interval_seconds: 600
timezone: Australia/Melbourne

Cursor o Instantánea

Esto ayuda al agente a evitar reprocesar los mismos datos.

Dependiendo de la fuente, esto puede ser:

last_seen_id
last_seen_timestamp
api_cursor
etag
version
content_hash

Para una cola de tareas de Notion, el cursor puede ser menos importante que el estado de la tarea y los campos de reclamación. Para Gmail, GitHub o una API de sincronización, el cursor suele ser crítico.

Reclamación o Arrendamiento

Esto evita que dos trabajadores tomen el mismo trabajo.

claimed_by
claimed_at
claim_expires_at
run_id

Por ejemplo, una tarea de Notion puede cambiar de:

Estado: Pendiente

a:

Estado: EnProgreso
ReclamadoPor: hermes
ReclamadoEn: 2026-06-19T01:00:00Z
ExpiraciónDeReclamación: 2026-06-19T01:30:00Z
RunId: run_789

Esta es la diferencia entre «espero que solo un trabajador lo tome» y «el sistema tiene un protocolo de reclamación».

Registro de Ejecución

Esto registra lo que ocurrió durante una ejecución.

run_id
poll_id
source_object_id
started_at
finished_at
status
items_checked
items_changed
decision_summary
error

El registro de ejecución debe vivir en el backend del asistente, no solo en Notion u otra herramienta externa. Notion es bueno para la visibilidad humana. No es ideal como único registro de ejecución.

Registro de Deduplicación

Esto evita notificaciones duplicadas o acciones repetidas.

dedupe_key
poll_id
source_object_id
condition_version
action_type
delivered_at

Por ejemplo:

user_456:poll_123:notion_page_999:execute:v1

Si se intenta la misma acción nuevamente, el sistema puede suprimirla.

Método 1: Trabajador de Sondeo Programado

Este es el patrón más simple y fiable.

Un programador despierta cada intervalo fijo y llama a un trabajador. El trabajador lee la fuente, actualiza el estado y desencadena una acción del asistente si es necesario.

programador
  -> trabajador
  -> API de fuente
  -> base de datos
  -> acción del asistente

Cómo se Ejecuta

El programador es responsable del tiempo. Puede ser cron, un programador en la nube, un CronJob de Kubernetes o un pequeño programador interno.

Cada intervalo, inicia una ejecución del trabajador. El trabajador carga su configuración, consulta la fuente objetivo, compara el resultado con el estado almacenado y actúa si es necesario.

Para un asistente simple, esto suele ser suficiente. Un único programador y un proceso de trabajador ligero pueden manejar docenas de verificaciones diarias sin necesidad de colas, arrendamientos o coordinación distribuida.

Modelo de Estado

El programador almacena muy poco. Por lo general, solo sabe cuándo desencadenar un trabajo.

La base de datos de la aplicación almacena el estado importante:

definición de sondeo
programación
cursor o instantánea
último tiempo de ejecución
conteo de fallos
estado

El trabajador debe ser sin estado. Puede contener datos temporales mientras se ejecuta, pero la verdad duradero pertenece a la base de datos.

Flujo de Ejemplo

Cada 10 minutos:
  activar trabajador de sondeo de Hermes

Trabajador:
  cargar configuración de sondeo activo
  consultar fuente
  comparar con estado anterior
  ejecutar comprobaciones deterministas
  llamar al LLM solo si es necesario
  actualizar estado
  emitir evento del asistente

Mejor Aplicación

Usa trabajadores de sondeo programados para:

• Resúmenes diarios.
• Verificaciones horarias.
• Automatizaciones internas pequeñas.
• Tareas simples de «vigilar esto».
• Trabajos de asistente de volumen bajo a medio.

Debilidades

El sondeo programado es fácil de entender, pero puede volverse frágil a gran escala. Si muchos sondeos se ejecutan al mismo tiempo, puede sobrecargar a tus trabajadores o alcanzar los límites de tasa del proveedor. Los reintentos también pueden volverse desordenados si el programador inicia el trabajo directamente.

Método 2: Trabajadores de Sondeo Basados en Cola

El sondeo basado en cola suele ser la opción predeterminada mejor para asistentes de IA en producción.

El programador no ejecuta el sondeo directamente. Pone un trabajo en una cola. Los procesos de trabajador consumen trabajos de la cola.

programador
  -> cola
  -> grupo de trabajadores
  -> API de fuente
  -> almacén de estado
  -> acción del asistente

Cómo se Ejecuta

Un programador busca sondeos vencidos y pone trabajos en cola. Los trabajadores extraen trabajos cuando tienen capacidad.

Esto te da contrapresión. Si el sistema está ocupado, los trabajos esperan en la cola en lugar de abrumar la API de la fuente o el proveedor de LLM.

Modelo de Estado

La base de datos almacena el estado del sondeo:

poll_id
user_id
source_ref
condition_text
next_run_at
cursor
status
failure_count

El mensaje de la cola debe mantenerse pequeño:

{
  "poll_id": "poll_123",
  "scheduled_for": "2026-06-19T01:10:00Z",
  "attempt": 1
}

El trabajador carga el estado completo de la base de datos cuando comienza.

Flujo de Ejemplo

Cada minuto:
  el programador encuentra sondeos donde next_run_at <= ahora
  el programador pone trabajos en cola

Trabajadores:
  extraer trabajos de la cola
  bloquear o arrendar el sondeo
  consultar la fuente
  actualizar estado
  emitir acción del asistente si es necesario
  establecer next_run_at

Mejor Aplicación

Usa sondeo basado en cola para:

• Asistentes de IA multiusuario.
• Muchos sondeos simultáneos.
• Integraciones con límites de tasa.
• Trabajo en segundo plano reintentable.
• Trabajos que pueden tomar diferentes cantidades de tiempo.
• Productos SaaS donde la fiabilidad importa.

Debilidades

Las colas añaden infraestructura. Necesitas manejo de cartas muertas, idempotencia, tiempos de visibilidad y políticas de reintento. Esto vale la pena para sistemas de producción, pero probablemente sea excesivo para un pequeño prototipo.

Método 3: Herramienta Externa como Cola de Tareas

Este es el patrón en el ejemplo de Notion más Hermes.

La herramienta externa no es solo una fuente de datos. Se convierte en la cola de tareas orientada al humano. El agente verifica periódicamente la herramienta, reclama una tarea, la ejecuta y actualiza el estado de la tarea.

programador
  -> trabajador de Hermes
  -> base de datos de Notion
  -> reclamar una tarea
  -> ejecutar tarea
  -> actualizar estado de Notion

Cómo se Ejecuta

Cada 10 minutos, Hermes consulta la base de datos de Notion para una tarea en estado Pendiente. Elige la siguiente tarea, generalmente por prioridad y tiempo de creación. Luego reclama la tarea estableciéndola en EnProgreso.

Después de eso, Hermes ejecuta la tarea. Si la ejecución tiene éxito, marca la tarea como Completada. Si la ejecución falla, marca la tarea como Fallida o la devuelve a Pendiente con un conteo de reintento.

Modelo de Estado

Notion almacena el estado de la tarea orientado al humano:

Título
Descripción
Estado: Pendiente | EnProgreso | Completada | Fallida
Prioridad
CreadoEn
ReclamadoPor
ReclamadoEn
ExpiraciónDeReclamación
RunId
RetryCount
LastError
CompletadoEn

El backend de Hermes almacena el estado de ejecución operativo:

run_id
notion_page_id
started_at
finished_at
execution_status
tool_calls
LLM trace
error details
idempotency_key

Esta división importa. Notion es excelente para visibilidad y edición manual. El backend de Hermes es mejor para registros, reintentos, deduplicación e historial de auditoría.

Flujo de Ejemplo

Cada 10 minutos:
  Hermes despierta

Hermes:
  consultar Notion para una tarea donde Estado = Pendiente
  ordenar por Prioridad, CreadoEn
  actualizar tarea seleccionada a EnProgreso
  establecer ReclamadoPor, ReclamadoEn, ExpiraciónDeReclamación, RunId
  ejecutar la tarea
  escribir registro de ejecución
  establecer tarea como Completada o Fallida

Mejor Aplicación

Usa este patrón cuando:

• Los humanos ya gestionan el trabajo en Notion, Jira, Linear, Trello u otra herramienta.
• Quieres que el asistente procese tareas visibles.
• El tablero de tareas es la interfaz de usuario.
• Necesitas un modelo de automatización simple con humano en el bucle.

Debilidades

Las herramientas externas rara vez son colas perfectas. Las reclamaciones atómicas pueden ser limitadas. La consistencia de consulta puede retrasarse. Pueden aplicarse límites de tasa. Si el agente puede ejecutarse en múltiples instancias, necesitas una estrategia de reclamación o arrendamiento cuidadosa.

La recomendación práctica es usar Notion como la bandeja de entrada de tareas orientada al humano mientras se mantienen todos los registros de ejecución, registros de reintento, trazas y claves de idempotencia en Hermes. Notion da a los usuarios visibilidad; Hermes mantiene el sistema fiable. Para los mecanismos de despachador y concurrencia que están detrás de este patrón en Hermes, consulta Kanban en Hermes Agent para Flujos de Trabajo de LLM Autohospedados.

Método 4: Bucle de Trabajador de Larga Ejecución

Un bucle de larga ejecución es la implementación más simple.

while True:
    due_polls = db.find_due_polls()
    for poll in due_polls:
        run_poll(poll)
    sleep(30)

Este patrón combina programación y ejecución en un solo servicio, lo que lo convierte en el punto de inicio más simple posible para el trabajo de agente en segundo plano.

Cómo se Ejecuta

El proceso de trabajador se ejecuta continuamente. Cada pocos segundos o minutos, verifica la base de datos en busca de sondeos vencidos y los ejecuta. Es fácil de construir, fácil de razonar y rápido de iterar durante el desarrollo.

Modelo de Estado

La base de datos sigue almacenando estado duradero:

configuración de sondeo
next_run_at
cursor
último resultado
conteo de fallos
estado

La memoria del proceso solo debe contener estado temporal:

lote actual
caché de corta vida
ejecución en vuelo

Nunca almacenes progreso importante solo en memoria. Si el proceso falla, cualquier estado que no se haya escrito en almacenamiento duradero se pierde, y la siguiente ejecución no tendrá manera de saber dónde se quedó.

Mejor Aplicación

Usa bucles de larga ejecución para:

• Prototipos.
• Desarrollo local.
• Herramientas internas.
• Sistemas de inquilino único.
• Agentes de bajo volumen.

Debilidades

Este patrón se vuelve arriesgado con múltiples réplicas. Sin arrendamientos, dos trabajadores pueden ejecutar el mismo sondeo. También carece de las características operativas de una cola o motor de flujo de trabajo real.

Un bucle de larga ejecución no está mal como punto de partida, pero no es un programador distribuido y no debe tratarse como tal. Tan pronto como necesites múltiples réplicas o garantías de fiabilidad más fuertes, necesitarás pasar a uno de los patrones más estructurados anteriores.

Método 5: Webhook Primero con Fallback de Sondeo

Si la fuente soporta webhooks, úsalos. El sondeo debería a menudo ser el respaldo, no el mecanismo principal. La misma división aparece en el diseño del protocolo de agente: las notificaciones push A2A despiertan un manejador de cliente, que luego realiza sondeo a GetTask para obtener el estado completo, como se describe en A2A Streaming y Tareas Async para Flujos de Trabajo de Agentes de Larga Ejecución.

sistema externo
  -> punto final de webhook
  -> almacén de eventos
  -> acción del asistente

sondeo de reconciliación
  -> API de fuente
  -> comparar con almacén de eventos
  -> reparar eventos perdidos

Cómo se Ejecuta

El sistema externo envía eventos a tu punto final de webhook cuando algo cambia. Tu sistema almacena el evento y lo procesa asíncronamente.

Un sondeo de reconciliación más lento se ejecuta cada pocas horas o una vez al día. Verifica si se perdieron algunos eventos.

Modelo de Estado

El almacén de eventos registra los webhooks entrantes:

event_id
source_type
source_object_id
event_type
received_at
payload_hash
processed_at
signature_valid

El sondeo de reconciliación almacena:

last_reconciliation_at
last_seen_cursor
last_seen_version

La tabla de objetos fuente almacena el último estado conocido:

external_id
current_status
external_updated_at
last_processed_event_id

Mejor Aplicación

Usa arquitectura webhook primero para:

• Eventos de GitHub.
• Eventos de Stripe.
• Eventos de Slack.
• Actualizaciones de CRM.
• Notificaciones de despliegue.
• Sistemas de ticketing.

Debilidades

Los webhooks requieren un punto final público, validación de firma, protección contra repetición y deduplicación de eventos. Algunos proveedores también envían eventos incompletos, por lo que aún puede ser necesario obtener el objeto completo.

Aun así, si existen buenos webhooks, sondear cada minuto suele ser un desperdicio.

Método 6: Sondeo de Trabajos en Segundo Lado del Proveedor

A veces, lo que se está sondeando es el trabajo de IA en sí.

La aplicación inicia un trabajo de larga ejecución del proveedor, almacena el ID del trabajo y verifica más tarde si se ha completado.

app
  -> iniciar trabajo en segundo plano de IA
  -> almacenar ID de trabajo del proveedor
  -> sondear estado
  -> obtener resultado
  -> notificar usuario

Cómo se Ejecuta

El asistente inicia un trabajo con el proveedor. El proveedor devuelve un ID. Tu backend almacena ese ID y verifica su estado hasta que el trabajo tenga éxito, falle, expire o se agote el tiempo.

Modelo de Estado

Tu backend almacena:

assistant_task_id
provider_job_id
user_id
status
created_at
last_checked_at
expires_at
result_ref

El proveedor almacena el estado temporal del trabajo y la salida.

Si la salida importa, cópiala en tu propio almacenamiento duradero tan pronto como se complete el trabajo. El almacenamiento de resultados del lado del proveedor tiene ventanas de retención cortas y no es un sustituto de un archivo adecuado en tu propio sistema.

Mejor Aplicación

Usa sondeo de trabajos en segundo plano del lado del proveedor para:

• Tareas de investigación de IA largas.
• Procesamiento de documentos grandes.
• Análisis de base de código.
• Generación de informes.
• Trabajos de extracción de datos.
• Tareas que exceden los tiempos de espera normales de solicitudes HTTP.

Debilidades

Este patrón resuelve un problema: esperar un trabajo largo del proveedor. No reemplaza tu motor de flujo de trabajo, programador, cola o almacén de estado de negocio.

Método 7: Motor de Flujo de Trabajo Duradero

Un motor de flujo de trabajo duradero gestiona la ejecución de larga duración, temporizadores, reintentos y recuperación. Temporal es la opción más común para backends de asistentes basados en Go y Python; para una guía de implementación completa, consulta Implementando Aplicaciones de Flujo de Trabajo con Temporal en Go.

En lugar de cablear manualmente cada espera y reintento, modelas el proceso como un flujo de trabajo.

motor de flujo de trabajo
  -> actividad: verificar fuente
  -> temporizador: esperar
  -> actividad: evaluar resultado
  -> actividad: notificar usuario

Cómo se Ejecuta

El flujo de trabajo comienza una vez y luego controla su propia espera. Puede dormir durante minutos, días o semanas. Si el proceso de trabajador falla, el motor de flujo de trabajo puede reanudar desde el estado registrado.

Modelo de Estado

El motor de flujo de trabajo almacena:

workflow_id
historial de ejecución
estado del temporizador
intentos de actividad
política de reintento
estado actual del flujo de trabajo

Tu base de datos de la aplicación almacena:

definición de sondeo orientada al usuario
referencias de autorización
registros de negocio
registros de notificación

El motor de flujo de trabajo es dueño del estado del proceso: historial de ejecución, temporizadores, reintentos e intentos de actividad. Tu base de datos es dueña del estado de negocio: configuraciones de usuario, registros de autorización, notificaciones y registros de auditoría. Mantener estos separados evita que cada capa se convierta en un híbrido confundido de ambos.

Mejor Aplicación

Usa flujos de trabajo duraderos para:

• Procesos de negocio de múltiples pasos.
• Automatizaciones de larga ejecución.
• Flujos de aprobación humana.
• Reintentos fiables.
• Trabajo en segundo plano auditable.
• Procesos que deben reanudarse después de un fallo.

Debilidades

Los motores de flujo de trabajo añaden conceptos e infraestructura. Son excelentes cuando el proceso es importante, pero pesados para verificaciones horarias simples.

Método 8: Runtime de Agente Persistente

Algunos marcos de trabajo de agentes pueden persistir el estado del agente, hacer checkpoint de la ejecución y reanudar más tarde.

Esto es útil cuando el agente en sí tiene un proceso de razonamiento de múltiples pasos.

programador o flujo de trabajo
  -> runtime de agente
  -> cargar checkpoint
  -> llamar herramientas
  -> guardar checkpoint
  -> reanudar más tarde

Cómo se Ejecuta

Un programador externo o flujo de trabajo inicia el agente. El runtime del agente carga el estado anterior, ejecuta el siguiente paso, llama a herramientas si es necesario y escribe un checkpoint.

El runtime del agente no debe ser tu único programador. Es mejor tratarlo como la capa de razonamiento dentro de una arquitectura de backend más grande.

Modelo de Estado

El almacenamiento de checkpoint del agente contiene:

nodo actual
mensajes
salidas de herramientas
estado de razonamiento intermedio
acción pendiente

La memoria a largo plazo contiene:

preferencias estables del usuario
hechos
contexto del proyecto
referencias de fuente

El estado operativo todavía pertenece en otro lugar:

programación de sondeo
cursor
estado
conteo de reintento
registros de deduplicación

Una regla útil: la memoria no es un cursor, y un checkpoint no es una cola. La memoria del agente almacena lo que el modelo sabe; el estado operativo rastrea dónde está el proceso y qué ha hecho. Confluir los dos conduce a errores sutiles que solo aparecen bajo concurrencia o después de un reinicio. El espacio de diseño completo para memoria de trabajo, estado duradero y capas de recuperación se cubre en Sistemas de Memoria en Asistentes de IA.

Mejor Aplicación

Usa runtime de agente persistente para:

• Investigación de múltiples pasos.
• Agentes que pausan y reanudan.
• Trabajo con humano en el bucle.
• Razonamiento pesado en herramientas.
• Tareas donde el contexto se acumula con el tiempo.

Debilidades

La persistencia del agente no es lo mismo que la fiabilidad operativa. Aún necesitas programación, bloqueo, reintentos, límites de tasa y registros de auditoría.

Método 9: Sincronización de Base de Datos Más Evaluación de Cambios

En este patrón, el sondeo se usa para sincronizar datos externos en tu propia base de datos. El asistente luego reacciona a los cambios locales de la base de datos en lugar de consultar APIs externas directamente en cada ciclo de evaluación.

sondeador de sincronización
  -> API externa
  -> base de datos local
  -> evaluador de cambios
  -> acción del asistente

Esto separa la sincronización de datos de la inteligencia del asistente. El trabajador de sincronización es responsable de mantener los registros locales actualizados; el evaluador es responsable de decidir qué hacer con los cambios. Cada capa puede ser probada, monitoreada y escalada de forma independiente.

Cómo se Ejecuta

El trabajador de sincronización busca periódicamente cambios externos y escribe registros normalizados en tu base de datos. Un segundo trabajador o flujo de cambios detecta filas actualizadas y decide si el asistente debe actuar.

Modelo de Estado

La tabla de sincronización almacena:

external_id
source_type
raw_payload
normalized_fields
external_updated_at
synced_at
version
content_hash

El estado de sincronización almacena:

source_cursor
last_sync_at
rate_limit_status
failure_count

La tabla de evaluación del asistente almacena:

object_id
evaluation_status
last_evaluated_hash
decision
notification_id

Mejor Aplicación

Usa este patrón para:

• Sincronización de CRM.
• Sistemas de ticketing.
• Documentos contables.
• Inventario de productos.
• Revisión de cumplimiento.
• Indexación de búsqueda.
• Paneles de control internos.

Debilidades

Sincronizar todo puede ser costoso e innecesario. También puede crear obligaciones de privacidad y retención. Usa este patrón cuando los datos locales tengan valor más allá de una sola acción del asistente.

Método 10: Sondeo Adaptativo

El sondeo adaptativo cambia la frecuencia basada en el estado, urgencia o actividad reciente.

objeto activo: sondear cada 1 minuto
objeto esperando: sondear cada 1 hora
objeto obsoleto: sondear una vez por día
objeto completado: dejar de sondear

Cómo se Ejecuta

Después de cada ejecución, el trabajador decide cuándo debería ocurrir la siguiente ejecución.

Si el objeto cambió recientemente, sondea antes. Si nada ha cambiado por mucho tiempo, ralentiza. Si la tarea está completa, detén.

Modelo de Estado

El estado del sondeo incluye:

current_interval
minimum_interval
maximum_interval
backoff_policy
last_activity_at
priority
stop_condition

La instantánea de la fuente incluye:

status
updated_at
activity_level
expected_next_change

Mejor Aplicación

Usa sondeo adaptativo para:

• Estado de despliegue.
• Seguimiento de entregas.
• Disponibilidad de franjas de calendario.
• Monitoreo de precios.
• Trabajos de compilación.
• Tareas de proveedor de larga ejecución.
• Cualquier fuente con actualizaciones intermitentes.

Debilidades

El sondeo adaptativo puede ser más difícil de razonar. Si una tarea debe ejecutarse en un tiempo estricto, manténlo estricto. No hagas trabajos de cumplimiento inteligentes.

Método 11: Sondeo Semántico con un Evaluador de LLM

El sondeo semántico se usa cuando la condición es difusa.

El código puede responder:

¿Es el estado igual a Completado?
¿Es el precio inferior a 100?
¿Hay un nuevo mensaje?

Un LLM puede ayudar a responder:

¿Suena urgente este correo electrónico?
¿Es probable que este cliente esté descontento?
¿Es relevante este paper de investigación?
¿Requiere mi atención este cambio?

Cómo se Ejecuta

El trabajador primero aplica filtros deterministas baratos. Solo los elementos candidatos van al LLM.

¿nuevo elemento?
¿coincide con filtros de fuente?
¿no ya procesado?
¿no obviamente irrelevante?

Entonces el LLM evalúa el conjunto de candidatos más pequeño y devuelve salida estructurada.

{
  "should_notify": true,
  "urgency": "high",
  "reason": "El cliente informa una interrupción de producción."
}

Modelo de Estado

La definición de sondeo almacena:

semantic_condition
examples
negative_examples
user_preference_summary
model_config

El registro de evaluación almacena:

input_reference
model
prompt_version
structured_output
confidence
cost
latency

El estado del sondeo almacena:

last_seen_ids
last_evaluated_hashes
last_decision
last_decision_reason

Mejor Aplicación

Usa sondeo semántico para:

• Detección de correos importantes.
• Monitoreo de sentimiento del cliente.
• Alertas de investigación.
• Detección de oportunidades de ventas.
• Triaje de seguridad.
• Resúmenes ejecutivos.

Debilidades

Las llamadas al LLM cuestan dinero y añaden latencia. También pueden ser inconsistentes si los prompts y esquemas son flojos. Usa filtros deterministas primero. Pide al modelo solo cuando realmente se necesite juicio.

Tabla de Decisiones: Eliigiendo un Método de Agente de Sondeo

Arquitectura Predeterminada Recomendada

Para la mayoría de los asistentes de IA en producción, comienza con esto:

tabla de sondeos
  -> programador
  -> cola
  -> trabajadores sin estado
  -> filtros deterministas
  -> evaluador de LLM opcional
  -> notificación o acción del asistente

Un esquema mínimo:

CREATE TABLE polls (
    id TEXT PRIMARY KEY,
    user_id TEXT NOT NULL,
    source_type TEXT NOT NULL,
    source_ref TEXT NOT NULL,
    condition_text TEXT NOT NULL,
    schedule_type TEXT NOT NULL,
    interval_seconds INTEGER,
    timezone TEXT,
    next_run_at TIMESTAMP NOT NULL,
    last_run_at TIMESTAMP,
    cursor_value TEXT,
    last_hash TEXT,
    status TEXT NOT NULL,
    failure_count INTEGER NOT NULL DEFAULT 0,
    last_error TEXT,
    created_at TIMESTAMP NOT NULL,
    updated_at TIMESTAMP NOT NULL
);

CREATE TABLE poll_runs (
    id TEXT PRIMARY KEY,
    poll_id TEXT NOT NULL,
    started_at TIMESTAMP NOT NULL,
    finished_at TIMESTAMP,
    status TEXT NOT NULL,
    items_checked INTEGER,
    items_matched INTEGER,
    decision_summary TEXT,
    error TEXT
);

CREATE TABLE notifications (
    id TEXT PRIMARY KEY,
    poll_id TEXT NOT NULL,
    user_id TEXT NOT NULL,
    dedupe_key TEXT NOT NULL,
    title TEXT NOT NULL,
    body TEXT NOT NULL,
    delivered_at TIMESTAMP,
    UNIQUE (dedupe_key)
);

Esto te da una separación limpia:

el programador es dueño del tiempo
la cola es dueña del amortiguamiento
el trabajador es dueño de la ejecución
la base de datos es dueña del estado
el LLM es dueño del juicio semántico
el asistente es dueño de la interacción del usuario

Esa separación es el corazón de un agente de sondeo fiable.

Ejemplo: Agente Hermes Procesando Tareas de Notion

Ahora apliquemos la arquitectura a un caso concreto.

Asumamos que una base de datos de Notion contiene tareas. Hermes debería ejecutarse cada 10 minutos, tomar una tarea en estado Pendiente, establecerla en EnProgreso, ejecutarla y luego marcarla como Completada.

Esto se describe mejor como:

herramienta externa como cola de tareas
+
trabajador de sondeo programado
+
ejecución basada en reclamación o arrendamiento

Para una versión de producción, se convierte en:

sondeo basado en cola con Notion como la bandeja de entrada de tareas orientada al humano

Propiedades de Tarea de Notion

La base de datos de Notion debería contener campos como:

Nombre
Estado: Pendiente | EnProgreso | Completada | Fallida
Prioridad
CreadoEn
ReclamadoPor
ReclamadoEn
ExpiraciónDeReclamación
RunId
RetryCount
LastError
CompletadoEn

Los campos importantes son ReclamadoEn, ExpiraciónDeReclamación y RunId. Hacen que la reclamación de la tarea sea visible y recuperable.

Estado de Ejecución de Hermes

Hermes también debería mantener su propio registro de ejecución:

run_id
notion_page_id
started_at
finished_at
status
input_snapshot
tool_calls
result_summary
error
idempotency_key

Esto te protege si Notion se edita manualmente, si una llamada a la API falla, o si necesitas auditar qué hizo realmente Hermes.

Flujo de Ejecución

Cada 10 minutos:
  el programador de Hermes crea una ejecución

Trabajador de Hermes:
  encuentra una tarea de Notion donde Estado = Pendiente
  ordena por Prioridad y CreadoEn
  reclama la tarea estableciendo Estado = EnProgreso
  escribe ReclamadoPor, ReclamadoEn, ExpiraciónDeReclamación y RunId
  ejecuta la tarea
  escribe registros de ejecución en el backend de Hermes
  establece Estado de Notion = Completada en éxito
  establece Estado de Notion = Fallida en fallo

Si Hermes falla después de reclamar una tarea, el arrendamiento puede expirar:

Estado = EnProgreso
ExpiraciónDeReclamación < ahora

Una ejecución futura puede entonces recuperar la tarea o marcarla como fallida.

Manejo de Fallos

En éxito:

Estado = Completada
CompletadoEn = ahora
LastError = vacío

En fallo recuperable:

Estado = Pendiente
RetryCount = RetryCount + 1
LastError = mensaje de error corto

En fallo no recuperable:

Estado = Fallida
LastError = explicación clara

Por seguridad, Hermes también debería usar una clave de idempotencia:

notion_page_id + task_version + action_type

Esto evita que la misma tarea se ejecute dos veces si ocurre un reintento en el momento equivocado.

Por Qué Esto No es Solo Sondeo

La parte de sondeo es solo el mecanismo de despertar. La arquitectura real es la reclamación de tareas y la ejecución fiable.

Una implementación ingenua dice:

Cada 10 minutos, encontrar una tarea Pendiente y hacerla.

Una implementación fiable dice:

Cada 10 minutos, reclamar exactamente una tarea elegible, registrar la ejecución, ejecutar de forma idempotente y mover la tarea a un estado terminal.

Esa es la diferencia entre una demostración y un agente en el que puedes confiar.

Errores Comunes de los Agentes de Sondeo

Error 1: Sin Protocolo de Reclamación

Si dos trabajadores pueden ver la misma tarea, ambos pueden ejecutarla.

Usa:

ReclamadoPor
ReclamadoEn
ExpiraciónDeReclamación
RunId

Incluso si actualmente ejecutas un trabajador, diseña como si un segundo trabajador pudiera aparecer más tarde.

Error 2: Sin Clave de Deduplicación

Cada acción externa debería tener una clave de deduplicación.

user_id + poll_id + source_object_id + action_type + condition_version

Esto evita notificaciones repetidas, correos repetidos, ejecución de tareas repetida y llamadas a herramientas repetidas. Los principios más amplios detrás del alcance, almacenamiento y prueba de estas claves se aplican igualmente aquí — consulta Idempotencia en Sistemas Distribuidos que Realmente Funciona.

Error 3: Llamar al LLM Demasiado Temprano

No pidas al modelo que haga filtrado de base de datos.

Mal:

Enviar todas las tareas al LLM y preguntar cuál es Pendiente.

Mejor:

Usar el filtro de la API de Notion para obtener tareas Pendientes.
Entonces usar el LLM solo si se necesita interpretación de la tarea.

Error 4: Tratar Notion como el Único Backend

Notion es una buena interfaz humana. No es un backend de ejecución completo.

Mantén los registros de ejecución, reintentos, trazas y registros de idempotencia en Hermes.

Error 5: Sondeo Infinito

Cada sondeo debería tener una condición de parada.

Ejemplos:

detener después del éxito
detener después de la fecha
detener después de reintentos máximos
detener cuando el usuario lo deshabilita
detener después de fallo de autorización repetido

Un agente de sondeo sin condición de parada es una fuga de costos silenciosa.

Error 6: Sin Observabilidad

Deberías poder responder:

¿Qué ejecutó el agente?
¿Por qué se ejecutó?
¿Qué leyó?
¿Qué cambió?
¿Por qué falló?
¿Notificó al usuario?
¿Se ejecutó dos veces?

Si no puedes responder esas preguntas, el sistema no está listo para trabajo importante.

Lista de Verificación de Observabilidad

Rastrea métricas como:

polls_due
polls_started
polls_succeeded
polls_failed
tasks_claimed
tasks_completed
tasks_failed
claim_expired_count
duplicate_suppressed_count
llm_calls
llm_cost
rate_limit_count
average_run_duration

Registra campos como:

poll_id
run_id
source_type
source_object_id
claim_id
cursor_before
cursor_after
decision
dedupe_key
error

Construye una vista de administrador para:

sondeos activos
tareas EnProgreso atascadas
fallos recientes
tareas de alto reintento
trabajos de carta muerta
evaluaciones de LLM costosas
integraciones deshabilitadas

Los agentes de sondeo se ejecutan en segundo plano, donde los fallos son silenciosos y los problemas pueden acumularse antes de que alguien se dé cuenta. Los sistemas en segundo plano necesitan visibilidad integrada desde el principio, no añadida como una reflexión tardía cuando algo sale mal. Para la pila completa de observabilidad para sistemas de IA y respaldados por LLM — métricas, trazas, registros estructurados y SLOs — consulta Observabilidad para Sistemas de LLM: Métricas, Trazas, Registros y Pruebas en Producción.

Recomendación Final

Los patrones de sondeo manejan la capa de programación proactiva debajo de un sistema multiagente. Una vez que tienes múltiples agentes que necesitan coordinarse entre sí — no solo sondear de forma independiente — la siguiente decisión de diseño es cómo se coordinan: hub-and-spoke, pipeline, fan-out, o swarm. Patrones de Orquestación Multiagente cubre esas topologías de coordinación con modos de fallo y un marco de decisión.

Para un asistente de IA serio, comienza con trabajadores de sondeo basados en cola y un almacén de estado duradero. Añade webhooks donde los proveedores los soporten. Usa sondeo adaptativo cuando los límites de tasa importen. Usa un motor de flujo de trabajo duradero cuando el proceso sea de larga ejecución y múltiples pasos. Usa runtime de agente persistente cuando el agente necesite razonar a lo largo del tiempo.

Para el ejemplo de Hermes y Notion, la arquitectura correcta es:

Notion como la bandeja de entrada de tareas orientada al humano
Programador de Hermes cada 10 minutos
Trabajador de Hermes con lógica de reclamación o arrendamiento
Backend de Hermes para registros de ejecución e idempotencia
Actualizaciones de estado de Notion para visibilidad

El intervalo de sondeo no es la parte difícil. La parte difícil es asegurarse de que el agente reclame una tarea, la ejecute una vez, registre lo que ocurrió y deje el sistema en un estado que los humanos puedan entender.

Eso es lo que convierte un script de sondeo en un asistente de IA fiable — no el intervalo, no el modelo, sino la disciplina alrededor de reclamar trabajo, registrarlo y dejar el sistema en un estado que tanto humanos como futuras ejecuciones puedan entender.