Pular para o conteúdo
TipoNovo primitivoEstágioProduçãoDificuldadeModeradoTrabalhoAutomatizar tarefaParaConstrutores de IAParaDesenvolvedores backendServiçosCronServiçosAgentePor que HoodyNativo de IAPor que HoodyHTTP-nativo
TipoNovo primitivoEstágioProduçãoDificuldadeModeradoTrabalhoAutomatizar tarefaParaConstrutores de IAParaDesenvolvedores backendServiçosCronServiçosAgentePor que HoodyNativo de IAPor que HoodyHTTP-nativo
TipoNovo primitivoEstágioProduçãoDificuldadeModeradoTrabalhoAutomatizar tarefaParaConstrutores de IAParaDesenvolvedores backendServiçosCronServiçosAgentePor que HoodyNativo de IAPor que HoodyHTTP-nativo
TipoNovo primitivoEstágioProduçãoDificuldadeModeradoTrabalhoAutomatizar tarefaParaConstrutores de IAParaDesenvolvedores backendServiçosCronServiçosAgentePor que HoodyNativo de IAPor que HoodyHTTP-nativo
Voltar aos casos de uso
use-cases / schedule-the-agent / hero
CRON · AGENTE · 0 7 * * *

Agende o agente, não o script

Uma linha cron tradicional roda reconcile.sh às 2 da manhã. Uma linha cron Hoody faz POST de um prompt para hoody-agent. O agendamento é fixo. O trabalho não. Casos extremos param de ser branches que você mantém — viram contexto sobre o qual o agente raciocina.

Ler os docs cron + agente
use-cases / schedule-the-agent / mechanism

Duas URLs, um prompt

Hoody Cron é um crontab gerenciado em todo contêiner. Hoody Agent é um agente autônomo embutido no mesmo contêiner. A entrada cron faz curl no agente. O agente lê a data, lê os dados e decide o que o dia exige. As duas superfícies são HTTP — o cron mora em /api/v1/cron/users/me/entries, o agente em /api/v1/agent/tasks. Não há código de cola entre eles.

cron-1.containers.hoody.com · entrada
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": "Reconcilie os pedidos de ontem. Remapeie se o esquema mudou. Pare e paginate o plantonista se o anomaly score > 3. Se hoje for o último dia do mês, inclua o fechamento mensal no ledger ajustado por imposto.",
  "mode": "code"
}

Dois POSTs e pronto. A linha do crontab nunca mais muda — o único arquivo que você mantém é o prompt. Caso extremo novo? Adicione uma frase. Regra de anomalia nova? Adicione uma frase. O agendamento continua disparando; o agente descobre o que cada disparo significa.

use-cases / schedule-the-agent / powers

Três coisas que um prompt faz que um script não faz

O formato do trabalho que o agente recebe é sempre o mesmo — uma data, um conjunto de dados, um objetivo. O que muda é o que o agente decide fazer com eles.

RACIOCÍNIO

Lê a data, lê os dados, decide

O agente roda depois que o cron dispara. Ele consulta o calendário — fim de mês, feriado, fechamento fiscal. Faz amostragem do conjunto de dados — esquema, volume, anomaly score. Escolhe a próxima ação com esse contexto, não a partir de uma if-tree estática que você escreveu seis meses atrás.

ADAPTAÇÃO

Colunas novas? Moedas novas? Mesmo prompt.

Quando a exportação de ontem ganha uma coluna refund_reason, um script quebra e te paginate. O agente lê o esquema, mapeia para o campo legado e registra a mudança no resumo da execução. A linha do crontab nunca precisou saber.

OBSERVABILIDADE

Cada execução é um parágrafo, não um código de retorno

Cada execução posta de volta o que o agente decidiu e por quê. O histórico é português corrido — "pulou: sem dados novos", "adaptou: coluna refund adicionada", "anomalia: pico de refund +412%, plantonista paginado" — não exit code 0 / exit code 1. Os logs do cron viram um diário.

use-cases / schedule-the-agent / flow

Do agendamento à decisão

Três passos — o cron dispara, o agente raciocina, a decisão acontece. O passo do meio é o que você costumava escrever em um shell script de 400 linhas com dezessete branches de caso extremo. Agora é um prompt.

Loop diário em três passosUM PROMPT · INFINITOS CASOS EXTREMOS
07:00

O cron dispara

Hoody Cron roda a entrada. A linha do crontab é um curl: POST /api/v1/agent/tasks com o corpo do prompt. Sem retries escritos por você, sem encanamento de logs — o serviço cron injeta a entrada no crontab do sistema e acompanha a execução.

07:00 + ε

O agente raciocina

O agente recebe a descrição, abre as ferramentas — terminal, arquivos, sqlite, navegador, exec — e escolhe um plano de ação. Pode rodar, pular, adaptar ou paginar. As escolhas mudam todo dia. As instruções não.

07:00 — 07:04

A decisão acontece

A execução termina. O agente posta uma linha de resumo de volta: relatórios regenerados, pulado por falta de dados novos, parado por anomalia. Você lê no celular tomando café.

O agendamento não mudou. O script não mudou. O que mudou foi se você, humano, teve que acordar para tratar. Com o agente no loop, a resposta é quase sempre não — e o histórico de execução te conta o porquê.

use-cases / schedule-the-agent / capacity

O que você ganha do par cron + agente

Hoody Cron e Hoody Agent são dois serviços no mesmo contêiner, ambos acessíveis por HTTP. Os números vêm das superfícies documentadas — não de benchmarks inventados.

  1. TAMANHO DO CRONTAB1 linha

    Um curl no crontab, para sempre. O corpo do prompt é a única coisa que você reescreve — e isso em um arquivo JSON, não rodando crontab -e.

  2. ENDPOINTS DO AGENTE100+

    hoody-agent expõe a superfície completa — terminal exec, leitura/escrita de arquivos, query sqlite, automação de navegador, controle de daemon — para a tarefa do agente como chamadas HTTP simples.

  3. LINHAS DE COLA0

    Sem SDK entre o cron e o agente. POST em uma URL, leitura em outra. Os dois serviços vivem no mesmo contêiner, então a chamada é local-network rápida.

Hoody Cron suporta expressões padrão de 5 campos (* * * * *) e macros (@hourly, @daily, @weekly, @monthly, @yearly). A criação de tarefa do Hoody Agent é um POST /api/v1/agent/tasks; updates ao vivo fluem por /api/v1/agent/ws.

use-cases / schedule-the-agent / punchline

A entrada cron não roda o job — ela pede para um agente descobrir o job.

antes · script com branchesdepois · prompt com branches
PARA ONDE A ENTRADA CRON ANTIGA APONTAVA0 2 * * * /usr/local/bin/reconcile.sh # 412 linhas · 17 casos extremostoda nova regra de fim de mês significava editar o script e rezar
PARA ONDE APONTA AGORA0 7 * * * curl POST agent/tasks -d @prompt.jsonuma linha, para sempre — o prompt é o único artefato que você mantém
Ler a especificação de tarefa do agente
use-cases / schedule-the-agent / replaces

O que isso substitui

O conjunto de coisas que você costumava escrever dentro de reconcile.sh porque o cron só sabia rodar arquivos. Cada uma é uma branch, uma flag, uma config — nenhuma das quais o agendamento precisa saber. O agente lê o dia e decide.

  • jobs cron com scripts frágeisBranches bash que quebram quando uma coluna de entrada muda de lugar
  • manutenção manual para esquemas que mudamEditar reconcile.sh toda vez que a exportação upstream ganha um campo
  • scripts ETL escritos à mãoUma pasta de arquivos .sh que só uma pessoa do time entende
  • lógica cron if X then Y else ZFim de mês, feriado, anomalia — três flags conectadas em um script
  • scripts de polling para mudançasUm cron separado que fica de olho na saída do primeiro cron e decide
  • schedulers if-else escritos à mãoUm dispatcher de 200 linhas cujo único trabalho é escolher qual script rodar
use-cases / schedule-the-agent / cta

Pare de manter scripts cron. Comece a manter prompts. O agendamento dispara; o agente descobre.

Ler os docs cron + agente
use-cases / schedule-the-agent / related

Leia os outros