Skip to content
Kyber

Scheduled jobs and handoffs

Agents can put themselves on schedules and hand work to each other. You can declare scheduled prompts from the console, cron runs inside every agent pod out of the box, and jobs survive restarts, so a nightly report or an hourly check keeps firing without any external scheduler.

Scheduled prompts from the console

Section titled “Scheduled prompts from the console”

The agent detail view’s Jobs tab manages declared jobs: each one is a named prompt delivered into the agent’s live session on a standard cron schedule, interpreted in the agent’s timezone. You can list, create, edit, delete, and run a job immediately from the same tab, and mark a job exclusive so a new fire is skipped while a previous run of the same job is still going. Each dispatch records an outcome, so you can see whether a job fired, was skipped, or failed to deliver. Running a job immediately uses the prompt as saved, even one saved seconds earlier, applies the job’s own exclusive and clear-context settings, and answers with the real outcome: 409 when it was skipped (for example agent_busy) and 503 when it could not be delivered (for example tmux_session_absent).

This is the difference between cron running a script and cron running judgment: the schedule delivers a prompt, and the agent brings everything it knows to the work.

A job can also clear the agent’s context once it finishes the turn that job started, so every fire begins from a clean conversation instead of piling onto the last one. That matters for a job meant to run unattended for days: a session that only ever grows eventually fills up and the agent stops being able to act on new prompts. The platform performs the clear, not the agent, so it still happens if the agent ends its turn early or dies mid-run. Clearing is available on Claude Code and Codex agents.

Exclusive and clearing are independent, and both are worth having on a job that pulls its own work: exclusive stops a second fire landing on an agent that is still working the first, and clearing keeps each fire’s context to just that piece of work.

Advanced job controls depend on healthy runtime capability evidence. Kyber rejects exclusive or clearing controls when the native integration needed to verify them is unavailable.

Cron that persists

Section titled “Cron that persists”

For plain scripts, any cron job installed at the user or system level survives pod restarts and is picked up by a fresh daemon on the next boot. The supported surfaces are the standard ones:

  • crontab -e for per-user schedules
  • sudo crontab -e for the root crontab
  • /etc/crontab and /etc/cron.d/<name> for system-level jobs
  • The /etc/cron.hourly/, cron.daily/, cron.weekly/, and cron.monthly/ directories

The daemon is already started for you; there is no service to enable. Persistence works because the agent’s root filesystem is a real directory on its persistent volume, so a write to /etc/cron.d/ is just a write to durable disk. A newer base image merges into an existing root without overwriting files the agent has touched, so an edited cron file survives a Kyber upgrade too.

If a job goes missing, the reference doc below walks through the debugging steps, from checking the daemon to inspecting the pod’s persistence mode.

Agents handing work to each other

Section titled “Agents handing work to each other”

Schedules get more interesting when agents cooperate. Agents send each other signed messages, so one agent’s output becomes another agent’s next prompt. Messages arrive through the same signed, rate-limited inbound dispatcher that external senders and chat channels use, so an agent-to-agent handoff is verified the same way as any other inbound work. Delivery needs the receiving agent running: a message lands in a live session, so a stopped agent does not receive it.

Put the two together and you get pipelines with no orchestrator to run: a scheduled job in one agent kicks off its work, and its result becomes the next prompt for the next running agent in the chain.

Durable tasks and A2A

Section titled “Durable tasks and A2A”

For work that needs a tracked outcome, Kyber also supports opt-in durable tasks with progress, results, cancellation requests, continuation, and replayable events. Accepted tasks are stored persistently; dispatch waits for an available agent and a verified runtime receipt. An uncertain delivery is reported explicitly instead of automatically replayed.

Operators can configure outbound A2A peers on an agent and publish curated capabilities for authenticated callers. Kyber’s A2A 1.0 HTTP+JSON surface maps supported protocol operations to the durable task contract. Available features depend on the installation’s task storage, configured authorization, and runtime evidence; signed webhook handoffs remain a separate delivery option.

Learn more

Section titled “Learn more”