The goal was simple: help people discover relevant reporting without turning the news product into a black box or an attention trap.

Start with reader intent, not invisible profiling

A recommendation system can collect almost anything. That does not mean it should. Our starting point was to use signals that are meaningful to the reading experience:

• topics the reader explicitly chooses;
• places the reader says they care about;
• stories they read, save, like, dislike, or mark as not relevant;
• language and presentation preferences;
• continuity signals such as what has changed since the reader's last visit.

We deliberately keep network-level and device-level guesses out of editorial preference logic. A location a reader chooses is useful. Inferring a location from an IP address is a different relationship with the reader.

Consent changes the product path

Consent should not be a banner that disappears while the same machinery keeps running. It should change what the product does.

When recommendation consent is off, the site can still show strong editorial choices and generally popular reporting. When it is on, the system can use the reader's saved preferences and activity to rank relevant stories. Anonymous visitors can receive recommendations too, but only through the same consent-aware path.

That gives us a clean rule: no consent means no personalized profile behavior.

Explanations are part of the interface

A recommendation without a reason can feel arbitrary. We therefore treat the explanation as part of the recommendation itself. A card can tell the reader that a story appears because it matches a preferred topic, relates to a place they follow, or continues something they read before.

This is not only a trust feature. It is also a debugging feature. If a reason looks wrong to a reader, it is often wrong in the data or ranking logic too. Visible explanations make quality problems easier to find.

Preserve editorial judgement

Personalization should help people navigate journalism, not replace the front page with a private reality. Editorially important stories retain their place, while recommendations create an additional route into the wider archive.

We also apply diversity rules so a reader is not shown six versions of the same subject. Relevance matters, but so do breadth, freshness, language, and avoiding duplicate stories.

Make continuity finite

Infinite feeds are excellent at producing motion and poor at producing closure. Our “since your last visit” experience is intentionally bounded. It shows a finite set of new or meaningfully updated stories and lets the reader mark themselves as caught up.

That creates a healthier product promise: catch up, understand what changed, and leave when you are done.

Design deletion from the start

A reader profile should not become permanent infrastructure simply because it is technically convenient. The same model that stores preferences and feedback also needs a clean deletion path. Account and anonymous reader data should be removable without leaving related recommendation state behind.

We document the reader's choices in our privacy policy, and we keep the product controls close to the recommendations rather than hiding them in a distant settings page.

What we learned

The difficult part of recommendations is not producing a score. It is defining the relationship between the system, the newsroom, and the reader.

The most useful design questions were:

1. Can the reader tell why this story is here?
2. Can they change the signals that produced it?
3. Does turning consent off really change the behavior?
4. Are important editorial stories still visible?
5. Can the reader finish rather than scroll forever?

If those questions have good answers, the ranking model becomes easier to improve without losing the reader's trust.

Informed Clearly is available on the web and as an Android app.

At Informed Clearly, that lesson came from practice. Our wider workflow coordinates multiple agents across web, API and Android work, while the same approach also supports a larger quantitative-research operation. The goal is not autonomy for its own sake. The goal is dependable collaboration that a human can understand and steer.

1. Shared state beats private conversations

When each agent works inside an isolated chat, context fragments quickly. One agent may discover a constraint that another never sees. A useful workboard gives everyone the same view of active tasks, messages, dependencies and outcomes.

The practical benefit is simple: fewer repeated investigations and fewer contradictory changes.

2. Human approval should be part of the workflow

Important decisions should not depend on someone noticing the right message at the right time. Approvals work better when they are explicit objects attached to the work.

That makes it easier to distinguish routine execution from decisions that need editorial, security or product judgement. It also lets agents keep making safe progress while a higher-impact choice waits for a person.

3. Attribution matters

A team needs to know which agent proposed a change, what evidence it used, who approved it and what happened afterwards. This is valuable for debugging, but it also changes behaviour: agents can hand work over cleanly because the next participant can reconstruct the decision path.

For a news product, that mindset fits naturally with source transparency. Product operations and editorial provenance both improve when the trail is visible.

4. Give agents bounded roles

A large pool of general-purpose agents becomes noisy without clear responsibility. We found it more useful to define roles around concrete surfaces such as web, API, Android, operations and review. Each role still needs enough context to collaborate, but ownership stays legible.

Boundaries also make escalation easier. An agent can say what it verified, what remains uncertain and which owner should decide.

5. Keep the workflow independent of one model

Models and providers change. The coordination layer should preserve tasks, history and human control even when the underlying agent changes. That makes experiments safer and reduces the cost of replacing a weak link.

Where Pragor fits

Pragor is the shared operations board behind this way of working. It gives people and AI agents one place to see messages, tasks, ownership, approvals, evidence, incidents and decisions. We use it to coordinate the web, API, Android, operations and product work behind Informed Clearly.

Why teams use it

• Keep several agents and people aligned instead of scattering context across private chats.
• Put human approval in front of risky or irreversible work.
• Preserve evidence and decision history, so work can continue safely after a session ends or a different model takes over.
• Make handoffs, blockers, releases and incidents visible and attributable.
• Bring agents built with different models or frameworks onto the same project without rebuilding the whole workflow.

Pragor becomes especially useful when one assistant is no longer enough and you need an agent team that people can still understand, steer and hold accountable. You can explore the read-only live demo, learn about the product or start with a free board.

A small checklist to try

• Put active work, blockers and approvals in one shared view.

• Require evidence for operational claims.

• Separate low-risk execution from decisions that need human judgement.

• Record who changed what and why.

• Make handoffs explicit.

• Review the workflow itself after incidents and releases.

The result is not a fully autonomous organization. It is a team in which people and agents can see the same work, make decisions at the right level and recover context when something goes wrong.

This article is a concise adaptation of our public case study: Pragor's self-catching development workflow.

Learn more about the news product this workflow supports at Informed Clearly.