Open-source scheduled AI agents: a machine, a stop condition, state

What changes when the clock starts the work

On demand, a person opens the session, reads the result, and closes it. A schedule removes that person from both ends. Something else has to start the work, something has to decide it is finished, and something has to hold the result until a person looks. Those are the same three questions you answer when you put any job on a server.

Most advice about scheduling an agent is about the trigger. A cron line, a helper script, a wrapper that posts to a model API. That gets a first run. The second run is where the laptop closes, the machine is gone, or the model starts from zero and repeats work it already did.

A machine that wakes without you

Kortix's README states the split plainly: "Compute and state are separate. Every session runs on its own cloud computer. The computer sleeps 15 to 20 minutes after the last turn and wakes on the next message or event, with its full history. State lives in the repo, in Drive, in the session's /workspace and in the session's record." Sleep here is a cost control. The machine comes back for the next fire with the history it had.

An owner's published seven-agent experiment running OpenClaw solved the same problem with systemd. Each gateway ran as a service with Restart=always and loginctl enable-linger, so a logout or a reboot did not take the agents with it. The account shows the shape of the problem as well as the result: a machine that stays up is a precondition, and someone has to own it.

A stop condition the agent sets before it stops

A cron job runs a command and exits. An agent can keep working, so the exit needs a rule. In Kortix a session sets its own check-in before it stops: it picks the signal it waits for, paces the loop to the wait, and tells the person in one line what it will check and until when. Every loop has an end date, 14 days unless another is named, and the agent removes it when the work is done.

The guardrails around that live in the trigger itself. A trigger starts at most 60 runs an hour by default. A schedule skips a fire while the previous run is still active. A triggered session that needs a person waits at most 30 minutes, then stops. Those numbers decide whether an unattended job is safe to leave alone, and they belong in the manifest, where a diff can show them.

This is the difference a scheduler alone cannot cover. Cron knows the time. The session knows whether the report has the numbers in it, whether the deploy finished, and whether the vendor replied.

State that outlives the machine

The seven-agent experiment is the clearest warning about state. Each agent had markdown files for identity, user context and memory, and the owner checked in about once a day. The post found the identity and memory files stale within the week.

Markdown is a fine place for memory. The state still needs a run that reads and writes it on a clock, with a stop condition attached.

Kortix keeps the same idea but separates the storage from the run: the project is a git repository, Drive holds shared files, /workspace holds a session's files, and the session's record holds the transcript. A new run can read what the last one wrote, and a person can read the diff.

The trigger, in the manifest

The trigger reference is short. Triggers start sessions from schedules (cron), signed webhooks, connector events, App events and merged change requests. session_mode has four values: fresh, reuse, pinned, keyed. The default is fresh. The mode answers a question a plain cron line cannot: should this fire start clean, continue the last session this trigger made, run in one named session, or get one session per key in the payload.

The four modes map to four kinds of recurring work. A daily report wants a fresh session. A running support thread wants reuse, so the agent keeps the context of the last cycle. A single long-lived operator session wants pinned. A queue of customer conversations wants keyed, with the conversation id as the key.

A schedule covers the clock. A signed webhook covers an event another system can announce. A connector event or an App event covers something that happens in a connected app or in one of your Apps, and a merged change request starts work once a review lands. The same session machinery runs whichever source fires.

The parts that keep parallel work apart

A schedule multiplies. Ten triggers that fire every few minutes create a small fleet, and a fleet needs isolation as much as it needs a clock. One isolated sandbox per session. Each session has its own isolated machine and branch. Thousands of agents in parallel on one config, each on its own cloud computer.

The isolation is what keeps two runs from writing over each other. It also means the shared state has to be chosen: the repo for what the company owns, Drive for what outlives a single job, the session record for what happened. That choice is the design work behind a schedule, and it is worth making before the first trigger is enabled.

A checklist before you leave it running

• The machine: does it wake on the event, and where does its state land when it sleeps?
• The end: what ends the run, what is the loop's end date, and what happens when the run limit is reached?
• The gate: what may the agent change without a person? The agent approval workflow covers how a rule holds an action and who can release it.
• The review: can a person read the diff and the run history afterwards?

It is the same set of decisions as putting a nightly job on a server, with one addition: the job can now decide what to do next. That addition is why the infrastructure questions come first, and why a schedule written into a repo is easier to review than a script on someone's laptop.