Actualizado el Aug 28, 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 más una nota de recordatorio. El paso devuelve de inmediato un monitorId; cuando la vigía coincida, AutoTalk publica un mensaje de evento de monitor en la conversación, y el agente despierta por el pipeline normal de mensajes con todo el historial de la conversación. La nota que escribiste se reproduce en ese evento — es tu instrucción para tu yo del futuro.

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	Menos de un segundo para trabajos de transcripción/conversión (sus motores activan el sweeper directamente); el siguiente minuto del sweeper (hasta ~1 min) para otros documentos	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)

Regla general: nunca uses agent_tool para algo que AutoTalk ya controla. Un trabajo de transcripción, una conversión de medios, cualquier documento de la empresa — dynadata_doc despierta para esos en menos de un segundo. agent_tool es un sondeo periódico; existe para el mundo fuera de AutoTalk, que vigilas envolviendo la lectura (una petición HTTP, por ejemplo) en una herramienta normal del agente. Así las credenciales quedan en la configuración de los pasos de la herramienta, nunca en el prompt del modelo.

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. step(0).jobId). Solo se pueden vigilar tipos publicados legibles por el tenant y tipos personalizados ct:
condition	Una cadena CEL simple (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

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

Escribiendo la condición

Usa verificaciones positivas. Un campo ausente del documento vigilado se lee como null, así que una comparación negativa como doc.outputs.txt != '' es verdadera mientras el campo aún no existe y dispara de inmediato. Escribe doc.status == 'done', no "cualquier cosa excepto pendiente".

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).

Como la condición es una cadena simple, no puedes interpolar un umbral en ella. 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 completo; 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 step(N).monitorId, no con step(N).status — status está reservado para códigos de estado HTTP.