My Digital Newsroom: How 13 AI Staff Run BlogVoyager Together

19/07/2026 · 3 min read · 🌐 Automatically translated

Behind BlogVoyager runs a specialised digital newsroom: from news scouting through research, editorial review and fact-checking to image design and LinkedIn preparation. I show which tasks my AI staff take on, how they collaborate, and why the final decision still rests with me.

A newsroom of specialised AI staff

BlogVoyager appears outwardly like a personal specialist blog. Behind the scenes, however, a larger digital newsroom is at work. Its staff are not humans, but specialised AI agents and automated verification steps.

Each digital staff member has a clearly defined task. One looks for interesting topics, another assesses their relevance, others handle research, writing, fact-checking, technical examples, images, translation and LinkedIn.

I myself take on the role of publisher and editor-in-chief. The digital newsroom prepares articles, reviews them, and suggests improvements. Publication only happens after I have checked and approved the article.

My digital staff

Nika – News Scout

Nika monitors the news sources and feeds configured for BlogVoyager. Her focus is on Microsoft Azure, Azure AI Foundry, Azure AI Services, Microsoft Entra, Microsoft 365 Copilot and GitHub Copilot.

She collects new items and uses technical characteristics to detect which entries have been added since the last run. At this stage she does not decide whether an article will actually be created. Her task is first to reliably pass on relevant candidates to the next stage.

Theo – Topic Analyst

Theo evaluates each new candidate based on four criteria:

• subject alignment with BlogVoyager’s themes
• newsworthiness
• relevance for IT decision-makers and cloud architects
• concreteness and practical feasibility

These criteria produce a relevance score. Items without a direct connection to Azure, Microsoft AI, Entra or Copilot are filtered out. General marketing texts without technical substance should not enter the newsroom either.

Theo also proposes suitable tags. He uses the blog’s predefined taxonomy so that similar posts are categorised consistently.

Dana – Research Coordinator

Dana prevents multiple media reports about the same event from resulting in several near-identical articles.

To do this, a candidate’s title and short description are converted into a mathematical representation, an embedding. Dana compares this embedding with already processed items and with other candidates from the same scan.

If two items are semantically very similar, only one of them is processed further. Additional finds can be retained as related sources. This turns multiple reports about the same topic into a single consolidated research process.

Rhea – Source Researcher

Rhea looks for additional sources before an article is written or re-checked.

For Microsoft topics she favours official product pages, Microsoft Learn, Azure architectural documentation, pricing overviews, and Azure Command-Line Interface (Azure CLI) references. Research is not limited to Microsoft, though. If a topic involves other providers, standards, studies or independent analyses, she may also consider suitable external sources.

Rhea does not just work with search results. Found pages are refetched and their usable content extracted. Unreachable pages, redirects, unsuitable content, and pages with too little analysable text are documented or discarded.

Armin – Subject Matter Author

Armin creates an independent German technical article from the initial topic and the research context.

He should not merely rephrase a news item. His task is to contextualise the topic and prepare it for BlogVoyager’s target audience. This includes technical relationships, impacts on architecture and operations, potential risks, and concrete courses of action.

Sources and internal review notes do not belong as distracting wording in the running text. Instead, factual claims and their sources are stored in a separate facts block.

Armin also creates the title, teaser, outline, tags, and an estimated reading time.

Quinn – Quality Editor

Quinn reads the complete draft with distance from the author.

He checks, among other things:

• Is the article structured in a technically understandable way?
• Does it contain enough concrete information?
• Are abbreviations spelled out and explained on first use?
• Are product names and technical terms correct?
• Does the text fit the target audience?
• Does the article merely repeat a source or does it provide its own perspective?
• Are the tags complete and meaningful?
• Do code examples and technical instructions match the provided context?

Quinn may revise the draft. His changes and notes are recorded in the revision notes.

Vera – Fact Checker

Vera breaks the article down into verifiable factual claims. Opinions and personal recommendations are not treated like facts.

She distinguishes between different types of statements:

• quantitative statements such as prices, dates, percentages or versions
• causal statements about cause and effect
• comparisons between products or approaches
• categorical statements about functions and properties
• procedural statements such as configuration steps

For each claim, Vera looks for suitable evidence in the provided source context. The result is either substantiated, unsubstantiated, or contradicted by a source.

A statement is not considered substantiated merely because the source and the article mention the same product. For a comparison, for example, both compared sides must be evident from the evidence. For numbers, dates and versions, the specific value must appear in the source.

Gabriel – Grounding Analyst

Gabriel calculates the article’s Groundedness and Coverage from Vera’s results.

Groundedness describes how reliably the checked statements align with the sources. Coverage shows what proportion of the identified factual claims could be substantiated at all.

The calculation takes place in the backend. The value proposed by an AI model is not adopted unchecked.

If a source contradicts a statement, publication is blocked. The same applies to unsubstantiated concrete numbers, prices, dates, or versions. If the fact-check for a technical article finds no verifiable statements at all, the system does not automatically treat this as a success. Product terms, code, numbers and also the length of the article serve as signals that the check may have been incomplete.

Kai – Technical Reviewer

Kai is responsible for code blocks and technical commands.

He checks, for example:

• Azure CLI commands
• parameters used
• obvious syntax errors
• undocumented options
• deprecated or possibly preview-only features
• implausible Software Development Kit signatures

A technical blocker requires evidence from the provided documentation context. If the reviewer cannot substantiate his objection, it is not automatically treated as a hard publication block.

If the technical review itself fails, this is visibly indicated. A review failure must not silently appear as a successful check.

Riva – Revision Editor

If Vera, Gabriel or Kai find issues, Riva receives the draft.

She first attempts to rephrase the affected statement correctly and precisely based on the existing sources. If no substantiable formulation is possible, she removes the statement. The article is then rechecked.

This cycle of revision and renewed verification is limited. This prevents an article from being bounced endlessly between review steps.

Mira – Picture Editor

Mira takes care of the title image.

She can generate a new image with artificial intelligence or look for an image that can be used. When searching for images, only sources and providers with machine-readable licence information are considered. Origin, licence and decision are documented.

Alternatively, I can upload an image myself. The image selection, alternative text and origin remain in the article’s editorial dataset.

Ella – Translation Editor

After approval, Ella creates the English version.

She does not just translate individual words, but should preserve structure, meaning, technical terms, code and links correctly. Product names, commands and technical identifiers must not be inadvertently altered.

This is how the German and English publications emerge from a checked German post.

Linus – LinkedIn Editor

Linus creates a LinkedIn post from a published article.

He does not simply summarise the teaser. The post should start with an engaging hook, present the key insights in readable paragraphs, and lead readers to the full article.

Text, hashtags and image can be manually reviewed and edited again before publication.

How the newsroom collaborates

Collaboration follows a fixed handover chain:

1. Nika collects new topics from the configured sources.
2. Dana removes known and semantically similar items.
3. Theo evaluates topical fit, newsworthiness, customer relevance and concreteness.
4. Rhea adds current and preferably robust sources.
5. Armin creates the first complete draft.
6. Quinn performs the editorial quality review.
7. Vera checks the factual claims.
8. Gabriel calculates Groundedness and Coverage.
9. Kai checks included code blocks and technical commands.
10. Riva revises unsubstantiated, contradictory or imprecise passages.
11. Mira prepares the title image.
12. Ella creates the English version.
13. Linus prepares the LinkedIn post.
14. I review the article, sources, preview and image, and decide on publication.

Not every article requires every step to the same extent. A post without code, for example, does not need a code review. However, fact-checking, quality review and my final approval remain central elements of the process.

Technical foundation: Azure AI Foundry and the models used

My digital staff do not run as standalone virtual machines. Technically, they are specialised work steps within a shared editorial pipeline. The AI-supported roles each receive a system prompt tailored to their task, a defined input context, and a fixed output format. Other roles, such as duplicate checking and score calculation, are implemented by deterministic functions in the backend.

The required AI models are provided via Azure AI Foundry.

GPT-5 for complex editorial tasks

The primary model GPT-5 handles tasks where text quality, contextual understanding and extensive revisions are especially important. These include:

• writing complete technical articles
• editorial quality review
• revising problematic passages
• translation into English
• creating LinkedIn posts
• repairing unsubstantiated or contradictory statements

Depending on the task, creativity is controlled via different temperature settings. Facts-focused revisions run with a very low temperature. Editorial texts and LinkedIn posts may be phrased somewhat more variably.

GPT-5 Mini for analysis and verification

GPT-5 Mini is used for more structured and repeatable tasks:

• evaluating new topic candidates
• extracting and classifying factual claims
• independent fact-checking
• checking technical code examples
• developing and reviewing image concepts
• assessing image sources and licences

Fact and code checks are executed with a temperature of 0 to reduce creative deviations. Since even an AI configured this way does not automatically work flawlessly, BlogVoyager does not rely on a single review run: source research, fact-checking, code review, groundedness and coverage assessment, and targeted revision interlock as a multi-stage control system. Finally, I personally review and approve the post.

Responses are requested as structured JSON data. The server validates these results and calculates security-relevant values such as Groundedness and Coverage itself. An overall value proposed by the model is not adopted unchecked.

Text Embedding 3 Large for duplicate checking

The model text-embedding-3-large generates embeddings from titles and short descriptions.

An embedding maps the semantic meaning of a text as a numerical vector. This allows Dana to recognise that two differently worded news items cover the same event.

Similarity is calculated mathematically using cosine similarity. If it exceeds the configured threshold, the item is treated as a semantic duplicate.

GPT Image 1 Mini for title images

For artificially generated title images, Mira uses gpt-image-1-mini.

Before the actual image creation, a language model first produces a structured image concept. This then becomes the prompt for the image model. Style, subject, image format and alternative text are stored together with the draft.

AI-generated images can remain recognisable as AI content through technical provenance markers from the model provider. This marking is not removed.

Technical configuration and access protection

The models are set up as separate deployments in an Azure AI Foundry account:

• gpt-5 as the primary model
• gpt-5-mini as the analysis and review model
• gpt-image-1-mini as the image model
• text-embedding-3-large as the embedding model

The model versions used are fixed in the infrastructure configuration. A version change only occurs when the current model version expires. This is intended to prevent the newsroom’s behaviour from changing uncontrollably due to an automatic model switch.

The editorial pipeline runs in an Azure Function App. It authenticates to Azure AI Foundry via a system-assigned Managed Identity. Local key-based authentication is disabled for the Foundry account. Therefore, no API keys for model access need to be stored in the application code.

Each AI-supported work step only receives the information it needs for its task. The fact-check, for example, receives the article and the newly fetched source context. The technical review additionally receives the detected code blocks and appropriate documentation pages.

The staff described are therefore not free-roaming universal agents. They are understandable names for specialised AI calls and controlled backend processes within a defined workflow. Status, results, token consumption, review warnings and revision notes are centrally stored and consolidated in the editorial dashboard.