Newsroom UX Review — newsroom.sgit.ai

Oct 11, 2026 · @Agent

Executive summary

The content and the production workflow are strong; the reader's path into them is not yet built. The site is technically clean (921 URLs crawled, no broken internal links, no script errors on the 10 articles tested), but it is organised around how the newsroom works rather than around what a visitor came to read.

A contact who clicks a link today lands on a 49,715-pixel phone homepage (about 59 screens, 845 links), an unexplained £5.00 balance chip, the version number three times, and 67 articles of roughly 4,500 words each, filed under six topics where one topic holds 35 of them. Tags are not clickable, filters are not linkable, persona links are designed but not live, and the ratings a reader gives never reach you unless they choose to send them.

Five things to fix this week, in order:

1. One source of truth for articles. sgit.ai is serving five 11 October articles that 404 on the newsroom, and both domains declare themselves canonical for the same pages.
2. A front page for a stranger. A one-line "what this is and who it is for", three entry doors (security leaders, builders, news people), and the long lists moved off the home page.
3. Label the money. The chip should read "£5 free reading credit", the first penny charged should be announced, and the ratings should start unselected.
4. Make feedback reach you. Send an anonymous one-tap rating (or a "tell Dinis" button) by default with clear consent, instead of keeping it in the browser.
5. Ship persona links (/for/ciso and two or three others) so every contact you send arrives somewhere made for them.

Context

The newsroom is the public argument for two products, and the review judges it on whether a stranger can follow that argument. Three sites carry it:

The site's stated promise is "one page, one argument, with the figures, the data and the links to check it". Its design pillars, described in its own articles, are: the story as a graph, corrections that propagate, provenance as the product, and paying for reading after you read. The llms.txt is unusually honest about what runs and what is only designed, which is a real asset.

The audience you named is your contacts and first subscribers: CISOs, security and AI-governance people, builders, investors and media people. They arrive from a link, mostly on a phone, with one question and a few minutes.

Method and review panel

Every finding below comes from the live site on 11 October 2026, measured rather than recalled. I crawled newsroom.sgit.ai (921 URLs, 409 HTML pages), drove a real Chromium browser at phone (390×844) and desktop (1366×900) sizes, rendered ten articles to check images and script errors, and read the pages that explain the positioning, the meter, personas and the synthetic-user study.

The review panel was run as six distinct perspectives within this session, not as separately spawned agents; this chat cannot start sub-agents. Each role read the same evidence with its own question:

Worth running next: the same panel as real agents in your Claude Code setup, plus a fourth synthetic-user run against v0.6.4 so the before and after can be compared.

Bugs and broken things

The site has few hard bugs; the serious ones are consistency bugs between sites and labels, which erode trust faster than a broken link.

Checked and fine: 0 broken internal links across 921 URLs, 0 broken images and 0 page errors on 10 rendered articles, robots.txt and sitemap.xml present, per-article canonical and Open Graph images set.

First visit: a contact arriving from a link

On a phone, the first screen tells a stranger how the site is built, not what it is about or why they should care. Here is what a CISO you messaged sees at 390×844:

[image: First phone screen of newsroom.sgit.ai, 11 October 2026]

1. A header that takes two rows. The brand, an unlabelled £5.00 chip, Menu, then a GitHub button wrapped onto its own line.
2. A "For agents /llms.txt" strip above the masthead: useful to agents, noise to a person.
3. Three lines of metadata (edition date, counts, version) before the title.
4. A tagline about method ("one page, one argument") with no subject: nothing says agents, AI governance, security or news economics.
5. A second navigation bar of nine links, repeating the menu.
6. The editor's note, written for someone who read the last two editions ("Third edition... the last two days").

The lead story appears on the second screen. Below it the page keeps going for about 59 screens: Latest, Highlights, desk notes, collections, the full 67-article list, then a "How they connect" map of every article's links. The menu holds about 60 links in nine groups, mixing reader pages (Newsletter, Collections) with builder pages (Replicate, Admin, Release history, The run log).

Opening any article charges a penny straight away, so the chip changes to £4.99 with no message. The synthetic-user study found this exact moment made a retired reader ask whether she owed money; it is still unexplained.

What the first screen should hold instead: one sentence on what this is ("Field reports on AI agents, their rules and their risks, with the evidence attached"), who writes it (Dinis Cruz, with an agent newsroom, said in the byline area rather than the footer), three doors ("I run security", "I build agents", "I work in news"), and the lead story. Everything else moves below or into the menu.

Findability and information architecture

The newsroom has 67 articles and about 300,000 words, but only one way in: a reverse-chronological list. Everything else that would help a reader find their subject exists in data but not as a page they can land on.

What exists today. Six topics as filter chips on the article list, five collections curated by the Historian, four desk notes, "builds on / continued by" links on every article, a per-article graph, and a search box that matches titles, teasers and tags.

Where it breaks.

• Topics are too broad to choose from. "Agents & policy" holds 35 of 67 articles; a CISO picking it still faces 35 long reads. The other five topics hold 13 to 26 each and overlap heavily (an article sits in about two).
• Tags are dead ends. The lead article carries 12 tags (agents, harness, tokens, simulation...), none of them links, and there are no tag pages. They also mix subject, format and product names ("article", "riskmandate").
• Filters cannot be shared. Choosing a topic does not change the address, so you cannot send a contact "the security articles".
• Series are invisible. Several articles are clearly parts of one story (the reading meter in five pieces; the homepage diagnosis and its rebuild; the agent team in three depths) but nothing says "part 2 of 5" or offers the next part.
• No start-here path. The Historian's weekly note and the collections are the best orientation on the site, and they sit below the fold.
• Length is not signalled. The median article is about 4,500 words (25 of 66 are over 5,000), yet cards show no reading time and no format (field report, explainer, analysis, desk note).

Proposed structure. Three layers, each a real page with its own address:

Each desk page should open with "Start here: five articles in order", written by the Historian, then the series in that desk, then everything else newest first. The Librarian should own the tag vocabulary: merge near-duplicates, drop format words, and reject new tags at build time unless they are on the list.

Also add: reading time and a format label on every card; search over article bodies and abstracts (the markdown copies already exist); linkable filters (/articles/?desk=security); and a monthly archive page.

Article page and feedback

The article page has the site's best reader feature, the Five readers block, but puts it behind a wall of metadata and a 250-word italic abstract. On the lead article (about 8,000 words) a phone reader scrolls past a three-line breadcrumb, the byline with two version numbers, 12 tag pills and the abstract before reaching it.

Reorder the top of every article:

1. Title and a one-line standfirst.
2. Byline that says how it was made ("Dinis Cruz, written with the SGit agent newsroom"), the date and reading time. Version numbers move to the foot.
3. The short version: the Explainer's two-minute summary, as three or four plain sentences.
4. Links to the other reader views (the arc, the deck, the map) as one compact row.
5. The article. Tags go to the foot, as links, capped at five.

The abstract can stay, but in roman type and collapsed after the first two sentences; long italic text is hard to read on a phone.

The feedback block works as a design and fails as a channel. Three five-point scales sit at the foot of every article:

[image: The meter and rating block at the foot of an article]

The "Don't charge me" link is a good idea and should stay. After the scales, the end of the article should offer one next step, not seven: the next part of the series, or the next "start here" article for the reader's desk, then the newsletter.

Synthetic users: what is fixed and what is open

Of the study's findings I could re-check against v0.6.4, two are fixed and eight are still open. The third run (10 October, against v0.6.1) sent five invented readers through the site: four of five left, the average rating was 2.4 out of 5, and 31 findings were logged, six of them blocking.

Not re-checked: the developer-only install steps, the missing plain-language paragraph for writers' readers, and where "How the meter works" leads.

The study's five personas are a good fit for your real audience, with one gap: none of them is a CISO or a security buyer, who are most of the people you will send links to. Add that persona, run a fourth study against the next release, and publish the before-and-after scores side by side, as the homepage rebuild articles did.

Benchmarks from other news sites

Established news sites solve the same two problems this one has: separating fact from view, and turning an archive into places a reader can arrive. Five patterns transfer directly.

Where this site is already ahead of most newsrooms: published method, version history per article, public corrections, evidence in openable vaults, and an honest list of what runs versus what is designed. The job is to put those strengths one tap away instead of on separate pages.

Panel perspectives

All six roles reached the same conclusion from different directions: the newsroom has outgrown a single front page and needs desks, an owner for each, and a feedback loop that reaches the editor.

The one disagreement worth noting: the Architect wants the "For agents" strip kept on every page, and the Designer wants it off the first screen. Both are satisfied by moving it into the footer and the page head (as a link rel), where agents look anyway.

Publishing pipeline

The writing pipeline is mature; the release pipeline needs checks that catch reader-facing problems before readers do. Every bug in this review would have been caught by an automated check at build time.

One path from voice note to reader:

1. Draft in the newsroom vault, as now.
2. Classify: the Librarian assigns one desk, a format, up to five tags from the controlled list, and any series with its position.
3. Reader views: the five readers run, and the Explainer's two-minute summary becomes the article's "short version".
4. Manifest: one file lists every article with its fields. Counts, desk pages, tag pages, feed, llms.txt, sitemap and the sgit.ai teaser block are all generated from it.
5. Build checks (fail the release if any fail): broken internal links and images; one canonical per article; counts match the manifest; tags on the list; edition date equals the newest article; no author-only blocks in reader pages.
6. Stranger test: a short synthetic-user run on the front page and the newest article at phone size, scored against the last run (baseline 2.4 out of 5).
7. Publish to newsroom.sgit.ai only; sgit.ai picks up the feed.
8. Learn: a weekly digest of ratings and free-text replies goes to the Editor, who adjusts the front page and the next week's pitches.

Release notes for two audiences. The release history is engineering-facing. Readers need a short "What's new on the site" line in the newsletter instead, and the version badges can leave the reader pages.

Scaling the desk. As output grows past a few articles a day, give each desk a standing editor role (an agent with a policy) that owns its start-here list and its weekly round-up. The Historian then works across desks, which is what it does best already.

Since v0.6.4: what v0.7.1 changed

v0.7.1 closed the biggest content bug and shipped persona links; the first screen is unchanged. Checked on 11 October against the live site.

The direction: a publication with a heart

Treat the newsroom as a publication first and a demo second: it should read as professionally as any major news site, with a clear subject, a named author and a stated purpose. Today the masthead describes a method ("one page, one argument") and the menu is half about how the site is built.

Name the heart. The content already has one: practical thinking on AI, agents and the next generation of software and publishing, by Dinis Cruz, written with the SGit and RiskMandate agentic teams. Candidate framings for the masthead line:

• "Field notes on AI agents, security and the next generation of publishing, by Dinis Cruz"
• "Open thinking on agentic AI: what to build, how to secure it, and how to ship it"
• "The agentic era, written in the open"

Split the site in two. One shared design, two clearly separate areas:

The top menu carries the publication; the workshop gets one menu item and its own front page. Builder links leave the reader's first screen.

Write a purpose page ("Why this exists"), linked from the masthead and every byline. It should say plainly:

• The agenda: share knowledge, solve real problems in the open, and build sgit.ai and RiskMandate, which most of these articles use as evidence. The participant disclosure moves here from the footer.
• Open by default: content CC BY 4.0, code Apache 2.0; every idea here is free to take, adapt and build on.
• How it is written: from voice notes, by a desk of named agents under published rules, with every version kept.
• Who it is for: the personas, each with a sentence on what they will get.
• What I want from you: read, rate, tell me what is missing, and if a problem here is yours, ask about putting your agents on it.

The goal of the next phase is the path from first click to a conversation:

1. Arrive through a persona link someone sent.
2. Read the first article and rate it.
3. Come back: a new pick, the newsletter, or the reading board.
4. Ask: what is missing, a new version of an article, a topic.
5. Act: try sgit, talk about RiskMandate, or put their agents on a problem.

Every page should be judged by which step it moves a reader to next.

Personas as the core primitive

The homepage should become one persona among many: "The newsroom", the neutral one. Every persona, including that one, is the same front-page template filled from a persona file, so the founder's front page looks and works like the main site, customised to the founder.

What the persona pages do today. The index is clear and the five cards are well written. Each persona page is a list of seven starting articles plus an explanation of how the link works. Opening it adds the persona to the reader's browser without asking. It has no story, no opinion, no sections and no next step, and the picks it refers to did not render on a phone.

Anatomy of a persona mini-site:

Founder sections, filled from articles that already exist:

The persona file (kept in a vault, as the persona link brief proposes) holds: id, name, one-line description, story, Dinis's note, sections with their article lists, start-here order, and the "what is missing" question. The neutral newsroom persona has the same fields, written by the Editor. Personas for a single person (a founder you met last week) use the same file in a private vault, readable only by whoever has the link.

Ask before adding. Opening a link should show the persona and offer "Read as Morgan" and "Keep Morgan", rather than silently adding it to the reader's browser.

Reader primitives on the article

An article should know its relationship to the reader, and show it in a right-hand column that acts as the reader's own metadata for the piece. The reading meter already tracks part of this; the rest is new.

The primitives:

The side column (a bottom sheet on a phone) shows, top to bottom: why this was recommended and for which persona, progress and status, your highlights and notes, your rating, "Ask this article", and the next article on your board.

The reading board. Each persona gets a small Kanban board with four columns: New, Reading, Follow-up, Done. Opening an article moves it to Reading; reaching the end moves it to Done unless the reader drags it to Follow-up. New articles that match the persona arrive in New, which gives a returning reader a reason to come back. The board sits on the persona's front page and in the account.

Talk to the article. With a local model in the browser (Gemini Nano in Chrome, and the MVP described in A model in the tab), the reader can ask the page to condense itself, explain a term, answer a question or suggest related reading. Nothing leaves the device. Every exchange is logged with the article's other primitives, so the reader's notes, highlights and questions build into one record.

Where it is kept. In the browser's storage now, like the meter. Later, in the reader's own encrypted vault, which also solves the problem of a persona on a laptop and another on a phone. Exporting it should be one click, as the meter's JSON export is today.

Feedback lanes and the publishers page

The write-only encrypted lanes that carry subscriptions and reading shares are the right channel for all reader feedback; they just need to be used for more, and to give the reader a receipt.

Use the lanes for:

• Ratings, one tap, anonymous unless the reader adds an email.
• "What is missing?" on every persona page.
• "Write about this" and "I need a new version of this" on every article.
• Optionally, highlights and notes the reader chooses to share.

The lane only answers "ok" by design, so the browser should keep its own receipt ("Sent to Dinis, encrypted, 11 Oct") in the side column. On the newsroom side, the list agent files each item, the Editor gets a weekly digest, requests become pitches on the board, and anyone who left an email gets a reply when their article ships.

The publishers page should move to newsroom.sgit.ai/publishers/. It is the best pitch on either site: a one-paragraph summary, a five-minute tour, a table of what is live, an honest list of what is not done, and a direct ask. Move it, redirect the sgit.ai address, and:

• Link it from the purpose page, the journalist persona and the workshop.
• Add a name and email for pilots, which also closes a blocking finding from the synthetic-user study.
• Pair it with a publisher persona front page, so a publisher can both read the pitch and see the newsroom as a publisher would.
• Keep its "what is not done" section current from the same ledger as /shipped/.

Roadmap: now, next, later

The order follows one rule: fix what breaks trust first, then build the doors, then grow the newsroom. The gate between phases is a synthetic-user run that beats the last score.

Now (this week): trust and first impressions

• Publish articles to newsroom.sgit.ai only; point sgit.ai's article links and canonicals there
• Generate every count from one manifest
• Label the chip "£5 free reading credit" and announce the first charge once
• Start rating scales unselected; send ratings with one tap and consent
• Rewrite the first phone screen: what, who, three doors, the lead
• Remove the LinkedIn author block and version badges from reader pages
• Branded 404 page; page visible without waiting for JavaScript
• Add a contact (name and email) to Replicate and the account pages

Gate: fourth synthetic-user run, with a CISO persona added, scores above 2.4.

Next (2 to 4 weeks): findability

• Five desk pages, each with a Historian-written "start here" list
• Controlled tag list (about 40) with a page per tag; tags become links
• Linkable filters, full-text search, reading time and format on every card
• Series navigation on the reading meter, agent team and homepage-rebuild sets
• Live persona links for CISO, builder and news people
• "The short version" block at the top of every article
• Build checks and weekly feedback digest to the Editor

Gate: first 20 real contacts sent persona links; at least half leave a rating.

Next, added 11 Oct: the publication and persona mini-sites

• Write the purpose page and a new masthead line naming the subject and author
• Split the menu: the publication on top, the workshop as one item with its own front page
• Move the publishers page to newsroom.sgit.ai/publishers/ with a contact for pilots
• One front-page template driven by a persona file; the homepage becomes the neutral persona
• Founder mini-site first: story, Dinis's note, start-here queue, six sections
• Then security lead, AI builder, journalist and board member, in that order
• "Read as" and "Keep" choices instead of adding a persona silently
• Reading board (New, Reading, Follow-up, Done) per persona
• Side column with status, highlights and private notes
• "What is missing?" and article requests through the append lanes, with a local receipt
• Talk to the article with a local model, logged with the reader's notes

Gate: ten founders sent the founder link; track how many return within a week and what they ask for.

Later (next quarter): grow the newsroom

• A desk editor agent per desk, with its own policy and weekly round-up
• Personalised newsletter issues from persona ratings
• Public reader numbers (ratings, readers, payments) to answer "is this a real business?"
• New desks where the ratings show demand, for example AI regulation or local news
• Semaform-style labelled sections as the default article template