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

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

Un asistente de chat normal espera a que el usuario le haga una pregunta. Un agente de sondeo mantiene la vigilancia. Revisa una fuente, nota los cambios, decide si algo es importante y, a continuación, 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 a mi pregunta” a “mantén vigilado esto para 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. Utiliza la infraestructura de backend normal para eso. Utiliza el modelo donde es valioso: interpretando contextos desordenados, realizando juicios semánticos y produciendo lenguaje útil.

¿Qué es un agente de sondeo?

Un agente de sondeo es un proceso en segundo plano que revisa repetidamente una fuente y desencadena una acción del asistente cuando se cumple una condición. En el sistema de IA más amplio — 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 la imagen completa de las cinco capas, consulta Arquitectura del Asistente de IA: LLM, Memoria, Herramientas, Enrutamiento, Observabilidad.

Ejemplos:

• Revisar un buzón cada mañana y resumir los mensajes importantes.
• Vigilar una lista de tareas en Notion y ejecutar el siguiente elemento pendiente.
• Monitorear un problema en GitHub hasta que cambie de estado.
• Consultar una tarea de IA de larga ejecución hasta que el resultado esté listo.
• Revisar una disponibilidad de reserva hasta que haya una disponible.
• Vigilar un portal de proveedores hasta que aparezca un documento.
• Escanear nuevos artículos 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 desde la fuente.
3. Recordar lo que ya ha visto.
4. Decidir si el nuevo estado es importante.
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 la 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 Todo 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_or_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 del 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 Todo, 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 revisa 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 cambiarse de:

Status: Todo

a:

Status: InProgress
ClaimedBy: hermes
ClaimedAt: 2026-06-19T01:00:00Z
ClaimExpiresAt: 2026-06-19T01:30:00Z
RunId: run_789

Esta es la diferencia entre “espero que solo un trabajador lo elija” y “el sistema tiene un protocolo de reclamación”.

Registro de ejecución

Esto registra lo que sucedió 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 se 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 la 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 decenas de revisiones diarias sin requerir 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 del sondeo
programación
cursor o instantánea
última hora de ejecución
conteo de errores
estado

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

Flujo de ejemplo

Cada 10 minutos:
  activar el trabajador de sondeo de Hermes

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

Mejor uso

Utiliza trabajadores de sondeo programados para:

• Resúmenes diarios.
• Revisiones horarias.
• Automatizaciones internas pequeñas.
• Tareas simples de “vigilar esto”.
• Tareas 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, puedes sobrecargar tus trabajadores o alcanzar los límites de velocidad del proveedor. Los reintentos también pueden volverse desordenados si el programador inicia el trabajo directamente.

Método 2: Trabajadores de sondeo basados en colas

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

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

programador
  -> cola
  -> grupo de trabajadores
  -> API de la 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 desde 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 el estado
  emitir acción del asistente si es necesario
  establecer next_run_at

Mejor uso

Utiliza el sondeo basado en colas para:

• Asistentes de IA multiusuario.
• Muchos sondeos simultáneos.
• Integraciones con límites de velocidad.
• Trabajo en segundo plano reintenable.
• Trabajos que pueden tardar 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. Vale la pena para sistemas en producción, pero probablemente sea excesivo para un prototipo pequeño.

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 visible para humanos. El agente revisa 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 encontrar una tarea en estado Todo. Elige la siguiente tarea, generalmente por prioridad y tiempo de creación. Luego reclama la tarea estableciéndola en InProgress.

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

Modelo de estado

Notion almacena el estado de la tarea visible para humanos:

Título
Descripción
Estado: Todo | InProgress | Complete | Failed
Prioridad
CreatedAt
ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId
RetryCount
LastError
CompletedAt

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

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 se despierta

Hermes:
  consultar Notion para una tarea donde Status = Todo
  ordenar por Prioridad, CreatedAt
  actualizar la tarea seleccionada a InProgress
  establecer ClaimedBy, ClaimedAt, ClaimExpiresAt, RunId
  ejecutar la tarea
  escribir registro de ejecución
  establecer tarea en Complete o Failed

Mejor uso

Utiliza 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 supervisión humana.

Debilidades

Las herramientas externas rara vez son colas perfectas. Las reclamaciones atómicas pueden ser limitadas. La consistencia de las consultas puede retrasarse. Pueden aplicarse límites de velocidad. 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 el buzón de tareas visible para humanos mientras se mantienen todos los registros de ejecución, registros de reintento, trazas y claves de idempotencia en Hermes. Notion da visibilidad a los usuarios; Hermes mantiene el sistema fiable. Para ver 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 la programación y la ejecución en un solo servicio, lo que lo convierte en el punto de partida más simple posible para el trabajo del agente en segundo plano.

Cómo se ejecuta

El proceso del trabajador se ejecuta continuamente. Cada pocos segundos o minutos, revisa 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 aún almacena un estado duradero:

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

La memoria del proceso solo debe contener estado temporal:

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

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

Mejor uso

Utiliza bucles de larga ejecución para:

• Prototipos.
• Desarrollo local.
• Herramientas internas.
• Sistemas de un solo inquilino.
• 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 real o un motor de flujo de trabajo.

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

Método 5: Webhooks primero con respaldo de sondeo

Si la fuente admite webhooks, úsalos. El sondeo debería ser a menudo el respaldo, no el mecanismo principal.

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

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

Cómo se ejecuta

El sistema externo envía eventos a tu extremo del webhook cuando algo cambia. Tu sistema almacena el evento y lo procesa de forma asíncrona.

Un sondeo de reconciliación más lento se ejecuta cada pocas horas o una vez al día. Revisa si se perdieron algún evento.

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 uso

Utiliza la arquitectura de webhooks primero para:

• Eventos de GitHub.
• Eventos de Stripe.
• Eventos de Slack.
• Actualizaciones de CRM.
• Notificaciones de implementación.
• Sistemas de ticketing.

Debilidades

Los webhooks requieren un extremo público, validación de firma, protección contra reproducció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.

Aún así, si existen buenos webhooks, sondear cada minuto suele ser un desperdicio.

Método 6: Sondeo de trabajos en segundo plano del lado del proveedor

A veces, lo que se sondea es el trabajo de IA en sí mismo.

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

aplicación
  -> 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 revisa 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 uso

Utiliza el 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 de proveedor largo. 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 Implementación de 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 del 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 visible para el usuario
referencias de autorización
registros de negocio
registros de notificación

El motor de flujo de trabajo posee el estado del proceso: historial de ejecución, temporizadores, reintentos e intentos de actividad. Tu base de datos posee el 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 confuso de ambos.

Mejor uso

Utiliza 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 una falla.

Debilidades

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

Método 8: Tiempo de ejecución persistente del agente

Algunos marcos de agentes pueden persistir el estado del agente, crear puntos de control de 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
  -> tiempo de ejecución del agente
  -> cargar punto de control
  -> llamar a herramientas
  -> guardar punto de control
  -> reanudar más tarde

Cómo se ejecuta

Un programador externo o flujo de trabajo inicia el agente. El tiempo de ejecución del agente carga el estado anterior, ejecuta el siguiente paso, llama a herramientas si es necesario y escribe un punto de control.

El tiempo de ejecución del agente no debería 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 puntos de control 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 sigue perteneciendo 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 punto de control 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 uso

Utiliza el tiempo de ejecución persistente del agente para:

• Investigación de múltiples pasos.
• Agentes que hacen pausa y reanudan.
• Trabajo con supervisión humana.
• Razonamiento intensivo 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 velocidad 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 utiliza 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 obtiene periódicamente cambios externos y escribe registros normalizados en tu base de datos. Un segundo trabajador o flujo de cambios detecta las 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 uso

Utiliza 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 internos.

Debilidades

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

Método 10: Sondeo adaptativo

El sondeo adaptativo cambia la frecuencia según el estado, la urgencia o la actividad reciente.

objeto activo: sondear cada 1 minuto
objeto esperando: sondear cada 1 hora
objeto obsoleto: sondear una vez al 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, para.

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 uso

Utiliza el sondeo adaptativo para:

• Estado de implementación.
• Seguimiento de entregas.
• Disponibilidad de slots del 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 estricto momento, manténla estricta. No hagas que los trabajos de cumplimiento sean inteligentes.

Método 11: Sondeo semántico con un evaluador de LLM

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

El código puede responder:

¿El estado es igual a Completado?
¿El precio es inferior a 100?
¿Hay un nuevo mensaje?

Un LLM puede ayudar a responder:

¿Este correo electrónico suena urgente?
¿Es probable que este cliente esté insatisfecho?
¿Este artículo de investigación es relevante?
¿Este cambio requiere mi atención?

Cómo se ejecuta

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

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

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

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

Modelo de estado

La definición del 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 uso

Utiliza el sondeo semántico para:

• Detección de correos electrónicos 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. Utiliza filtros deterministas primero. Pregunta al modelo solo cuando realmente se necesite juicio.

Tabla de decisiones: Elegir 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 posee el tiempo
la cola posee el amortiguamiento
el trabajador posee la ejecución
la base de datos posee el estado
el LLM posee el juicio semántico
el asistente posee la interacción con el 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.

Supongamos que una base de datos de Notion contiene tareas. Hermes debería ejecutarse cada 10 minutos, tomar una tarea en estado Todo, establecerla en InProgress, ejecutarla y luego marcarla como Complete.

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 en producción, se convierte en:

sondeo basado en colas con Notion como el buzón de tareas visible para humanos

Propiedades de la tarea de Notion

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

Nombre
Estado: Todo | InProgress | Complete | Failed
Prioridad
CreatedAt
ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId
RetryCount
LastError
CompletedAt

Los campos importantes son ClaimedAt, ClaimExpiresAt 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 lo que Hermes realmente hizo.

Flujo de ejecución

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

Trabajador de Hermes:
  encuentra una tarea de Notion donde Status = Todo
  ordena por Prioridad y CreatedAt
  reclama la tarea estableciendo Status = InProgress
  escribe ClaimedBy, ClaimedAt, ClaimExpiresAt y RunId
  ejecuta la tarea
  escribe registros de ejecución en el backend de Hermes
  establece Status de Notion = Complete en caso de éxito
  establece Status de Notion = Failed en caso de falla

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

Status = InProgress
ClaimExpiresAt < ahora

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

Manejo de errores

En caso de éxito:

Status = Complete
CompletedAt = ahora
LastError = vacío

En caso de falla recuperable:

Status = Todo
RetryCount = RetryCount + 1
LastError = mensaje de error corto

En caso de falla no recuperable:

Status = Failed
LastError = explicación clara

Para 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 del 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, encuentra una tarea Todo y hazla.

Una implementación fiable dice:

Cada 10 minutos, reclama exactamente una tarea elegible, registra la ejecución, ejecuta de forma idempotente y mueve 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.

Utiliza:

ClaimedBy
ClaimedAt
ClaimExpiresAt
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 electrónicos repetidos, ejecución de tareas repetidas 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.

Malo:

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

Mejor:

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

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:

parar después del éxito
parar después de la fecha
parar después de reintentos máximos
parar cuando el usuario lo desactive
parar después de fallas de autorización repetidas

Un agente de sondeo sin una 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 administración para:

sondeos activos
tareas InProgress atascadas
fallas recientes
tareas de reintento alto
trabajos de cartas muertas
evaluaciones de LLM costosas
integraciones deshabilitadas

Los agentes de sondeo se ejecutan en segundo plano, donde las fallas son silenciosas 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 un pensamiento posterior cuando algo sale mal. Para la pila completa de observabilidad para sistemas de IA y 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

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

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

Notion como el buzón de tareas visible para humanos
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 sucedió 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 el trabajo, registrarlo y dejar el sistema en un estado que tanto humanos como ejecuciones futuras puedan entender.