What the agent sees
The tools are offered in any turn that answers a message in a conversation,
including a turn started by a follow-up, so the agent can keep watching by
scheduling another one.
When it fires
Each follow-up has its own Temporal workflow holding a durable timer, so a pending follow-up survives deploys and restarts. When the timer fires, the workflow starts an ordinary run in the original conversation, anchored to the message the agent was answering, so the reply lands in the same channel and thread. The run gets the agent’s normal per-turn budget and its full tools. The note reaches the agent as an instruction from its earlier self, not as a new human message. The anchor message is only the place to answer: it gets no new reaction, and identity commands, task intake, and continuation checks are not run on it again. If another run is answering in the conversation at that moment, the follow-up waits and retries until the conversation is free.No authority model
A follow-up records who it is for only by its conversation. Anyone in that conversation can ask the agent to cancel it. Nothing about the agent is locked while one is pending, and changes in memory, participants, or anything else are new input to the run when it fires, not a reason to skip it. The database row decides. The timer workflow reads the row under lock before it starts the run, so a cancellation saved before the timer fires always wins, even if the signal that ends the timer early arrives late.Operators
GET /api/agents/{slug}/follow-ups lists an agent’s follow-ups, newest first
(see the operator API). A pending follow-up keeps its
Temporal connection’s worker running until it fires or is cancelled, so
switching connections does not strand it.