The AI Agent Events & Triggers Catalog

Source: github.com/crewAIInc/crewai (Python, MIT)

Intent

Provide explicit execution paths, conditional branching, and clean state management for event-driven agent workflows --- the deterministic counterpart to CrewAI’s autonomous, role-based Crews.

Motivating Problem

CrewAI is best known for autonomous “Crews” --- collections of role-defined agents that decide among themselves how to accomplish a task. Crews are excellent for open-ended problems but harder to reason about when you need a specific sequence: do step A, then if condition X branch to B, else to C, then trigger sub-crew D. Flows fills that need with an event-driven decorator-based API: methods on a Flow class are bound to events; @start, @listen, @router decorators define the graph; state is a Pydantic model the framework maintains.

How It Works

The author subclasses Flow with a typed Pydantic state. Methods get decorators: @start marks an entry point, @listen(method_name) makes a method fire when another method completes, @router decorates a method whose return value picks the next step. The framework runs methods in topological order, manages state transitions, and integrates with CrewAI’s Crews --- a Flow step can kickoff() a whole Crew as a sub-task.

Compared with LangGraph: similar graph-shaped execution, slightly more opinionated API (decorators instead of explicit StateGraph), and tighter integration with CrewAI’s role-based agent definitions. The state model is Pydantic (not TypedDict), which gives validation for free.

When to Use It

Teams already using CrewAI for autonomous Crews who need a deterministic counterpart for specific workflows. Hybrid systems where a Flow orchestrates the high-level sequence and Crews handle open-ended sub-tasks. Event-driven workflows with conditional routing where the Pydantic state model is a good fit.

Alternatives --- LangGraph (Volume 9) for the larger ecosystem and broader checkpoint backends; LlamaIndex Workflows for a similar step-and-event API outside the CrewAI orbit; vanilla Python state machines when the workflow is small enough that a framework is overkill. For CrewAI itself (Crews, roles, delegation), see Volume 9, CrewAI; this entry covers only Flows as an event-driven example.

Sources

• github.com/crewAIInc/crewai

• docs.crewai.com (Flows section)

Example

A market-research workflow: @start collects the user’s topic; @listen for the topic-received event dispatches a web-search Crew; @router examines the search results and routes either to a deep-research Crew (if results look promising) or back to a refinement step (if not); a final @listen synthesizes the deliverable. Each step is decoratively bound to its predecessor; the framework handles dispatch and state.

Example artifacts

Setup.

pip install crewai

Code.

from crewai.flow.flow import Flow, listen, router, start

from pydantic import BaseModel

class ResearchState(BaseModel):

topic: str = ""

findings: list = []

quality: str = ""

class ResearchFlow(Flow[ResearchState]):

\@start()

def collect_topic(self):

self.state.topic = "agent observability tooling"

\@listen(collect_topic)

def initial_search(self):

# call a Crew to do searches

self.state.findings = ["..."]

\@router(initial_search)

def assess(self):

return "deep_dive" if len(self.state.findings) > 5 else "refine"

\@listen("deep_dive")

def synthesize(self):

return "final report"

\@listen("refine")

def refine_search(self):

# adjust query, loop

...

ResearchFlow().kickoff()

Source: github.com/run-llama/llama-agents (Python, MIT; llama-index-workflows package)

Intent

Build event-driven agent workflows as steps that emit and listen for typed events, with the runtime handling dispatch, parallelism, and durability.

Motivating Problem

The graph metaphor (nodes + edges) works for many agent flows but feels awkward when the natural unit is the event itself. LlamaIndex Workflows inverts the framing: steps are async methods, each declares which event type it handles, and steps emit new events to drive the next step. The runtime tracks events, dispatches steps, supports parallelism, and provides a visualization. The metaphor is closer to actor systems than to typed graphs.

How It Works

Workflows ship as the standalone llama-index-workflows package (developed in the run-llama/llama-agents repo, formerly workflows-py), which llama_index re-exports. The author subclasses Workflow, defines step methods decorated with @step, and uses Pydantic-shaped Event classes. The framework reads each step’s type annotations to build the event routing, so there is no graph to declare. Each step takes a Context and an event, does work, and returns a new event. The first step takes a StartEvent; the workflow completes when a step returns a StopEvent. Steps can run concurrently when multiple branches emit independent events; ctx.collect_events lets a step wait for several event types to all arrive.

Native checkpointing is via Context serialization; the workflow can be paused, persisted, and resumed. The framework integrates with LlamaIndex’s broader retrieval and indexing primitives, which makes it natural for retrieval-heavy workflows (RAG with multiple retrievers, query decomposition, multi-step search).

When to Use It

Workflows where the natural unit is the event, not the node. Retrieval-heavy systems that compose well with LlamaIndex’s indexing surface. Multi-agent systems where steps fan out, run in parallel, and merge.

Alternatives --- LangGraph (Volume 9) when graph and state are the right metaphor and the workflow is sequential or branching but not heavily parallel; CrewAI Flows when you’re in the CrewAI ecosystem. Volume 9 points here for the multi-agent use of Workflows.

Sources

• developers.llamaindex.ai/python/llamaagents/workflows/

• github.com/run-llama/llama-agents

Example

A multi-source research workflow: the StartEvent fans out to three parallel retrieval steps (vector, keyword, web); each emits a typed result event; a synthesis step uses ctx.collect_events to wait for all three before running. The framework parallelizes the retrieval steps automatically; the explicit event types make the data flow easy to read.

Example artifacts

Code.

from llama_index.core.workflow import (

StartEvent, StopEvent, Event, Workflow, step, Context

)

class SearchEvent(Event):

query: str

class ResultsEvent(Event):

docs: list

class ResearchFlow(Workflow):

\@step

async def kickoff(self, ev: StartEvent) -> SearchEvent:

return SearchEvent(query=ev.topic)

\@step

async def search(self, ev: SearchEvent) -> ResultsEvent:

docs = await retriever.aretrieve(ev.query)

return ResultsEvent(docs=docs)

\@step

async def finalize(self, ctx: Context, ev: ResultsEvent) ->
StopEvent:

return StopEvent(result=summarize(ev.docs))

Source: inngest.com (TypeScript, Python, Go SDKs; hosted + self-hostable)

Intent

Make long-running, event-driven workflows reliable by abstracting the durability concerns (queue, retries, idempotency, fan-out, scheduling) behind a TypeScript/Python function-style API.

Motivating Problem

A production AI workflow that responds to a webhook, calls an LLM, waits on a human approval, calls another tool, and finally emits a result can fail at any step. Without a durable layer, the developer writes the queue, the retry logic, the dead-letter handling, the idempotency keys, and the long-poll handlers by hand. Inngest provides all of that as a hosted platform with a function-style SDK: write your workflow as one async function with step.run() and step.sleep() calls; Inngest handles the rest.

How It Works

The SDK exposes inngest.createFunction with event triggers (event: “user.signup”), step.run (a step whose result is memoized), step.sleep (durable sleeps, including for days), step.waitForEvent (pause until a matching event arrives), and step.invoke (call another function). Each step.run boundary is a checkpoint; if the function crashes mid-execution, the next attempt picks up at the failed step with all prior step outputs replayed from the log.

Events come in via inngest.send() from anywhere in the application (HTTP, webhooks, scheduled crons), get routed to matching functions, and trigger workflow runs that the platform owns end-to-end. The dashboard shows every step, every retry, every input and output. For AI workflows specifically, Inngest documents patterns for the agent loop (step.ai.infer wraps LLM calls; concurrency controls bound parallel agent runs; rate limits prevent runaway costs).

When to Use It

Production AI workflows that mix LLM calls with waits on external systems (webhooks, human approvals, scheduled actions). Startups that want durable execution without operating Temporal themselves. Workflows that fan out across many sub-agents and need backpressure / concurrency controls.

Alternatives --- Temporal when scale demands the most-mature engine, or when self-hosting is non-negotiable. Restate for a newer single-binary alternative. AWS Step Functions when the rest of the stack is on AWS. LangGraph or LlamaIndex Workflows when the orchestration logic is graph-shaped and the durability needs are bounded.

Sources

• inngest.com

• inngest.com/docs/features/inngest-functions/steps-workflows/step-ai-orchestration (step.ai)

• agentkit.inngest.com (AgentKit, Inngest’s agent-specific layer)

Example

A research-agent product: a user submits a topic via a web form; the form posts an event; Inngest fires a function that calls an LLM to generate a research plan, fans out three parallel step.run calls for retrieval, step.waitForEvent for a human-approval Slack reply, step.run on a final synthesis LLM call, and step.run on the email-send. The whole workflow can take an hour or a day; if the process crashes, it resumes at the failed step.

Example artifacts

Setup.

npm install inngest

# or

pip install inngest

Code.

import { Inngest } from "inngest";

const inngest = new Inngest({ id: "my-app" });

export const researchAgent = inngest.createFunction(

{ id: "research-agent" },

{ event: "research/request" },

async ({ event, step }) => {

const plan = await step.run("make-plan", () =>

llm.complete({ messages: [...] })

);

const docs = await step.run("retrieve", () =>

retriever.search(plan.queries)

);

await step.waitForEvent("wait-for-approval", {

event: "research/approved",

timeout: "24h",

match: "data.requestId",

});

const report = await step.run("synthesize", () =>

llm.complete({ messages: [...] })

);

await step.run("send-email", () =>

mailer.send({ to: event.data.email, body: report })

);

}

);

Source: github.com/triggerdotdev/trigger.dev (16k+ stars, Apache-2.0; TypeScript SDK; cloud or self-hosted with Docker or Kubernetes)

Intent

Run long-running TypeScript tasks and agents triggered by events, schedules or other tasks, with retries, queues, waits and human approval points, and without the execution time limits of serverless functions.

Motivating Problem

An agent run started by a webhook can take minutes or hours: it calls models, runs a headless browser, waits on a child task, waits for a human. Serverless platforms cut such runs off at their timeout, and a hand-built worker fleet needs its own queue, retry and status plumbing. Trigger.dev keeps the task in the application’s codebase and moves its execution onto a managed (or self-hosted) runtime with no timeout, where waiting does not hold compute.

How It Works

A task is a function exported from the codebase with task({ id, run }). Application code starts it with tasks.trigger() or yourTask.trigger(), optionally with an idempotency key so a retried webhook does not start a second run; a parent task can call triggerAndWait() on a child. schedules.task() attaches cron schedules (with a timezone) to a task.

Durability comes from a checkpoint-resume system rather than from replaying a log. When a task waits on a child task, a long wait.for() pause, or a waitpoint token (wait.createToken() plus wait.forToken(), completed by a human or another system with wait.completeToken()), the runtime uses CRIU to snapshot the whole process, releases the machine, and restores the snapshot in a new environment when the wait ends. Runs have queues and concurrency limits, automatic retries, tracing, and a Realtime API that lets a frontend subscribe to a run or stream LLM output from it.

When to Use It

TypeScript stacks that want agent runs as background tasks with no timeout and a human-approval wait built in. Agents that need system packages (browsers, FFmpeg, Python scripts) inside the task. Teams that want an open-source engine they can self-host later.

Alternatives --- Inngest for a step-memoization model with event-first routing; Temporal for multi-language workflows at the largest scale; Vercel Workflow or DBOS when you want durability as a library without a separate task runtime.

Sources

• github.com/triggerdotdev/trigger.dev

• trigger.dev/docs/how-it-works (checkpoint-resume)

• trigger.dev/docs/wait-for-token

Example

A support-ticket webhook calls tasks.trigger(“triage-ticket”, payload) with the ticket ID as the idempotency key. The task classifies the ticket, drafts a reply, creates a waitpoint token and posts its approval link to Slack, then waits on wait.forToken(). The process is checkpointed while the support lead reviews; when the lead approves, the task resumes on a fresh machine and sends the reply.

Source: temporal.io (Go, Java, Python, TypeScript, .NET, PHP, Ruby SDKs; OSS MIT)

Intent

Run long-lived, fault-tolerant workflows across machines and deployments, with deterministic replay as the central guarantee.

Motivating Problem

Temporal predates the AI-agent wave by years --- it was extracted from Uber’s Cadence and is used at production scale at Datadog, Snap, Stripe, Coinbase, and many others. The premise is the same as Inngest’s but the engine is more mature and operationally more demanding: a workflow function runs deterministically, every external call is wrapped in an Activity (a regular function that can fail and retry), the engine persists every event in an event log, and a replay deterministically reconstructs the workflow state. For AI agents, Temporal is the choice when reliability and scale are non-negotiable and the team has the operational maturity to run it.

How It Works

Workflows are functions that take inputs and return outputs; they’re written in a deterministic style (no clock reads, no random numbers, no direct I/O --- those go in Activities). Activities are regular functions invoked from the workflow; the engine handles retries, timeouts, and result persistence. The engine is split into a Server (the orchestrator, with a Postgres / Cassandra / MySQL backing store) and Workers (your code, polling the server for work).

Temporal’s positioning for AI agents (temporal.io/solutions/ai) emphasizes long-lived state and reliability for multi-step agent flows. The patterns translate directly: each LLM call is an Activity (so retries and timeouts are handled), the agent loop is a Workflow (so it survives deploys and crashes), and Signals let external systems wake up a sleeping Workflow (the durable-execution equivalent of waitForEvent). Temporal also ships an official OpenAI Agents SDK integration that runs the agent loop as a durable Workflow. For multi-service work, the Saga pattern pairs each forward Activity with a compensating one, so a failure part-way through can be unwound; Volume 2’s workflow-orchestration-patterns skill teaches these Temporal patterns to a coding model.

When to Use It

Production AI workflows at scale where reliability is critical and the team has the operational maturity to run Temporal (it’s not a one-binary install --- you operate a cluster). Workflows that span days or weeks and pass through many external systems. Teams already using Temporal for non-AI workloads who want to add AI workflows on the same platform.

Alternatives --- Inngest for a lighter operational footprint and explicit AI-agent positioning. Restate for a single-binary alternative. AWS Step Functions when running on AWS and the workflow shape fits.

Sources

• temporal.io

• temporal.io/solutions/ai

• temporal.io/blog/announcing-openai-agents-sdk-integration

• github.com/temporalio/temporal

Example

A customer-support agent that listens for support-ticket-created events. The Workflow opens the ticket, runs an Activity that calls an LLM to classify it, runs another Activity to retrieve relevant docs from the knowledge base, runs an LLM Activity to draft a response, then enters a Signal-wait state for human approval. On approval (delivered as a Signal), it runs the send-response Activity and closes the ticket. The whole flow can take days; the engine handles every retry and resume.

Example artifacts

Code.

# Python workflow

from datetime import timedelta

from temporalio import workflow

@workflow.defn

class SupportTicketWorkflow:

@workflow.run

async def run(self, ticket_id: str) -> str:

category = await workflow.execute_activity(

classify_ticket, ticket_id,

start_to_close_timeout=timedelta(minutes=5))

docs = await workflow.execute_activity(

retrieve_docs, category,

start_to_close_timeout=timedelta(minutes=2))

draft = await workflow.execute_activity(

draft_response, ticket_id, docs,

start_to_close_timeout=timedelta(minutes=10))

# Wait up to 24h for a human to signal approval.

await workflow.wait_condition(

lambda: self._approved, timeout=timedelta(hours=24))

return await workflow.execute_activity(

send_response, ticket_id, draft,

start_to_close_timeout=timedelta(minutes=1))

@workflow.signal

def approve(self) -> None:

self._approved = True

Source: restate.dev (single-binary durable execution engine; Java, Kotlin, TypeScript, Python, Go, Rust SDKs)

Intent

Combine durable functions, durable communication, and durable state in one engine, with the operational footprint of a single binary rather than a cluster.

Motivating Problem

Temporal’s engine is sophisticated but requires real operational investment. Restate’s positioning is the same durability guarantees in a single, embedded-friendly binary: write durable functions, persist their state, dispatch them by event --- all in one process you can run on a laptop, scale up later, and treat operationally like Postgres rather than like Kafka. For AI agents this matters because the operational tax of Temporal is non-trivial for early-stage products.

How It Works

Restate provides three primitives: Services (functions that handle events), Virtual Objects (single-key durable state machines), and Workflows (long-lived saga-style flows). All three are durable by default: state is persisted; calls between services are tracked; retries are automatic. The engine is a single binary backed by RocksDB; you point your SDK at it and start writing handlers.

For AI agents, the most useful primitive is the Virtual Object: a per-user (or per-session, per-conversation) durable actor that holds state across many events. The agent’s memory lives in the Virtual Object; each incoming event mutates it; the engine persists every transition. Compared with Temporal’s Workflow-and-Activity model, Restate’s Virtual-Object model fits the conversational agent shape more naturally.

When to Use It

AI products that want durable execution without operating a Temporal cluster. Conversational agents where the per-user state machine is the right abstraction. Smaller teams that prefer one binary to a multi-component cluster.

Alternatives --- Inngest for the lightest operational footprint and explicit AI positioning. Temporal for the mature, scaled-up alternative.

Sources

• restate.dev

• github.com/restatedev/restate

Example

A multi-turn chat agent where each user has a per-user Virtual Object holding conversation history and memory. Each incoming message is an event delivered to the user’s Virtual Object; the handler updates state, calls LLMs as durable side-effects, and returns the response. The Virtual Object survives restarts; if the process crashes mid-message, the next attempt resumes at the failed step with all prior state intact.

Source: github.com/dbos-inc/dbos-transact-py (MIT; TypeScript sibling dbos-transact-ts, MIT) and github.com/vercel/workflow (Workflow SDK, Apache-2.0)

Intent

Make ordinary application functions durable by checkpointing their steps into storage the application already has (Postgres for DBOS, a pluggable backend for Vercel’s Workflow SDK), so an event-triggered agent loop survives crashes without a workflow cluster to run.

Motivating Problem

Temporal, Inngest and Restate all put an engine between the application and its workflows: a server, a hosted service or a binary that owns the event log. For a team whose agent is one service with one Postgres database, that is a second system to deploy, secure and monitor. The library approach keeps the log in the application’s own database or host runtime: the workflow code is the same shape, but there is nothing extra to operate.

How It Works

DBOS: decorate functions with @DBOS.workflow() and @DBOS.step(). DBOS records each step’s result in Postgres as it completes; after a crash, a restarted process finds unfinished workflows and resumes them from the last completed step. The same Postgres tables back durable queues (with concurrency limits, rate limits, deduplication and priority), cron schedules registered with apply_schedules, durable sleep, and a Kafka consumer decorator. For event triggers, the README pattern is to start the workflow with the event’s ID as the workflow ID (SetWorkflowID), so a redelivered webhook or Kafka message runs the workflow exactly once, and to acknowledge the event immediately while the workflow runs in the background.

Vercel Workflow (the Workflow SDK, npm package workflow): mark a TypeScript function with the “use workflow” directive and the functions it calls with “use step”. The SDK persists progress, retries failed steps, and suspends the workflow without using compute during sleep(“7 days”) or while waiting on a hook. createWebhook() exposes a URL that resumes the workflow when it receives a request. Code starts a workflow with start() from an API route or server action. Storage is a “World”: a bundled local backend in development, managed storage and queues when deployed on Vercel, or a Postgres or third-party World when self-hosted.

When to Use It

Agent services that already run on Postgres (DBOS) or on Next.js and similar TypeScript frameworks (Vercel Workflow) and want durable steps, sleeps and event-triggered runs without adopting a workflow server. Small teams where one less system matters more than a central workflow console.

Alternatives --- Temporal or Restate when many services and languages share one workflow engine; Inngest or Trigger.dev for a hosted engine with its own dashboard and queueing; Cloudflare Workflows or Lambda durable functions when the agent already lives on that serverless platform.

Sources

• github.com/dbos-inc/dbos-transact-py

• docs.dbos.dev

• github.com/vercel/workflow

• workflow-sdk.dev

Example

A webhook receiver for inbound support email runs in a FastAPI service with Postgres. The handler calls DBOS.start_workflow inside SetWorkflowID(message_id) and returns 200 at once. The workflow’s steps classify the email with an LLM, look up the customer, draft a reply and enqueue it for sending; if the service is redeployed mid-run, the new process resumes the workflow at the next unfinished step, and a duplicate delivery of the same email is ignored because its workflow ID already exists.

Source: developers.cloudflare.com/workflows, developers.cloudflare.com/agents, docs.aws.amazon.com/lambda (durable functions)

Intent

Run event-triggered, long-lived agent work on the serverless platform the application already uses, with durable steps, sleeps, event waits and per-agent state provided by the platform instead of a separate orchestrator.

Motivating Problem

Serverless functions are a natural target for webhook and queue triggers, but a plain function invocation is short-lived and stateless: it cannot wait a day for an approval, and a crash loses progress. Teams used to pair the function with Step Functions, Temporal or a queue plus a database. Cloudflare and AWS now build the durable layer into the compute platform itself.

How It Works

Cloudflare Workflows: a workflow is a class whose run method calls step.do() for each retried, persisted step, step.sleep() and step.sleepUntil() for pauses of seconds to days, and step.waitForEvent() to pause until a webhook, user input or other system sends a matching event (with a timeout). State persists for minutes, hours or weeks. The Cloudflare Agents SDK gives each agent instance a durable identity backed by a Durable Object, with its own SQLite storage, WebSocket connections and a scheduler: this.schedule() takes a delay in seconds, a Date, or a cron string, and this.scheduleEvery() sets an interval. Schedules are stored in SQLite and fire through Durable Object alarms, so they survive restarts. An agent can hand long multi-step work to a Workflow.

AWS Lambda durable functions: a regular Lambda handler wrapped by the durable execution SDK (JavaScript, TypeScript, Python, Java, Go and .NET). Steps run business logic with retries and progress tracking; waits suspend the function without compute charges. The runtime checkpoints each completed operation and recovers by replaying the handler from the beginning while skipping completed work. A durable execution can last up to one year. AWS positions it next to Step Functions: durable functions keep the workflow in code inside Lambda, Step Functions define it as a state machine.

When to Use It

Agents already deployed on Cloudflare Workers or AWS Lambda that need to wait on humans or external systems, run on a schedule, or keep per-user state, without adding an orchestrator. Per-user or per-session agents with their own state and timers (Cloudflare Agents SDK).

Alternatives --- Temporal, Restate or Inngest when the workflows must span clouds or run outside one vendor’s platform; AWS Step Functions when a visual state machine fits better than code; DBOS or Vercel Workflow for library-style durability on other hosts.

Sources

• developers.cloudflare.com/workflows/

• developers.cloudflare.com/agents/api-reference/schedule-tasks/

• docs.aws.amazon.com/lambda/latest/dg/durable-functions.html

Example

A per-customer account agent on Cloudflare: each customer has one Agents SDK instance. A Stripe webhook routed to that instance starts an onboarding Workflow whose steps call a model to draft a welcome plan, then step.waitForEvent() for the customer’s confirmation for up to 24 hours. The same agent calls this.schedule(“0 8 * * 1”, “weeklyReview”) to run a Monday check-in, which survives deploys because the schedule lives in the agent’s SQLite storage.

Source: github.com/OrchestratorInc/agent-orchestrator (Orchestrator.inc, formerly Composio Agent Orchestrator; 13k+ stars, Apache-2.0; desktop app for macOS, Windows, Linux)

Intent

Run parallel AI coding agents (Claude Code, Codex, Cursor, OpenCode and 30+ others) on a single repo, each in its own git worktree, and route CI failures, review comments, and PR state changes back to the agent that owns the work.

Motivating Problem

Running one AI coding agent in a terminal is easy. Running thirty across different issues, branches, and PRs is a coordination problem: who owns which branch, when did the agent stall, what does it do when CI fails, when does a human get pulled in, how do you watch all of it. Orchestrator.inc handles the coordination: each agent works in its own git worktree, CI failures and review comments are routed back to the responsible agent, a live Kanban shows fleet state, and the human gets pulled in only when judgment is needed.

How It Works

Download the Orchestrator.inc desktop app and point it at a repository; the app runs a local daemon that watches agent activity and source-control state, so no CLI is required. Each worker session gets its own branch and worktree, and a live Kanban places every worker by its session, pull request, CI and review state. An orchestrator agent can delegate work to new workers, and actionable failures and review comments go back to the worker that owns the PR. Earlier releases (the npm @composio/ao CLI, last released as 0.2.2 in March 2026) ran from the command line with a dashboard at localhost:3000.

In the March 2026 CLI release, the reactions section of agent-orchestrator.yaml was the heart of the system (whether the desktop version keeps this schema is not confirmed). Each reaction bound an event type to an action: ci-failed → send-to-agent (the agent sees the CI logs and fixes the failure); changes-requested → send-to-agent (the review comments become a new prompt); approved-and-green → notify (or auto-merge if configured). Retries, escalation timeouts, and notifier choices (desktop, Slack, Discord, webhook) were configurable per-reaction.

That release also had a plugin architecture with seven slots --- Runtime (tmux or process), Agent (claude-code, codex, aider, opencode), Workspace (worktree or clone), Tracker (github, linear, gitlab), SCM (github, gitlab), Notifier (desktop, slack, discord, composio, webhook), Terminal (iterm2 or web) --- so teams could swap any layer without rewriting the orchestrator.

When to Use It

Teams running AI coding agents at fleet scale: dozens of issues per week, multiple agents in flight, CI and review feedback that should route back to the agent automatically. Anywhere the agent should react to repository events rather than be driven manually.

Alternatives --- GitHub Actions for simpler workflows where the agent runs as a step in a workflow. Background-coding agent platforms (Devin, Cursor agents) when you want a hosted product rather than a self-run orchestrator. Plain git worktree + tmux for one-off parallel sessions.

Sources

• github.com/OrchestratorInc/agent-orchestrator

• docs.orchestrator.inc

Example

A small team merges 50 PRs a week. They add each repo to Orchestrator.inc; the orchestrator agent triages incoming issues, spawns coding agents in worktrees, and routes CI failures and review comments back to the responsible agent. The team’s actual job becomes reviewing PRs and making judgment calls; the agents handle the loop.

Example artifacts

Trigger schema (March 2026 CLI release).

# agent-orchestrator.yaml (excerpt)

port: 3000

defaults:

runtime: tmux # or: process

agent: claude-code # or: codex, aider, opencode

workspace: worktree # or: clone

notifiers: [desktop] # or: slack, discord, webhook

projects:

my-app:

repo: owner/my-app

path: ~/my-app

defaultBranch: main

sessionPrefix: app

reactions:

ci-failed:

auto: true

action: send-to-agent

retries: 2

changes-requested:

auto: true

action: send-to-agent

escalateAfter: 30m

approved-and-green:

auto: false # flip to true for auto-merge

action: notify

Setup.

Download the desktop app for macOS, Windows or Linux from the GitHub releases page or docs.orchestrator.inc, open it, and add a repository. The app starts the local daemon itself.

Source: GitHub Actions (built into GitHub; YAML workflow files in .github/workflows/)

Intent

Use GitHub Actions’ native event triggers (push, pull_request, schedule, workflow_dispatch, repository_dispatch) to invoke AI coding agents on a repository.

Motivating Problem

For workflows that don’t need the parallel-agent coordination of Orchestrator.inc, GitHub Actions is already a complete event-trigger platform sitting next to the code. It has webhook integrations, scheduled triggers, manual triggers, repository-dispatch triggers from external systems, secrets management, and a billing model that’s familiar to engineering teams. Wrapping a coding agent (Claude Code, Codex, or a custom Anthropic API workflow) as an Action step gives an event-driven agent without operating a separate orchestrator.

How It Works

The team commits a .github/workflows/*.yml file with on: clauses that match events (issue_comment, pull_request, schedule, etc.). Steps in the workflow check out the repo, install dependencies, and call the agent --- either an off-the-shelf Action (the official anthropics/claude-code-action exists), a CLI install of Claude Code or Codex, or a custom Python script that calls the Anthropic API.

Outputs go back to the repository via the agent’s normal mechanisms: git push, gh pr create, gh issue comment. Secrets (ANTHROPIC_API_KEY, GITHUB_TOKEN) are managed by GitHub Actions’ secrets store. Concurrency, retries, and timeouts are configured per-workflow.

Limitations: each workflow run is a fresh ephemeral runner (no state across runs without an external store); the maximum runtime is 6 hours per job on GitHub-hosted runners (so long-running agent loops need to be persisted externally); schedule triggers run at most every 5 minutes, can be delayed at high load (especially on the hour), and may be dropped; cost is per minute of compute and adds the LLM call cost on top.

This entry covers Actions as a trigger surface. For the sandboxed runner GitHub built for agents (GitHub Agentic Workflows), see Volume 5, GitHub Agentic Workflows substrate.

When to Use It

Simple repository-event-triggered agent workflows: a nightly issue-triage agent (schedule: cron), a comment-triggered code-review agent (issue_comment), a PR-checker (pull_request). Anywhere the team already runs CI on GitHub and adding an Actions workflow is the lowest-friction path.

Alternatives --- Orchestrator.inc for parallel-agent fleets that need worktree isolation and reactive routing. Background coding platforms when the agent should run continuously rather than per-event. Inngest or Temporal when the workflow needs durable execution beyond Actions’ 6-hour run limit.

Sources

• docs.github.com/actions

• github.com/anthropics/claude-code-action

Example

A nightly issue-triage workflow: a schedule trigger fires at 02:00 UTC; the workflow checks out the repo, lists issues opened in the last 24 hours via gh, sends each issue body to an Anthropic API call for classification, and posts a triage label and a comment for each. Costs a few minutes of Actions compute and a handful of LLM tokens per night.

Example artifacts

Trigger schema.

# .github/workflows/triage.yml

name: Nightly Issue Triage

on:

schedule:

- cron: '0 2 * * *' # 02:00 UTC daily

workflow_dispatch: {} # manual fallback

jobs:

triage:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- name: Set up Claude Code

uses: anthropics/setup-claude-code@v1

with:

anthropic_api_key: \${{ secrets.ANTHROPIC_API_KEY }}

- name: Triage open issues

env:

GH_TOKEN: \${{ secrets.GITHUB_TOKEN }}

run: |

claude-code --task "Triage all issues opened in the last 24 hours;
label and comment per the rubric in TRIAGE.md."

Source: devin.ai, cursor.com/agents, GitHub Copilot coding agent, OpenAI Codex cloud, jules.google, cosine.sh, factory.com, others

Intent

Provide background coding agents that watch a repository, react to issues / PR comments / mentions, and produce PRs without the team operating the orchestrator themselves.

Motivating Problem

For teams that don’t want to run their own orchestrator (Orchestrator.inc, GitHub Actions, or a custom build), several hosted products provide background coding agents as a service. The agent is connected to the repository; events trigger work; the agent opens PRs and responds to comments. The team gets the reactive-agent experience without the operational tax.

How It Works

Each product has its own onboarding (connect GitHub, choose repos, configure permissions) but the operational shape is similar: events on the repo trigger the agent; the agent operates in a hosted sandbox; outputs come back as PRs and comments. The trigger is usually one of three: assigning an issue to the agent (GitHub Copilot coding agent starts when an issue is assigned to Copilot), an @mention in an issue or PR comment (@devin, @claude for Claude Code on GitHub), or a task handed over from a chat or IDE surface (OpenAI Codex cloud, Google Jules, Cursor agents). Devin, Cursor agents, Copilot, Codex, Jules, Cosine, and Factory each have distinctive product positioning, but the event-driven orchestration shape is the common feature. For the products themselves, see Volume 14, Devin, OpenAI Codex, Replit Agent (the autonomous async tier); this entry covers only the trigger shape.

The trade-off relative to self-hosted: less control over the agent’s exact model, prompt, and sandbox; less visibility into the orchestration; higher per-task cost but lower operational cost; and lock-in to the vendor’s product surface.

When to Use It

Teams that want background coding agents without operating any orchestration themselves. Pilots and proofs of concept where speed-to-value matters more than control. Workloads where the vendor’s opinionated product surface matches the team’s shape (e.g. Cursor users who want Cursor’s agents).

Alternatives --- Orchestrator.inc for the same shape with full control; GitHub Actions for simpler cases. Self-hosted is usually the right long-term choice once volume justifies the operational investment.

Sources

• devin.ai

• cursor.com/agents

• docs.github.com/copilot (Copilot coding agent)

• jules.google

• cosine.sh

• factory.com

Source: standardwebhooks.com and github.com/standard-webhooks/standard-webhooks (spec and reference libraries, Apache-2.0); webhook gateways such as Hookdeck Event Gateway

Intent

Accept inbound webhooks so that only authentic, fresh, first-time events start agent runs, and failed deliveries can be replayed instead of lost.

Motivating Problem

Webhooks are the most common external trigger (Appendix A), and every provider sends them a little differently. Senders retry on any non-2xx response or timeout, so the same event arrives more than once; anyone who finds the URL can post to it; a slow handler that runs the agent inline times out and triggers more retries. For an agent, each of these turns into a duplicate or forged run that calls models and tools with real side effects.

How It Works

The Standard Webhooks specification, written by a steering committee with engineers from Zapier, Twilio, Svix, Kong, ngrok, Supabase and others, fixes the shape of a signed webhook. Every delivery carries three headers: webhook-id (unique per event and unchanged across retries), webhook-timestamp (Unix seconds) and webhook-signature. The signature covers id.timestamp.body, using HMAC-SHA256 with a shared secret (prefix v1) or ed25519 (prefix v1a); during secret rotation the sender includes signatures from both keys. The spec publishes reference libraries for Python, JavaScript/TypeScript, Java/Kotlin, Rust, Go, Ruby, PHP, C# and Elixir.

The receiver’s checklist follows from the spec: verify the signature with a constant-time comparison; reject timestamps outside a small tolerance to block replay attacks; use webhook-id as the idempotency key (the spec’s example keeps seen IDs in Redis for a few minutes); return 2xx quickly and run the agent asynchronously, since senders typically time out after 15 to 30 seconds. On the sending side the spec recommends exponential backoff with jitter over several days, so receivers should expect the same event hours later.

A webhook gateway moves this work in front of the application. Hookdeck’s Event Gateway, for example, receives inbound webhooks, filters, transforms and routes them, queues them with rate control so a burst does not start hundreds of agent runs at once, and lets an operator replay failed events after a fix. Durable execution platforms (Inngest, Trigger.dev, DBOS) take the next step: the verified event ID becomes the run’s idempotency key.

When to Use It

Any agent started by a third-party webhook: GitHub, Stripe, Slack, CRM or ticketing events. Use the Standard Webhooks headers when you control the sender; put a gateway in front when several providers, bursts or replay after outages matter more than one less service.

Alternatives --- polling the provider’s API when it offers no webhooks or delivery is unreliable; a message bus (Section E) when the producer is your own system; the provider’s own SDK verification helper when only one provider is involved.

Sources

• standardwebhooks.com

• github.com/standard-webhooks/standard-webhooks (spec/standard-webhooks.md)

• hookdeck.com

Example

A GitHub issue-triage agent behind a gateway. GitHub posts issues events to the gateway, which verifies the signature, drops event types other than issues.opened, and forwards at most five events per second to the agent service. The service checks the delivery ID against a Redis set, returns 202, and starts a durable run keyed on that ID. When a bad deploy causes an hour of 500s, the operator fixes it and replays the failed events from the gateway; deliveries the agent had already handled are skipped by the ID check.

Source: github.com/n8n-io/n8n (Sustainable Use License, fair-code and source-available; JavaScript/TypeScript; self-host or n8n.cloud)

Intent

Build event-driven workflows with a visual graph editor and a large library of pre-built integrations, including LLM and agent nodes that work as first-class steps.

Motivating Problem

For workflows that span many SaaS sources --- a Slack mention triggers a Notion lookup which triggers a Google Calendar create which triggers an OpenAI summarization --- writing all the connector code is tedious. n8n provides 500+ pre-built integrations; the workflow author drags them on a canvas, configures the credentials and inputs, and the platform runs the orchestration. AI nodes (OpenAI, Anthropic, agents) are first-class; the platform also has an explicit “AI Agent” node that runs a configurable agent loop with tools.

How It Works

Workflows are visual graphs. Trigger nodes (cron, webhook, manual, app-specific webhooks like “Slack message received”) start a run; data flows along edges; action nodes do work. The workflow is JSON under the hood; for advanced cases there’s a Function node where you write JavaScript. The AI Agent node lets the workflow author configure a tools-using agent with the LLM model, system prompt, and which other n8n nodes the agent can invoke as tools.

Self-hosting is one Docker command (n8nio/n8n); the cloud offering handles operations. The license is n8n’s Sustainable Use License (fair-code, source-available, in place since 2022; files marked .ee. fall under a separate Enterprise License): free for internal business and personal use, with no commercial resale or hosting for others.

When to Use It

SaaS-heavy workflows where the connectors matter more than the orchestration. Teams that want the workflow editable by less-technical stakeholders (the visual canvas is the input artifact). Self-hosted deployments where the SaaS Zapier model isn’t acceptable.

Alternatives --- Zapier for the largest connector library and the most polished no-code experience. Pipedream when you want code-first with managed infrastructure. n8n is the right choice when self-hosting is required.

Sources

• n8n.io

• github.com/n8n-io/n8n

Example

A customer-onboarding workflow: a webhook from Stripe (new subscription) triggers; n8n looks up the customer in HubSpot, sends a welcome email via SendGrid, creates a Notion page with their account details, and runs an AI Agent node that drafts a personalized welcome message based on their HubSpot profile. The whole workflow is one visual canvas; the team edits it without writing code.

Example artifacts

Setup.

docker run -it --rm \

-p 5678:5678 \

-v ~/.n8n:/home/node/.n8n \

n8nio/n8n

# Then open http://localhost:5678

Source: zapier.com (SaaS, proprietary)

Intent

Connect SaaS apps via “Zaps” (trigger → actions) with a vast connector library, now extended with AI Agents that run multi-step LLM workflows.

Motivating Problem

Zapier is the incumbent. The connector library is unmatched (8,000+ apps), the no-code editor is the most polished, and most operations teams already know it. The 2024 Zapier Central beta, relaunched as Zapier Agents in January 2025, brought multi-step LLM workflows into the same platform: an agent can be triggered by any Zap, can use Zapier’s connectors as tools, and can run multi-step reasoning loops. For event-driven agent workflows tied to popular SaaS, Zapier is often the path of least resistance even when a developer would prefer to write code.

How It Works

A Zap binds a trigger (an event from one app, like “new row in Google Sheets”) to a series of actions in other apps. AI Agents extend this: the agent is a multi-step LLM-driven loop that can invoke Zapier actions as tools. Trigger events arrive via the connector’s webhook integration; the platform handles authentication, retries, and rate limits.

The trade-off compared with n8n or code-first platforms: less control over the LLM prompts, less observability into the agent’s reasoning, and per-Zap-run pricing that can add up. The trade-off compared with code: enormously faster time-to-value for SaaS-heavy workflows.

When to Use It

SaaS-heavy automations where the team already uses Zapier. Workflows where the agent’s job is to glue together SaaS apps rather than perform deep reasoning. Cases where less-technical stakeholders need to edit the workflow.

Alternatives --- n8n for self-hosted and source-available; Make.com for similar no-code with different pricing; Pipedream for a developer-oriented middle ground. Skip Zapier when the workflow has heavy LLM reasoning that justifies a code-first framework.

Sources

• zapier.com

• zapier.com/agents

Example

A sales follow-up workflow: a HubSpot deal moves to “Closed Won”; a Zapier Zap fires; the AI Agent step reads the deal context, drafts a personalized thank-you email, schedules a follow-up calendar event for 30 days out, and posts a celebration message in #sales-wins on Slack. Everything is one Zap; the team edits it from the Zapier UI.

Source: pipedream.com (Workday-owned since early 2026; SaaS, free tier) and github.com/activepieces/activepieces (community edition MIT, enterprise folders under a separate license)

Intent

Sit between Zapier (no-code, polished) and n8n (self-hosted, code-friendly): code-first workflow steps with managed infrastructure, full webhook surface, and a generous free tier.

Motivating Problem

Many developers want Zapier’s connector library and managed infrastructure but find the no-code editor too limiting once workflows get non-trivial. Pipedream and Activepieces are positioned exactly at that midpoint: each step in a workflow can be code (Node.js or Python in Pipedream; TypeScript in Activepieces), the platform handles event triggers and connector authentication, and the pricing is friendlier to high-volume developer use cases.

How It Works

A workflow has a trigger (HTTP webhook, schedule, app-specific event) and one or more steps. Steps can be pre-built actions (“post to Slack”) or code blocks where the author writes whatever logic they need (including LLM calls). Authentication for app integrations is managed by the platform.

Workday agreed to acquire Pipedream in November 2025 and now positions it as an integration layer for AI agents (3,000+ connectors through Pipedream Connect and MCP). Pipedream’s free tier and “one-click MCP server” feature (which exposes a Pipedream workflow as an MCP server reachable from Claude or Cursor) make it particularly popular for agent prototyping. Activepieces leans more open-source and self-hostable, with similar primitives.

When to Use It

Developer prototypes that need webhook handling and a few SaaS connectors without the operational tax of self-hosted alternatives. Workflows that mix code and pre-built actions. Cases where exposing a workflow as an MCP server is useful (Pipedream specifically).

Alternatives --- Zapier for the broadest connector library and the most polished UX; n8n for self-hosted; Inngest or Temporal when the workflow needs durable execution beyond what these platforms provide.

Sources

• pipedream.com

• github.com/activepieces/activepieces

Source: aws.amazon.com/eventbridge (managed; pay-per-event)

Intent

Route events between AWS services, SaaS apps, and custom applications via declarative pattern rules, with a schema registry that knows the shape of every event source.

Motivating Problem

Production event-driven systems that span AWS services (Lambda, SQS, Step Functions), SaaS apps (Stripe, Shopify, Datadog), and custom applications need a routing substrate that knows how to deliver each event to the right consumers. EventBridge is AWS’s answer: a managed bus where producers PutEvents, consumers register rules that match on event pattern (source, detail-type, content), and the platform handles delivery with at-least-once semantics and automatic retries.

How It Works

Event buses are namespaces (the default bus, plus custom buses per application or team). Rules specify the pattern (a JSON object that matches events by source, detail-type, account, or detail fields) and the target (Lambda, SQS, Step Functions, ECS task, API destination, or another EventBridge bus). The Schema Registry watches incoming events and discovers schemas automatically; code bindings can be generated for Java, Python, TypeScript.

For event-driven agents, EventBridge is the natural top-of-stack on AWS: webhook events arrive via an API Gateway endpoint, get PutEvents-ed to the bus, get routed by rules to specific Step Functions or Lambdas that invoke agents. Scheduling is built in: EventBridge Scheduler (2022) is the recommended successor to scheduled rules, which still work.

When to Use It

AWS-hosted agent systems that need a managed event substrate. Multi-team systems where different teams publish events and other teams consume them without direct coupling. Workloads that need pattern-based routing rather than topic-based subscription.

Alternatives --- Kafka when throughput or cross-cloud portability matters more than managed convenience; Cloudflare Workflows or upstash QStash for non-AWS deployments; SQS+SNS for simpler queue-fan-out without pattern matching.

Sources

• aws.amazon.com/eventbridge

• docs.aws.amazon.com/eventbridge

Example

A research-agent SaaS: Stripe webhooks for new subscriptions arrive at an API Gateway, get PutEvents-ed to the custom event bus, get routed by rule (source = stripe, detail-type = invoice.paid) to a Step Functions workflow that provisions the account, calls an Anthropic API agent to draft a welcome message, and emits a downstream account.provisioned event for other teams’ consumers.

Example artifacts

Trigger schema.

// EventBridge rule pattern (JSON):

{

"source": ["stripe.com"],

"detail-type": ["invoice.paid"],

"detail": {

"billing_reason": ["subscription_create"]

}

}

// Target: Step Functions ARN (or Lambda, ECS task, etc.)

Code.

# Python producer via boto3:

import boto3, json

client = boto3.client("events")

client.put_events(Entries=[{

"Source": "my-app.research",

"DetailType": "research.requested",

"EventBusName": "agents",

"Detail": json.dumps({

"topic": "vector retrieval benchmarks 2026",

"requestedBy": "user_42"

})

}])

Source: kafka.apache.org (Apache-2; self-host or hosted via Confluent / AWS MSK / Redpanda / Aiven)

Intent

Carry millions of events per second across many producers and consumers, with durable retention measured in days or weeks, and the strongest delivery semantics of any of the options in this section.

Motivating Problem

For systems where event volume exceeds what a managed bus can serve at reasonable cost (or where the application must own its substrate for portability), Kafka has been the standard answer for a decade. The premise: topics are ordered, durable, partitioned logs; producers append; consumers read by offset; many consumer groups can independently read the same topic. For agent systems that ingest large event streams (security telemetry, IoT data, financial market data), Kafka often sits below the agent orchestration layer.

How It Works

Topics are partitioned for parallelism; within a partition, order is preserved. Producers send messages with optional keys; the partitioner sends messages with the same key to the same partition. Consumers organize into consumer groups; the cluster assigns partitions to consumers so each message is delivered to exactly one consumer per group.

For AI agents, the dominant pattern is: events arrive on input topics (from a web app, mobile clients, IoT devices, partner integrations); a stream-processing layer (Kafka Streams, Flink, ksqlDB) filters and enriches; agent triggers consume from filtered topics; agent outputs (state changes, side effects) are published to output topics for downstream consumers. The substrate is operationally heavy but the throughput ceiling is essentially unbounded.

When to Use It

High-volume event-driven agent systems. Cross-cloud or on-prem deployments where managed AWS services aren’t an option. Workloads where strong ordering guarantees per partition matter. Teams already running Kafka for non-AI workloads.

Alternatives --- EventBridge on AWS for managed convenience; Redis Streams or NATS for lower-throughput, lower-operational-cost options; Pulsar or Redpanda as Kafka-compatible alternatives.

Sources

• kafka.apache.org

• confluent.io

Example

A security-operations platform that ingests millions of events per minute from endpoint sensors. Kafka topics by event type; a stream-processing layer enriches with context; an alerting topic filters to suspicious events; an agent-trigger consumer reads from the alerts topic, invokes a triage agent (via Inngest or Temporal), and publishes the agent’s findings to an output topic for SOC analysts.

Source: redis.io (Streams since 5.0); nats.io (NATS JetStream)

Intent

Provide event streaming and pub/sub with much lower operational footprint than Kafka, suitable for agent systems that don’t need Kafka’s scale.

Motivating Problem

Kafka is overkill for systems that process tens of thousands of events per day, not millions per second. EventBridge ties teams to AWS. Many agent systems sit in the middle: more than a single-process queue can handle but less than Kafka’s operational tax can justify. Redis Streams (already running in many stacks for caching) and NATS (a small, fast pub/sub server) fit this middle ground.

How It Works

Redis Streams: an append-only log data structure with consumer groups, XADD/XREADGROUP for produce/consume, explicit XACK acknowledgment with a pending-entries list for redelivery (XREADGROUP NOACK opts out), and replay by ID. Persistence comes from Redis’ AOF and RDB; durability is Redis-level, not Kafka-level. Many AI-agent stacks already running Redis for caching find Streams a one-line addition.

NATS JetStream: a separate distributed streaming server with at-least-once delivery, consumer groups, key-value store, and object store. The operational footprint is a single binary; the throughput sits between Redis Streams and Kafka. Both are open-source.

When to Use It

Agent systems that need a stream substrate without the Kafka operational tax. Stacks already running Redis or NATS for other purposes. Smaller-scale event-driven workloads (tens to hundreds of thousands of events per day).

Alternatives --- Kafka when scale demands it; EventBridge when running on AWS; in-process queues (Celery, RQ, BullMQ) when the producer and consumer are the same service.

Sources

• redis.io/docs/data-types/streams

• docs.nats.io/nats-concepts/jetstream

Source: GitHub Actions schedule, Modal scheduled functions, Vercel Cron, AWS EventBridge Scheduler, cron(1), Kubernetes CronJob

Intent

Fire events on a recurring schedule or at a specific future time, so agents can run periodic work without an external system to nudge them.

Motivating Problem

The simplest non-interactive agent trigger: “run this every N minutes” or “run this at 9am Monday.” Every production agent stack needs a way to express this; every cloud and CI platform has one; the abstractions look nearly identical across providers.

How It Works

The recurring case is universally expressed as a cron string (5-field cron, sometimes 6-field with seconds), often with a timezone. The one-shot case is a target timestamp. The trigger fires at the configured moment; the runtime invokes the registered handler.

Significant variation between providers in delivery semantics: AWS EventBridge Scheduler guarantees at-least-once delivery with a configurable flex window; GitHub Actions schedules can be delayed at high load, especially on the hour, and runs may be dropped; the minimum interval is 5 minutes; Vercel Cron has a minimum 1-minute granularity on paid plans; cron(1) on a single host has no failover. Production agent systems read the fine print before choosing.

For AI agents specifically, the most common patterns are: daily / hourly periodic reports (issue triage, status digests, monitoring summaries), inactivity timeouts (“if no message in 30 minutes, send a check-in”), and scheduled escalations (“if no human approval in 24 hours, escalate to the next manager”). Each is a scheduled trigger pointing at an agent runtime.

When to Use It

Periodic agent work that doesn’t depend on an external event. Daily summary agents, hourly health checks, weekly retrospectives. Pair with explicit cost caps (“max 10 LLM calls per scheduled run”) because schedule misconfigurations are the most common runaway-cost source.

Alternatives --- webhook triggers when the schedule should be set by an external system. Inactivity triggers in topic-trigger platforms (Copilot Studio) when the agent is conversational.

See Volume 19 (The Agentic Loop & Autonomy Catalog) for the invocation-side framing --- the Proactive / Scheduled Loop, where the cloud holds the stop decision with no human in real time --- and its distinction from the session-bound local Interval Loop.

Sources

• docs.github.com/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#schedule

• modal.com/docs/guide/cron

• docs.aws.amazon.com/scheduler/latest/UserGuide/what-is-scheduler.html

Example

A morning standup-summary agent. GitHub Actions schedule fires at 08:30 local time; the workflow runs an agent that reads yesterday’s Linear issue activity and Slack #engineering messages, drafts a summary, and posts to #standup. Costs a few cents of LLM tokens per run and a minute of Actions compute.

Example artifacts

Trigger schema.

# GitHub Actions:

on:

schedule:

- cron: '30 8 * * 1-5' # 08:30 Mon-Fri UTC

# Modal Python:

\@app.function(schedule=modal.Cron("30 8 * * 1-5"))

def morning_summary():

...

# Vercel Cron (vercel.json):

{

"crons": [{

"path": "/api/agents/morning-summary",

"schedule": "30 8 * * 1-5"

}]

}

Source: S3 Event Notifications, Google Drive Push Notifications, SharePoint Webhooks, Dropbox API webhooks, inotify/fsnotify

Intent

Fire events when files or storage objects change, so agents can react to incoming documents without polling.

Motivating Problem

A common agent shape is “when a document lands in {folder}, process it.” Doing this by polling is wasteful and slow. Every major storage system has a push-notification or event-emission feature that informs the agent runtime when something changed: an S3 ObjectCreated event, a Google Drive changes-API watch, a SharePoint webhook, an inotify watcher in a local filesystem. The agent listens; the trigger fires; the document gets processed.

How It Works

S3 Event Notifications: configure a bucket-level rule that emits events on object-created, object-removed, etc., to SNS, SQS, Lambda, or EventBridge. Delivery is at-least-once; events can be filtered by prefix and suffix.

Google Drive: the Changes API supports push notifications via webhook; expire and need refresh; deliver to an HTTPS endpoint.

SharePoint: webhook subscriptions on lists and document libraries; expiration up to 6 months; the webhook notifies of changes but doesn’t carry payload (the agent must query the change feed).

Local: inotify (Linux), FSEvents (macOS), fsnotify (cross-platform Go library) for filesystem watching in a long-running process. Less common in production agents but useful in dev environments and self-hosted Claude Code setups.

Across all of these, the operational discipline is the same: deduplicate (a single file upload can generate multiple events under retry), filter (only the events that matter for the agent’s job), and constrain (a folder receiving 1000 files per hour shouldn’t spawn 1000 agent runs without rate limiting).

When to Use It

Document-processing agents: a report uploaded to S3 triggers extraction-and-summarization; a Word doc into SharePoint triggers index update; a CSV into Google Drive triggers an analysis run. Anywhere the agent’s job is “wait for a file, then process it.”

Alternatives --- polling when push notifications aren’t available; webhook-based intake APIs (the user uploads via your own endpoint rather than landing in a third-party storage system).

Sources

• docs.aws.amazon.com/AmazonS3/latest/userguide/NotificationHowTo.html

• developers.google.com/drive/api/guides/push

Example

A contract-review agent: legal team uploads new contracts to an S3 prefix. ObjectCreated events fire to EventBridge; an EventBridge rule routes to a Step Functions workflow that invokes an agent; the agent extracts key clauses, flags issues against a rubric, and posts a review summary in Slack. The pipeline takes seconds; no polling involved.

Source: Copilot Studio, as documented in microsoft.github.io/agent-academy/operative/04-automate-triggers/

Intent

Standardize the inventory of in-conversation events an agent should be able to react to: “user said something,” “planner picked a topic,” “user has been silent,” “plan completed,” “typed activity received.”

Motivating Problem

When the agent runs in a conversational surface (Microsoft Copilot, an in-app assistant, Slack), the events that matter aren’t HTTP webhooks --- they’re patterns of user activity. A clean inventory of these patterns lets the agent author bind topic-handling code to specific event types without inventing a new abstraction for each. Copilot Studio documents nine topic trigger types (listed in Microsoft Agent Academy); similar events exist on other conversational platforms under other names.

How It Works

Copilot Studio’s nine trigger types: By Agent / Phrases (the planner matches by topic description or a literal phrase); Message Received (any incoming user message); Event Received (an emitted event in the conversation); Activity Received (any typed activity, like an adaptive-card submission); Invoke Received (a typed invoke action with a structured payload); Conversation Update (a member joined or left, conversation metadata changed); Inactivity (no activity for N seconds); Plan Complete (the current plan reached a terminal state); On Redirect (the conversation was redirected from another topic).

Each trigger has a well-defined firing condition and a payload shape. Authoring an agent means binding handlers to one or more of these triggers (a planner-driven agent uses By Agent; a check-in agent uses Inactivity; a finalizer uses Plan Complete). Roughly equivalent events exist in Slack interactivity events, Discord slash commands, in-app chat handlers, and LangGraph’s interrupt mechanism, though the mapping is this catalog’s, not Microsoft’s. The same Agent Academy page also covers event triggers for autonomous agents: connector-based triggers (new email, new file, recurrence) that start an agent with no conversation at all.

When to Use It

Conversational agents built in Copilot Studio (including agents published to M365 Copilot), or on any platform whose event vocabulary maps onto these nine categories.

Alternatives --- platform-specific event vocabularies when the agent runs only on one platform (Slack’s event-types, Discord’s interactions). LangGraph’s interrupt + Command(resume=…) pattern when the conversation is graph-shaped rather than topic-shaped.

Sources

• microsoft.github.io/agent-academy/operative/04-automate-triggers/

Source: Open Policy Agent (openpolicyagent.org), Cedar (cedarpolicy.com), emerging agent-governance frameworks

Intent

Fire events when a permission gate, budget threshold, or governance rule is crossed, so an agent’s action can be paused for review, escalated, or routed differently.

Motivating Problem

For agents that operate against real systems with real consequences (deploying to production, sending external email, charging payment methods), the moment a Tier 4 action (an external side effect, in the permission tiers of Volume 3, Chapter 5) is about to happen is the moment a policy engine should evaluate. A modest set of declarative rules (“if the action targets prod, require human approval”; “if the cumulative LLM cost this run exceeds $5, escalate”; “if the agent is about to modify more than 100 files, pause”) catches most of the worst-failure scenarios without slowing routine operations.

How It Works

OPA (Open Policy Agent) and Cedar are the two dominant general-purpose policy engines. Both take a policy expressed in a declarative language (Rego for OPA, Cedar policy language for Cedar) and evaluate it against an input (the proposed action and its context). The agent runtime queries the policy engine before every Tier 3+ action; if the policy says “require approval,” the agent runtime emits a human-approval event and waits.

Beyond the general engines, agent-specific governance layers such as Microsoft’s Agent Governance Toolkit (MIT, released April 2026) intercept every tool call and evaluate YAML, OPA/Rego or Cedar policies before it executes, adding audit logging and enforcement around the engine. As of October 2026 the space is still young. For the policy engines themselves, see Volume 12, Policy engines for agent authorization (OPA, Cedar, SpiceDB); this entry covers the trigger and pause behaviour.

When to Use It

Production agent systems with Tier 4 actions. Any deployment where audit trails and policy enforcement are compliance or risk requirements. Multi-tenant agent platforms where policies vary per tenant.

Alternatives --- hard-coded approval gates in the agent code when the policy is fixed and simple. Cloud-vendor IAM and resource-level policies for restrictions that fit the cloud’s model (S3 bucket policies, GCP IAM conditions).

Sources

• openpolicyagent.org

• cedarpolicy.com

• github.com/microsoft/agent-governance-toolkit

Source: agentops.ai (Python SDK; free tier; SOC 2 on enterprise)

Intent

Provide observability for agents built with any framework --- LangGraph, CrewAI, AutoGen, OpenAI Agents SDK, custom --- with the agent run as the central unit.

Motivating Problem

LangSmith’s tight integration with LangChain is also its constraint. Teams using CrewAI, AutoGen, or custom frameworks need an observability layer that doesn’t assume a particular agent framework. AgentOps targets that gap with a one-line auto-instrument SDK that hooks into 400+ LLM providers and agent frameworks.

How It Works

Install agentops; call agentops.init(); every LLM call, tool call, and span gets recorded with cost, latency, and content. Sessions group spans into the unit ‘one agent run’ (started by an event, ended on completion). The dashboard shows session waterfall, span tree, replay.

Comparable in feature surface to LangSmith but without the LangChain-specific affordances; comparable to Logfire but with agent-specific (not APM-specific) primitives.

When to Use It

Multi-framework agent stacks (CrewAI plus LangGraph plus custom code on the same system). Teams that want vendor neutrality from the start.

Alternatives --- LangSmith (Volume 7) when the entire stack is LangChain-shaped. Logfire or another OpenTelemetry backend (Volume 7) when the team already uses OpenTelemetry-based APM and wants agent observability under the same pane. Langfuse or Arize Phoenix (Volume 7) for an open-source, vendor-neutral option with more active development: AgentOps’ latest PyPI release is 0.4.21 from August 2025. See Volume 14, Agent observability platforms, for the wider comparison.

Sources

• agentops.ai

• github.com/AgentOps-AI/agentops

Appendix A --- Trigger Reference Table

Cross-reference between the three trigger sources (from Chapter 2) and the most common concrete trigger families. Use this to choose the right substrate for a given workflow.

Source	Trigger family	Examples / notes
External	Webhook (HTTP POST), SaaS app events	Most common; needs idempotency, dedup, DLQ
External	Repo / Git / CI events	PR opened, CI failed, review comment; Orchestrator.inc and GitHub Actions
External	Message / queue	Kafka, SQS, EventBridge, Redis Streams
External	File-system / storage	S3 events, Google Drive watch, SharePoint webhook
External	Email / chat	Inbound email, Slack mention, Teams chat
Temporal	Schedule (cron / recurrence)	Daily reports, hourly checks, weekly digests
Temporal	One-shot delay	Send follow-up in 24h, retry after 5m
Temporal	Inactivity timeout	No activity for N minutes → check in
Internal	Plan complete	Planner reached terminal state → finalize
Internal	Sub-agent returned	Delegated work finished → consume result
Internal	Memory key changed	Knowledge-base updated → re-index
Internal	Approval granted / denied	Human gate passed → proceed / abort

Appendix B --- The Trilogy + One

This catalog is the fourth volume of the Agentic AI Series, which now runs to nineteen volumes. The first four, read together, describe agentic AI at four levels of abstraction:

• Patterns of AI Agent Workflows (Vol. 1) --- the temporal patterns by which LLM calls, tools, and sub-agents compose. The vocabulary for how an agent run is structured in time.

• The Claude Skills Catalog (Vol. 2) --- the SKILL.md-format instruction packs that tell the model when and how to use tools. The vocabulary for the model’s domain knowledge.

• The AI Agent Tools Catalog (Vol. 3) --- the function-calling primitives that the agent invokes. The vocabulary for what the agent can do.

• The AI Agent Events & Triggers Catalog (this volume) --- the mechanisms by which agents are activated. The vocabulary for what makes the agent run.

The four levels are independent but composable. A production agent system makes choices at all four: a pattern (e.g. evaluator-optimizer from Vol. 1), the skills that load when relevant (Vol. 2), the tools the agent invokes (Vol. 3), and the events that trigger the agent in the first place (this volume). The choices interact --- a webhook-triggered agent using the autonomous-agent loop pattern, with the critical-code-reviewer skill loaded, calling GitHub MCP tools, looks materially different from a cron-triggered agent using the same pattern but different skill, tools, and trigger.

Appendix C --- Discovery and Awesome Lists

The event-driven agent orchestration ecosystem is young and moves fast; specific projects rise and fall over months. A few hubs that consolidate the current state:

• Awesome Agent Orchestrators (github.com/andyrewlee/awesome-agent-orchestrators) --- curated list categorized into Parallel Agent Runners (cmux, claude-squad, vibe-kanban, etc.), Personal Assistants (always-running variants), Multi-Agent Swarms (claude-flow, gastown), and Autonomous Loop Runners (the “Ralph” family).

• GitHub topic: agentic-orchestration --- the official topic tag aggregating new repos. Sub-topic tags include intent-to-task, agent-coordination, and parallel-agents.

• GitHub topic: agent-orchestration --- broader umbrella with most of the established frameworks.

• Microsoft Agent Academy (microsoft.github.io/agent-academy) --- Microsoft’s operative-mission curriculum covering trigger taxonomies, classic-vs-generative orchestration, and the patterns documented in Chapter 4 of this catalog.

• GitHub Resource: “What is AI agent orchestration” (github.com/resources/articles/what-is-ai-agent-orchestration) --- GitHub’s own enterprise-positioning piece on agent orchestration patterns for repository-driven workloads.

Three pragmatic rules. First, beware of star count: orchestration projects accumulate stars quickly during hype cycles, but durable usage is the better signal (look at “Used by” and “Dependent repositories” counts). Second, the framework-specific orchestrators (LangGraph for LangChain, CrewAI Flows for CrewAI) have stronger longevity than standalone alternatives because they ride their parent’s ecosystem. Third, the “awesome-X” lists are best treated as discovery tools, not as endorsements --- most entries are early-stage.

Appendix D --- Omissions

This catalog covers 23 frameworks, platforms and trigger families across 8 sections. The wider ecosystem is much larger; a non-exhaustive list of what isn’t here:

• General-purpose workflow engines without agent positioning: Airflow, Argo Workflows, Prefect, Dagster. The orchestration patterns transfer but the agent-specific framings don’t.

• Per-platform connector libraries: Power Automate connectors, Zapier Zaps, n8n nodes, Pipedream actions. The platforms are covered; the per-connector inventory would be too long.

• Vendor-specific BPM/BPMN suites (Camunda, Activiti, Bonita) when used without an AI agent layer. With an agent layer they belong in Section B.

• Frameworks and observability tools covered in other volumes: LangGraph and AutoGen / AG2 (Volume 9), Microsoft Agent Framework (Volume 5), LangSmith and OpenTelemetry GenAI / Logfire (Volume 7).

• Agent platforms that bundle orchestration with the product (LangSmith Deployment, formerly LangGraph Platform; Anthropic’s Managed Agents; OpenAI’s Assistants API). These are mentioned in passing within the relevant entries but don’t merit standalone entries.

• Background coding agent platforms (Devin, Cursor agents, GitHub Copilot coding agent, OpenAI Codex cloud, Jules, Cosine, Factory) get one composite entry in Section C; each has distinctive product positioning but the event-driven orchestration shape is the common feature.

• The “Ralph loop” family of autonomous agents (ralph-claude-code, ralph-orchestrator, etc.) --- useful for understanding the autonomous-loop pattern but mostly variations on the same Patterns-catalog primitive.

Appendix E --- A Note on the Moving Target

Anthropic published MCP in November 2024 and the Linux Foundation’s AAIF took over governance in December 2025. LangGraph reached 1.0 in October 2025 and passed 40K stars in 2026. CrewAI Flows shipped in late 2024 and rapidly became the deterministic counterpart to CrewAI’s autonomous Crews. Composio Agent Orchestrator launched in early 2026 as an npm CLI and by October had become Orchestrator.inc, a desktop app with over 13K stars. Inngest and Temporal both made explicit AI-agent positioning a marketing focus in 2025. The Anthropic Advisor tool entered beta in March 2026. The space is moving fast; this catalog captures a moment.

The deepest structural fact to internalize: the choice points are stable even though the specific products move. An event-driven agent system always answers four questions --- where do events come from, who routes them, how does state survive failures, and how do humans intervene. Choose well at each layer and the specific product is replaceable.

--- End of The AI Agent Events & Triggers Catalog v0.1 ---