“What needs attention before the Monday meeting?” is a useful first question for an agent. When the answer starts helping every week, the next step is a routine that prepares it without someone remembering to ask.
The schedule is easy. The harder part is keeping the definitions, sources and failure behavior dependable.
At a glance
- Ask the question in chat until the answer is useful to its reader.
- Keep the reporting definitions in shared context, rather than copying them into the schedule.
- Run as a named account and decide what happens when data is missing or a step is interrupted.
First, find out what the question really means
In an illustrative distributor, the operations lead wants late shipments, orders at risk and unresolved handover items before the weekly call.
The first answer raises useful questions. Does late mean dispatched after the promised date or delivered after it? Does a shipment held at the customer's request count? When is an order considered at risk?
Resolve these with the owner before automation. Put the agreed definitions in the Hub, with their source and effective date.
A wrong answer is often an unwritten definition becoming visible.
Give the report a structure its reader can check
A useful report might have four sections:
- The figures and the reporting period.
- Exceptions against the approved thresholds.
- Missing or stale inputs.
- The owner of each next action.
Use code to calculate the figures and compare thresholds. Let the agent explain the findings using the relevant knowledge and procedure.
If the north warehouse export is missing, the report should say so and hold its affected conclusions. An incomplete report can still help. A confident report built from half the inputs is harder to trust.
Choose instructions or exact steps
Hubzoid offers two ways to define recurring work:
| Choose | When it fits |
|---|---|
| A plain-language scheduled task | The job can be expressed as bounded instructions for the agent |
| A code workflow | Exact steps, thresholds, timing or integrations need more control |
The two have different behavior. Plain-language tasks wait to start while chat is busy and catch up once after downtime. Code workflows do not wait for chat and do not backfill missed slots. Choose deliberately if the report must be ready at a particular time.
The run needs an account and a failure plan
Scheduled work acts as the account configured for it. Give that account the access the task needs and review where its output can be seen.
Record which reporting periods have been handled. Finished code-workflow steps can be reused after a restart, but an interrupted step may run again. Prevent a repeated run from creating a duplicate message or record. A plain-language task interrupted during its work fails rather than silently repeating all of it.
The Console provides the run record, status and errors. Name someone to check it when the report does not arrive.
A correction should improve the next report
When the team notices a customer-held shipment was counted as late, update the shared definition. Add a behavioral check for that case and run it after later edits.
Chat, the report and a supported assistant connected through MCP can then use the same definition. Reuse the maintained rule instead of repairing one conversation at a time.
Next step: compare workflows and schedules for the job you want to automate.
Watch The daily report, episode 7 (opens in a new tab). It demonstrates the pattern in the fictional Wren & Page bookshop.