Updated Aug 28, 2026

Create Monitor

Action type: actions/monitors/create.

Use this action when an agent (or workflow) needs to be woken up later — when a document changes, at a point in time, or when something outside AutoTalk reaches a state you care about.

A monitor is a registered watch plus a reminder note. The step returns immediately with a monitorId; when the watch matches, AutoTalk posts a monitor event message into the conversation, and the agent wakes through the normal message pipeline with its full conversation history. The note you wrote is replayed in that event — it is your instruction to your future self.

Best for

• Delivering the result of a long job (a transcription, a transcode) into the same conversation when it finishes — without polling
• "Remind me in 30 minutes" style self-wakes
• Watching something outside AutoTalk — a ticket status, a price, an external job — by re-running one of the agent's own read-only tools on a schedule

The three watch types

Watch type	Watches	Wake latency	Needs
dynadata_doc	One of your company's documents (e.g. a transcription_jobs row, or a ct: custom type document) until a CEL condition over it holds	Under a second for transcription/transcode jobs (their engines kick the sweeper directly); the next sweeper minute (up to ~1 min) for other documents	itemType + itemId + condition
time	The clock	The next sweeper minute after fireAt	fireAt or delayMinutes
agent_tool	The result of one of the agent's own tools, re-run on a schedule	The first poll whose condition holds — polls run at intervalMinutes (minimum 5)	toolName + condition (+ toolArgs, intervalMinutes)

Rule of thumb: never use agent_tool for something AutoTalk already owns. A transcription job, a transcode job, any company document — dynadata_doc wakes for those in under a second. agent_tool is a poll; it exists for the world outside AutoTalk, which you watch by wrapping the read (an HTTP request, for example) in a normal agent tool first. That way credentials stay in the tool's step configuration, never in the model's prompt.

Main fields

Field	What it does
watchType	CEL resolving to dynadata_doc, time, or agent_tool
itemType / itemId	dynadata_doc only: the watched document's type and _id (e.g. step(0).jobId). Only tenant-readable published types and ct: custom types can be watched
condition	A plain CEL string (not evaluated at create time — only parse-checked) the sweeper evaluates later. For dynadata_doc it runs over doc (the watched document); for agent_tool see the arena below
fireAt / delayMinutes	time only: when to fire — an ISO datetime, or minutes from now
agentId / toolName / toolArgs	agent_tool only: which tool to re-run. agentId defaults to the agent running the step; toolName must be unique on that agent (a duplicate name is refused rather than guessed); toolArgs is an object of scalar arguments checked against the tool's declared parameters at create time
intervalMinutes	agent_tool only: how often to poll. Clamped to 5–1440 and jittered — never faster than 5 minutes
note	Your reminder, replayed verbatim in the wake. Write what the agent should do when the watch fires
conversationId	Which conversation to wake. Defaults to the conversation the run is in — a workflow run has no conversation, so workflow steps must set it
ttlMinutes	How long the watch stays armed. Default 1440 (24 h), maximum 10080 (7 days). Past it the monitor expires without firing

What later steps can use

• step(N).monitorId — the armed monitor's id (poll it via the read-only monitors data type)
• step(N).monitorState — armed at create time
• step(N).expiresAtIso — when the watch dies unfired

Writing the condition

Use positive checks. A field missing from the watched document reads as null, so a negative comparison like doc.outputs.txt != '' is true while the field does not exist yet and fires immediately. Write doc.status == 'done', not "anything except pending".

For dynadata_doc, the condition sees doc — the watched document.

For agent_tool, the condition sees the tool's own declared output:

Variable	What it is
output	The tool's rendered output.main result
outputText	The same, always as a string
data	The tool output parsed as JSON, when it is a JSON object or array — otherwise null. Parsed from the full output before the display truncation, so data stays usable even when outputText is cut
steps	Per-step {ok, status, error} — ok is true for a completed step whose HTTP status, if it has one, is 2xx
now	The evaluation time

Example: data.atingiu == true, or steps[0].status == 200. Per-step payloads are deliberately not exposed — the condition sees only what the tool's own output.main projects, and the watched tool must declare an output.main (a tool without one is refused: its condition could never become true).

Because the condition is a plain string, you cannot template a threshold into it. Put the moving part in toolArgs instead and have the tool compute the verdict — for example a limite parameter the tool compares against, so the condition is just data.reached == true.

What a watched tool may do

An agent_tool watch re-runs the tool headless — no model, no conversation, unattended, for up to seven days. So the tool may only read:

• Every step must be a read-only action (HTTP request, fetch/search/count company data, resolve variables). Anything that writes data, sends messages, spends money, or mints credentials is refused — at create time and re-checked on every poll.
• At most 5 steps, and the whole tool must finish within 25 seconds per poll — a tool that is fine as an LLM tool (an HTTP step alone allows 120 s) can exceed that as a watch; three consecutive overruns end the watch.
• A step that answers with an HTTP 4xx/5xx counts as completed data (steps[i].ok false, status set) and the watch keeps polling — so a condition can watch for recovery. A poll counts toward the error strikes only when a step cannot run at all (DNS failure, connection refused, timeout) and no step in the chain completed — one completed step means the poll parks as not-met instead. To detect a persistently failing later step, put steps[i].ok into your condition.

Editing the watched tool ends the watch

The watch records a fingerprint of the tool's executable surface as it was when armed — its name, parameters, steps, and output expression. If any of those change, or the tool is removed or duplicated by name, the monitor stops immediately with a notification to your team — it does not silently keep running an older version, and it does not guess between two tools with the same name. Cosmetic edits (the description, hiding the tool) do not end the watch. Re-arm after finishing behavioral edits.

Limits

• 10 armed monitors per conversation, 50 per account, and 10 armed agent_tool watches per account (each one is a recurring poll). A monitor you no longer need can be canceled with Cancel Monitor — canceling frees its armed slot immediately
• 20 fires per conversation per day — every fire is a billable agent run; a monitor that hits the cap takes the error path rather than resuming the next day
• A run that was itself woken by a monitor may arm one more monitor (depth 1); chaining further is refused, so watch → wake → watch → wake loops cannot run away
• Three consecutive evaluation failures flip the monitor to error and notify your team

Tips

• End the run normally after arming — send the user an interim reply ("I'll get back to you when it's ready"). The wake continues the conversation later with full history; the monitor is how you stop polling, not another thing to wait on.
• The wake arrives as a monitor event message carrying your note and a snapshot of what matched. Add a system prompt telling the agent how to treat these events — see Async wakes.
• Read the create result via step(N).monitorId, not step(N).status — status is reserved for HTTP status codes.