Taxonomy tour

A guided walk through the event types every conformant consumer must understand, grouped by what they're for rather than reproduced as a table.

Categories, not a flat list

Every AEP type starts with a category (session, run, tool, attention, and so on). The category tells you what a type is about before you've read the rest of its name. AEP-0002 §3 defines the closed set of categories for 0.1 and what each one scopes to: a session, an agent, or session-or-agent for control. This tour walks the fourteen types every consumer must understand, the mandatory type set (AEP-0002 §4.1), by category, rather than restating that table verbatim.

Session and run: the shape of activity

session.started and session.ended bracket a whole conversation or unit of work. run.started, run.finished, run.failed, and run.cancelled bracket one activation within it: a turn, a task, a job. There are three distinct terminal types for a run rather than one type with a status field, deliberately: success, failure, and cancellation are meaningfully different outcomes for a fleet observer routing on type alone. See AEP-0002 §2 for the start/finish-pairing and distinct-terminal-states conventions that shape the whole taxonomy, not just this category.

Tool: what the agent actually did

tool.requested, tool.completed, tool.failed, and tool.denied cover one tool invocation end to end. tool.requested is a pre-execution fact: the tool is about to run. tool.denied is specifically for a policy/runtime block before execution, with no human involved. Compare attention.requested below, which is exactly the case where a human (or a policy delegate) has to decide.

Attention: the lifecycle this protocol exists for

what-and-why.md names this category as one of the three things no incumbent protocol carries as a first-class citizen. Four mandatory types trace one request from start to close:

attention.requested: the agent needs a human.
attention.answered: a response was produced, whether via a control command or out of band.
attention.resolved: the request's lifecycle closed.
attention.timeout: it expired unanswered, a terminal outcome in its own right, not a failure of the other three.

stateDiagram-v2
    [*] --> requested: attention.requested
    requested --> answered: attention.answered
    requested --> timeout: attention.timeout
    answered --> resolved: attention.resolved
    timeout --> resolved: attention.resolved
    resolved --> [*]

The full lifecycle is normative in AEP-0002 §7. That section also covers the optional attention.routed hop a consumer may emit when it forwards a request to a human surface, and the correlation rules that let a consumer reconstruct the whole loop even if it missed intermediate events. How a human's answer actually gets back to the agent is the control profile's job. See control-profile.md, which picks up this lifecycle from the other side.

Beyond the fourteen mandatory types

The mandatory set is a floor a consumer must understand, not a ceiling on what it might see. AEP-0002 also registers optional core types: things like session.compacted, run.step.started/finished, progress.*, delegation.subagent.*, and the agent.* presence/health/heartbeat family, which a conformant consumer should handle but must tolerate either way, the same as any type it doesn't recognize at all. See AEP-0002 §4.2 for that list, and §4.3 for the reserved message.* names a future sub-profile will fill in. Vendors can also carry runtime-specific detail through x.{vendor}.* extension types without touching the core namespace (AEP-0002 §6).