Actualizado el Oct 9, 2026

Crear Monitor

Tipo de acción: actions/monitors/create.

Usa esta acción cuando un agente (o workflow) necesite ser despertado más tarde — cuando un documento cambie, en un momento definido, o cuando algo fuera de AutoTalk llegue a un estado que te interesa.

Un monitor es una vigía registrada con un recordatorio. El paso devuelve inmediatamente monitorId; cuando una comprobación coincide, AutoTalk publica un evento de monitor en la conversación y el agente puede continuar por el flujo normal de mensajes. El historial está limitado por el presupuesto de contexto y puede recortarse. El evento repite tu nota como recordatorio para la siguiente ejecución.

Ideal para

• Entregar el resultado de un trabajo largo (una transcripción, una conversión de medios) en la misma conversación cuando termine — sin sondear
• Autorecordatorios del tipo "recuérdame en 30 minutos"
• Vigilar algo fuera de AutoTalk — el estado de un ticket, un precio, un trabajo externo — reejecutando una de las herramientas de solo lectura del propio agente según un cronograma

Los tres tipos de vigía

Tipo de vigía	Vigila	Latencia del despertar	Necesita
dynadata_doc	Un documento de tu empresa (por ejemplo una fila de transcription_jobs, o un documento de tipo personalizado ct:) hasta que una condición CEL sobre él se cumpla	Comprobaciones aceleradas después de transcripción/transcode; barridos periódicos para otros cambios. Pueden quedar en cola, fallar o reintentarse; la latencia no está garantizada	itemType + itemId + condition
time	El reloj	El siguiente minuto del sweeper después de fireAt	fireAt o delayMinutes
agent_tool	El resultado de una de las herramientas del propio agente, reejecutada según un cronograma	La primera consulta cuya condición se cumpla — las consultas corren cada intervalMinutes (mínimo 5)	toolName + condition (+ toolArgs, intervalMinutes)

Usa vigías de documentos para datos de AutoTalk. Un job de transcripción, transcode o documento de la empresa puede usar dynadata_doc; al terminar puede solicitar una comprobación acelerada. agent_tool consulta periódicamente y sirve para datos externos leídos por una herramienta del agente. Mantén las credenciales en la configuración de los pasos, no en el prompt. Todas las comprobaciones pueden quedar en cola, fallar o reintentarse.

Campos principales

Campo	Qué hace
watchType	CEL que resuelve a dynadata_doc, time o agent_tool
itemType / itemId	Solo dynadata_doc: el tipo y el _id del documento vigilado (p. ej. workflow.step(0).jobId). Solo se pueden vigilar tipos publicados legibles por el tenant y tipos personalizados ct:
condition	Un descriptor CEL nativo {expr: "..."} (no evaluada al crear — solo verificada sintácticamente) que el sweeper evalúa después. Para dynadata_doc corre sobre doc (el documento vigilado); para agent_tool mira la arena abajo
fireAt / delayMinutes	Solo time: cuándo disparar — un datetime ISO, o minutos desde ahora
agentId / toolName / toolArgs	Solo agent_tool: qué herramienta reejecutar. agentId toma por defecto el agente que corre el paso; toolName debe ser único en ese agente (un nombre duplicado se rechaza en lugar de adivinarse); toolArgs es un objeto de argumentos escalares verificado contra los parámetros declarados de la herramienta al crear
intervalMinutes	Solo agent_tool: con qué frecuencia sondear. Limitado a 5–1440 y con variación aleatoria — nunca más rápido que 5 minutos
note	Tu recordatorio, reproducido literalmente en el despertar. Escribe qué debe hacer el agente cuando la vigía dispare
conversationId	Qué conversación despertar. Por defecto la conversación en la que está la ejecución — una ejecución de workflow no tiene conversación, así que los pasos de workflow deben definirlo
ttlMinutes	Cuánto tiempo queda armada la vigía. Por defecto 1440 (24 h), máximo 10080 (7 días). Pasado eso el monitor expira sin disparar

Qué pueden usar los pasos siguientes

• workflow.step(N).monitorId — el id del monitor armado (consúltalo por el tipo de datos de solo lectura monitors)
• workflow.step(N).monitorState — armed al momento de crear
• workflow.step(N).expiresAtIso — cuándo muere la vigía sin disparar

Escribiendo la condición

Un campo ausente es un error de evaluación. Una condición sin protección, como doc.outputs.txt != '', falla mientras falte outputs o txt y cuenta para el límite de fallas de evaluación. Tres fallas consecutivas detienen el monitor con error y notifican a tu equipo. Para seguir esperando datos opcionales, usa una protección de presencia, como has(doc.status) && doc.status == 'ready', o lee un valor predeterminado seguro: maps.get(doc, 'outputs.txt', '') != ''. Una condición que se evalúa correctamente como false mantiene el monitor armado.

Para dynadata_doc, la condición ve doc — el documento vigilado.

Para agent_tool, la condición ve la salida declarada de la propia herramienta:

Variable	Qué es
output	El resultado renderizado del output.main de la herramienta
outputText	Lo mismo, siempre como cadena
data	La salida de la herramienta interpretada como JSON, cuando es un objeto o array JSON — en caso contrario null. Interpretada a partir de la salida completa antes del recorte de visualización, así que data sigue siendo utilizable aunque outputText esté truncado
steps	Por paso, {ok, status, error} — ok es verdadero para un paso completado cuyo status HTTP, si lo tiene, es 2xx
now	El momento de la evaluación

Ejemplo: data.atingiu == true, o steps[0].status == 200. Los payloads por paso deliberadamente no se exponen — la condición solo ve lo que proyecta el output.main de la propia herramienta, y la herramienta vigilada debe declarar un output.main (una herramienta sin él se rechaza: su condición nunca podría volverse verdadera).

El descriptor de la condición se almacena sin evaluarlo al crear; su contexto de ejecución incluye los bindings declarados. Pon la parte variable en toolArgs y haz que la herramienta calcule el veredicto — por ejemplo un parámetro limite que la herramienta compara, de forma que la condición sea solo data.atingiu == true.

Qué puede hacer una herramienta vigilada

Una vigía agent_tool reejecuta la herramienta sin modelo — sin conversación, sin supervisión, hasta por siete días. Así que la herramienta solo puede leer:

• Cada paso debe ser una acción de solo lectura (petición HTTP, buscar/consultar/contar datos de la empresa, resolver variables). Cualquier cosa que escriba datos, envíe mensajes, gaste dinero o emita credenciales se rechaza — al crear y se vuelve a verificar en cada sondeo.
• Como máximo 5 pasos, y la herramienta entera debe terminar en 25 segundos por sondeo — una herramienta que funciona bien como herramienta de LLM (un paso HTTP solo permite 120 s) puede excederlo como vigía; tres excesos consecutivos terminan la vigía.
• Un paso que responde con HTTP 4xx/5xx cuenta como dato completado (steps[i].ok falso, status presente) y la vigía sigue sondeando — así una condición puede vigilar la recuperación. Un sondeo solo cuenta para las fallas cuando un paso no puede correr en absoluto (fallo de DNS, conexión rechazada, timeout) y ningún paso de la cadena se completó — un paso completado hace que el sondeo se estacione como "no cumplida". Para detectar un paso posterior que falla persistentemente, pon steps[i].ok en tu condición.

Editar la herramienta vigilada termina la vigía

La vigía registra una huella digital de la superficie ejecutable de la herramienta tal como era al armarse — su nombre, parámetros, pasos y expresión de salida. Si cualquiera de esos cambia, o la herramienta se elimina o se duplica por nombre, el monitor se detiene de inmediato con una notificación a tu equipo — no sigue corriendo en silencio una versión vieja, y no adivina entre dos herramientas con el mismo nombre. Las ediciones cosméticas (la descripción, ocultar la herramienta) no terminan la vigía. Rearma después de terminar ediciones de comportamiento.

Límites

• 10 monitores armados por conversación, 50 por cuenta, y 10 vigías agent_tool armadas por cuenta (cada una es un sondeo recurrente). Un monitor que ya no necesitas puede cancelarse con Cancelar Monitor — cancelar libera su lugar de inmediato
• 20 disparos por conversación por día — cada disparo es una ejecución de agente facturable; un monitor que alcanza el tope entra en el camino de error en lugar de retomar al día siguiente
• Una ejecución que fue a su vez despertada por un monitor puede armar un monitor más (profundidad 1); encadenar más allá se rechaza, así que los bucles vigía → despertar → vigía → despertar no pueden descontrolarse
• Tres fallas de evaluación consecutivas cambian el monitor a error y notifican a tu equipo

Consejos

• Termina la ejecución normalmente después de armar — envía al usuario una respuesta provisional ("Te aviso en cuanto esté listo"). El despertar continúa la conversación después con el historial conservado dentro del presupuesto de contexto; el monitor es cómo dejas de sondear, no otra cosa que esperar.
• El despertar llega como un mensaje de evento de monitor con tu nota y una instantánea de lo que coincidió. Añade un prompt de sistema que le diga al agente cómo tratar estos eventos — mira Despertares asíncronos.
• Lee el resultado de la creación con workflow.step(N).monitorId, no con workflow.step(N).status — status está reservado para códigos de estado HTTP.