Ir al contenido
TipoNueva primitivaEtapaProducciónDificultadModeradoTrabajoAutomatizar tareaParaConstructores de IAParaDesarrolladores backendServiciosCronServiciosAgentPor qué HoodyNativo de IAPor qué HoodyHTTP nativo
TipoNueva primitivaEtapaProducciónDificultadModeradoTrabajoAutomatizar tareaParaConstructores de IAParaDesarrolladores backendServiciosCronServiciosAgentPor qué HoodyNativo de IAPor qué HoodyHTTP nativo
TipoNueva primitivaEtapaProducciónDificultadModeradoTrabajoAutomatizar tareaParaConstructores de IAParaDesarrolladores backendServiciosCronServiciosAgentPor qué HoodyNativo de IAPor qué HoodyHTTP nativo
TipoNueva primitivaEtapaProducciónDificultadModeradoTrabajoAutomatizar tareaParaConstructores de IAParaDesarrolladores backendServiciosCronServiciosAgentPor qué HoodyNativo de IAPor qué HoodyHTTP nativo
Volver a casos de uso
use-cases / schedule-the-agent / hero
CRON · AGENTE · 0 7 * * *

Programa el agente, no el script

Una línea cron tradicional ejecuta reconcile.sh a las 2 de la mañana. Una línea cron de Hoody hace POST de un prompt a hoody-agent. La programación es fija. El trabajo no. Los casos extremos dejan de ser ramas que mantienes — se convierten en contexto sobre el que razona el agente.

Leer los docs de cron + agente
use-cases / schedule-the-agent / mechanism

Dos URLs, un prompt

Hoody Cron es un crontab gestionado en cada contenedor. Hoody Agent es un agente autónomo integrado en el mismo contenedor. La entrada cron hace curl al agente. El agente lee la fecha, lee los datos y decide lo que el día requiere. Las dos superficies son HTTP — el cron vive en /api/v1/cron/users/me/entries, el agente en /api/v1/agent/tasks. No hay código pegamento entre ellos.

cron-1.containers.hoody.com · entry
POST · cron/users/me/entries
# POST /api/v1/cron/users/me/entries
{
  "schedule": "0 7 * * *",
  "command": "curl -X POST $AGENT/api/v1/agent/tasks \
     -d @prompt.json",
  "comment": "morning-reports"
}
agent-1.containers.hoody.com · task
POST · agent/tasks
# prompt.json — the body of the POST
{
  "description": "Reconcilia los pedidos de ayer. Remapea si el esquema cambió. Párate y avisa al de guardia si la puntuación de anomalía > 3. Si hoy es el último día del mes, incluye el cierre mensual sobre el libro mayor ajustado por impuestos.",
  "mode": "code"
}

Dos POSTs y has acabado. La línea del crontab no vuelve a cambiar — el único archivo que mantienes es el prompt. ¿Nuevo caso extremo? Añade una frase. ¿Nueva regla de anomalía? Añade una frase. La programación sigue disparándose; el agente averigua qué significa cada disparo.

use-cases / schedule-the-agent / powers

Tres cosas que hace un prompt y no puede hacer un script

La forma del trabajo que recibe el agente siempre es la misma — una fecha, un dataset, un objetivo. Lo que cambia es lo que el agente decide hacer al respecto.

RAZONAMIENTO

Lee la fecha, lee los datos, decide

El agente corre después de que dispare el cron. Mira el calendario — fin de mes, festivo, cierre fiscal. Muestrea el dataset — esquema, volumen, puntuación de anomalía. Elige la siguiente acción con ese contexto, no desde un árbol if estático que escribiste hace seis meses.

ADAPTACIÓN

¿Columnas nuevas? ¿Monedas nuevas? El mismo prompt.

Cuando el export de ayer añade una columna refund_reason, un script se rompe y te avisa. El agente lee el esquema, lo mapea al campo legado y lo anota en el resumen de la ejecución. La línea del crontab nunca tuvo que enterarse.

OBSERVABILIDAD

Cada ejecución es un párrafo, no un código de retorno

Cada ejecución devuelve por escrito qué decidió el agente y por qué. El historial es texto en español — «omitido: sin datos nuevos», «adaptado: se añadió la columna refund», «anomalía: pico de reembolsos +412%, avisado al de guardia» — no exit code 0 / exit code 1. Los logs del cron se convierten en un diario.

use-cases / schedule-the-agent / flow

De la programación a la decisión

Tres pasos — el cron dispara, el agente razona, la decisión aterriza. El paso intermedio es el que solías escribir tú en un script de shell de 400 líneas con diecisiete ramas para casos extremos. Ahora es un prompt.

Bucle diario en tres pasosUN PROMPT · INFINITOS CASOS EXTREMOS
07:00

El cron dispara

Hoody Cron ejecuta la entrada. La línea del crontab es un curl: POST /api/v1/agent/tasks con el cuerpo del prompt. Sin reintentos escritos por ti, sin plumbing de logging — el servicio de cron inyecta la entrada en el crontab del sistema y lleva el seguimiento de la ejecución.

07:00 + ε

El agente razona

El agente recibe la descripción, abre sus herramientas — terminal, archivos, sqlite, navegador, exec — y elige un plan de acción. Puede ejecutar, omitir, adaptarse o avisar. Las decisiones cambian a diario. Las instrucciones no.

07:00 — 07:04

La decisión aterriza

La ejecución termina. El agente publica una línea de resumen: informes regenerados, omitido por falta de datos nuevos, parado por anomalía. Lo lees en el móvil con el desayuno.

La programación no cambió. El script no cambió. Lo que cambió es si tú, humano, tenías que despertarte para gestionarlo. Con el agente en el bucle, la respuesta es casi siempre que no — y el historial de ejecuciones te dice por qué.

use-cases / schedule-the-agent / capacity

Lo que obtienes del par cron + agente

Hoody Cron y Hoody Agent son dos servicios en el mismo contenedor, ambos accesibles por HTTP. Las cifras vienen de las superficies documentadas — no de benchmarks inventados.

  1. TAMAÑO DEL CRONTAB1 línea

    Un curl en el crontab, para siempre. El cuerpo del prompt es lo único que reescribes — y lo haces en un archivo JSON, no ejecutando crontab -e.

  2. ENDPOINTS DEL AGENTE100+

    hoody-agent expone la superficie completa — exec de terminal, lectura/escritura de archivos, consultas sqlite, automatización de navegador, control de daemons — a la tarea del agente como llamadas HTTP planas.

  3. LÍNEAS DE PEGAMENTO0

    Sin SDK entre el cron y el agente. Haz POST a una URL, lee otra. Los dos servicios viven en el mismo contenedor, así que la llamada va por red local rápida.

Hoody Cron soporta expresiones estándar de 5 campos (* * * * *) y macros (@hourly, @daily, @weekly, @monthly, @yearly). La creación de tareas en Hoody Agent es un POST /api/v1/agent/tasks; las actualizaciones en vivo van por streaming en /api/v1/agent/ws.

use-cases / schedule-the-agent / punchline

La entrada cron no ejecuta el job — le pide a un agente que averigüe el job.

antes · script con ramasdespués · prompt con ramas
A QUÉ APUNTABA LA ENTRADA CRON ANTERIOR0 2 * * * /usr/local/bin/reconcile.sh # 412 líneas · 17 casos extremoscada nueva regla de fin de mes implicaba editar el script y rezar
A QUÉ APUNTA AHORA0 7 * * * curl POST agent/tasks -d @prompt.jsonuna línea, para siempre — el prompt es el único artefacto que mantienes
Leer la spec de tareas del agente
use-cases / schedule-the-agent / replaces

Lo que esto reemplaza

El conjunto de cosas que solías escribir dentro de reconcile.sh porque cron solo sabía ejecutar archivos. Cada una es una rama, un flag, una config — nada de lo cual la programación necesita saber. El agente lee el día y decide.

  • jobs cron en script frágilesRamas en bash que se rompen cuando una columna de entrada se mueve
  • mantenimiento manual para esquemas cambiantesEditar reconcile.sh cada vez que el export upstream gana un campo
  • scripts ETL escritos a manoUna carpeta de archivos .sh que solo una persona del equipo entiende
  • lógica cron if X then Y else ZFin de mes, festivo, anomalía — tres flags cableados en un script
  • scripts de polling de cambiosUn cron separado que vigila la salida del primer cron y decide
  • schedulers if-else escritos a manoUn dispatcher de 200 líneas cuyo único trabajo es elegir qué script ejecutar
use-cases / schedule-the-agent / cta

Deja de mantener scripts cron. Empieza a mantener prompts. La programación dispara; el agente lo resuelve.

Leer los docs de cron + agente
use-cases / schedule-the-agent / related

Lee los otros