Agentes por Eventos vs Agentes Programados: Qué Patrón Usar en Cada Caso

Tabla de contenidos

Actualizado mayo 2026.

TL;DR: Usa agentes por eventos cuando una acción del usuario exige respuesta inmediata—si el retraso supera unos segundos, la experiencia se rompe. Usa agentes programados para trabajo periódico o por lotes donde el momento es predecible. La restricción: los agentes por eventos deben ser stateless y rápidos; los programados pueden ser stateful y lentos.

[Lectura del operador] Mantengo más de 30 agentes en producción entre mi marca de consultoría y Pickleland, una cancha de pickleball en Pflugerville, TX. Cada uno cae en uno de dos patrones: se activa por un evento o se activa por un reloj. Equivocarse aquí desperdicia dinero y entrega experiencias rotas.

Los dos patrones en lenguaje simple

Un agente por eventos despierta porque algo sucedió. Llegó una reserva. Se publicó un comentario. Se envió un formulario. El disparador es externo e impredecible en tiempo. Tu trabajo es responder rápido.

Un agente programado despierta porque el reloj lo dice. Cada mañana a las 7am. Cada domingo a las 6pm. Cada hora en punto. El disparador es interno y completamente predecible. Tu trabajo es hacer un trabajo minucioso.

Eso es todo. No lo compliques. La arquitectura se deriva de la respuesta a una pregunta: ¿el usuario o el sistema necesitan una respuesta ahora mismo, o puede esperar hasta un momento específico?

Por eventos: el agente de respuesta en redes sociales

Mi agente de respuesta social se activa cuando llega un nuevo comentario a una publicación de Facebook monitoreada. El agente lee el comentario, clasifica la intención (pregunta, queja, cumplido, spam), redacta una respuesta y la publica—o la marca para revisión humana si la confianza es baja.

Todo el ciclo completo debe terminar en menos de 30 segundos o la respuesta se siente rancia. Ese es un problema de activación por eventos.

Aquí hay un Cloudflare Worker simplificado que maneja el webhook de un servicio de monitoreo social:

// workers/social-reply.ts
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    if (request.method !== "POST") {
      return new Response("Method not allowed", { status: 405 });
    }

    // Verificar la firma del webhook
    const sig = request.headers.get("x-webhook-signature") ?? "";
    const body = await request.text();
    const valid = await verifySignature(body, sig, env.WEBHOOK_SECRET);
    if (!valid) return new Response("Unauthorized", { status: 401 });

    const event = JSON.parse(body) as SocialCommentEvent;

    // Clasificar y responder — mantenerlo async para devolver 200 rápido
    env.REPLY_QUEUE.send(event);

    return new Response("OK", { status: 200 });
  },
};

// Consumidor de cola — hace el trabajo real de IA
export const queue: ExportedHandlerQueueHandler<Env, SocialCommentEvent> =
  async (batch, env) => {
    for (const msg of batch.messages) {
      const comment = msg.body;

      const classification = await classifyComment(comment.text, env);
      if (classification.intent === "spam") {
        msg.ack();
        continue;
      }

      const reply = await draftReply(comment, classification, env);

      if (classification.confidence > 0.85) {
        await postReply(comment.postId, comment.id, reply, env);
      } else {
        await flagForReview(comment, reply, env);
      }

      msg.ack();
    }
  };

Dos cosas a notar. Primero, el handler fetch devuelve 200 inmediatamente y delega el trabajo real a una cola. Esto mantiene la respuesta del webhook rápida y evita que el servicio de monitoreo reintente. Segundo, el consumidor de cola hace la llamada real de IA—clasificando y redactando—sin presión de tiempo por una conexión HTTP abierta.

Programado: el promotor de eventos de Pickleland

Pickleland gestiona canchas y eventos. Cada semana, alguien necesita publicar los próximos eventos en los grupos de Facebook correctos para llenar los cupos. Esto es puro trabajo periódico por lotes—no hay ninguna acción del usuario que lo dispare, y no necesita ocurrir en tiempo real.

El promotor de eventos de Pickleland corre en un cron, revisa el sistema de reservas para eventos en los próximos 4 días, redacta publicaciones específicas para cada grupo de Facebook coincidente, y las presenta para mi revisión antes de que nada se publique.

// workers/event-promoter.ts
export default {
  async scheduled(
    event: ScheduledEvent,
    env: Env,
    ctx: ExecutionContext
  ): Promise<void> {
    ctx.waitUntil(runPromoter(env));
  },
};

async function runPromoter(env: Env): Promise<void> {
  // Obtener eventos del sistema de reservas
  const upcomingEvents = await fetchUpcomingEvents(env, { daysAhead: 4 });

  if (upcomingEvents.length === 0) return;

  const drafts: PromoDraft[] = [];

  for (const event of upcomingEvents) {
    // Emparejar cada evento con los grupos de FB correctos
    const groups = await matchFacebookGroups(event, env);

    for (const group of groups) {
      const post = await draftPromoPost(event, group, env);
      drafts.push({ event, group, post });
    }
  }

  // Guardar borradores en Airtable para revisión — nada se publica automáticamente
  await saveDraftsForReview(drafts, env);

  // Notificarme por Slack
  await notifyOperator(
    `${drafts.length} borradores de promo listos para revisión`,
    env
  );
}

La configuración de wrangler que conecta todo:

# wrangler.toml
[[triggers]]
crons = ["0 18 * * 0"]  # Cada domingo a las 6pm UTC

Nota lo que el agente programado puede hacer que el de eventos no puede: itera sobre múltiples eventos, escribe en una base de datos y envía una notificación de resumen. Está haciendo trabajo por lotes. El agente por eventos necesita mantenerse liviano y devolver respuesta rápido.

Programado: el resumen diario

Cada mañana a las 7am corre mi agente de resumen diario. Obtiene los emails de la noche, mi calendario, las tareas principales y cualquier noticia que haya marcado como relevante. Formatea todo en un solo documento y lo deposita en mi carpeta de AI Workspace.

Este es puro programado. No hay ningún evento que lo dispararía—simplemente lo quiero cada mañana antes de comenzar a trabajar.

// workers/daily-brief.ts
export default {
  async scheduled(
    event: ScheduledEvent,
    env: Env,
    ctx: ExecutionContext
  ): Promise<void> {
    ctx.waitUntil(buildDailyBrief(env));
  },
};

async function buildDailyBrief(env: Env): Promise<void> {
  const [emails, calendar, tasks] = await Promise.all([
    fetchOvernightEmails(env),
    fetchTodayCalendar(env),
    fetchTopTasks(env),
  ]);

  const brief = await synthesizeBrief({ emails, calendar, tasks }, env);

  await writeToWorkspace(brief, env);
}

[[triggers]]
crons = ["0 7 * * *"]  # Cada día a las 7am UTC

El Promise.all en paralelo es deliberado. Los agentes programados no tienen un humano esperando—pero aun así no deberían ser más lentos de lo necesario. Obtén todas tus fuentes de datos en paralelo, luego haz la síntesis de IA una vez.

Cuándo falla el patrón por eventos

El fallo que veo con más frecuencia: alguien construye un agente por eventos que hace demasiado trabajo en el handler.

Llega una reserva. El agente obtiene el perfil del cliente, lo enriquece desde tres APIs externas, ejecuta un modelo de personalización, escribe en el CRM, envía el email de confirmación y actualiza un dashboard. Todo tarda 45 segundos. La plataforma de reservas reintenta porque no recibió un 200 rápido. Ahora el agente corre dos veces.

Corrígelo de la misma manera que está construido el agente de respuesta social: devuelve 200 inmediatamente, empuja el evento a una cola, deja que el consumidor de cola haga el trabajo pesado de forma asíncrona.

El otro fallo: usar por eventos para trabajo que en realidad es periódico. “Enviar un resumen semanal” no es un evento. No lo conectes a un webhook de cron sintético—usa un disparador programado apropiado.

Cuándo falla el patrón programado

Los agentes programados fallan cuando el trabajo es en realidad sensible a la latencia. Si un usuario envía un formulario y el agente que lo procesa corre en un cron de 5 minutos, el usuario está mirando un spinner hasta 5 minutos. Eso no es un trabajo programado—es un trabajo por eventos lento disfrazado de programado.

El otro fallo: agentes programados que se expanden a trabajo sin límites. Si tu cron corre cada minuto y cada invocación puede procesar cientos de registros, alcanzarás los límites de CPU de Cloudflare rápido. O aumenta el intervalo del cron, agrega una cola para limitar el trabajo por invocación, o cambia a Durable Objects para coordinación de larga duración.

Mezclando patrones: el pipeline de reservas

Algunos flujos de trabajo genuinamente necesitan ambos. El pipeline de reservas de Pickleland funciona así:

1. Por eventos: webhook de nueva reserva → confirmar la reserva, enviar el recibo al cliente, actualizar disponibilidad. Debe completarse en menos de 10 segundos.
2. Programado: cada domingo → revisar todas las reservas de la semana pasada, generar un informe de resumen, marcar anomalías (reservas duplicadas, tasas de cancelación inusuales).

Mismo dominio, dos patrones, dos agentes. El de eventos gestiona la experiencia del usuario en tiempo real. El programado gestiona la revisión de operaciones semanal. Comparten una base de datos pero nada más.

No intentes combinarlos en un solo agente que “hace todo.” Terminarás con algo demasiado lento para eventos y demasiado acoplado al flujo en tiempo real para trabajo por lotes.

Cloudflare Workers: por qué es la infraestructura correcta para ambos

Cloudflare Workers maneja ambos patrones de forma nativa:

• Handler fetch → por eventos (webhooks, llamadas API)
• Handler scheduled → basado en cron (via [[triggers]] en wrangler.toml)
• Consumidor queue → procesamiento asíncrono desacoplado de la capa HTTP

El despliegue en el edge significa que tus agentes por eventos responden rápido globalmente. El nivel gratuito es lo suficientemente generoso para prototipar ambos patrones sin gastar nada. Y la configuración unificada de wrangler.toml significa que no estás gestionando dos configuraciones de infraestructura separadas para dos patrones.

Lo único que Workers no resuelve bien: agentes que necesitan correr por más de unos minutos. Para esos, recurre a Durable Objects o delega a un backend de mayor duración.

La conclusión del operador

Elige tu patrón antes de escribir una sola línea de código de agente. Por eventos para cualquier cosa en la que un humano esté esperando; programado para cualquier cosa que corra en un reloj. Mantén los handlers por eventos delgados—devuelve rápido, encola el trabajo. Mantén los agentes programados paralelos—no serialices lo que puedes paralelizar. La arquitectura es simple. Violarla es de donde viene la complejidad.