It does the drafting. You do the deciding
Detection, the brief, the article and the proposed publish are the loop’s work. The publish is the step that stops: it lands in the queue with its destination, the query that prompted it and a link into the draft, and it sits there until you approve or reject it — with an optional reason recorded on a rejection.
Manual is the starting setting, not a fallback
A brand begins in Manual: nothing runs on its own and every step is one you start. Propose is the next rung — auto-drafts content, but you approve every publish. Autopilot is the third, and it is a choice you make rather than a level you drift into.
Autopilot, on rails you set
In Autopilot the publish no longer waits for a person, and three things still hold: a destination must be connected, the fact-check still applies, and every run is recorded. Switching back to Manual or Propose is one selection and applies on the next load.
Auto-publish has to be earned
For a key driving the loop, auto-publish unlocks only after its own record reaches 20 reviewed proposals with 95% approved. Below that line the key proposes. The number comes from the decisions you have already made, so it reflects experience rather than a setting someone typed.
Stale pages get refreshed, not replaced
A published page that stays uncited past its observation window is refreshed in place — the same URL, no duplicate article — and your live page only changes when the update is published. The refreshed draft is fact-checked again before it ships, and a page that is already cited, or still inside its window, is left alone.
Every action leaves a receipt
Each proposal, approval, rejection and refusal is recorded with the action, who or what requested it, the destination, the exact prompt that was sent, the credits it spent and what came back. Technical details stay collapsed on the card until you ask for them, and the same records are readable per key through the public API.
Decide from the inbox
The “your article is ready” email is no longer only a notification. It carries the draft, what the agent is unsure about, and an Approve and publish button. Approving runs the same account-scoped approval the queue uses — the same row, the same audit entry — so the only thing that changed is that you did not have to open the app to make the call.
Reply to ask for a change
The Reply-To on the email carries that thread, so replying “make the headline more bold” is the whole instruction. The agent applies it to that draft and emails back the revised article with a fresh Approve and publish button, so the loop can continue from the inbox. The reply is handed to the revision engine for that one article; it is never interpreted as a command that could choose a destination, approve itself or change a limit.
The flags arrive before the button
Above the button the email lists what the agent is unsure about, most serious first: claims it could not back up with your sources (quoted back to you), drafts written without your documents, unfinished placeholder text, claims it is only partly sure of, an article that has not been fact-checked yet, a short article, a draft without structured data. When there is nothing to raise it stays silent rather than promising the draft is clean.
Approve from your phone without signing in
The button opens a confirmation page — the publish happens on the confirm, with the destination and the flags shown again, so a preview or a forwarded link cannot publish anything. Each link is single-use, expires, is bound to one account and one draft, and is revoked when the draft moves on.
A reply can be a decision, not only a request
“publish” or “approved” in a reply takes the same path as the button, and “reject” or “no” declines the proposal and records it. “stop” switches the email channel off and confirms once; only you can turn it back on. Revisions are capped per day and per thread, so a long thread cannot run up a bill on its own.