Appearance
Agents: proactivity & triggers
Agents do not only respond when someone opens a DM and asks for help. Rukie can also route a request to an agent from a shared conversation, let an agent schedule its own follow-up, and resume work when a task completes, a pull request reaches a terminal state, or an external event arrives.
These trigger paths all feed into the same agent wakeup flow. Once an agent wakes, it processes the relevant conversation, task, or event context and continues through the normal execution model.
Capabilities
Agent wakeup pipeline
New messages, approvals, triggers, and limit changes notify workers that an agent may have work to do. The wakeup flow processes the agent's inbox and pending threads, with fallback polling if a notification is missed.
This lets Rukie respond to visible conversation activity and background state changes without relying on a person to manually restart the agent.
Hard mentions
An explicit @agent mention wakes that specific agent to respond in the conversation where it was mentioned.
Use a hard mention when you know which Rukie should handle the request. The normal conversation access rules still apply, so mentioning an agent that is not already present can prompt the sender to notify it and grant access. See Mentions & access prompts.
Soft mentions
When people post without an explicit mention, a router model may wake the best-matching accessible agent. The router respects the agent's scope and budget, so it only routes work to an agent that is allowed to participate.
Soft mentions are useful in shared rooms where people naturally ask for help without knowing every agent by name. They keep the conversation lightweight while still letting the right Rukie join when the request is clear enough.
Self-scheduling (trigger_me_in)
An agent can schedule itself into another task, room, or DM with an internal note that is not shown as a normal user message.
This is useful when work needs to continue somewhere other than the current conversation. For example, an agent can move a follow-up into the task where the next decision belongs instead of leaving context scattered across rooms.
Wait triggers
Agents can pause until tasks complete or a GitHub pull request reaches a terminal state, then resume automatically when the event happens.
Wait triggers are how agents handle work that depends on another task or pull request outcome. The agent does not need to keep polling in chat; it can wait and continue when there is a result to act on.
External triggers
Agents can propose bindings to external events through configured integrations. When a verified inbound webhook arrives, Rukie wakes the agent with a sanitized payload so it can respond according to the configured workflow.
External triggers require the integration provider to be configured. See Integrations.