Skip to content

Scheduled Jobs

Quincy can run agents on a schedule — no manual trigger required. A scheduled job tells Quincy which agent to run, when to run it, what goal to send, and where to send the result.

This is how you build background automations: a daily email summary, a morning briefing with your calendar and reminders, a weekly review that searches your notes and posts a digest somewhere useful.

When a job's schedule triggers, Quincy assembles context from configured sources, runs the agent headlessly, and routes the output wherever you specified.

flowchart LR
    Cron[Cron trigger] --> Context[Fetch context]
    Context --> Memory[Memory search]
    Context --> Tools[Tool calls]
    Context --> Cascade[Agent cascade]
    Context --> Execute[Headless agent runs]
    Execute --> Output[Route output]
    Output --> Notify[Push notification]
    Output --> Mem[Save to memory]
    Output --> Tool[Call a tool]

What a Job Contains

Each scheduled job has:

  • An agent — which agent to run (identified by name)
  • A schedule — when to run it, using a standard five-field cron expression (e.g., 0 8 * * 1-5 for weekdays at 8 AM)
  • A goal — the instruction sent to the agent as its first message (e.g., "Summarize unread emails from the last 24 hours and highlight anything requiring action")
  • Context (optional) — data fetched and injected before the goal, so the agent starts with relevant information already in hand
  • Output routing (optional) — where to send the agent's final response

Creating a Job

Ask Quincy to create a scheduled job for you. Describe what you want to happen and when:

> Create a job that runs my email agent every weekday morning at 8 AM and summarizes overnight messages

You can create scheduled jobs by asking Quincy directly — for example, "create a job that checks my email every morning at 8am and summarizes what needs attention." Quincy validates the job configuration before saving it.

Quincy will set up the job, confirm the schedule, and start running it at the next trigger time. Jobs can be paused, edited, or deleted at any time.

Context Providers

Context providers fetch data and inject it into the job's system context before the goal is sent. This lets the agent start already knowing relevant information rather than having to look it up first.

Available context sources:

  • Memory search — pull in remembered facts relevant to the job (e.g., recent user preferences)
  • Another agent — run a different agent first and pass its output as context
  • A tool call — invoke a specific tool and inject the result

You can combine multiple context providers in a single job. They all run in parallel before the goal is sent.

Output Routing

By default, the agent's response is logged internally. You can route the output elsewhere:

  • Push notification — sends the final response as a notification to your Mac or iPhone (requires push notifications to be configured)
  • Memory — saves the result to persistent memory for recall in future sessions or jobs
  • A tool call — passes the output to a specific tool (e.g., append to a file, post to a service)

Timeouts

Jobs have a maximum run duration (default: 30 minutes). If the agent hasn't finished by then, the job is cancelled. You can raise or lower this per job.

Approval Timeouts

If a scheduled job needs your approval for a tool call and no device responds within the configured timeout, the job skips that action and continues. Timeouts are paused when you're actively connected to the session.

Headless Execution

Scheduled jobs run in headless mode — there's no interactive session. The agent gets one chance to complete its goal using the tools available to it. If it needs to ask a question, it can't wait for a user response; it should either make a reasonable assumption or use save_to_memory to flag that human input is needed next time.

For this reason, the agents used in scheduled jobs are typically non-conversational, focused specialists rather than general-purpose conversational agents.