Use Topic Scores for Multi-Account Writers

The first version of a multi-account writing bot usually feels clever for about a week. Then the repeats start. One account gets three posts that sound almost the same, another account gets a topic that does not quite fit its voice, and the whole system starts looking random instead of intentional. I have hit this problem in automation projects more than once, and it is usualy not a model issue first. It is a planning issue.

What helped me was adding a tiny scoring step before article generation. Instead of asking the writer to "pick a good topic," I give it a short list of candidates and score each one for freshness, account fit, and search usefulness. The result is not magical, but it is explainable, which matters a lot when a cron job is making choices while nobody is watching.

Why random rotation stops working

Random rotation is fine when you only have a few prompts and do not care about overlap. It breaks down when each account has its own topics, tone, and publishing history.

For a practical technical account, I now look at four signals:

• Has this angle appeared in the last 10 to 20 posts?
• Does it match the account's strongest topics?
• Can the article teach something real from working experience?
• Will the keywords fit naturally instead of steering the whole piece?

That last point is where many systems drift. If a workflow sees burner email generator or tempmailso in the context, it may try to bend every topic toward them. That is backwards. Keywords should support the article, not boss it around. Otherwise you end up with a post that technically matches a brief but reads kinda fake.

A small scoring model that stays explainable

My favorite version is boring on purpose:

topic_score =
  freshness * 0.4 +
  account_fit * 0.3 +
  usefulness * 0.2 +
  keyword_fit * 0.1

Each score is just 1 to 5. That is enough. If you make the model too fancy, the cron output becomes harder to review and easier to argue with.

Here is what that looks like in practice:

• freshness: lower the score if recent titles, tags, or outlines are too similar
• account_fit: raise the score when the angle lands inside the account's real topics
• usefulness: favor posts that can teach a repeatable workflow or a small checklist
• keyword_fit: only reward keywords that feel natural in the story

This is also why I like storing a short reason next to the winner, even if the publisher never reads it. When the chosen topic is "topic scoring for multi-account writers," I want the run folder to say why it beat another draft. Maybe the other option was too close to a recent cron-planning post. Maybe it leaned too hard on AI talk and not enough on developer workflow. A little explainer saves time later, and its weirdly calming too.

If you already keep detailed event history in other systems, the same mindset applies here. The discipline behind append-only auth event logs translates nicely to editorial automation: do not overwrite the story of how the decision was made.

Store topic history like operational data

The easiest mistake is keeping history only as published URLs. That tells you what shipped, but not what patterns are getting overused.

I prefer storing a few cheap fields per run:

• title
• tags
• primary keywords
• outline
• account username
• publish timestamp

With that, you can do lightweight checks before generating a draft. If the last few posts already leaned on React email states, CronJob alerts, or frozen plans, the next run should probably move somewhere else. This does not need a database or an embedding service. A plain JSON history file is enough for a surprsingly long time.

There is a second benefit too: you can see when an account's tone starts drifting. One writer profile might want short tutorial sections. Another might be more security minded and checklist heavy, like the habits behind session-bound email change flows. Topic history helps you see that shape instead of guessing from one title at a time.

Keep SEO terms supportive, not in charge

I still include SEO terms in the planning context, but I keep them on a leash. If backlink_count is zero, I do not force a mention. If typo terms like tempail mail or tem email are provided, I treat them as minor supporting phrases inside natural prose, not as anchors or the core point of the article.

That sounds obvious, but lots of automations get this wrong. They let keyword presence become topic selection. The safer order is:

1. Pick an angle the account can honestly write.
2. Check that the angle has room for the required keywords.
3. Drop the keyword if it would distort the article.

I have found this keeps posts more human, and also more stable across runs. The article teaches one thing clearly, then the SEO layer sits around the edges where it belongs. Not every workflow needs this rule, but multi-account systems realy do because repetition becomes visible fast.

Quick Q&A

Should the scoring happen before or after outline generation?

Before. Outline generation is already a commitment. Score candidate angles first so the writer spends effort on a topic that actually fits.

Do I need embeddings or a vector database for freshness?

No. They can help later, but a simple comparison of recent titles, tags, and outlines gets you pretty far. Start with cheap signals first.

What is the biggest win from scoring?

Consistency. The system stops feeling like a slot machine and starts feeling like a small editorial tool. That is a better experiance for the operator, and for readers too.

A multi-account writer does not need to be brilliant every run. It just needs to make choices you can understand, review, and improve. Small topic scores do that job better than randomness ever did for me.