RankMill runs a blog on your behalf, but it does not do it in one big move. The work is split across four agents, each with a job it does well, and a human who owns the calls that matter. This post walks through the loop, who does what, and why splitting it beats a single giant prompt.
The four jobs, in one paragraph
The research agent reads your site and builds the website profile, then hunts for topics you could write about. The writer agent takes an approved topic and produces the full post in markdown. The editor agent rewrites parts of a finished post when you ask it to, and returns each change as a diff. The human, that is you, sits at the two moments where a choice really matters: approving a topic before the writer starts, and approving a post before it goes out.
The research agent: reading and suggesting
The research agent has two shifts.
The first is on day one of a project. You point RankMill at a website, and the research agent reads it and writes a website profile, a markdown document that says what the business sells, who it sells to, and how it sounds. Every agent that runs afterwards reads the profile, so getting this right at the start matters. You can edit the profile yourself, or ask for an AI edit and read it as a diff before you apply it.
The second shift is topic hunting. A topic hunt reads the profile and comes back with five suggested topics, each with a title and an outline. Some topics arrive with up to four questions, the facts the agent could not find on its own: a price, a customer name, a supported integration. Those questions are for you.
What the research agent owns:
- Turning your URL into a website profile
- Finding topics you could write about
- Writing the outline for each topic
- Deciding which facts it needs a person to fill in
What it does not own:
- Whether a topic is worth writing
- Whether the profile matches how you actually sound
- What voice the writer will use
The human, part one: answering and approving
Between research and writing, control is yours.
You read the suggested topic. You answer the questions if there are any, in plain text, and your answers travel with the topic as facts stated by the business. Then you approve the topic, which is the signal for the writer to start. You can also skip the questions: the writer will write around a missing fact instead of guessing it, so an unanswered question is a fact the post will not lean on.
If you would rather the writing started on its own, a team setting approves every new suggestion automatically. There is a spending floor so automatic writing stops while you still have runs left for the work you ask for by hand.
What you own at this stage:
- Whether a topic gets written at all
- The answers to any questions the research agent asked
- Any per-post writing rules you want on top of the project's own
The writer agent: turning a topic into a post
Once a topic is approved, the writer agent runs. It reads:
- The topic and its outline
- Your answers to the questions
- The website profile
- The project's writing rules
Out comes one complete post in markdown, from its heading to its closing paragraph. The writer never invents a number, a customer name or a feature. If a fact would have been useful and it is not in the material, the sentence that needed it is dropped or rewritten. This is the rule that keeps the loop honest.
What the writer owns:
- Structure and headings
- Word choice and voice, inside the rules you set
- Which examples to use, from the material it has
- Following the writing rules exactly
What it does not own:
- The subject of the post (that came from research, or from you)
- The facts (those come from the profile and your answers)
- Whether the post is ready to publish
There is a second way in for the writer, write from an idea, where you give a title and a short brief and the writer starts immediately, with no separate topic step. And a third, import a post, where an existing post is either stored as is, restructured into clean markdown, or rewritten in your voice. Whatever route a post came in by, it behaves the same from then on.
The editor agent: shaping the draft
A finished post is a draft, not a final. This is where the editor agent takes over.
You open the post and chat with the editor. You ask it to shorten a section, sharpen an argument, drop a heading, or add a paragraph about a related topic. Each request comes back as a diff on the post: the change, in place, with what was there before. You accept it or you throw it away. The conversation carries context, so make that shorter on the third message still knows what that was.
You can also edit the post by hand, in a block editor that reads and writes markdown, so a one-word fix does not need an agent at all.
What the editor owns:
- Applying the changes you asked for
- Doing so as a diff you can read before you accept it
- Keeping the writing rules intact through the edit
What it does not own:
- Deciding what to change
- Publishing the change
- Overwriting your work in one step without showing you first
There is also an auditor that reads every finished post in the project at once and writes down up to five things that are wrong: two posts that contradict each other, one that has drifted from the profile, a claim that no longer holds. Each finding becomes a task the editor picks up when you tell it to. Think of the auditor as the editor's brief across the whole project rather than a fifth role.
The human, part two: publishing
The second place you sit in the loop is at the door. A post is not published until you say so, or until it hits a scheduled time you set, or until the project's automatic publishing takes it out. Every route goes through your call at some point.
If a post has already gone out and you edit it, the app tells you the published copy is stale. You can push the change as a follow-up commit while the pull request is still open, or as a new Update post pull request once it has merged. Nothing updates on its own.
What you own at this stage:
- When, and whether, a post goes out
- Which repository it goes to
- Whether an update to a published post is pushed as well
What moves between stages
The handoffs matter as much as the roles. Between each stage sits an artifact you can read.
- Research to human. The website profile, plus a topic with an outline and questions.
- Human to writer. The topic, your answers, and the project's writing rules.
- Writer to human. One complete post, in markdown.
- Human to editor. The post, plus an instruction in plain English.
- Editor to human. A diff.
- Human to publish. The finished post, with any frontmatter your project asks for, going out as a pull request to your repository.
Every artifact is markdown or something close to it. You can copy it out, paste it in, read it in the app, or take it to the shell. Nothing important lives only in a chat window.
Why splitting beats one big prompt
You could imagine skipping the loop and giving one model everything at once: the URL, the rules, the goal, and asking it to hand back a finished post. It would work some of the time. But you would lose four things that make the loop useful.
Checkpoints. With four agents, there are two natural places to say no: before the writer starts, and before the post goes out. A single call has no gaps to slip a decision into.
Small artifacts to read. A profile is easier to check than a post. An outline is easier to check than the full post. A diff is easier to check than a rewrite. Each handoff is a thing you can read in a minute.
Narrow prompts. Each agent has one job and the rules that go with that job. That means fewer places for a rule to be forgotten, and fewer competing pressures inside a single call.
Errors do not compound. If the writer picks a bad opening, the editor can fix it without redoing the research. If the profile drifts, you can rebuild it without touching the posts you already have.
The loop is not there to make the work slower. It is there to keep the moments that matter in your hands, and to leave the rest to agents that are good at their bit. That is the whole idea: a supervised pipeline, artifacts you can read, and a human at the two gates.