Agentes por evento ou por agendamento: qual usar

Atualizado maio 2026.

TL;DR: Use agentes por eventos quando uma ação do usuário exige resposta imediata — qualquer atraso acima de alguns segundos quebra a experiência. Use agentes agendados para trabalho em lote ou periódico onde o timing é previsível. A restrição: agentes por eventos devem ser stateless e rápidos; agentes agendados podem ser stateful e mais lentos.

[Perspectiva do operador] Mantenho mais de 30 agentes em produção na minha marca de consultoria e no Pickleland, uma arena de pickleball em Pflugerville, TX. Cada um deles se encaixa em um de dois padrões: dispara por um evento, ou dispara por um relógio. Errar aqui desperdiça dinheiro e entrega experiências quebradas.

Índice

Os dois padrões em linguagem simples

Um agente por eventos acorda porque algo aconteceu. Uma reserva chegou. Um comentário foi postado. Um formulário foi enviado. O gatilho é externo e imprevisível no tempo. O trabalho: responder rápido.

Um agente agendado acorda porque o relógio mandou. Todo dia às 7h. Todo domingo às 18h. Toda hora no horário exato. O gatilho é interno e completamente previsível. O trabalho: fazer um trabalho minucioso.

É só isso. Não complique. A arquitetura segue da resposta a uma pergunta: o usuário ou o sistema precisa de resposta agora mesmo, ou pode esperar até um momento específico?

Por eventos: o agente de resposta nas redes sociais

Meu agente de resposta social dispara quando um novo comentário chega em um post do Facebook monitorado. O agente lê o comentário, classifica a intenção (pergunta, reclamação, elogio, spam), rascunha uma resposta e a publica — ou a sinaliza para revisão humana se a confiança for baixa.

Todo o ciclo completo precisa terminar em menos de 30 segundos ou a resposta parece desatualizada. Esse é um problema de ativação por eventos.

Aqui está um Cloudflare Worker simplificado que lida com o webhook de um serviço de monitoramento 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 a assinatura do 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;

    // Classificar e responder — manter async para retornar 200 rápido
    env.REPLY_QUEUE.send(event);

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

// Consumidor de fila — faz o trabalho 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();
    }
  };

Duas coisas a notar. Primeiro, o handler fetch retorna 200 imediatamente e delega o trabalho real para uma fila. Isso mantém a resposta do webhook rápida e evita que o serviço de monitoramento tente novamente. Segundo, o consumidor de fila faz a chamada real de IA — classificando e rascunhando — sem pressão de tempo de uma conexão HTTP aberta.

Agendado: o promotor de eventos do Pickleland

O Pickleland gerencia quadras e eventos. Toda semana, alguém precisa divulgar os próximos eventos nos grupos certos do Facebook para preencher vagas. Isso é puro trabalho periódico em lote — nenhuma ação do usuário o dispara, e não precisa acontecer em tempo real.

O promotor de eventos do Pickleland roda em um cron, verifica o sistema de reservas para eventos nos próximos 4 dias, rascunha posts específicos para cada grupo do Facebook correspondente, e os apresenta para minha revisão antes de qualquer coisa ir ao ar.

// 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> {
  // Buscar eventos do sistema de reservas
  const upcomingEvents = await fetchUpcomingEvents(env, { daysAhead: 4 });

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

  const drafts: PromoDraft[] = [];

  for (const event of upcomingEvents) {
    // Associar cada evento aos grupos de FB corretos
    const groups = await matchFacebookGroups(event, env);

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

  // Salvar rascunhos no Airtable para revisão — nada é publicado automaticamente
  await saveDraftsForReview(drafts, env);

  // Me notificar pelo Slack
  await notifyOperator(
    `${drafts.length} rascunhos de promo prontos para revisão`,
    env
  );
}

A configuração do wrangler que conecta tudo:

# wrangler.toml
[[triggers]]
crons = ["0 18 * * 0"]  # Todo domingo às 18h UTC

Note o que o agente agendado pode fazer que o por eventos não pode: itera sobre múltiplos eventos, escreve em um banco de dados e envia uma notificação resumida. Está fazendo trabalho em lote. O agente por eventos precisa se manter leve e retornar resposta rapidamente.

Agendado: o briefing diário

Todo dia às 7h, meu agente de briefing diário roda. Ele busca e-mails noturnos, meu calendário, tarefas principais e qualquer notícia que eu marquei como relevante. Formata tudo em um único documento e o deposita na minha pasta AI Workspace.

Este é puro agendamento. Não há nenhum evento que o dispararia — eu simplesmente quero que ele rode toda manhã antes de começar a trabalhar.

// 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 * * *"]  # Todo dia às 7h UTC

O Promise.all paralelo é deliberado. Agentes agendados não têm um humano esperando — mas ainda assim não deveriam ser mais lentos do que precisam. Busque todas as fontes de dados em paralelo, depois faça a síntese de IA uma vez.

Quando agentes por eventos falham

O modo de falha que vejo com mais frequência: alguém constrói um agente por eventos que faz trabalho demais no handler.

Uma reserva chega. O agente busca o perfil do cliente, enriquece a partir de três APIs externas, executa um modelo de personalização, escreve no CRM, envia o e-mail de confirmação e atualiza um dashboard. Tudo leva 45 segundos. A plataforma de reservas tenta novamente porque não recebeu um 200 rápido o suficiente. Agora o agente roda duas vezes.

Corrija da mesma forma que o agente de resposta social é construído: retorne 200 imediatamente, empurre o evento para uma fila, deixe o consumidor de fila fazer o trabalho pesado de forma assíncrona.

O outro modo de falha: usar por eventos para trabalho que é na verdade periódico. “Enviar um resumo semanal” não é um evento. Não conecte isso a um webhook de cron sintético — use um gatilho agendado adequado.

Quando agentes agendados falham

Agentes agendados falham quando o trabalho é na verdade sensível à latência. Se um usuário envia um formulário e o agente que o processa roda em um cron de 5 minutos, o usuário fica olhando para um spinner por até 5 minutos. Isso não é um job agendado — é um job por eventos lento se passando por agendado.

O outro falha: agentes agendados que se expandem para trabalho ilimitado. Se seu cron roda a cada minuto e cada invocação pode processar centenas de registros, você atingirá os limites de CPU do Cloudflare rapidamente. Aumente o intervalo do cron, adicione uma fila para limitar o trabalho por invocação, ou mude para Durable Objects para coordenação de longa duração.

Misturando padrões: o pipeline de reservas

Alguns fluxos de trabalho genuinamente precisam de ambos. O pipeline de reservas do Pickleland funciona assim:

1. Por eventos: webhook de nova reserva → confirmar a reserva, enviar o recibo ao cliente, atualizar disponibilidade. Deve ser concluído em menos de 10 segundos.
2. Agendado: todo domingo → revisar todas as reservas da semana passada, gerar um relatório resumido, sinalizar anomalias (reservas duplicadas, taxas de cancelamento incomuns).

Mesmo domínio, dois padrões, dois agentes. O por eventos é dono da experiência do usuário em tempo real. O agendado é dono da revisão operacional semanal. Eles compartilham um banco de dados, mas nada mais.

Não tente combiná-los em um único agente que “faz tudo.” O resultado será algo muito lento para eventos e muito acoplado ao fluxo em tempo real para trabalho em lote.

Cloudflare Workers: por que é a infraestrutura certa para ambos

O Cloudflare Workers lida com ambos os padrões nativamente:

• Handler fetch → por eventos (webhooks, chamadas de API)
• Handler scheduled → baseado em cron (via [[triggers]] no wrangler.toml)
• Consumidor queue → processamento assíncrono desacoplado da camada HTTP

O deployment no edge significa que seus agentes por eventos respondem rapidamente globalmente. O nível gratuito é generoso o suficiente para prototipar ambos os padrões sem gastar nada. E a configuração unificada do wrangler.toml significa que você não está gerenciando dois setups de infraestrutura separados para dois padrões.

A única coisa que o Workers não resolve bem: agentes que precisam rodar por mais de alguns minutos. Para esses, recorra aos Durable Objects ou delegue a um backend de maior duração.

A conclusão do operador

Escolha seu padrão antes de escrever uma única linha de código de agente. Por eventos para qualquer coisa em que um humano esteja esperando; agendado para qualquer coisa que roda em um relógio. Mantenha os handlers por eventos leves — retorne rápido, enfileire o trabalho. Mantenha os agentes agendados paralelos — não serialize o que você pode paralelizar. A arquitetura é simples. Violá-la é de onde vem a complexidade.