Running several workspaces in parallel is a normal DF Code habit, not a hypothetical — which means "catching up" usually means opening each one in turn to see what moved overnight. That's the same tax as checking five Slack channels or five project boards by hand, just paid every single morning.
Most agents don't help with that, because most agents are built to react to one thing. An `unread`-trigger agent notices new messages in a single thread. An `always`-trigger agent keeps nudging that same thread every tick, whether anything changed or not. Either way, there's a thread already in front of it, telling it where to look.
A `scheduled` agent is the odd one out. It gets no thread at all — nothing arrives for it to react to. Given an interval instead, it has to go looking for its own work, the same way you'd poll a repo for anything new. Point that at a single project and it's a quiet poller. Point it at every workspace you're running, and it becomes something closer to a morning briefing.
That's exactly what DF Code's own "Status Triage" canned Agent does — it surveys your workspaces on a schedule and posts what it finds as a single thread in the shared `Uncategorized` workspace, the same place the floating one-off-thread panel keeps its own ad-hoc chats. Nothing about that clutters any individual project's own thread history; the digest lives in one place, separate from the work it's reporting on. From there it surfaces on its own — the Status Report hub's "New Messages" list aggregates unread activity and notifications across every workspace that isn't marked complete, so the digest is already waiting the next time you open the hub, not something you had to go find.
Setting this up yourself is the same primitive as any other agent in DF Code: assign a `scheduled` canned Agent to a workspace (the Agents view, or `update_workspace`'s `agents` array), give it an interval, and write it a prompt that calls its own `list_workspaces` and `get_thread` to decide what's actually worth mentioning before posting the digest with `send_thread_message`. No special "reporting" mechanism exists underneath it — it's the same agent shape you'd use for anything else, just pointed outward at everything instead of inward at one thread.
What it deliberately doesn't do is act on any of it. Like every other agent-authored thread in DF Code, the digest is something to read and decide on — not something that already happened on your behalf. It just means the reading part is waiting for you, instead of being ten tabs you have to open first.
Q: What's the difference between a Watcher agent and a scheduled status-digest agent in DF Code? A: A Watcher agent uses the `unread` trigger and reacts to new messages in one specific thread; a status-digest agent uses the `scheduled` trigger with no thread context at all, and instead polls across workspaces itself to decide what's worth reporting.
Q: Where do a scheduled agent's cross-workspace findings actually show up? A: They post as a new thread in whichever workspace it's assigned to — DF Code's own "Status Triage" Agent posts into the shared `Uncategorized` workspace, so the digest surfaces in that workspace's Threads tab and in the Status Report hub's "New Messages" list without cluttering any single project's own thread history.
Q: Do I need a separate tool to get a daily status summary across projects? A: No — it's the same canned Agent primitive used everywhere else in DF Code, just configured with a `scheduled` trigger and a prompt that calls its own `list_workspaces`/`get_thread` tools to build the digest, then posts it with `send_thread_message`.
Q: Does a status-digest agent take any action on your behalf? A: No — it only reports. Like any other agent-authored thread, review and follow-up action stays with the person reading the digest.