The AI Agent Events & Triggers Catalog

A Catalog of Reactive Orchestration

Draft v0.1

May 2026

Table of Contents

About This Catalog

This is the fourth volume in a catalog of the working vocabulary of agentic AI. The first volume cataloged the patterns by which LLM calls compose in time. The second cataloged the skills repositories that distribute model instructions in packaged form. The third cataloged the tools --- the typed function-calling primitives that agents invoke during a turn. This fourth volume catalogs the events and triggers --- the mechanisms by which agents wake up, react to the world, and coordinate across time.

Where the prior three volumes treated agents primarily as something a user initiates by typing into a chat, this volume reverses the polarity. The signals that activate an agent are the subject. A new email arrives in an inbox; a git push lands on a watched branch; a cron tick rolls over at 9 AM; a sub-agent finishes its plan; a customer abandons a session for 30 minutes. Each of these is an event, and the agent system that listens for it and responds is an event-driven orchestration.

“Event” and “trigger” have precise meanings here. An event is a signal that something has happened, carrying a structured payload that names what and gives the context. A trigger is the listener that turns events of a particular shape into agent invocations. Together they sit one layer above the tools layer: tools are how an agent acts; events and triggers are how an agent gets to act in the first place.

The catalog covers about twenty-six frameworks and platforms across eight sections: stateful graph and event-driven frameworks; durable execution platforms; CI and repository agent orchestrators; webhook and automation platforms; message buses and queues; file and schedule triggers; intent and policy-based triggers; and observability for event-driven agents. Each gets a Fowler-style entry: classification, intent, motivating problem, how it works, when to use it (with alternatives), sources, an example, and artifacts --- a setup snippet or a code excerpt, depending on what fits.

Scope

Coverage:

• Code-first stateful graph frameworks: LangGraph, CrewAI Flows, LlamaIndex Workflows, Microsoft Semantic Kernel Process Framework, AutoGen.

• Durable execution platforms that make long-running event-driven workflows reliable: Inngest, Temporal, Restate.

• CI and repository-driven orchestrators that react to PRs, issues, and build failures: Composio Agent Orchestrator, GitHub Actions as agent runner, Background-coding agent platforms.

• Webhook and low/no-code automation platforms: Zapier, Make.com, n8n, Pipedream/Activepieces.

• Message buses and queues: AWS EventBridge, Apache Kafka, Redis Streams.

• File-system, schedule, and intent-based triggers, including the Microsoft Agent Academy taxonomy of inactivity and plan-complete signals.

• Observability platforms purpose-built for event-driven agents: LangSmith, AgentOps, Logfire.

Out of scope:

• General-purpose workflow engines without an agent angle (Airflow, Argo, Prefect). The mechanisms transfer; the agent-specific framings don’t.

• Vendor-specific BPM/BPMN suites with deep enterprise tooling but minimal LLM-agent positioning.

• Per-platform connector libraries (Power Automate connectors, Zapier Zaps) catalogued individually --- the platforms are covered; the per-connector inventory is too large.

• LLM observability that isn’t event-driven-agent shaped (general LLM eval suites, prompt-engineering platforms).

How to read this catalog

Part 1 (“The Narratives”) is conceptual orientation: what an event is mechanically, the three sources from which events originate, the three orchestration topologies that organize event flow, the canonical trigger-type taxonomy (adapted from Microsoft Agent Academy), and the durable execution model that makes long-running event-driven agents reliable. Five diagrams sit in Part 1; everything in Part 2 is text and code.

Part 2 (“The Frameworks and Platforms”) is reference material organized by section. Each section opens with a short essay on what its entries have in common and how they relate to alternatives. Representative tools follow as individual Fowler-style entries. The entries are not meant to be read front-to-back; jump in via the table of contents to whatever matches the task at hand.

Part 1 — The Narratives

Five short essays frame the design space for event-driven agent orchestration. The reference entries in Part 2 assume the vocabulary established here.

Chapter 1. What an Event Is

An event, in the sense used throughout this catalog, is a discrete signal that something has happened, carrying a structured payload that names what happened and supplies the context an agent needs to act. The signal is asynchronous, the consumer is decoupled from the producer, and the payload is the contract between them. Where a tool call is initiated by the agent during a turn, an event is what causes a turn to begin in the first place.

The lifecycle has five recognizable steps. An event source emits a signal: an HTTP POST from a webhook, a file write that crosses a watcher, a cron tick, a message landing in a queue. A trigger --- a subscription, route, or listener --- evaluates each event against criteria and decides whether to fire. The orchestrator (a graph framework, a durable execution engine, a low-code platform) delivers the payload to the right agent or node. The agent runs, often using tools from the prior volume to read and write the world. Side effects propagate --- new events emit, downstream agents wake up, the loop restarts.

Three properties follow from this design. First, the producer doesn’t know about the consumer; an event source emits the signal whether anything is listening or not. Second, the consumer doesn’t have to be running at the moment of emission; events are queued, deferred, or persisted until a consumer is ready. Third, the system is fundamentally concurrent --- many events can be in flight at once, many consumers can react to the same event, and the orchestrator’s job is to keep state coherent across all of them.

Chapter 2. The Three Trigger Sources

Events come from three sources, and the distinction matters because each carries different reliability, latency, and ordering guarantees.

External sources are events from outside the agent system: a webhook from GitHub when a PR opens, an email arriving in an Outlook inbox, a Slack message in a watched channel, a file landing in S3 or SharePoint, a form submission, a message in a Kafka topic. These dominate production agent workloads; they’re also the noisiest --- producers retry on failure, sometimes deliver out of order, and occasionally lose events entirely. Production-grade event-driven agents handle external events with explicit idempotency, deduplication, and dead-letter handling.

Temporal sources are events fired by time itself, either by a schedule (cron, every fifteen minutes, every Monday at 9 AM) or by an absence (inactivity timeout: no message for ten minutes, no heartbeat for two hours). Temporal triggers are reliable in a way external ones aren’t --- the schedule fires deterministically --- but they’re also where agent systems most often accumulate cost without realizing it (a ten-minute recurrence on a Copilot Studio agent fires six times per hour, twenty-four hours a day, indefinitely).

Internal sources are events emitted by the agent system itself: a plan reaches a terminal state, a sub-agent returns a result, a graph node updates its memory, an approval is granted, a watched memory key changes. These are the events that knit a multi-agent system together; in graph frameworks they’re the edges, in pub-sub systems they’re published to internal channels. Internal events are the most reliable of the three (no network in between) but also the easiest to get into infinite loops if cycle detection is missing.

A well-designed event-driven agent makes the source explicit. Whether an event is external, temporal, or internal determines the dedup strategy, the retry budget, and where the system should fail loudly versus silently.

Chapter 3. Three Orchestration Topologies

Once events are arriving, the question becomes how to route them. Three topologies dominate; each has a different shape, different state model, and different debugging story.

The pipeline topology is the simplest: events arrive at step 1, flow to step 2, then step 3, etc. The flow is linear, state is implicit (whatever the previous step returned), and reasoning about the system means reading top to bottom. Pipelines are right for ETL-shaped work, for transformations, for any flow where the next step is uniquely determined by the previous one. They’re wrong when the system has loops, branches that re-merge, or multiple agents that need to react to the same event.

The graph topology makes nodes and edges first-class. A node is an agent or a function; an edge is a transition with a condition. The graph framework (LangGraph being the canonical example) holds the state object, evaluates conditional edges to decide where to route, and supports cycles --- the same node can be visited many times with evolving state. Graphs are right for stateful multi-agent systems with explicit branching: the planner-executor-reviewer loop, the iterative refinement pattern, the orchestrator-worker pattern. They’re wrong when the orchestration is trivially linear (overengineered) or when subscribers genuinely shouldn’t know about each other (too coupled).

The pub-sub bus topology decouples producers from consumers entirely. An event is published to a topic; any number of subscribers --- zero, one, many --- react independently. State is held in each subscriber, not centrally. Pub-sub is right for fan-out work (one event drives many parallel sub-agents), for cross-team integration where the producer shouldn’t know about all the consumers, for high-volume systems where each subscriber can scale independently. It’s wrong when the workflow needs a single coherent state, when ordering across subscribers matters, or when debugging a flow requires reconstructing a multi-hop conversation from logs.

Most real systems mix the three. A graph framework at the top routes the high-level flow; pub-sub buses underneath fan work out to many parallel agents; pipelines inside each subscriber do the linear transformation work. Choosing the topology is choosing where the state lives.

Chapter 4. The Trigger Type Taxonomy

Microsoft Agent Academy distinguishes two top-level categories of triggers, and the distinction maps cleanly onto every other event-driven agent platform once the names are stripped away.

Topic triggers are conversation-activity starters. A user types something and a topic fires --- either because the planner picked it by description (the “By agent” trigger), because a specific phrase matched, because any message was received, because the channel saw a typed activity (an adaptive-card submission, an invoke), because the user has been silent for some configured duration (the Inactivity trigger), or because a plan reached a terminal state (Plan complete). Topic triggers are how interactive agents react to humans in the loop.

Event triggers are external system events delivered via connectors. New emails, files, calendar events, form submissions, database row changes, webhooks from third-party services, recurring schedule ticks. The agent author configures a connector, supplies authentication, optionally constrains the trigger with a payload filter, and gets a structured payload delivered when the event fires. Event triggers are how autonomous agents react to the world without a human starting the conversation.

Most production agent systems use both categories. The interactive surface lets humans drive the agent for ad-hoc work; the autonomous surface lets the agent take action on its own when the world changes. The category choice has operational implications: topic triggers run within the conversation’s authentication and billing context, where event triggers typically run under the agent author’s account and consume background-execution capacity. The accounting is different, and so are the failure modes.

The same distinction shows up under different names in the rest of the ecosystem. LangGraph distinguishes between user-initiated invocations and system-emitted node transitions. Inngest distinguishes between user actions and scheduled or webhook-driven events. Zapier distinguishes between manual zaps and triggered zaps. The taxonomy in this chapter --- conversation-activity versus external-system event --- maps cleanly onto all of them.

Chapter 5. Durable Execution, Checkpoint, and Replay

Event-driven agents fail. Networks drop packets, processes crash, deployments mid-flight kill in-progress runs, the third-party service the agent was waiting on returns a 503. The dominant operational concern in production event-driven agents is therefore reliability --- specifically, the ability to resume from where a run left off rather than restart from the beginning.

Durable execution is the term of art for the property that solves this. A durable execution engine --- Temporal, Inngest, Restate, the LangGraph checkpointer, the AutoGen runtime --- persists the state of every step as it completes. On crash or restart, the engine reads the log, identifies the last successfully completed step, and resumes the run from that point rather than re-executing everything from the start. The work the engine does to make this safe is non-trivial: it must record each step’s inputs and outputs, prevent re-execution of side-effectful steps that already ran, and reconcile concurrent attempts to advance the same run.

Three implementation strategies dominate. Event-sourcing engines (Temporal, Restate) treat the run as a sequence of events; replaying the events deterministically reconstructs the state. Checkpointing engines (LangGraph) snapshot the graph’s state object at every transition; resume reads the latest snapshot and dispatches from there. Step-function engines (Inngest, AWS Step Functions) externalize the orchestration to the engine and execute each step as a separately-recorded unit of work. All three give the same operational guarantee: a process crash mid-run doesn’t lose work.

The operational test is simple. Start a multi-step agent run. Kill the process at step three. Restart. If the agent resumes at step three (or four, if step three completed before the kill) rather than re-running step one, you have durable execution. If it restarts from the beginning, you don’t --- and any side-effectful step one will execute twice, which in production usually means duplicate emails sent, duplicate payments charged, or duplicate database writes attempted.

Durable execution is the foundation that makes event-driven agents safe to run unattended for hours, days, or weeks. Most of the platforms in this catalog’s Section B (Durable execution platforms) are built around this property as their central proposition; most of the platforms in Section A (Stateful graph frameworks) have it as a configurable feature.

Part 2 — The Frameworks and Platforms

Eight sections follow. Each opens with a short essay on what its entries have in common and how they relate to alternatives. Representative platforms are presented in the same Fowler-style template used by the prior three catalogs.

Sections at a glance

• Section A --- Stateful graph & event-driven frameworks

• Section B --- Durable execution platforms

• Section C --- CI and repository agent orchestrators

• Section D --- Webhook & automation platforms

• Section E --- Message buses & queues

• Section F --- File system & schedule triggers

• Section G --- Intent and policy-based triggers

• Section H --- Observability for event-driven agents

Section A — Stateful graph and event-driven frameworks

Code-first frameworks where the agent’s execution IS a graph

Four frameworks dominate the code-first stateful-graph category, plus one notable conversational-multi-agent alternative. LangGraph is the incumbent and the most-used: 26K+ GitHub stars, Pregel-inspired supersteps, with checkpointing and durable execution built in. CrewAI Flows is the event-driven half of CrewAI --- a different design philosophy from CrewAI’s autonomous “Crews,” adding explicit execution paths and conditional branching. LlamaIndex Workflows is the third major contender, with a step-and-event API distinctive enough that it earns its own entry. AutoGen rounds out the section as the conversational-multi-agent alternative --- Microsoft’s framework where agents talk to each other rather than transitioning between graph nodes.

The shared design assumption: the agent author writes Python (or TypeScript), and the framework gives runtime guarantees around state persistence, replay, human-in-the-loop interrupts, and visual debugging. Choose by the shape of the work, not by which framework has the highest star count.

LangGraph

Source: github.com/langchain-ai/langgraph (26.2k stars, MIT)

Classification Stateful graph framework, code-first, Python and TypeScript.

Intent

Build resilient, long-running, stateful language agents as graphs of nodes and conditional edges, with durable execution and human-in-the-loop interrupts as first-class concerns.

Motivating Problem

A typical agent loop is more than a single LLM call --- it’s a sequence with conditional branches, retries, sub-agent dispatches, and persistent state that should survive a process restart. Writing this directly produces a tangle of if-statements, try/excepts, and database calls. LangGraph factors the structure out: nodes are pure functions over typed state; edges are transitions (possibly conditional); the runtime handles checkpoint, retry, and resume.

How It Works

The author defines a typed state object (typically a TypedDict), creates a StateGraph, adds nodes as Python functions that take the current state and return an update, and adds edges (sequential, conditional, or to special targets like START and END). compile() produces a callable graph object. invoke() runs the graph to completion; stream() yields intermediate state; with_config(thread_id=”…”) binds the run to a persistent thread.

Behind the scenes, the framework implements a Pregel-inspired execution model (acknowledged in the README): nodes that depend on the same state run in supersteps; checkpointers (in-memory, SQLite, Postgres, or the LangGraph Cloud) snapshot state at every transition. interrupt() lets the graph pause for human input --- the run persists in the checkpointer, and resuming is as simple as Command(resume=value).

Inspired by Apache Beam and NetworkX in addition to Pregel; the README emphasizes that LangGraph can be used standalone without LangChain.

When to Use It

Multi-step stateful agents with branching: planner-executor-reviewer loops, iterative refinement (evaluator-optimizer pattern from the Patterns catalog), routing where the next node depends on intermediate results. Human-in-the-loop where the agent pauses, asks the human, then resumes with the answer.

Alternatives --- CrewAI Flows for a similar event-driven graph model with a CrewAI ecosystem; LlamaIndex Workflows for a step-based alternative; AutoGen when the workflow is genuinely conversational between agents. Skip LangGraph for trivially linear pipelines where a plain function call is enough.

Sources

• github.com/langchain-ai/langgraph

• docs.langchain.com/oss/python/langgraph/overview

• Pregel: A System for Large-Scale Graph Processing (Google Research, 2010)

Example

A research assistant that plans queries, dispatches to search tools, evaluates the results, and decides whether to refine the plan. Each step is a node; a conditional edge from the evaluator decides between “refine plan” and “synthesize answer”. The state object carries query history, retrieved documents, and the current plan. The checkpointer persists state at every transition; a process restart resumes the run without losing context.

Example artifacts

Setup.

pip install -U langgraph

Code.

from langgraph.graph import START, StateGraph

from typing_extensions import TypedDict

class State(TypedDict):

text: str

def node_a(state: State) -> dict:

return {"text": state["text"] + "a"}

def node_b(state: State) -> dict:

return {"text": state["text"] + "b"}

graph = StateGraph(State)

graph.add_node("node_a", node_a)

graph.add_node("node_b", node_b)

graph.add_edge(START, "node_a")

graph.add_edge("node_a", "node_b")

print(graph.compile().invoke({"text": ""}))

# {'text': 'ab'}

CrewAI Flows

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

Classification Event-driven graph framework, complementary to CrewAI's autonomous Crews.

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

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()

LlamaIndex Workflows

Source: github.com/run-llama/llama_index (Python, MIT; Workflows module)

Classification Step-and-event framework, code-first.

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

The author subclasses Workflow, defines step methods decorated with @step, and uses Pydantic-shaped Event classes. 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 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.

Sources

• docs.llamaindex.ai/en/stable/module_guides/workflow/

• github.com/run-llama/llama_index

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))

AutoGen

Source: github.com/microsoft/autogen (Python and .NET, MIT)

Classification Conversational multi-agent framework, event-driven via inter-agent messaging.

Intent

Coordinate multiple agents through asynchronous message passing, with each agent following a conversation pattern (initiator, responder, group chat).

Motivating Problem

For some problems, the natural decomposition isn’t a graph of typed steps but a group of agents holding a conversation. A user-proxy agent receives the request; a planner agent emits a plan; an executor agent runs the plan; a critic agent reviews; the planner revises; the loop converges. AutoGen models this directly: agents have conversations; messages are the events; the runtime routes messages between agents.

How It Works

AutoGen v0.4 (the current major version) introduces a layered architecture: AutoGen Core (a low-level actor framework with explicit messages), AutoGen AgentChat (the higher-level abstraction for conversational multi-agent flows), and AutoGen Extensions (LLM clients, tools, code executors). The actor model under AutoGen Core uses single-threaded actors that process messages from a mailbox; messages cross the wire via a runtime that handles serialization, persistence, and distributed deployment.

Agents are typed by their role. RoutedAgent dispatches messages by type; AssistantAgent wraps an LLM call; UserProxyAgent represents a human; GroupChatManager coordinates a multi-agent conversation. Tools and code execution are first-class; the framework includes sandboxed Python executors and tool interfaces.

When to Use It

Multi-agent problems where the agents have distinct roles and the work is genuinely conversational --- multiple specialized agents collaborating, with the conversation transcript as the system’s record. Distributed deployments where agents run in different processes or services.

Alternatives --- LangGraph when the right metaphor is typed state flowing through a graph; CrewAI when the autonomous-Crew model fits; Microsoft Semantic Kernel Process Framework when you’re on the Microsoft enterprise stack and need BPM-style workflows.

Sources

• github.com/microsoft/autogen

• microsoft.github.io/autogen

Example

A code-review workflow: a Reviewer agent reads a diff and emits review comments; an Author agent reads the comments and proposes fixes; a Tester agent runs the proposed fix in a sandbox; a Coordinator decides when consensus has been reached. The conversation transcript captures the entire negotiation; the runtime persists messages and handles delivery.

Example artifacts

Setup.

pip install autogen-agentchat autogen-ext[openai]

Code.

from autogen_agentchat.agents import AssistantAgent

from autogen_agentchat.teams import RoundRobinGroupChat

from autogen_ext.models.openai import OpenAIChatCompletionClient

model = OpenAIChatCompletionClient(model="gpt-4o")

planner = AssistantAgent("planner", model_client=model,
system_message="Plan the task.")

executor = AssistantAgent("executor", model_client=model,
system_message="Execute the plan.")

team = RoundRobinGroupChat([planner, executor], max_turns=4)

result = await team.run(task="Build a CSV summarizer.")

Section B — Durable execution platforms

Platforms whose core proposition is reliable, replayable, long-running execution

Where stateful graph frameworks make checkpointing a feature, durable execution platforms make it the entire product. The premise: write your workflow as ordinary code (Python, TypeScript, Go); the platform records every step, persists every input and output, and replays deterministically on crash. LLM calls become just one kind of step among many. The result is a workflow that can run for hours, days, or weeks across deploys, network failures, and process crashes --- the property required for production event-driven agents that wait on external systems.

Three platforms dominate at different ends of the spectrum: Inngest (developer-experience-first, hosted, free tier), Temporal (battle-tested at scale, self-hostable, the incumbent), and Restate (newer, single-binary, distributed-system-shaped). All three handle the same core problem; the choice is operational.

Inngest

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

Classification Durable workflow platform with explicit AI-agent positioning.

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/ai/overview

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 })

);

}

);

Temporal

Source: temporal.io (Go, Java, Python, TypeScript, .NET, PHP SDKs; OSS Apache-2)

Classification Durable execution platform, battle-tested at scale, self-hostable.

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).

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

• 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

Restate

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

Classification Durable execution platform, single-binary, distributed-systems-positioned.

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.

Section C — CI and repository agent orchestrators

Platforms that wire AI coding agents to repository events: PRs, CI failures, review comments

A specialized but high-leverage category: orchestrators that hold the relationship between repository events and AI coding agents. Composio Agent Orchestrator is the most-developed example --- 5.8K stars, a YAML-configurable reaction layer that spawns parallel agents in git worktrees in response to PR-opened, CI-failed, and review-comment events. GitHub Actions, used judiciously, becomes a serviceable equivalent for simpler cases. A handful of background-coding agent platforms (Devin, Cursor agents, Cosine) blur the boundary between this section and Section A, embedding the orchestration into a hosted product.

The shared challenge is the reaction pattern: events arrive (PR opened, CI failed, reviewer requested changes); rules decide which agent to invoke; the agent runs in an isolated workspace; results emit new events (a new commit, a PR comment, a status change). The dominant operational concern is cost containment --- each agent run can call an LLM many times, so the trigger rules need to be narrow and the retry budgets explicit.

Composio Agent Orchestrator

Source: github.com/ComposioHQ/agent-orchestrator (5.8k stars, MIT, npm @composio/ao)

Classification Multi-agent code orchestrator with declarative reaction rules.

Intent

Spawn parallel AI coding agents (Claude Code, Codex, Aider, OpenCode) on a single repo, each in its own git worktree, with declarative YAML rules for reacting to CI failures, review comments, and PR approvals.

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. Composio Agent Orchestrator handles the coordination: each agent works in its own git worktree, declarative rules route CI failures and review comments back to the responsible agent, a dashboard shows fleet state, and the human gets pulled in only when judgment is needed.

How It Works

Install with npm install -g @composio/ao; run ao start either pointed at a remote repo URL or from inside a local clone. The CLI generates an agent-orchestrator.yaml with defaults; the dashboard at localhost:3000 shows every active session. The orchestrator agent itself uses the AO CLI to manage worker sessions; you don’t learn or use the CLI directly.

The reactions section of the YAML is the heart of the system. Each reaction binds 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) are all configurable per-reaction.

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) --- lets teams swap any layer without rewriting the orchestrator. 3,288 test cases in the released codebase; March 2026 latest release.

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/ComposioHQ/agent-orchestrator

• platform.composio.dev

Example

A small team merges 50 PRs a week. They run ao start on each repo; 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.

# 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.

npm install -g \@composio/ao

# Start against a remote repo:

ao start https://github.com/your-org/your-repo

# Or from inside a local repo:

cd ~/your-project && ao start

# Dashboard opens at http://localhost:3000

GitHub Actions as agent runner

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

Classification Event-trigger platform repurposed as an agent runner.

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 Composio AO, 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 (so long-running agent loops need to be persisted externally); cost is per minute of compute and adds the LLM call cost on top.

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 --- Composio AO 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."

Background coding agent platforms

Source: devin.ai, cursor.com/agents, cosine.sh, factory.ai, others

Classification Hosted multi-agent code platforms with event-driven orchestration built in.

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 (Composio AO, 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 (an issue mentions @devin, a PR review comment tags an agent) trigger the agent; the agent operates in a hosted sandbox; outputs come back as PRs and comments. Devin, Cursor agents, Cosine, and Factory each have distinctive product positioning (Devin emphasizing autonomous long-running work; Cursor agents tightly integrated with the Cursor IDE; etc.) but the event-driven orchestration shape is the common feature.

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 --- Composio AO 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

• cosine.sh

Section D — Webhook and automation platforms

Low/no-code platforms that route webhooks, schedules, and SaaS events into agent workflows

Before the AI-agent wave, an entire generation of products solved the “when X happens, do Y” problem for SaaS workflows: Zapier, Make.com (formerly Integromat), n8n, Pipedream, Activepieces, and several others. All of them have, in the last two years, added LLM and agent steps as first-class actions. For event-driven agent workflows that need to react to dozens of SaaS sources (Stripe, Slack, Notion, Google Workspace, HubSpot, Salesforce), these platforms remain the path of least resistance: the connectors are already written, the trigger and webhook plumbing exists, and the LLM step is one more node.

Three platforms cover the spectrum: n8n is open-source, self-hostable, code-friendly; Zapier is the incumbent SaaS, no-code-first, with the largest connector library; Pipedream and Activepieces sit between, with developer-oriented APIs and code steps.

n8n

Source: github.com/n8n-io/n8n (Apache-2 fair-code; JavaScript/TypeScript; self-host or n8n.cloud)

Classification Open-source workflow automation with AI nodes.

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 400+ pre-built nodes; 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 fair-code (Apache-2 with an additional commons clause) --- free for most uses, restricted for resale.

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

Zapier (with AI Agents)

Source: zapier.com (SaaS, proprietary)

Classification No-code workflow platform, 7,000+ connectors, AI features added 2023+.

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 (7,000+ apps), the no-code editor is the most polished, and most operations teams already know it. The 2024 introduction of Zapier AI Agents 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 open-source; 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/ai

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.

Pipedream / Activepieces

Source: pipedream.com (SaaS, free tier) and github.com/activepieces/activepieces (OSS)

Classification Developer-first automation platforms with AI workflows.

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.

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

Section E — Message buses and queues

Where events live in transit --- EventBridge, Kafka, Redis Streams

Below the orchestration layer, every event-driven agent system needs a substrate that carries events from producers to consumers. Three options dominate at very different scales: AWS EventBridge for managed pattern-matching event buses on the AWS ecosystem; Apache Kafka for high-throughput durable event streaming as a separate platform; Redis Streams (and NATS) for lightweight pub/sub when the operational footprint of Kafka isn’t justified. The agent orchestration platforms in Sections A and B sit on top of one of these; even when the platform abstracts the substrate, knowing which substrate is appropriate informs the choice.

The dimensions of choice are throughput (events per second), retention (how long events live), delivery semantics (at-most-once, at-least-once, exactly-once), fan-out (how many consumers per event), and operational footprint (hosted vs self-hosted).

AWS EventBridge

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

Classification Managed event bus with pattern matching and schema registry.

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 replaced CloudWatch Events Scheduled Rules in 2022).

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"

})

}])

Apache Kafka

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

Classification High-throughput durable event streaming platform.

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.

Redis Streams / NATS

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

Classification Lightweight pub/sub and stream substrates.

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, automatic message-acknowledgment, 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

• nats.io/jetstream

Section F — File system and schedule triggers

Triggers from time and from filesystem state changes

Two trigger families share this section because both are foundational and both are easy to get wrong. Schedule triggers (cron, recurrence) are reliable but easy to overschedule --- a fifteen-minute recurrence fires 96 times per day, an hourly recurrence 24 times, and an unbounded agent run multiplied by either of those is a runaway-cost incident waiting to happen. File-system triggers (S3 events, Google Drive watch, fsnotify) are powerful for document-processing agents but have surprising delivery semantics across providers --- some are at-least-once, some are at-most-once, some lose events on producer-side throttling.

The shared design discipline: explicit deduplication keys on every trigger, explicit budgets per trigger family, and observability that ties every agent run back to the trigger that fired it.

Schedule and cron triggers

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

Classification Temporal trigger family.

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 by up to 15 minutes during high load and may skip if a previous run is still in progress; 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 (Microsoft Agent Academy) when the agent is conversational.

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/

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"

}]

}

File-system and storage triggers

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

Classification External trigger family (file-system source).

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.

Section G — Intent and policy-based triggers

Triggers that fire on agent or conversation state, not on external events

The trigger families in Sections D, E, and F all originate outside the agent. The two families in this section originate inside the conversation or governance layer: intent triggers (the planner picks a topic, the user matches a phrase, the conversation goes silent for N seconds) and policy-based triggers (a permission gate fires, a budget threshold crosses, a governance rule matches). Microsoft Agent Academy’s taxonomy of “topic triggers” (Chapter 4) is the most-developed framing for the intent half; OPA, Cedar, and emerging agent-governance frameworks supply the policy half.

Topic triggers (Microsoft Agent Academy taxonomy)

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

Classification Intent trigger family (conversation-internal events).

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. Microsoft Agent Academy proposes nine canonical topic triggers; the same nine show up under different names in other conversational platforms.

How It Works

The nine canonical triggers: 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). The same vocabulary maps onto Slack interactivity events, Discord slash commands, in-app chat handlers, and LangGraph’s interrupt mechanism.

When to Use It

Conversational agents on any platform that adopts the Microsoft Agent Academy framing (Copilot Studio, M365 Copilot) or 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/

Policy and governance triggers

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

Classification Policy trigger family (rule-engine-driven gates).

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 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, several agent-specific governance frameworks (Mira, Aegis, vendor-specific governance products) wrap policy evaluation with audit logging, budget tracking, and connector-level enforcement. The space is young; expect significant evolution over 2026.

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

Section H — Observability for event-driven agents

Tools that make event-driven agent runs visible, debuggable, and improvable

An agent system that reacts to events is, by construction, more complex to debug than a synchronous chat agent. Runs are triggered from many sources, can be paused and resumed across hours or days, and pass through many tools and sub-agents. Three observability tools dominate: LangSmith (the LangChain-ecosystem incumbent, tightly integrated with LangGraph), AgentOps (vendor-neutral, oriented around the agent run as the unit of observability), and Logfire / OpenTelemetry GenAI (the emerging standards approach that re-uses APM infrastructure).

All three answer the same operational questions: which event triggered this run, what did the agent do at each step, where did time and cost go, what was the LLM’s reasoning at each call, where did the run fail or stall, how does today’s behavior compare with yesterday’s.

LangSmith

Source: smith.langchain.com (SaaS, free tier; self-hostable in enterprise)

Classification Agent observability and evaluation, LangChain-ecosystem-native.

Intent

Trace, debug, evaluate, and continuously improve LLM and agent applications, with first-class support for LangGraph and LangChain.

Motivating Problem

For teams building on LangChain or LangGraph, LangSmith is the path of least resistance for observability: a single environment variable enables tracing, traces show up immediately, the UI knows the LangGraph state model, and the evaluation framework integrates with the same agent code.

How It Works

Set LANGSMITH_API_KEY and LANGSMITH_TRACING=true; every LangChain/LangGraph run produces a trace tree in the dashboard. Each LLM call, tool call, and graph node is a node in the tree, with inputs, outputs, latency, token counts, and costs. Eval datasets can be built from production traces and run against new agent versions for regression testing.

For event-driven agents specifically, the trace tree shows every step from event ingress through agent completion; the metadata captures which event ID triggered the run; production data feeds back into eval sets via the LangSmith API.

When to Use It

Teams building on LangChain or LangGraph. The integration is so tight that there’s little reason not to use it for the observability surface.

Alternatives --- AgentOps for vendor-neutral observability; Logfire for OpenTelemetry-shaped observability that reuses APM infrastructure.

Sources

• docs.langchain.com/langsmith/home

Example

A LangGraph-based research agent in production. Every event-triggered run produces a LangSmith trace; on user-reported issues, the engineer pastes the run ID and sees the full agent reasoning, every LLM call, every tool output. Regression tests run against the eval set before each deploy.

AgentOps

Source: agentops.ai (Python and TypeScript SDKs; free tier; SOC 2)

Classification Vendor-neutral agent observability platform.

Intent

Provide observability for agents built with any framework --- LangGraph, CrewAI, AutoGen, OpenAI Agents SDK, custom --- with the agent run as the central unit and an MCP server option for in-IDE integration.

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; the MCP server option exposes recent session traces to Claude Code or Cursor for inline debugging.

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. Cases where in-IDE trace replay (via the MCP integration) speeds debugging.

Alternatives --- LangSmith when the entire stack is LangChain-shaped. Logfire when the team already uses OpenTelemetry-based APM and wants agent observability under the same pane.

Sources

• agentops.ai

• github.com/AgentOps-AI/agentops

Logfire / OpenTelemetry GenAI

Source: logfire.pydantic.dev; opentelemetry.io GenAI semantic conventions

Classification Observability via OpenTelemetry, agent-aware.

Intent

Use the same observability infrastructure as the rest of the application stack --- OpenTelemetry traces, metrics, logs --- with conventions that capture agent and LLM call semantics.

Motivating Problem

Many engineering teams already run APM (Datadog, Honeycomb, Grafana Tempo) and don’t want a separate observability silo for agents. The OpenTelemetry GenAI semantic conventions (stable as of 2025) define how LLM calls, agent runs, tool invocations, and prompts should be represented as OpenTelemetry spans; Logfire is Pydantic’s commercial implementation that adds agent-specific UI on top.

How It Works

Instrument the application with OpenTelemetry SDKs (Python, Node, Go, Java, others). Use the GenAI semantic conventions (or Pydantic’s pydantic-ai instrumentation, which produces them automatically) for LLM calls and agent operations. Spans flow to any OTLP-compatible backend: Logfire, Honeycomb, Grafana, Datadog, Jaeger, Tempo.

For event-driven agents, the trace context propagates across the event boundary (events carry trace headers; downstream consumers continue the trace), so a single distributed trace can show the entire event-trigger-agent-tool chain across services.

When to Use It

Engineering teams with existing OpenTelemetry-based APM that want to bring agents into the same observability surface. Distributed agent systems where trace propagation across services matters. Workloads with strict data residency where a SaaS LangSmith or AgentOps isn’t acceptable.

Alternatives --- LangSmith for LangChain stacks; AgentOps for the agent-specific dashboard.

Sources

• logfire.pydantic.dev

• opentelemetry.io/docs/specs/semconv/gen-ai/

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; Composio AO 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 in a four-volume series. Read together, they 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 about 23 frameworks and platforms 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.

• Agent platforms that bundle orchestration with the product (LangSmith’s LangGraph Cloud, 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, 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 hit 1.0 in 2024 and reached 26K stars by mid-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 and grew to 5.8K stars in months. 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 ---