Skip to content
TypeNew primitiveStageProductionDifficultyModerateJobAutomate taskForAI buildersForBackend devsServicesCronServicesAgentWhy HoodyAI-nativeWhy HoodyHTTP-native
TypeNew primitiveStageProductionDifficultyModerateJobAutomate taskForAI buildersForBackend devsServicesCronServicesAgentWhy HoodyAI-nativeWhy HoodyHTTP-native
TypeNew primitiveStageProductionDifficultyModerateJobAutomate taskForAI buildersForBackend devsServicesCronServicesAgentWhy HoodyAI-nativeWhy HoodyHTTP-native
TypeNew primitiveStageProductionDifficultyModerateJobAutomate taskForAI buildersForBackend devsServicesCronServicesAgentWhy HoodyAI-nativeWhy HoodyHTTP-native
Back to use cases
use-cases / schedule-the-agent / hero
CRON · AGENT · 0 7 * * *

Schedule the agent, not the script

A traditional cron line runs reconcile.sh at 2am. A Hoody cron line POSTs a prompt to hoody-agent. The schedule is fixed. The work isn't. Edge cases stop being branches you maintain — they become context the agent reasons about.

Read the cron + agent docs
use-cases / schedule-the-agent / mechanism

Two URLs, one prompt

Hoody Cron is a managed crontab on every container. Hoody Agent is a built-in autonomous agent on the same container. The cron entry curls the agent. The agent reads the date, reads the data, and decides what the day requires. Both surfaces are HTTP — the cron lives at /api/v1/cron/users/me/entries, the agent at /api/v1/agent/tasks. There is no glue code between them.

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": "Reconcile yesterday’s orders. Remap if schema drifted. Halt and page on-call if anomaly score > 3. If today is the last day of the month, include monthly close on the tax-adjusted ledger.",
  "mode": "code"
}

Two POSTs and you are done. The crontab line never changes again — the only file you maintain is the prompt. New edge case? Add a sentence. New anomaly rule? Add a sentence. The schedule keeps firing; the agent figures out what each firing means.

use-cases / schedule-the-agent / powers

Three things a prompt does that a script can't

The shape of the work the agent receives is always the same — a date, a dataset, a goal. What changes is what the agent decides to do about them.

REASONING

Reads the date, reads the data, decides

The agent runs after the cron fires. It checks the calendar — month-end, holiday, fiscal close. It samples the dataset — schema, volume, anomaly score. It picks the next action with that context, not from a static if-tree you wrote six months ago.

ADAPTATION

New columns? New currencies? Same prompt.

When yesterday's export adds a refund_reason column, a script breaks and pages you. The agent reads the schema, maps it to the legacy field, and notes the change in the run summary. The crontab line never had to know.

OBSERVABILITY

Every run is a paragraph, not a return code

Each run posts back what the agent decided and why. The history is plain English — "skipped: no new data", "adapted: refund column added", "anomaly: refund spike +412%, paged on-call" — not exit code 0 / exit code 1. The cron's logs become a journal.

use-cases / schedule-the-agent / flow

From schedule to decision

Three steps — the cron fires, the agent reasons, the decision lands. The middle step is the one you used to write yourself in a 400-line shell script with seventeen edge-case branches. Now it's a prompt.

Three-step daily loopONE PROMPT · INFINITE EDGE CASES
07:00

The cron fires

Hoody Cron runs the entry. The crontab line is one curl: POST /api/v1/agent/tasks with the prompt body. No retries written by you, no logging plumbing — the cron service injects the entry into the system crontab and tracks the run.

07:00 + ε

The agent reasons

The agent receives the description, opens its tools — terminal, files, sqlite, browser, exec — and picks an action plan. It might run, skip, adapt, or page. The picks change daily. The instructions don't.

07:00 — 07:04

The decision lands

The run finishes. The agent posts a summary line back: regenerated reports, skipped because no new data, halted on anomaly. You read it on your phone with breakfast.

The schedule didn't change. The script didn't change. What changed is whether you, the human, had to wake up to handle it. With the agent in the loop, the answer is almost always no — and the run history tells you why.

use-cases / schedule-the-agent / capacity

What you get from the cron + agent pair

Hoody Cron and Hoody Agent are two services on the same container, both reachable as HTTP. Numbers come from the documented surfaces — not from invented benchmarks.

  1. CRONTAB SIZE1 line

    One curl in the crontab, forever. The prompt body is the only thing you ever rewrite — and you do it in a JSON file, not by running crontab -e.

  2. AGENT ENDPOINTS100+

    hoody-agent exposes the full surface — terminal exec, file read/write, sqlite query, browser automation, daemon control — to the agent's task as plain HTTP calls.

  3. LINES OF GLUE0

    No SDK between the cron and the agent. POST one URL, read another. Both services live on the same container, so the call is local-network fast.

Hoody Cron supports standard 5-field expressions (* * * * *) and macros (@hourly, @daily, @weekly, @monthly, @yearly). Hoody Agent task creation is one POST /api/v1/agent/tasks; live updates stream over /api/v1/agent/ws.

use-cases / schedule-the-agent / punchline

The cron entry doesn't run the job — it asks an agent to figure out the job.

before · branching scriptafter · branching prompt
WHAT THE OLD CRON ENTRY POINTED AT0 2 * * * /usr/local/bin/reconcile.sh # 412 lines · 17 edge casesevery new month-end rule meant editing the script and praying
WHAT IT POINTS AT NOW0 7 * * * curl POST agent/tasks -d @prompt.jsonone line, forever — the prompt is the only artifact you maintain
Read the agent task spec
use-cases / schedule-the-agent / replaces

What this replaces

The set of things you used to write inside reconcile.sh because cron only knew how to run files. Each one is a branch, a flag, a config — none of which the schedule actually needs to know about. The agent reads the day and decides.

  • brittle scripted cron jobsBash branches that crash when one input column moves
  • manual maintenance for changing schemasEditing reconcile.sh every time the upstream export grows a field
  • hand-written ETL scriptsA folder of .sh files only one person on the team understands
  • if X then Y else Z cron logicMonth-end, holiday, anomaly — three flags wired into one script
  • polling-for-changes scriptsA separate cron that watches the first cron's output and decides
  • hand-coded if-else schedulersA 200-line dispatcher whose only job is to pick which script to run
use-cases / schedule-the-agent / cta

Stop maintaining cron scripts. Start maintaining prompts. The schedule fires; the agent figures it out.

Read the cron + agent docs
use-cases / schedule-the-agent / related

Read the others