- Protocol Events - Sent from the TUI/daemon via IPC when conversations or agents change
- Signal Events - Triggered by OS signals for configuration and diagnostics
Quick Reference
| Event | Type | Status | Trigger |
|---|---|---|---|
on_new_conversation() | Protocol | ✅ Works | New conversation or /clear |
on_conversation_switched() | Protocol | ✅ Works | User switches conversations |
on_conversation_deleted() | Protocol | ✅ Works | Conversation deleted |
on_agent_activated() | Protocol | ✅ Works | Agent becomes active |
on_agent_deactivated() | Protocol | ✅ Works | Agent becomes inactive |
on_invocation_directory_changed() | Protocol | ✅ Works | User changes invocation directory |
on_config_update() | Signal | ✅ Works | SIGHUP signal (kill -HUP <pid>) |
on_status() | Signal | ✅ Works | SIGUSR1 signal (kill -USR1 <pid>) |
Architecture
Protocol Events Flow:Protocol-Based Events
These events are automatically sent by the Opperator daemon when user actions occur.Conversation Events
on_new_conversation()
on_new_conversation()
Called: When new conversation created or
/clear executedParameters:conversation_id(str): Unique conversation identifieris_clear(bool):Trueif/clearcommand,Falseif new conversation
- Clear conversation-specific caches
- Reset session state
- Initialize new conversation context
- Clear accumulated data
on_conversation_switched()
on_conversation_switched()
Called: When user switches to a different conversationParameters:
conversation_id(str): Conversation being switched toprevious_id(str): Previous conversation ID (may be empty)message_count(int): Number of messages in new conversation
- Load conversation-specific state
- Restore session data
- Update UI to reflect context
- Resume conversation history
on_conversation_deleted()
on_conversation_deleted()
Called: Before conversation is deletedParameters:
conversation_id(str): ID of conversation being deleted
- Delete cached data
- Clean up temporary files
- Remove conversation from databases
- Free memory
Agent Activation Events
on_agent_activated()
on_agent_activated()
Called: When this agent becomes the active agentParameters:
previous_agent(str | None): Previously active agent nameconversation_id(str): Current conversation ID
- Update UI to show active state
- Resume background tasks
- Initialize agent-specific context
- Update system prompt with current state
on_agent_deactivated()
on_agent_deactivated()
Called: When user switches away from this agentParameters:
next_agent(str | None): Agent being switched to
- Update UI to show inactive state
- Optionally pause background tasks
- Save state
- Reduce resource usage
Agents keep running when inactive. Only pause tasks if needed to reduce resource usage.
Invocation Directory Events
on_invocation_directory_changed()
on_invocation_directory_changed()
Called: When the invocation directory changes (where the user ran Access methods:
op from)Parameters:old_path(str): Previous invocation directorynew_path(str): New invocation directory
- Update file path resolution context
- Refresh file watchers
- Update relative path handling
- Notify user of context change
- When the TUI starts, the daemon stores where the user ran
opfrom - Agents can query this via
get_invocation_directory() - When the invocation directory changes, agents receive this lifecycle event
- Agents can use this to adjust their working context
The invocation directory is where the user ran the
op command, while the working directory is where the agent process is running. These are often different.Signal-Based Events
These events are triggered by OS signals that you must manually send to the agent process. They are useful for operational tasks like configuration reloading and health checks.Signal-based events only work on Unix/Linux systems. They use the Python signal handling mechanism, not the protocol event system.
on_config_update()
on_config_update()
Called: When SIGHUP signal receivedTrigger:
kill -HUP <pid> (where <pid> is your agent’s process ID)Parameters:config(dict): New configuration dictionary loaded fromagents.yaml
- Update runtime parameters without restart
- Reload connection settings
- Adjust logging levels
- Apply new feature flags
- You edit your
agents.yamlfile - Send SIGHUP signal:
kill -HUP <agent_pid> - Agent reloads config from file
- If config changed, calls
on_config_update()with new values
Hot reload lets you update agent behavior without restart. Find your agent’s PID with
ps aux | grep python.on_status()
on_status()
Called: When SIGUSR1 signal receivedTrigger:
kill -USR1 <pid> (where <pid> is your agent’s process ID)Use cases:- Log current state for debugging
- Report health metrics
- Dump diagnostic information
- Check resource usage
- Find your agent’s process ID:
ps aux | grep python - Send SIGUSR1 signal:
kill -USR1 <agent_pid> - Agent logs current status via
on_status()
View the logged status in the Opperator TUI logs panel or in your agent’s log file.
Complete Example
Agent demonstrating all lifecycle events:Event Flow Examples
User creates new conversation
User creates new conversation
Event Flow:
- User action in TUI
- Daemon sends protocol event
on_new_conversation(conv_id, is_clear=False)called- Agent resets conversation state
User types /clear
User types /clear
Event Flow:
- User types
/clearin TUI - Daemon sends protocol event
on_new_conversation(conv_id, is_clear=True)called- Agent clears conversation data
User switches conversations
User switches conversations
Event Flow:
- User switches conversation in TUI
- Daemon sends protocol event
on_conversation_switched(new_id, old_id, msg_count)called- Agent loads new conversation state
User switches agents
User switches agents
Event Flow:
- User switches to different agent
- Current agent:
on_agent_deactivated(next_agent="other_agent") - Other agent:
on_agent_activated(previous_agent="current_agent", conv_id)
Developer triggers config reload
Developer triggers config reload
Event Flow:
- Developer edits
agents.yaml - Sends signal:
kill -HUP <agent_pid> - Agent reloads config file
- If changed:
on_config_update(new_config)called - Agent applies new settings
Developer requests status check
Developer requests status check
Event Flow:
- Developer sends signal:
kill -USR1 <agent_pid> on_status()called- Agent logs metrics to TUI/logs
- Developer reviews status output
Best Practices
Don’t block event handlersEvent handlers should complete quickly (< 100ms). Avoid long-running operations.
Handle missing data gracefullyProtocol event parameters like
previous_id may be empty strings or None.Log all lifecycle eventsAlways log lifecycle events for debugging, monitoring, and audit trails.
Signal events are Unix/Linux onlyIf you need cross-platform config reloading, implement file watching in your
on_config_update() and on_status() use POSIX signals. They won’t work on Windows.main_loop() instead.