Scheduler Agent

⬜ Proposed — not built. Tier 1 — buildable now

What it would do

Decide when each approved piece goes out, and own the content calendar as the single route to publishing. Today scripts reach the calendar and stop; nothing decides a slot and nothing posts.

Why an agent — mostly it is not

Honest framing: this is a scheduler with a thin judgment layer on top. Most of the work is deterministic and should stay that way — the calendar write, recurrence, timezones, blackout dates and per-platform cadence are all rules, and in a regulated context they need to be auditable and reproducible.

The judgment is narrow: given a queue of approved pieces and a partly-full calendar, which piece goes in which slot. That is a ranking problem over theme spacing, format mix and freshness — the same shape as NBA, scaled down to a calendar.

Build the rules engine first. Add the ranker only when a human is visibly spending time on the ordering.

What already exists

Piece	State
`content_calendar_entries` collection, indexed by `tenantId + scheduledFor`	✅
Calendar page and API routes	✅
Daily Studio `schedule` action	✅
Anything that chooses a slot	⬜
Anything that publishes from the calendar	⬜

So this is the cheapest Tier 1 agent to reach — the store and the surface are already there.

Flow

approved pieces (scripts - blogs - creative)
        |
cadence rules per platform          <- deterministic
        |
conflict + blackout check           <- deterministic
        |
slot ranking                        <- the only judgment
        |
write content_calendar_entries
        |
[human] confirm
        |
publish                             <- still unbuilt, see gaps

Subagents

Slot picker — which day and time this piece should take, given what is already booked
Spacing guard — stops the same theme or format clustering across a week
Cadence keeper — holds each platform to its own posting frequency
Gap filler — flags empty slots that need commissioning rather than leaving silent holes

Deterministic, deliberately not subagents: the calendar write, recurrence and timezone handling, blackout dates, and conflict detection. These need to be auditable row by row — an LLM in this path adds cost and removes reproducibility.

What it needs first

Nothing new to schedule. Publishing is the gap — the calendar has no dispatcher behind it, so scheduling still ends in a human posting manually.

Approval gating already exists via content governance, and should stay in front of any auto-scheduling.

Roadmap source

Page 5 deliverable ③ (SM — E2E — A with WF) and page 4 ATL → Social. The whiteboard assumes scheduling; it never draws it, which is why this agent is an addition to the roster rather than an extraction from it.

Design notes and open questions

Never auto-publish without a human gate. Every other agent in this system stops short of the outward-facing action; scheduling should not be the exception.
Frequency capping must be shared with Program workflows — a customer-facing post and a lifecycle message both consume attention.
Best-time-to-post claims need evidence from the Learning Agent, not vendor folklore. Until that exists, use fixed cadence rules and say so.
Open: does the calendar own blogs as well as social, or only social? Today blogs go straight to CMS on a human click and never touch it.