Design pattern: the Work Tracker
This is one of the Practices and Patterns for thunk designers — proven ways to shape a thunk for a common class of problem, so you can start from a known-good structure instead of a blank page.
The Work Tracker is one of the most common and useful patterns. Use it whenever each work item represents a unit of work that a person is expected to do — a bug to fix, an article to write, a contract to countersign, an onboarding task to complete — and the thunk’s job is to track that work to completion, keep its status current, and nudge or escalate when it is at risk of missing a deadline.
The thunk is doing two things at once:
It is reactive: when new information arrives about a work item, it absorbs the update and revises its understanding of where the work stands.
It is proactive: on a schedule, it checks each work item against its deadline and drives the next action — a reminder, a warning, or an escalation — without anyone asking.
Legacy trackers (spreadsheets, ticket systems) only record status; people still have to watch the dates and chase the owners. A Work Tracker thunk does the watching and the chasing for you.
The shape of the pattern
A Work Tracker has two parts:
An inbound channel that accepts new work items and updates to existing ones.
A three-step Workflow Plan — Prepare, Track, and Wrap up — where the middle step does the heavy lifting.
The inbound channel
New work and updates usually arrive through the thunk’s Email Inbox or its Webhook endpoint (a REST API is also available for deeper integrations). See Inbound Requests for the full set of options.
The important design decision is matching: an incoming message is either new work (create a work item) or an update to existing work (find the right work item and revise it).
For email, replies on the same thread stay attached to the same work item automatically when you model the exchange as a Conversation property. See Conversation Properties for Email.
For webhooks and API calls, include a stable identifying property (for example a ticket ID or an order number) so an update can be routed to the matching work item instead of creating a duplicate.
The workflow state
Because more schematization leads to more reliable AI, decide the work item’s state up front (see Workflow Plan). A typical Work Tracker work item carries properties such as:
Owner — who is expected to do the work (and how to reach them).
DueDate — when the work is expected to be complete.
Status — a constrained set of values, e.g.
Not started,In progress,Blocked,Done.Health — a red / amber / green signal derived from how close the deadline is.
NextCheckDate — the next date this work item needs the agent’s attention (this property is the key to an efficient schedule — see below).
A Conversation property to hold the two-way thread of updates and reminders with the owner.
Step 1 — Prepare
The first step turns an intake message into a well-formed work item. Its AI Instructions extract and record the essentials: who owns the work, what is expected, and the DueDate. This is also where you set the initial Status, compute the first Health value, and set an initial NextCheckDate.
Keep this step deterministic and quick. Its only job is to get the work item into a clean, structured starting state so the tracking step has good data to work with.
Step 2 — Track (the long-running step)
This is the heart of the pattern. The Track step stays open for the whole life of the work item — often days or weeks — and does its work in three distinct modes.
(a) Set up, then wait
When a work item first reaches this step, the agent does any one-time setup — for example, sending the owner an initial acknowledgement or a “here’s what I’m tracking and when it’s due” message — and then concludes its run while leaving the step open. The step is now idle and waiting until something wakes it.
Two things can wake it: an inbound update about this work item, or a scheduled check.
(b) Handle an update
When a new message about this work item arrives — an email reply from the owner, a webhook event, an API call — it is routed to this same work item and re-invokes the step’s agent. The agent reads the update, revises the work item’s state (for example moving Status to Blocked or Done, adjusting the DueDate, or recording a note), recomputes Health, and — importantly — recomputes NextCheckDate based on the new situation. Then it concludes and the step goes back to waiting.
Write these instructions to answer: given this new information, what does the work item look like now, and when should I next look at it?
(c) Handle the scheduled check
The proactive half of the pattern runs on a schedule. In the step’s Scheduled Work Settings, choose a cadence — Daily at specific time (with a Days of week selection and timezone) or Every hour (optionally limited to certain active hours). On each tick, the agent re-evaluates the work item: how much time is left until DueDate, what the Health should now be, and whether it is time to send a reminder, a warning, or an escalation to the owner or their manager. It then updates the state and recomputes NextCheckDate for the following check.
The NextCheckDate technique — an efficient schedule
A fixed daily or hourly schedule would, on its own, wake the agent for every tracked work item on every tick — most of which have nothing that needs doing. The NextCheckDate property, combined with the schedule’s Query Filter, avoids that.
Each time the agent runs — on an update or on a scheduled check — it computes when this particular work item next needs attention and stores that date in NextCheckDate. Far from the deadline it might set NextCheckDate a week out; as the deadline approaches it tightens the interval so reminders come more frequently; once the work is
Doneit can push NextCheckDate far into the future.In Scheduled Work Settings, set a Query Filter such as NextCheckDate is on or before today. Now a scheduled tick only invokes the agent for work items that are actually due for a check. A work item whose NextCheckDate is still in the future is skipped for that tick — the agent is not invoked for it.
Conceptually, the agent is choosing its own next wake-up time for each work item by writing NextCheckDate; the fixed schedule plus the filter is simply the mechanism that honors that choice. This keeps the thunk responsive where it matters and quiet everywhere else, even across thousands of work items.
Deciding when the tracking is done
The Track step should proceed only when the work is genuinely complete. Express that with a Step Finish Condition under the step’s Workflow Options — for example, proceed only when Status is Done. Until the work item matches, the step stays open and keeps tracking; when it matches, the workflow advances to the final step. See Control when a step runs and proceeds.
Step 3 — Wrap up
Once tracking is complete, the final step performs whatever should happen after the work is done: recording the outcome in an external system, sending a completion notice, filing a summary, or writing back to the system that opened the request. Because the Track step only proceeds when its finish condition is met, this step can rely on the work item being in a clean, completed state.
Design tips
Schematize the status fields. Constrain Status and Health to an explicit set of values, and give DueDate and NextCheckDate date types. Precise property definitions make the agent’s updates far more consistent.
Let the agent own NextCheckDate. Every run — update or scheduled — should end by deciding the next check date. That single habit is what makes both the reminders well-timed and the schedule inexpensive.
Match the reminder cadence to the deadline. Tighten NextCheckDate as the DueDate nears, and relax it when the work item is far out or already complete.
Use the Query Filter to stay cheap at scale. The filter is what prevents a daily or hourly schedule from running the agent on every work item every tick.
Know when status is refreshed. A work item’s health and reminders are recomputed the next time the agent runs on it — on the next inbound update or the next scheduled check that its filter allows — not the instant a date passes. Choose a schedule cadence tight enough that your reminders arrive when you need them.
The Work Tracker pattern is deliberately simple, and it adapts to many domains: bug SLAs, content pipelines, approvals, renewals, onboarding checklists, and program-management tracking of any kind. Once you have built one, the same three-step shape — Prepare, Track, Wrap up — with a reactive update handler and a proactive, self-scheduling check will serve for the next one.