Tasks and Schedules: AI Coding Work on a Board and on a Clock
Live chat is one engineer, one turn, watching.
Real teams also need work that queues, runs, and comes back for review, and work that runs while nobody is watching.
That is Tasks and Schedules.
What this covers
- Pathrule Studio has two distinct surfaces for non-interactive work. Tasks is a Kanban board of cards you write and run on demand. Schedules is a set of unattended runs that fire on a cadence.
- Board cards move through To do, In progress, Awaiting approval, and Done. An agent parks a finished card in Awaiting approval; a human approves it into Done.
- Run all hands the To do lane to an orchestrator that clusters cards by topic and gives each group its own git branch, one commit per card.
- Both board runs and scheduled runs execute scoped to the selected path, so the same path-scoped memories and rules Pathrule injects into chat also shape work that runs on a board or a timer.
Comparison
| Dimension | Tasks (the board) | Schedules |
|---|---|---|
| Who writes it | You, as a card on the board | The assistant, when you ask it to run something on a cadence |
| When it runs | On demand, when you hit run | On a cadence: hourly, daily, weekly, or monthly |
| Who is watching | You can watch a card run in chat | Nobody; it runs unattended and leaves a result to read |
| What you get back | A card parked in Awaiting approval | A team-visible run you can open later |
| Best for | A batch of scoped changes to queue and review | Recurring upkeep that should not depend on someone remembering |
Chat is not the only shape of AI coding work
Most AI coding happens in a live session. You type, the assistant works, you watch, you correct. It is the right shape for exploratory work and for anything where you want your hands on the wheel.
It is the wrong shape for two other kinds of work teams actually have. The first is a batch: a stack of small, well-understood changes you want to queue up, run, and review, without babysitting each one. The second is upkeep: something that should happen every morning or every week, whether or not anyone remembers to start it.
Pathrule Studio adds a surface for each. Tasks is a board for the batch. Schedules is a timer for the upkeep. They are separate features with separate lifecycles, and it is worth keeping them straight.
Tasks: a board you write and run
Tasks is a Kanban board, and it behaves the way an engineer expects a board to behave. You write the cards. Each one is a unit of work you want an assistant to do, in a lane that reflects its state: To do, In progress, Awaiting approval, Done.
A card carries the engine it should run on. You can pin it to a specific assistant, or leave it on auto and let the workspace default decide. When you run a single card, it opens in chat so you can watch the turn happen, with the board framing delivered quietly in the background rather than cluttering the transcript.
The board is team knowledge, not a personal scratchpad. Cards, their state, and the discussion on them are shared and survive the app closing and reopening, so a board is something a team can reason about together rather than a queue that lives on one laptop.
From a one-line card to a reviewed change
A good card often starts as one line. Before it runs, Pathrule can turn that brief into a real plan in the background, without opening a chat tab, so a terse note becomes a task the assistant actually understands.
When the planning step hits a genuine fork, an architectural choice or a missing decision it should not guess, it does not plow ahead. It asks. The question lands as a comment on the card, in a thread that reads like a pull-request conversation and survives restarts. You answer, and planning resumes. The clarifying questions are part of the record, not a modal you dismissed and forgot.
When a card runs and finishes, the agent moves it to Awaiting approval and stops. It never marks its own work Done. That last move belongs to a person, which keeps the board honest: finished means a human looked at it, not that the model said so.
Run all: an orchestrator with git discipline
Running one card at a time is fine for a few. For a full lane, there is Run all. It hands the To do cards to an orchestrator that works through them, and this is where the board earns its keep.
The orchestrator does not run every card into one messy working tree. It clusters the cards by topic and gives each cluster its own git branch, cut from your base, with one commit per card. When it finishes, it returns you to the branch you started on. A stack of changes becomes a set of reviewable branches instead of a tangle.
The git work is deterministic, not improvised. The model decides how to group the cards and what to name the branches and commits; the actual branch, checkout, and commit operations run through a fixed path. It refuses to start on a dirty working tree or outside a git repo, and if one card fails to integrate it skips that card, keeps going, and tells you in the summary. Each cluster lands on its own branch, so you review the batch and open pull requests on your own terms.
Schedules: work that runs on a clock
Schedules is the other surface, and it is deliberately not a board. It is for work that should run on a cadence with nobody watching: a daily summary, a weekly sweep, a recurring check.
You do not fill out a cron form. You ask the assistant, in chat, to run something on a schedule, and it writes the scheduled task for you: the prompt, the cadence, and how it should run. The cadence is plain, hourly, daily, weekly, or monthly, rather than raw cron syntax. Execution is a hybrid: the cloud marks a task due when its time arrives, and your desktop runs it, reconciling any windows it missed while the app was closed.
A scheduled run can be a single assistant working the task, or it can hand off to the same orchestrator the board uses for heavier work. Execution is opt-in per machine, so a shared task does not fire on every laptop at once, and it steps aside when your token budget is low rather than burning it at a bad moment. Each run leaves a team-visible result you can open later.
Both inherit your path-scoped context
The reason both of these belong in Pathrule and not in a generic task runner is what they run with. A board card and a scheduled task both execute scoped to the path you selected in the workspace tree. The same path-scoped memories and rules that Pathrule injects into a live chat session ride along into work that runs on a board or on a timer.
That is the difference between an agent that runs your task and an agent that runs your task the way your team would. The context does not stay behind in the chat window. It follows the work into the queue and into the schedule, and the prompts that carry it are end-to-end encrypted the same way chat is.
Every signup gets three months of Pathrule PRO on the house. If you want to move a recurring chore onto a schedule or turn a backlog into a reviewed set of branches, [email protected] is open.