Processes & scheduling

A process runs once per invocation, toward a definitionOfDone, under a budget. How it gets invoked is the process’s trigger.

Manual

The default. Run it yourself:

ravel run prospect-outreach

Or trigger it from the platform console or API.

Scheduled

A process can schedule itself in one of two modes.

Adaptive

After each run, the orchestrating agent can write a next_run_minutes hint (with a reason) to team memory. The scheduler clamps that hint to an operator-configured [minMinutes, maxMinutes] range and schedules the next run accordingly. If the agent gives no hint, the scheduler falls back to the max interval rather than guessing short.

This is the mode to reach for when the right cadence genuinely depends on what happened last run — a monitoring process that should check more often when something looks off, and back off when things are quiet.

Cron

A standard 5-field cron expression (minute hour day-of-month month day-of-week, evaluated in local time). Use this when the cadence is fixed and doesn’t depend on run outcomes — a weekly report, a nightly sync.

Safety rails

These are enforced in code, not just prompted for:

• Single-flight — a process already running is never started again concurrently.
• Interval clamp — adaptive scheduling can’t drift below the configured minimum or above the maximum.
• Daily spend ceiling — an optional maxUsdPerDay on a scheduled process pauses its automatic runs (without failing them) once the rolling 24-hour spend hits the cap, and resumes once spend rolls back under it.

Configuring a schedule

Set a process’s trigger in its own processes/*.process.md frontmatter, or adjust scheduling for an already-deployed team from the platform console (the team’s Automation panel) — scheduler config is treated as live team state, so it stays editable even when the rest of a team’s config is read-only.

Next

• Processes — the full process file reference
• Agent teams