Blog · Guía · 28 de octubre de 2026
Ejecuta un agente programado con AEGIS: programaciones, ejecuciones y lo que ves cuando una falla
Aviso: en 100monkeys.ai construimos AEGIS, así que lee esta guía como el relato de quien lo fabrica. La redactó uno de nuestros agentes de IA a partir de la documentación pública de AEGIS, sobre todo la página Schedules y la referencia Schedule Tools, y la revisó la empresa; esta versión en español es una traducción de la guía original en inglés. Cada campo, ruta y mensaje está citado de esas páginas, en inglés y con la traducción al lado. No ejecutamos estas llamadas para esta guía y, donde la documentación deja un paso abierto, lo decimos.
AEGIS by 100monkeys.ai, in beta, es un orquestador autoalojado que ejecuta agentes autónomos en entornos aislados y con políticas aplicadas. Esta guía pone uno de tus agentes en un temporizador, lee lo que hizo cada disparo y muestra los cuatro resultados que puede tener, para que una ejecución que no ocurrió sea tan visible como una que sí.
Qué es una programación
La documentación lo define en una frase: "A schedule starts one of your agents or workflows as you, either once at a time you choose or again and again on a recurrence." (Una programación inicia uno de tus agentes o workflows en tu nombre, una sola vez a la hora que elijas o una y otra vez según una recurrencia.) De ahí salen tres consecuencias, y cada una da forma a los pasos siguientes.
- Una programación es un objeto tuyo, "never a field of the agent or workflow it runs" (nunca un campo del agente o workflow que ejecuta).
- Se ejecuta como una persona. "A schedule always runs as a person. A service account, or an operator acting for no person, cannot make, change, pause, resume, run or delete one." (Una programación siempre se ejecuta como una persona. Una cuenta de servicio, o un operador que no actúa por ninguna persona, no puede crearla, cambiarla, pausarla, reanudarla, ejecutarla ni borrarla.)
- Cada disparo es una ejecución normal. "At each fire the orchestrator starts the run exactly as
aegis.task.executeoraegis.workflow.runwould for you, with the schedule's intent, input and connections." (En cada disparo el orquestador inicia la ejecución exactamente como lo harían por tiaegis.task.executeoaegis.workflow.run, con la intención, la entrada y las conexiones de la programación.)
Paso 1. Elige el agente y el horario
Usa un agente que ya hayas ejecutado una vez a mano con aegis task execute <AGENT>, para saber cómo es una buena ejecución.
Después elige uno de dos horarios. Das exactamente uno de ellos.
- Una vez:
at, una hora RFC 3339 "at least one minute from now and at most a year ahead" (al menos un minuto a partir de ahora y como mucho un año después). - Recurrente:
recurrenceconcron,timezoneyjitter_seconds. El cron tiene cinco campos (minuto, hora, día del mes, mes, día de la semana), "no seconds field and no@daily-style shorthand" (sin campo de segundos y sin abreviaturas del estilo@daily). La zona horaria es un nombre IANA y valeUTCpor defecto. El jitter retrasa cada ejecución una cantidad aleatoria de hasta ese número de segundos, como máximo 3600.
Dos límites que hay que tener en cuenta: "A schedule runs at most once every 5 minutes" (una programación se ejecuta como mucho una vez cada 5 minutos), y puedes tener como máximo 25 programaciones no borradas.
Paso 2. Elige a qué puede llegar la ejecución
Una ejecución programada solo llega a las conexiones que nombran su profile o sus contexts, y "a schedule with neither reaches none of your connections" (una programación sin ninguno de los dos no llega a ninguna de tus conexiones). Una programación lleva uno u otro, nunca ambos. Si tu agente lee correo o un repositorio, nombra el perfil ahora; si no, el disparo se rechazará por falta de conexión, y el rechazo lo dirá.
Paso 3. Crea la programación
La CLI Reference no tiene ningún comando de shell aegis schedule. Creas una programación con la ruta REST POST /v1/schedules (ámbito schedule:write), con la herramienta MCP aegis.schedule.create o desde la página Schedules de Zaru. La herramienta recibe estos argumentos, tal como los lista la referencia:
aegis.schedule.create {
"name": "Morning inbox triage",
"target_kind": "workflow",
"target": "email-inbox-triage",
"intent": "Sort the new mail",
"input": { "mailbox": "ann@example.com" },
"recurrence": { "cron": "*/30 * * * *", "timezone": "UTC", "jitter_seconds": 300 }
}
Ese ejemplo es la programación de la propia documentación. Cambia target_kind a agent y target al nombre de tu agente. La respuesta es {"schedule": {...}} con su state, next_run_at y last_run. Lee next_run_at antes de irte.
Paso 4. Dispárala una vez, ahora
No esperes a la primera hora programada para saber si funciona. El propietario puede iniciar una ejecución inmediata con POST /v1/schedules/{id}/run o aegis.schedule.run_now. Se ejecuta "exactly as a fire starts it: as the owner, with the schedule's target, input, connections or profile, and attachments" (exactamente como la inicia un disparo: como el propietario, con el destino, la entrada, las conexiones o el perfil y los adjuntos de la programación), y "nothing else changes" (nada más cambia): la programación conserva su estado y su horario.
Paso 5. Lee las ejecuciones
aegis.schedule.runs { "schedule_id": "<id>", "limit": 20 }
La ruta es GET /v1/schedules/{id}/runs?limit=. Las ejecuciones llegan de la más reciente a la más antigua, cada una con su scheduled_time (null para una ejecución iniciada ahora), fired_at, outcome, detail y execution (su id, kind y status). Lleva el id de ejecución a la CLI para leer la ejecución en sí: aegis task logs <EXECUTION_ID>, con --errors-only cuando solo quieras los fallos.
Paso 6. Conoce los cuatro resultados
Cada disparo se registra una vez por hora programada, así que un disparo que Temporal repite "answers the first fire's record instead of starting a second run" (responde con el registro del primer disparo en lugar de iniciar una segunda ejecución). Cada registro tiene un resultado:
started: la ejecución empezó, y el disparo registra su id de ejecución.skipped_overlap: "The run the previous fire started is still running, so this fire starts nothing." (La ejecución que inició el disparo anterior sigue en marcha, así que este disparo no inicia nada.) Zaru lo muestra como "Skipped: the last run was still running".skipped_paused: la programación está pausada.refused: "The run could not start. The fire records the refusal's sentence, for example a required connection that was not chosen." (La ejecución no pudo empezar. El disparo registra la frase del rechazo, por ejemplo una conexión necesaria que no se eligió.)
Un resultado started dice que la ejecución empezó, no que tuvo éxito. El estado de la ejecución está en execution.status, y el motivo de un fallo, en sus logs.
Paso 7. Qué pasa cuando los disparos siguen fallando
"When the last three fires of a recurring schedule were all refused, the schedule pauses itself, with the reason 'Paused after three runs could not start: <the last refusal>.'" (Cuando los tres últimos disparos de una programación recurrente fueron rechazados, la programación se pausa sola, con ese motivo.) Lee paused_reason en la programación, corrige la causa y reanúdala con aegis.schedule.resume. Un disparo perdido mientras el orquestador se reinicia "is still made up to 10 minutes late; later than that, the time is skipped" (todavía se recupera con hasta 10 minutos de retraso; más tarde, esa hora se omite).
Paso 8. Las aprobaciones siguen aplicando
Una ejecución programada actúa en tu nombre, "so every tool call that waits for your approval in a conversation waits for it in a scheduled run too" (así que cada llamada a herramienta que espera tu aprobación en una conversación también la espera en una ejecución programada). En Zaru la solicitud aparece en la página Approvals como "From your schedule <name>".
Lo que la documentación deja abierto
- Un comando de shell. La CLI Reference no lista ningún subcomando de programación, así que quien se autoaloja usa las rutas REST o un cliente MCP.
- Quién eres "tú" en el stack local. Las programaciones se ejecutan como una persona y necesitan
schedule:write, mientras que el stack deaegis initfunciona sin IAM. La documentación no dice de quién es una programación ahí; no lo probamos.
Hacia dónde seguir
Para poner a una persona entre el agente programado y todo lo que envía, lee Cómo dar a un orquestador un paso de aprobación. Para leer lo que hizo una ejecución, lee Cómo leer el log de una ejecución de AEGIS.