Letting an agent schedule a post instead of publishing it
A future published_at schedules a post with no scheduler job behind it: every public surface filters on publishedAt <= now, so nothing has to run overnight for the post to appear.
Give a publish call a published_at that has not arrived yet and the post is scheduled rather than published: its status in the database becomes PUBLISHED, and every public surface hides it until that instant passes. There is no queue, no cron entry and no job that can fail overnight. The blog index, the single-post page, the sitemap and the llms.txt file all read the same condition — the post's published date is less than or equal to now — so a post dated next Tuesday simply starts existing on Tuesday.
A future published_at changes one field and nothing else. Market4's blog service selects live posts with a filter on status PUBLISHED and publishedAt less than or equal to the current time, and that same filter is repeated in five files: the blog service that renders the index and the single post, the sitemap builder, the llms.txt generator, the internal-link audit and the page preflight check. A scheduled post fails the date half of that test everywhere at once, which is why it is invisible on the blog, absent from the sitemap, and not offered as a link target to other posts.
Scheduling implemented as a query filter has one property a scheduler process does not: there is nothing to go down. A conventional design stores the post as a draft, records a wake-up time, and relies on a worker to flip a flag at that time. Every part of that can fail — the worker crashes, the queue loses the job, the clock drifts — and the failure is silent until somebody notices the post never went out. Reading publishedAt at request time moves the decision to the moment of the request, so a post that nobody has requested is the remaining way for one to look missing.
The trade is that the date is authoritative and immediate. Changing published_at to a time in the past makes the post live on the next request, with no rebuild and no cache to clear. Changing it to a time in the future takes a live post back off the blog, which is worth knowing before an agent edits that field to tidy up a timeline.
A scheduled post is not a draft, and two systems treat it as fully published from the moment the publish call succeeds. The originality index fingerprints every post whose status is PUBLISHED, with no date condition at all, so a post scheduled for next month is already in the corpus that later drafts are measured against. Editing the body of a scheduled post also clears the same content guardrails a live edit does, because the service branches on status rather than on visibility.
Publishing a post sends two independent announcements. One IndexNow request reaches Bing, Yandex, Seznam, Naver and Yep. Google takes no part in IndexNow, so it is told by re-submitting the sitemap.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
| Behaviour | Draft | Scheduled | Live |
|---|---|---|---|
| Appears on the blog index | No | No | Yes |
| Listed in the generated sitemap | No | No | Yes |
| Counted by the originality check | No | Yes | Yes |
| Body edits clear the publish guardrails | No | Yes | Yes |
An agent writing several posts in one session has a good reason to schedule rather than publish: ten posts landing in the same minute is a pattern a reader can see, and the app's own publishing rate policy is entitled to refuse it. Spreading the same ten posts across a day or a week costs one field per call. The rules worth following are short.
The same reasoning applies to who presses the button. Scheduling is the version of publishing that leaves a review window: the post exists, the address is fixed, and a human has until the scheduled instant to read it. That window is an inexpensive place to catch a wrong claim, and it costs nothing to leave open.
No. The sitemap builder applies the same publishedAt <= now filter as the blog index, so a scheduled post is left out until its instant arrives. This is deliberate: announcing a URL that answers 404 teaches a crawler that the sitemap is unreliable. After the date passes, the next sitemap generation includes it with no further action.
The post goes live immediately, because the filter is a comparison against the current time rather than a record of an event. Backdating is therefore a publish, not a schedule. It also sets the date shown on the post and used for sitemap lastmod, so backdating to make an archive look older changes what crawlers are told about freshness.
No. The blog service decides which guardrails apply by looking at the post's status, and a scheduled post's status is already PUBLISHED. A body edit therefore runs the banned-word lint and the originality check exactly as an edit to a live post would. If a draft edit is what you want, do it before the publish call rather than after.
Not through the public surfaces. The blog index, the single-post lookup, the sitemap and llms.txt all filter it out. It is visible to anyone with access to the app's own dashboard or MCP tools, because those read the post record directly rather than through the public path. Treat it as internal but final, not as a secret.
The server is the same in both. What differs is which layers the client implements: how it connects, how it discovers the authorisation server, which of the three capabilities it lists, and whether it reads the hints on each tool.
Both can hand a model a block of JSON, so the choice looks cosmetic. It is not. A tool call is a decision the model makes with arguments it invents; a resource read is a fetch the client performs against an address it already holds.