Notification is an interaction pattern in which an actor announces that something has happened without directing any specific response. It is the declarative form of communication in agentic systems—a signal that broadcasts a state change, an occurrence, or a condition to any actor that cares to listen. “A new customer signed up.” “Payment processed successfully.” “The error rate just exceeded the threshold.” These are notifications. The sender publishes the fact. What happens next—if anything—is up to the receivers.
This fire-and-forget characteristic is what makes notification fundamentally different from delegation and retrieval. Delegation expects action. Retrieval expects information. Notification expects nothing. The sender’s job is done the moment the signal goes out. This seems like a limitation, but it’s actually a powerful architectural property—it decouples the thing that happened from whatever needs to happen in response, enabling systems that are more flexible, more scalable, and more resilient than tightly coupled request-response alternatives.
How Notification Works
A notification interaction begins when an actor detects a state change or occurrence worth announcing. The actor publishes a notification message—typically to a channel, topic, or event bus—containing a description of what happened, relevant metadata, and optionally a payload with details about the state change. Any number of receivers can subscribe to that channel and process the notification independently, each responding in whatever way is appropriate to their own role and instructions.
The sender and receiver in a notification interaction are decoupled in three important ways. They’re decoupled in time—the sender publishes the notification and moves on, regardless of when (or whether) any receiver processes it. They’re decoupled in identity—the sender doesn’t need to know who the receivers are, and new receivers can subscribe without the sender’s awareness. And they’re decoupled in action—the sender doesn’t dictate what receivers should do with the information.
This triple decoupling is what makes notification the natural interaction pattern for event-driven architectures. In technical terms, notifications are typically implemented through message queues, event streams (like Kafka or event buses), webhooks, or publish-subscribe systems. The specific implementation matters for reliability and scaling, but the interaction pattern remains the same: something happened, and interested parties are informed.
Notification in Agentic Systems
In agentic systems, notifications serve as triggers that set agents in motion without explicitly telling them what to do. This is a subtle but important distinction from delegation. When an orchestrator delegates a task to an agent, it’s saying “do this specific thing.” When a system publishes a notification that an event occurred, it’s saying “this happened”—and any listening agent decides for itself whether and how to respond.
Consider a notification that a new customer has signed up. A welcome email agent might respond by drafting and sending an onboarding message. A lead scoring agent might respond by evaluating the customer’s profile and assigning an initial score. A compliance agent might respond by triggering a know-your-customer check. Each agent acts independently based on its own instructions and the information in the notification. The system that published the “new customer” event has no awareness of any of these downstream responses—and that’s by design.
This pattern—events triggering independent agent responses—is the foundation of choreography, one of the three coordination primitives. While orchestration relies on delegation (a central coordinator telling agents what to do), choreography relies on notification (events announcing what happened, with agents independently deciding how to respond). Understanding notification as an interaction pattern is essential for understanding choreography as a coordination pattern.
Notification vs. Other Interaction Patterns
Each of the four interaction primitives serves a distinct communication purpose, and notification’s uniqueness becomes clearest in contrast.
Notification says “this happened.” It is declarative, fire-and-forget, and expects nothing from receivers.
Delegation says “do this.” It is imperative and expects a specific outcome. If delegation is a manager assigning a task, notification is a news bulletin—it informs, but doesn’t direct.
Retrieval says “tell me this.” It is interrogative and expects information back. Retrieval is a conversation between two specific actors. Notification is a broadcast to an open audience.
Conversation says “let’s work through this together.” It is collaborative and multi-turn. Notification is a single, atomic signal—there’s no back-and-forth.
One important nuance: notification often triggers the other interaction patterns. A notification that an order has been placed might trigger an agent to delegate fulfillment tasks, retrieve inventory data, and start a conversation with the customer. The notification itself doesn’t do any of those things—it’s the catalyst that sets them in motion.
The Three Shapes of Notification
Not all notifications carry the same amount of information, and the amount of information in a notification shapes how receivers can use it. Enterprise architects familiar with event-driven patterns will recognize three distinct shapes.
Event notification is the leanest form. It announces that something happened and provides minimal detail—just enough for receivers to know what occurred and where to look for more information. “Order #4521 was placed.” A receiver that needs details—the order items, the customer information, the shipping address—must perform a retrieval interaction to get them. This keeps notifications small and fast but creates coupling between the notification and the system of record.
Event-carried state transfer is the richest form. It includes the relevant data directly in the notification payload—not just that an order was placed, but the complete order details. Receivers can act on the notification without making additional retrieval calls, which reduces latency and removes the dependency on the source system being available. The trade-off is larger messages and the possibility of receivers working with stale data if the source state changes between notification and processing.
Domain events fall in between. They carry enough contextual information for most receivers to act without additional lookups, but they represent meaningful business occurrences rather than raw state changes. “Customer moved to premium tier” is a domain event—it carries business meaning. “Customer.tier field updated from ‘standard’ to ‘premium’” is a state change notification—it carries technical detail. Domain events are more useful for agent reasoning because they encode business context that the agent would otherwise need to infer.
Choosing the right shape for each notification is a design decision that affects system coupling, data freshness, payload size, and the complexity of receiving agents.
Designing Effective Notifications
Several design principles determine whether notifications enable clean, reactive architectures or create confusing, unreliable message flows.
Clarity of event semantics matters enormously. A notification named “CustomerUpdated” is ambiguous—was the address changed? Was the account closed? Was a preference modified? Each of those changes might require completely different agent responses. Specific, well-named events—“CustomerAddressChanged,” “CustomerAccountClosed,” “CustomerPreferenceUpdated”—let receiving agents subscribe to exactly the events they care about and ignore the rest.
Reliable delivery ensures that notifications actually reach their intended receivers. In distributed systems, messages get lost, duplicated, or delivered out of order. Production notification infrastructure needs durability guarantees (messages survive system failures), at-least-once delivery (messages may be delivered multiple times but never zero times), and idempotent receivers (agents handle duplicate notifications gracefully). This is infrastructure-level work, but it directly impacts whether agents can trust the notifications they receive.
Schema governance prevents the kind of drift that makes event-driven systems brittle over time. When the structure of a notification changes—a field is renamed, a new field is added, a required field becomes optional—every receiving agent is potentially affected. Schema registries, versioning conventions, and compatibility contracts (like those defined through AsyncAPI specifications) keep notifications stable and predictable across an evolving system.
Observability answers the question that every operations team asks about event-driven systems: what happened? When a notification triggers a chain of agent responses that produces an unexpected outcome, the ability to trace the original event through every downstream reaction is essential for debugging and accountability. This means logging notifications at publication, tracking receipt by each subscriber, and correlating downstream actions back to the triggering event.
Why Notification Matters in Enterprise Contexts
In enterprise environments, notification is the interaction pattern that enables real-time responsiveness at scale. Traditional request-response architectures require someone or something to ask the right question at the right time. Notification-driven architectures flip this model—relevant information arrives automatically when it becomes available, and agents respond in real time rather than waiting to be queried.
This shift has profound implications for enterprise agentic systems. Customer onboarding processes that used to wait for batch processing can now trigger instantly when a customer signs up. Compliance monitoring that used to happen during scheduled audits can now react in real time when policy-relevant events occur. Supply chain agents can respond to disruptions as they’re detected rather than discovering them hours later in a status report.
Notification also enables organizational scalability in a way that delegation-based architectures struggle to match. When new capabilities need to be added—a new agent that responds to customer events, a new monitoring process that watches for anomalies—they can subscribe to existing notification channels without modifying the systems that publish those events. This extensibility without modification is one of the most valuable properties of event-driven architectures, and it applies directly to how agentic systems grow over time.
Also Known As
Notification appears under various names depending on the platform and architectural tradition. You’ll encounter it as events (the most common term in event-driven architectures), signals (in systems programming and reactive frameworks), messages (in message-queue contexts, though this term is broader), alerts (when the notification indicates a condition requiring attention), or webhooks (when implemented as HTTP callbacks). In the command/query/event taxonomy common in domain-driven design, notifications correspond to domain events. In publish-subscribe systems, they’re simply publications. The defining characteristic across all terminology is the same: an announcement of something that happened, broadcast without expectation of a directed response.
Key Takeaways
Notification is the declarative, fire-and-forget interaction pattern that enables reactive, event-driven agentic architectures. It announces state changes and occurrences without directing any specific response, decoupling senders from receivers in time, identity, and action. This decoupling is what makes notification the foundation of choreography-based coordination and the enabler of real-time, scalable enterprise systems. In the agentic primitives framework, notification sits alongside delegation, retrieval, and conversation as the four interaction patterns, and it is the pattern most directly tied to building agentic systems that respond to the world as it changes rather than waiting to be told what happened.