> ## Documentation Index
> Fetch the complete documentation index at: https://zenofirm.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Working on a cadence

> Zeno does not log into your books by itself. Here is how to put its work on a schedule anyway, using the scheduled tasks built into Claude and ChatGPT.

Zeno has no scheduler that reaches into your ledger. That is a deliberate
limit, not a missing feature: nothing posts to your books without a person
reading a plan first, and a robot that logs in overnight to click Approve is
the one thing that would quietly undo that promise.

What you can schedule is the **preparation**. The coding, the matching, the
reconciliation drafts, the questions that need a human — all of it can be
waiting for you when you sit down, with the approval still yours.

The scheduler lives in your assistant, not in Zeno. Both Claude and ChatGPT
can run a saved prompt on a timer against their connected tools, and Zeno is
one of those tools.

## Set up the scheduled work

<Steps>
  <Step title="Write the procedure down as a playbook">
    A playbook is the repeatable part: the order things happen in, the
    accounts that need checking, what to leave alone. Save it with
    `qb_write_playbook`, then confirm it with `qb_confirm_playbook` — an
    unconfirmed playbook is a draft, and `qb_run_playbook` will refuse it
    unless you ask for a rehearsal.

    Keep it firm-wide unless a client genuinely differs. A practice runs one
    month-end close, not seventeen.
  </Step>

  <Step title="Make the scheduled prompt short">
    The scheduled prompt should not contain the procedure. It should name it:

    ```
    Run the morning-feed-review playbook for Northwind.
    Post nothing — leave the plan for me and tell me what needs a decision.
    ```

    This matters more than it looks. A long scheduled prompt drifts from what
    your playbook says and you end up maintaining two procedures. A short one
    always runs the current version.
  </Step>

  <Step title="Let it stop at the plan">
    `qb_plan_batch` writes nothing to QuickBooks. It resolves names and
    accounts, applies your coding rules, flags duplicates, and leaves a table
    in the review journal. That table is what you read in the morning;
    `qb_apply_batch` is what you run after you have read it.
  </Step>
</Steps>

## Setting it up in Claude

Claude calls the feature **scheduled tasks**. It is available in Claude Cowork
on all paid plans (Pro, Max, Team, and Enterprise), and it runs on an hourly,
daily, weekly, weekday, or manual cadence.

Scheduled tasks have the same access as your ordinary chats, including
connectors — so a scheduled task can reach the Zeno connector exactly the
way you do when you type. Confirm the connector is enabled for the scheduled
task before relying on it.

<Info>
  Claude Code users have a second option: **routines**, which run scheduled
  agents in the cloud rather than in the chat app. That suits a practice that
  wants the run to happen whether or not anyone's laptop is open.
</Info>

## Setting it up in ChatGPT

ChatGPT calls it **scheduled tasks** too, reached from the **Scheduled** page
in the sidebar, where you can see the next run time and pause, edit, or delete
each one. How many you can have at once depends on your plan — roughly three
on the free and entry tiers, more on Pro and Enterprise.

Two caveats worth knowing before you build a practice around it:

* **MCP connector support is uneven.** Full read/write MCP connectors are a
  Business, Enterprise, and Edu capability; on Plus and Pro you connect
  servers through developer mode with tighter limits on what a tool is allowed
  to do. Confirm your plan reaches Zeno's write tools before you schedule work
  that depends on them.
* **A connector available in chat is not guaranteed inside a scheduled run.**
  Users report scheduled tasks reporting a connector unavailable that works
  fine when prompted live.

Neither is a reason to avoid ChatGPT. Both are a reason to watch the first
week of runs before you trust the eighth.

## What to schedule

<CardGroup cols={2}>
  <Card title="Daily, early" icon="sun">
    Sync the mirror, pull the feed, and plan the coding for anything the rules
    already cover. You arrive to a table, not a queue.
  </Card>

  <Card title="Weekly" icon="calendar">
    Unmatched receipts, aging that moved, bills approaching their due date, and
    anything sitting in Ask My Accountant.
  </Card>

  <Card title="Month-end" icon="calendar-check">
    Run the close playbook to the point of the plan. The entries wait for you.
  </Card>

  <Card title="After a cleanup" icon="rotate">
    Re-run `qb_study_history` so the drafted knowledge reflects the books as
    they now are, not as they were.
  </Card>
</CardGroup>

## What not to schedule

Do not schedule `qb_apply_batch`, and do not write a scheduled prompt that
tells Zeno to approve its own plan. You can phrase such a prompt, and it will
do as it is told — the tools obey you, including when you are wrong.

The reason not to is not that the coding will be bad. It is usually good. The
reason is that an approval nobody read is not an approval, and the audit trail
will show a month of them before anyone notices the first mistake. Reading the
table is the product.

## Put it on the firm's calendar

A scheduled prompt knows when it runs; it does not know what is due. Zeno
holds that. An **engagement** is a standing commitment — work this client's
books monthly, due the tenth business day — that opens a period every cycle
and puts it on the console's Today queue until a person closes it. Ask the
assistant to create one:

```
Set up a monthly close for Northwind, due 10 business days after month end,
running the month-end playbook.
```

That is `qb_create_engagement`, which binds the playbook in the same call.
From then on the scheduled prompt can be shorter still — *call `qb_due_work`
and work whatever it lists* — and changing a client's cadence means changing
the engagement, never the prompt. A person says when a period is finished
(`qb_close_period`), parks one that is waiting on a statement
(`qb_park_period`), and retires the engagement when the work ends
(`qb_retire_engagement`). The console's **Engagements** page shows what is
open, how late, and which machines have checked in.

## Know when it stopped

The scheduled prompt should call `qb_due_work` even when nothing is due. That
call is the machine's heartbeat. Under **Settings → Notifications**, choose how
many quiet days count as stopped and enable **Nothing is running**. See
[Notifications](/docs/cloud/notifications).

Prepared work appears in `qb_list_plans`; the scheduled agent should also write
what it did to the work log. Applying remains a separate, reviewed action.
