You've created a simple actor that stores greetings. Now consider what makes AI agents useful: they remember context. When a user asks a question, then follows up with "What about the deadline?", the agent understands "the deadline" refers to something from the previous exchange. Without conversation history, every interaction starts from zero.
This is the core use case for actors in AI systems. Each user session needs its own isolated state—their conversation history, preferences, and context. A traditional approach might use Redis keys like chat:user123:history, but you'd manage concurrency, serialization, and cleanup yourself. With Dapr actors, each chat session IS an actor instance. The runtime handles activation, state persistence, and concurrent access. You focus on conversation logic.
In this lesson, you'll build a ChatActor that maintains conversation history and publishes events when conversations update. By the end, you'll have a pattern for any stateful agent that needs to remember context across interactions.
A chat session maps naturally to an actor:
Why not just store history in a regular state store key? Three reasons:
Start with the interface that defines what your ChatActor can do:
The @actormethod decorator with the name parameter is critical. The name you provide (like "ProcessMessage") is the method name used in actor invocation. Python's snake_case method name (process_message) is your local implementation, but external callers use the decorator name.
Now implement the actor with state management and pub/sub integration:
Wire up the actor with FastAPI:
Create a subscription that routes conversation events to your endpoint:
Apply to your cluster:
With the service running (tilt up or kubectl apply), test the conversation flow:
Response:
Check history:
Response:
Alice and Bob have completely separate conversation histories. This is the power of actor IDs—natural isolation without explicit partitioning logic.
The actor ID pattern enables various session strategies:
The pub/sub integration opens powerful patterns. Other services can subscribe to user-chat events for:
You extended your dapr-deployment skill in L00. Does it include ChatActor patterns now?
"Using my dapr-deployment skill, generate a ChatActor that stores conversation history with a configurable limit and publishes events on each message."
If you found gaps:
"I'm building an AI agent that helps users plan travel itineraries. What state should my actor store besides basic conversation history? Consider preferences, intermediate results, and history limits."
"Take this ChatActor's process_message method and help me integrate an OpenAI call. How should I send conversation history as context while keeping the response time reasonable?"
"My ChatActor seems to lose history between calls. Help me debug: is it a configuration issue, a key pattern problem, or a misunderstanding of the virtual actor lifecycle?"