Skip to main content
AutoGen Core implements an event-driven architecture where agents react to messages asynchronously. Message handlers are decorated methods that process specific message types.

Handler Decorators

AutoGen Core provides three decorators for defining message handlers:

@event

One-way messages (no response)

@rpc

Request-response messages

@message_handler

Generic handler (both event and RPC)

@event Decorator

Use @event for handlers that process messages without returning a response (fire-and-forget).

Basic Usage

Event handlers must have return type None. They’re called when ctx.is_rpc == False.

Event Handler Signature

Requirements:
  1. Must be an async method
  2. Must have exactly 3 parameters: self, message, ctx
  3. message must be type-hinted with the message type to handle
  4. ctx must be type MessageContext
  5. Return type must be None

Event Parameters

bool
default:"True"
If True, raises exception for type mismatches. If False, logs warnings.
Callable[[MessageType, MessageContext], bool]
default:"None"
Secondary routing function. Applied in alphabetical order of handlers. First matching handler is called.

With Match Function

Match functions are evaluated in alphabetical order of handler names. Only the first matching handler is called. Remaining handlers are skipped.

@rpc Decorator

Use @rpc for handlers that process requests and return responses.

Basic Usage

RPC handlers must return a value (not None). They’re called when ctx.is_rpc == True.

RPC Handler Signature

Requirements:
  1. Must be an async method
  2. Must have exactly 3 parameters: self, message, ctx
  3. message must be type-hinted with the request type to handle
  4. ctx must be type MessageContext
  5. Return type must be type-hinted (not None)
  6. Must return a value

RPC Parameters

bool
default:"True"
If True, raises exception for type mismatches. If False, logs warnings.
Callable[[MessageType, MessageContext], bool]
default:"None"
Secondary routing function for selecting between multiple RPC handlers.

With Match Function

@message_handler Decorator

Use @message_handler for generic handlers that can process both events and RPCs.

Basic Usage

Message Handler Signature

Message Handler Parameters

bool
default:"True"
If True, raises exception for type mismatches. If False, logs warnings.
Callable[[MessageType, MessageContext], bool]
default:"None"
Secondary routing function.

Message Routing

Type-Based Routing

Messages are routed to handlers based on the type hint:
If multiple handlers match the same message type, they’re evaluated in alphabetical order. Only the first matching handler (including match function) is called.

Handler Selection Order

  1. Type match: Handler’s type annotation must match message type
  2. Alphabetical order: Handlers are sorted alphabetically by method name
  3. Match function: If provided, must return True
  4. First match wins: First handler that passes all checks is called

Unhandled Messages

By default, on_unhandled_message logs an info message. Override it to customize behavior.

Advanced Patterns

Chained Handlers

Publish from Handler

Error Handling

State Management in Handlers

Complete Example

Best Practices

Use @event when the sender doesn’t need a response. Perfect for logging, notifications, and status updates.
Use @rpc when the sender needs a response. Perfect for queries, calculations, and operations that produce results.
Always type-hint message parameters. This enables type checking and automatic routing.
RPC handlers should return error responses rather than raising exceptions when possible. This provides better error information to callers.
For long-running handlers, periodically check ctx.cancellation_token.is_cancelled().

Next Steps

Message Passing

Learn about messages, contexts, and subscriptions

Distributed Runtime

Scale event-driven agents across processes

Agent Runtime

Understand runtime operations

Core Overview

Return to Core API overview