<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel>
<title>sgit.ai articles</title><link>https://newsroom.sgit.ai/articles/index.html</link>
<description>Articles and desk notes from sgit.ai, newest first.</description>
<item><title>How to run synthetic users on your own site: five people who do not exist, a browser, and an afternoon</title><link>https://newsroom.sgit.ai/articles/how-to-run-synthetic-users.html</link><guid>https://newsroom.sgit.ai/articles/how-to-run-synthetic-users.html</guid><pubDate>Sat, 10 Oct 2026 23:09:00 +0000</pubDate><description>A how-to, from three studies we have published: store.sgit.ai in September, riskmandate.ai the day after, and newsroom.sgit.ai on 10 October, run for this article. Five to ten invented users of about five types, each with a profile, a question they arrive with and an expected journey, drive a real browser one screenshot at a time, saying what they see, think, ask and do; then they are interviewed and rate the experience, and their findings are ordered by what they cost. Claude Sonnet is good enough to play each user; the study can live in a GitHub repository or in an encrypted vault shared by a link. On the newsroom, five readers took 62 steps, asked 51 questions the site did not answer and produced 31 findings, six blocking; four of them left. Two findings turned out to be caused by our own tooling, and one turned out to be a real bug: 51 of 527 figures missing after the move. This article sets out each step with examples and screenshots, what went wrong, and a template to start from.</description></item>
<item><title>A link to a persona: send people to the newsroom as someone, not as nobody</title><link>https://newsroom.sgit.ai/articles/a-link-to-a-persona.html</link><guid>https://newsroom.sgit.ai/articles/a-link-to-a-persona.html</guid><pubDate>Sat, 10 Oct 2026 16:57:00 +0000</pubDate><description>When I send someone to the newsroom today, they land on a front page made for nobody. I would rather send a CISO to the newsroom as a CISO, a data protection officer as a DPO, a developer as a developer, and one particular person as a persona made for them. This is the brief for doing that with nothing but a link. Personas move out of the site's code into an encrypted vault, opened in the reader's browser with a published read key, so a persona can be added or updated by the newsroom's agents without a single change to the site. A few personas get a page of their own, /persona/ciso/; any number more are reached through the part of the link after the #, which browsers never send to a server; and a persona for one person can live in a vault of its own, readable only by whoever has the link. The reader can follow the persona as it is kept up to date, or fork it and make it theirs. It draws on what Netflix, Bluesky, Mastodon, Apple News and Brave News learned about profiles, starter packs and personalisation on the device, and it stays entirely client side.</description></item>
<item><title>Pay after you read: how a reading meter became a working business model in one afternoon, one release at a time</title><link>https://newsroom.sgit.ai/articles/pay-after-you-read.html</link><guid>https://newsroom.sgit.ai/articles/pay-after-you-read.html</guid><pubDate>Sat, 10 Oct 2026 16:37:00 +0000</pubDate><description>On 10 October the reading meter on sgit.ai went, in seven releases between 12:09 and 15:49, from an experiment to a working pay-on-demand publication. A reader pays pence for the share of a page they actually read, from a balance that can go below zero without ever blocking them; after reading, they say how useful it was, and that sets the price, from free to double; their reading builds personas and a newsroom of their own, kept in their browser; and they can send it to us, encrypted, for a front page designed for them. Once a Stripe link is set, the only question left is whether people pay. This article introduces each feature, shows how each one grew out of the last, with a Wardley map that adds them one at a time, explains why paying after you see the value is the right way round, and why every decision started from one rule: do not rip off the reader. It ends with an offer to sites with traffic that would like to test it.</description></item>
<item><title>Where the vault keys live: key management at sgit-ai v0.20.0, and what comes next</title><link>https://newsroom.sgit.ai/articles/where-the-vault-keys-live.html</link><guid>https://newsroom.sgit.ai/articles/where-the-vault-keys-live.html</guid><pubDate>Sat, 10 Oct 2026 15:31:00 +0000</pubDate><description>Every vault on this site is encrypted in the client, so the server never sees a key and the key is the whole question. This is the current state of vault key management at sgit-ai v0.20.0: where everything lives, the one secret and the keys derived from it, where vault keys are kept today (a password manager, and a registry vault run by an isolated agent session), how a new key reaches the registry without ever entering a chat, append lanes as the transport behind most of it, the small communication vaults that made the problem urgent, and the four tracks that come next: password manager integrations, secrets.sgit.ai's passkey-unlocked keyring, PKI, and decryption that happens out of band. Plus the one gap we cannot close ourselves: agent platforms have no per-session secrets.</description></item>
<item><title>The infographic bake-off: which image model for which job, judged blind on 10 October 2026</title><link>https://newsroom.sgit.ai/articles/the-infographic-bake-off.html</link><guid>https://newsroom.sgit.ai/articles/the-infographic-bake-off.html</guid><pubDate>Sat, 10 Oct 2026 15:08:00 +0000</pubDate><description>The articles here are moving from code-drawn figures to infographics made by image models, and the question was which model, for which job, at what cost. So we ran a bake-off. Every image-output model on OpenRouter on 10 October 2026, its auto-router and our own code-drawn renderer were given the same briefs from one article, from an eighteen-word stat card to the whole 2,800-word article, plus an edit, a UI component, a brand slide and a three-slide deck. Five rounds, models cut after each; 101 images, every one judged blind by a Designer agent; every cent recorded, $10.44 in all; an Accountant and a Data Scientist on the numbers. The result is three models and guidance. Nano Banana 2.1, at four cents an image, for concept slides, charts and decks. Gemini 3 Pro Image, at fourteen cents and twenty seconds, when you are in a hurry. GPT-5.4 Image 2, at seventeen to twenty-three cents and a minute and a half, for anything that starts from a document or where every character is specified. Choose the model by the job, not by the budget.</description></item>
<item><title>Pay to keep your persona: readers should pay because it helps them, not because they feel they should</title><link>https://newsroom.sgit.ai/articles/pay-to-keep-your-persona.html</link><guid>https://newsroom.sgit.ai/articles/pay-to-keep-your-persona.html</guid><pubDate>Sat, 10 Oct 2026 14:21:00 +0000</pubDate><description>Most of what readers are asked to pay for, they pay for because they have to, because they are made to feel they should, or because it is the right thing to do. That works to a degree, and it does not scale. The value proposition we want is the opposite: a reader pays because it helps them, because what they are buying is time, context, focus, the ability to make good decisions and a better experience. On this site that thing now has a name. Your reading builds a persona, with a name and a graph you can watch grow, and you can have several, because a persona is a way to manage focus: one for security, one for AI development, one for everything else. Start from five made from what this site publishes, keep articles in a persona or put them out of it, and switch between them. Today it all lives in one browser, so opening the site on an iPad and then on a laptop gives you two strangers. That is the bad experience worth fixing, and the thing worth paying for: a persona that follows you to your phone, your laptop and your agent, with the privacy intact.</description></item>
<item><title>Who will game the reading meter? Eight kinds of reader, nine ways to cheat, and the risks that will actually happen</title><link>https://newsroom.sgit.ai/articles/who-will-game-the-reading-meter.html</link><guid>https://newsroom.sgit.ai/articles/who-will-game-the-reading-meter.html</guid><pubDate>Sat, 10 Oct 2026 13:40:00 +0000</pubDate><description>The reading meter on sgit.ai keeps everything in the reader's browser, so anyone can cheat it: edit the balance, open a private window, or credit themselves £5 by opening the page a payment returns to with a made-up reference. This piece goes one level below &quot;who are you protecting against&quot;. None of the people here are attackers. They are readers, from engineers who are invisible by habit to people who can barely click, with agents moving between the levels in seconds. For each kind we estimate how many there are, from published figures, what they could do to the meter and whether they will. The answer is that cheating will happen, rarely, and costs nothing that reaches the site, while the risks that will actually happen are quieter: a shared computer showing someone's reading history, a reader confused by a number, and ordinary card fraud on the payment link. Security and usability are aimed at the readers who will pay, not at the ones who never would.</description></item>
<item><title>Going live with the reading meter: pay for what you read, go below zero if you like, and the numbers we will check in eight weeks</title><link>https://newsroom.sgit.ai/articles/going-live-with-the-reading-meter.html</link><guid>https://newsroom.sgit.ai/articles/going-live-with-the-reading-meter.html</guid><pubDate>Sat, 10 Oct 2026 13:40:00 +0000</pubDate><description>The reading meter on sgit.ai stops being a demonstration. A page now costs what you read of it: scroll a tenth of the way down a new article and you pay a tenth of 10p. Your balance can go below zero and stay there; nothing is blocked and nothing nags, there is only a small balance in the top bar. If a page was not worth it you can say so, with a reason, and it is not charged. Topping up is one £5 payment on Stripe, with no account and nothing that renews, and the page you come back to adds the credit without being able to check it, on purpose. The meter is also packaged as a library any website can add. This article is the plan and the reasoning, written down before the results: the business case, what we expect, the numbers that would prove us wrong, and the date we look.</description></item>
<item><title>Open source is not free: who pays to keep the long tail working?</title><link>https://newsroom.sgit.ai/articles/open-source-is-not-free.html</link><guid>https://newsroom.sgit.ai/articles/open-source-is-not-free.html</guid><pubDate>Sat, 10 Oct 2026 12:59:00 +0000</pubDate><description>An old Intel iMac, clean-installed for my agents, could not run Homebrew or Docker Desktop, and needed Python by hand. Each project that dropped it did so because supporting old machines costs money and the people on the long tail have no easy way to pay for it. This article measures that long tail from Homebrew and PyPI analytics, sets out where money does flow for old versions (Oracle, Red Hat, Windows ESU, Rimini Street) and where it does not (open source receives about 0.09% of its estimated value), shows why pence payments only work aggregated, and simulates five ways to pay for it. About £1.80 a machine a year from individuals covers one project's long-tail cost in half the draws; customised builds for companies cover it in 94%. Open source is not free; the question is whether the people who get the value have an easy way to pay for it.</description></item>
<item><title>One article, five readers: a librarian, a cartographer, a historian, an explainer and a storyteller read the same piece</title><link>https://newsroom.sgit.ai/articles/one-article-five-readers.html</link><guid>https://newsroom.sgit.ai/articles/one-article-five-readers.html</guid><pubDate>Sat, 10 Oct 2026 12:30:00 +0000</pubDate><description>The articles on this site are deep and carry their evidence, and that makes them long and hard to consume. The answer tried here is not shorter articles. It is to keep writing the article first, as prose, because writing is how the argument is found, and then to send five readers through it afterwards, each an agent with a defined role. Two build the platform: a Librarian that catalogues every fact, claim, number, question and source with the sentence it came from, and a Cartographer that turns the catalogues into an ontology at three altitudes and draws the maps. Three write for a person: a Historian that says what the article added and where it sits in the arc, an Explainer that says it in two minutes, and a Storyteller that tells it as a deck. We ran it on the five articles about agent behaviour policies published between 7 and 10 October: 662 items catalogued, 32 problems flagged in published articles, 45 concepts, nine maps, five decks, and one new concept in the most recent article. The views are now on those five articles, and the whole run is in a vault you can open.</description></item>
<item><title>A meter in the browser: a penny a page, a history you keep, and a site that picks for you</title><link>https://newsroom.sgit.ai/articles/a-meter-in-the-browser.html</link><guid>https://newsroom.sgit.ai/articles/a-meter-in-the-browser.html</guid><pubDate>Sat, 10 Oct 2026 12:09:00 +0000</pubDate><description>Every page on sgit.ai now has a price, a few pence, and a meter in the corner of the screen that debits it from five pounds of starting credit. There is a reading account with a history, a price table, a top-up page with a cart and a checkout that has every step except the payment, and an out-of-credit state that never blocks a page. All of it lives in the reader's browser and nowhere else: no account, no server, no card, nothing sent. Open a private window and the meter starts again at five pounds, which looks like a way to read for free, except that it also starts again with no history, and the history is what the site uses to pick articles for you. That is the trade this experiment puts in front of a reader: pay a little, keep the record of what you read on your own machine, and get a site that knows you back. Whether people would make that trade is the question worth testing, and a meter that charges nothing is the cheapest way to start.</description></item>
<item><title>Re-anchoring: keeping an agent's rules alive through every summary, and a canary that shows when they are not</title><link>https://newsroom.sgit.ai/articles/re-anchoring-agent-behaviour-policies.html</link><guid>https://newsroom.sgit.ai/articles/re-anchoring-agent-behaviour-policies.html</guid><pubDate>Sat, 10 Oct 2026 00:11:00 +0000</pubDate><description>Instructions given only in conversation can be lost when a long session is summarised. The session that runs this site has been summarised eighteen times in a month, each time keeping under 2% of what it replaced. Re-anchoring is the answer: keep the agent's rules in a behaviour policy file and have the harness print it back after every summary, so the rules are restored rather than remembered. And because you cannot see what a summary drops, add a canary: a short status report, computed from the transcript, that ends every few answers. If it stops appearing, something in the policy has not been read. Both are running in this session now. This is how they work, what each piece is for, and why the best way to do it today is a recipe that someone has to keep up to date.</description></item>
<item><title>A second reader the agent cannot skip: how two wrong emails became a gate on every draft</title><link>https://newsroom.sgit.ai/articles/a-second-reader-the-agent-cannot-skip.html</link><guid>https://newsroom.sgit.ai/articles/a-second-reader-the-agent-cannot-skip.html</guid><pubDate>Fri, 09 Oct 2026 22:59:00 +0000</pubDate><description>On 9 October two emails drafted by my agent went out in my voice and signed with my name. The rule against it existed, in four places, and it failed because the only thing enforcing it was the agent's memory, the agent was the only reader of its own draft, and the rule fell out of context when the conversation was summarised. The fix, built the same day by the agent itself, is a hook on the draft tool: code checks first, then a fresh model call with only the rules, the sources and the draft, failing closed and logging every verdict. This is how it works, what the first run caught, why its independence depends on where it is installed, and how the same pattern, which banks call maker-checker, applies to any tool call that matters.</description></item>
<item><title>The AI governance stack, as a graph: an answer to Hari Kota, built</title><link>https://newsroom.sgit.ai/articles/the-ai-governance-stack-as-a-graph.html</link><guid>https://newsroom.sgit.ai/articles/the-ai-governance-stack-as-a-graph.html</guid><pubDate>Fri, 09 Oct 2026 22:40:00 +0000</pubDate><description>Hari Kota posted The Full AI Governance Stack, ten layers from principles to people, and asked how I would structure the graph across the layers. This is the answer, built as a vault you can open. Hari's table is kept exactly as posted, every cell a node. The table already contains ten edges between layers before anything is added. Each layer is its own world with its own vocabulary, and the edges between those worlds come from the provisions themselves, so a gap is a missing edge and a missing edge is a query. Hari's three gaps and the &quot;do this today&quot; test run as queries on a fictional shop, and the line &quot;most teams cover only 4 or 5&quot; gets three honest readings.</description></item>
<item><title>RFC 0001: two ways to add public-key cryptography to sgit, and the questions we want you to answer</title><link>https://newsroom.sgit.ai/articles/rfc-0001-public-key-cryptography-for-sgit.html</link><guid>https://newsroom.sgit.ai/articles/rfc-0001-public-key-cryptography-for-sgit.html</guid><pubDate>Fri, 09 Oct 2026 20:07:00 +0000</pubDate><description>A Request for Comments, before anything is built. Today an sgit vault is protected by one symmetric read key and a write key that only the server checks, so anyone who holds the read key and can write to the store, the host or a mirror for example, can author history that clients accept. sgit's own threat model says so, and a test performs the attack. This RFC proposes two designs. Native PKI vault mode uses two key pairs, one for reading and one for writing, so a reader cannot write, a host cannot forge, and a write-only depositor becomes possible. Sealed files add an inner envelope to any vault, so chosen files can be read only by named people, whose private keys can live in a key file, an ssh key, a hardware key, or a remote service that logs and approves each decryption. We set out both, what they cost, what they cannot do, the services that could hold the private keys today, and fourteen questions where an outside view would change the design.</description></item>
<item><title>A Mac of the agent's own: a business plan for agent desktops, what Apple's licence allows, and three behaviour policies</title><link>https://newsroom.sgit.ai/articles/a-mac-of-the-agents-own.html</link><guid>https://newsroom.sgit.ai/articles/a-mac-of-the-agents-own.html</guid><pubDate>Fri, 09 Oct 2026 18:54:00 +0000</pubDate><description>Our agents already have dedicated resources with a small blast radius: their own mailbox, their own code-host account, their own Claude account. The next one is a desktop of their own, and it should be a Mac, because that is where most agent desktop apps arrive first. This is a business plan for somebody else to build, following our earlier research on renting an agent a desktop. It started as a pool of Macs rented by the minute, and Apple's licence rules that out: a leased Mac must be held for at least 24 hours, for developer services, by one customer, and virtual copies may not be time-shared. So the plan is the shapes that are allowed: a dedicated Mac per customer, run for them, with a per-minute meter on top and a clean desktop per run built from encrypted vaults; developer agents on leased Macs; software for the Mac mini you keep; and a request to Apple for terms. The reason to want any of it is in the three behaviour policies: the same customer service agent on your own Mac, on a dedicated Mac and on a hardened one, where the excess nothing bounds falls from 23 rows to 11 to 3.</description></item>
<item><title>Ten hard questions for RiskMandate, answered: the mandate, the reach, the gap, and what we are deliberately not</title><link>https://newsroom.sgit.ai/articles/riskmandate-ten-questions.html</link><guid>https://newsroom.sgit.ai/articles/riskmandate-ten-questions.html</guid><pubDate>Fri, 09 Oct 2026 03:34:00 +0000</pubDate><description>My co-founder came back from a conference with ten hard questions, the ones people actually ask about a product like RiskMandate. What happens when an agent bypasses its policy? How do you keep a policy current when the agent gains new powers? What exactly am I paying for? Who is liable when it goes wrong? What stops a big platform absorbing you? Why behaviour and not the supply chain? Who enforces? What happens after a breach? What about agents instructing agents? And what can you measure? I answered them in a two-hour interview with Claude acting as a journalist with an eye for detail, challenging every answer until the whole set was detailed and coherent. This page is the result, written for someone who has not seen the questions: the model every answer rests on, the ten answers in brief, what RiskMandate deliberately is not, an honest table of what is live and what is design, three things the exercise showed we must fix on our own site, and then each question in full, linked to the work behind it.</description></item>
<item><title>How I work with Claude: one session per topic, agents with names, and memory you curate</title><link>https://newsroom.sgit.ai/articles/how-i-work-with-claude.html</link><guid>https://newsroom.sgit.ai/articles/how-i-work-with-claude.html</guid><pubDate>Fri, 09 Oct 2026 03:27:00 +0000</pubDate><description>A practical guide to the way I work with Claude, written for the people joining the team and for anyone I am helping with their own agentic workflows. It comes from about a year of doing this every day. Keep sessions separate, one per major or recurring topic, and do not let a thread wander across topics. Name them, &quot;project | what we are working on&quot;, and give agent sessions an @ name. An agent is a session with a focus and a role.md. What a session knows is what it reads, so curate that memory: my memory is a set of websites, graphs and vaults, wired together, and almost everything in it is open, which makes sharing with agents and people very cheap. Vaults are how agents receive and send information without broad permissions. With all of that in place, the review becomes the quality step: when I find a mistake now, I can usually trace it back to a brief that needed to be better. Then the tips: documents with a preview, small proof-of-concept sites, skills used with care, an Agent Behaviour Policy before every new connector, and a separate Cowork session for each agent at work. With starter prompts you can copy.</description></item>
<item><title>The waiting room knew first: a live local story, and the gap where local information used to be</title><link>https://newsroom.sgit.ai/articles/the-waiting-room-knew-first.html</link><guid>https://newsroom.sgit.ai/articles/the-waiting-room-knew-first.html</guid><pubDate>Thu, 08 Oct 2026 21:57:00 +0000</pubDate><description>This afternoon, at two London hospitals, staff told the people in front of them that the IT systems were down. One waiting room was announced at about five hours, and a doctor said the problem was national. Nothing a person could check before leaving home showed any of it: no notice from the trust, no post, no local story, no dated search result. This is not a story about one hospital, whose staff were working through it, and it is not yet a story about a national outage, which has not been confirmed. It is a story about where local information is supposed to come from now. The information existed; it reached people only once they were already in the waiting room. Northern Ireland publishes live emergency waits for every hospital, updated tonight at 10.20 pm, and Wales has a live service; England has no national equivalent, and I found no live or disruption page for the trust involved. Local news has thinned out, and the social feeds that used to carry this kind of thing have fragmented. So I have started a vault to log this as a live local story, with the evidence separated by level, the public sources checked on a schedule, and an enquiry to the trust that my agent will send. It is the real counterpart of the fictional bridge story, and the first of several.</description></item>
<item><title>Encrypted memory for agents that run somewhere else: sgit deployment patterns, from a Mac mini to Kubernetes</title><link>https://newsroom.sgit.ai/articles/encrypted-memory-for-isolated-agents.html</link><guid>https://newsroom.sgit.ai/articles/encrypted-memory-for-isolated-agents.html</guid><pubDate>Thu, 08 Oct 2026 21:02:00 +0000</pubDate><description>Agents are safer when they run in isolated places: a cloud VM, a local VM, a container on a Mac mini, a GPU machine, a job that exists for one task. Isolation takes away the shared drive, and ephemeral compute takes away the disk, so the memory has to live somewhere else, somewhere the owner controls and a breach does not expose. This article maps how to give those agents encrypted memory with sgit and a vault server you run yourself: one container, an access token, storage in a folder or a bucket, and only ciphertext on the server. Five patterns, each drawn as a diagram with its Mermaid source: a Mac mini with Docker Compose, the life of one ephemeral agent run with a scoped clone, Kubernetes, a private cloud VPC with CloudFront in front, and two servers holding one vault. Every command was run against a local server for this article, including a scoped clone, a push from a second agent, replication to a second server and a restore after a restart, and a search of the server's storage that found none of the plaintext.</description></item>
<item><title>Knowing when to stop: what experience gives people, and what we have to design into agents</title><link>https://newsroom.sgit.ai/articles/knowing-when-to-stop.html</link><guid>https://newsroom.sgit.ai/articles/knowing-when-to-stop.html</guid><pubDate>Thu, 08 Oct 2026 15:07:00 +0000</pubDate><description>The hardest call in most work is not what to do next but when to stop. This article starts with people, because the problem is not new: security champions who had automated away whole classes of bugs and ended up debating whether GUIDs were random enough; development teams that hit every KPI and did not move the business; teams that found more work for themselves as they grew. What stopped them, when something did, was perspective: knowing who the attackers are, which phase the business is in, where the bottleneck is, and what good enough looks like, which is much of what seniority is. Agents have the same problem, worse. Their range is the feature: they can go in any direction, and variability is what makes them useful. But that range means they will keep going, fixing the twenty things they noticed rather than the one that mattered. The answer, for both, is not draconian rules but constraints that carry perspective: direction, a mandate, memory with the bigger picture, graphs that narrow the scope, a stop named before the work begins, one kind of work per step, and shipping often enough that the users tell you whether it mattered.</description></item>
<item><title>Agency is not a yes: a scale for human and agent decisions, from rubber stamp to the reviewer who fixes the source</title><link>https://newsroom.sgit.ai/articles/agency-is-not-a-yes.html</link><guid>https://newsroom.sgit.ai/articles/agency-is-not-a-yes.html</guid><pubDate>Thu, 08 Oct 2026 15:07:00 +0000</pubDate><description>We talk about the human in the loop as if the loop were the point. Most of the time the human, or the agent put in the same place, is asked for a yes or a no, and that is the least interesting part of a decision. This article sets out what agency actually needs, for a person and for an agent: options beyond yes, context in the decider's own terms, the ability to look behind what they are shown, time or tokens, incentives that treat a wrong yes and a wrong no alike, somewhere to escalate, and authority over the system that produced the request. It turns those into a scale of seven levels, from the rubber stamp to the delegator, where the weakest dimension caps the whole decision, and scores fourteen cases from the record and from my own agent team, from a prompt that asks to add label 756-459-3214 to the one email an agent of mine is allowed to send. Below level 3, the decider holds the liability for a decision the system made, and accountability belongs to whoever designed the decision point and up their chain. Above it, the review stops being a sign-off and becomes a QA step: each draft is a chance to validate everything that led to it, to fix the source rather than the output, and to think better. And when a kind of draft keeps going out unchanged, it becomes a rule that runs without review. A vault published with the article holds the scale, the cases and an assessment anyone can run on their own decision points.</description></item>
<item><title>Hope or enforcement: one customer service agent, three designs, and who keeps each promise</title><link>https://newsroom.sgit.ai/articles/hope-or-enforcement.html</link><guid>https://newsroom.sgit.ai/articles/hope-or-enforcement.html</guid><pubDate>Thu, 08 Oct 2026 12:32:00 +0000</pubDate><description>A company puts an agent on its customer service inbox. Where is my order, my delivery was damaged, I was charged twice: the ordinary mail of an online shop. This article and the vault published with it take one mandate for that agent and build it three ways. First, one capable model connected straight to the mailbox and the database, with a long and professional prompt. Second, the same agent behind a harness of business tools. Third, the job refactored into a control flow: a deterministic identity gateway, an intake and security agent, an orchestrator, five narrow specialists with tools bound to the verified customer, a controller on every reply, and an analyst after the run. Each design gets an Agent Behaviour Policy, and every rule in it is marked by what enforces it. The same 62 fictional emails, sixteen of them hostile, go through all three. In the first design 97% of the rules are hope, kept only by the model; in the second 73%; in the third 23%. The reach of one run falls from 38,000 customer records, unlimited refunds and any address, to one customer, 100 GBP per order and no other address, and the policy shrinks with it, because it no longer has to forbid what the agent cannot do. The third design still has too much power in two places, and the policy is what finds them. The article closes with the client's view: the same promises, the record of who keeps each, and the business case.</description></item>
<item><title>Who are you protecting against? Draw the security line where the attacker is, not above it</title><link>https://newsroom.sgit.ai/articles/who-are-you-protecting-against.html</link><guid>https://newsroom.sgit.ai/articles/who-are-you-protecting-against.html</guid><pubDate>Thu, 08 Oct 2026 03:10:00 +0000</pubDate><description>An entrepreneur doing everything they can to be secure bought a Mac mini for a customer, decided it would never touch the internet and that nothing would be installed on it, and ended up writing the application in the Perl that ships with macOS. The question that decides whether that is wise is not how secure the design is, but who it protects against. This article sets out the three questions that answer it, who the threat agent is, what the attack vector is, and how sophisticated they are, and a ladder of six tiers from your own mistakes to states, grounded in NIST SP 800-30, the NCSC's commodity, targeted and elevated threats, and MITRE ATT&amp;CK. It notes that the UK's new AI Risk Management Toolkit asks &quot;Who are the new threat actors?&quot; without defining them. It reads the Mac mini against the ladder, where the air gap stops attackers that no inbound ports and patches also stop while adding a USB path and removing backups, monitoring and mainstream tooling; makes the same argument about keeping systems on premises for security; and argues that you should sell something better than what the customer has, not something beyond what they need, because drawing the line too high is a disservice to both sides. With it ships a vault of eight fictional startups, each with its assets, an attack tree mapped to ATT&amp;CK techniques, and where it should draw the line, plus a questionnaire to draw your own.</description></item>
<item><title>Every mistake added a rule: complexity, agents, and the way back to shipping</title><link>https://newsroom.sgit.ai/articles/every-mistake-added-a-rule.html</link><guid>https://newsroom.sgit.ai/articles/every-mistake-added-a-rule.html</guid><pubDate>Thu, 08 Oct 2026 02:09:00 +0000</pubDate><description>A friend who uses agents better than most, one writing, others verifying, ChatGPT reviewing, every claim resting on an output read in full, sent me two messages about a verification that keeps breaking. The code is holding up. The process around it is not: long sessions compact and skip steps, outputs of failing commands are lost, prompts have grown to 100 KB, scripts are edited in place, the harness suggests what the rules forbid, and every mistake added a rule that caused new mistakes. This is complexity, and it is what hits the founders who are doing the right thing, clever, careful, now working as engineers without the scar tissue of engineering. This article maps their process as a Wardley map, where complexity is a position, custom-built process sitting where commodities already exist, and maps it again with each piece made small, shipped and moved right. Then it sets out the principles I work by: map it, commoditise small chunks and let them compound, ship, keep sessions small and the context yours, memory as versioned files, slow down when complexity hits, security by asset and attack vector, rules for incidents and machines for enforcement, run it in five environments, reverse-engineer the path to the destination, and learn the engineering that already exists. It ends with direct answers to their questions on compaction, audit cards and what deserves a STOP.</description></item>
<item><title>Thread: Range is the feature, so the stop has to be designed</title><link>https://newsroom.sgit.ai/articles/desk/range-is-the-feature-so-the-stop-is-designed.html</link><guid>https://newsroom.sgit.ai/articles/desk/range-is-the-feature-so-the-stop-is-designed.html</guid><pubDate>Thu, 08 Oct 2026 00:00:00 +0000</pubDate><description>Four articles from one day, written for different reasons, end on the same line: an agent's range is what makes it useful, and it is also why the decision to stop cannot be left to the agent.</description></item>
<item><title>Newsletter, issue 2: How agents decide, when they stop, and a local story kept as evidence</title><link>https://newsroom.sgit.ai/articles/newsletter/2026/10/08/002-how-agents-decide.html</link><guid>https://newsroom.sgit.ai/articles/newsletter/2026/10/08/002-how-agents-decide.html</guid><pubDate>Thu, 08 Oct 2026 00:00:00 +0000</pubDate><description>A day of articles on deciding: what a real decision needs, why an agent that can go anywhere has no reason to stop, what happens when every mistake adds a rule, and one customer service agent built three ways to count which rules are only hoped for. Alongside, a live local story, a hospital outage nobody could check from home, kept as evidence while it was happening.</description></item>
<item><title>Liquid content needs water: liquefy the journalist's notebook, not the finished product</title><link>https://newsroom.sgit.ai/articles/liquid-content-needs-water.html</link><guid>https://newsroom.sgit.ai/articles/liquid-content-needs-water.html</guid><pubDate>Wed, 07 Oct 2026 22:42:00 +0000</pubDate><description>FT Strategies has published a clear primer on liquid content, journalism built from datafied components that can be shaped into whatever a reader needs. I agree with most of it, and this article is about where I would push. What makes content liquid is the water inside it, and the water is the reporting: the notebook, the interviews, the documents, the hunches, kept with their sources as a graph. So the place to start is not a reinvention of newsroom norms but the opposite, putting the experienced journalist and the way they already work at the centre and giving them tools they have not had, including experts a newsroom could rarely afford. Writing stays theirs, because writing is how the story is found. Read that way, the three things the guide says liquid content is not each become part of it, personalisation becomes the meeting of the reader's graph and the story's, prioritising readers' tastes looks like the brief that produced clickbait, and the money goes beyond advertising, subscriptions and licensing to payment per use that walks back to whoever found the facts.</description></item>
<item><title>The bridge, followed to the end: what one local story is worth when it is kept as a graph</title><link>https://newsroom.sgit.ai/articles/the-bridge-followed-to-the-end.html</link><guid>https://newsroom.sgit.ai/articles/the-bridge-followed-to-the-end.html</guid><pubDate>Wed, 07 Oct 2026 22:05:00 +0000</pubDate><description>A simulation of Markus Franz's bridge example, played out on a story vault from the council's first notice to the first car across. A fictional town's main bridge closes; the council says one week, the contract on site says three, an independent engineer says five to seven, and it opens after forty-six days. The paper leads with it five times; readers need it on fifty-seven days. Three readers, a parent, a café owner on the far bank and a plumber who works both banks, use the same claims in three different ways, each from their own graph, and make better decisions with them: an after-school club booked in time, £640 of stock not wasted and £1,200 of relief claimed, nine hours of driving saved. A county highways team, an investor, a national desk and a routing agent buy from the same graph, and the agent spends a seventh of what it would have spent searching, and is right from the first week. Everything they pay, £2,707 in the simulation, walks back down the claims to the reporter, the paper and the resident whose photos were the evidence. The vault is published with its read key.</description></item>
<item><title>Story vault underneath, Reader Skills on top: why local journalism has the most to gain</title><link>https://newsroom.sgit.ai/articles/story-vault-meets-reader-skills.html</link><guid>https://newsroom.sgit.ai/articles/story-vault-meets-reader-skills.html</guid><pubDate>Wed, 07 Oct 2026 20:52:00 +0000</pubDate><description>Markus Franz published &quot;The Article Is Only the Beginning&quot; on 7 October 2026, proposing Liquid Utility, journalism that helps people understand, follow and act rather than only read, and six Reader Skills to deliver it, with a bridge closure as the example. He then wrote, under my comment, that his idea and the story vault connect at an architectural level: the story vault answers what we know and why it can be trusted, Reader Skills answer what we can reliably help someone do with it. This article draws that connection. Each of his six skills turns out to be an operation the story graph already supports, and each safeguard he asks for is a property the graph already has: versions for Update, supersede edges for corrections, freshness for &quot;could not check&quot;, a flag at the node for protected sources. His bridge is drawn as a graph. And his article adds the piece our monetisation had not mapped: locality, where the trust relationship and the brand are strongest. Local contributors feed local journalists, local stories feed national and international ones, and if every use pays back down the chain of claims it rests on, small payments from many people fund the reporting nearest to them.</description></item>
<item><title>Zoom into an agent's behaviour policy and you find the business logic</title><link>https://newsroom.sgit.ai/articles/the-behaviour-policy-is-the-business-logic.html</link><guid>https://newsroom.sgit.ai/articles/the-behaviour-policy-is-the-business-logic.html</guid><pubDate>Wed, 07 Oct 2026 18:07:00 +0000</pubDate><description>The first rules anybody writes for an agent are mechanical. Do not send, only draft. Do not delete. Use your own account. Vendors are good at those, and should be. Zoom in on any real agent's behaviour policy, though, and within a few layers you are writing how this company does email, which steps an invoice goes through, who a client is to it this week, and what the company is for. That is business logic, and many organisations have never written it down, because their software was the law. This article walks one fictional firm's email agent through six layers, from the platform to the board, records what stands in the way of each rule, counts how much of the policy is backed by a control, how much by an accepted risk and how much by hope, and shows where a vendor's existing control plugs in. The argument is that a behaviour policy built in layers, each refining the one below and each with its own owner, is the only way to describe agent behaviour at the granularity a business actually runs at, that vendors cannot and should not try to model it for each customer, and that writing it down is what lets the business scale.</description></item>
<item><title>A locked-down desktop for an agent, by the minute, is still hard to rent</title><link>https://newsroom.sgit.ai/articles/an-agent-desktop-by-the-minute.html</link><guid>https://newsroom.sgit.ai/articles/an-agent-desktop-by-the-minute.html</guid><pubDate>Wed, 07 Oct 2026 15:19:00 +0000</pubDate><description>We want to give each agent a desktop of its own, away from the laptop, that a person can watch and take over, that can reach only what its task needs, that holds no secret it could leak, that is thrown away afterwards, and that is billed for the minutes it works. In October 2026 every one of those properties can be bought somewhere, and no single product we looked at offers all of them. This article lays out the nine properties, puts nine products against them from their own documentation, prices two hours of work a day on each, and explains the three things that make it hard: macOS cannot be leased for less than a day and Apple's licence limits what a leased Mac is for; the strongest isolation controls are weeks old or in private beta; and prompt injection is not solved, so the desktop has to be the barrier rather than the model. It proposes what we would build from what exists, and closes with the startup credit programmes that would pay for trying it, verified on the day, with how to apply.</description></item>
<item><title>An open AI governance framework, and what its licence let us build</title><link>https://newsroom.sgit.ai/articles/ai-baseline-control-framework.html</link><guid>https://newsroom.sgit.ai/articles/ai-baseline-control-framework.html</guid><pubDate>Wed, 07 Oct 2026 15:13:00 +0000</pubDate><description>Jan van Dijke published the AI Baseline Control Framework on 2 October 2026, twenty controls for organisations that deploy AI, in five categories and three types, each with why it matters and how to put it in place, mapped to the NIST AI RMF, ISO/IEC 42001 and the EU AI Act, and licensed CC BY-SA 4.0. Part one is about the framework, what it does well, what it adds that the three it maps to do not, and why an open licence matters more for a control framework than for most documents. Part two is what the licence made possible on the day: the CSV export converted into a semantic graph with an ontology, a SKOS taxonomy, JSON-LD and Turtle, eighty hyperlinked documents and a database that runs in the browser, joined to the EU AI Act's own text, published as a vault under the same licence, with a fractal graph view that walks from the framework down to a paragraph of law, and the six things the graph found that the CSV does not say.</description></item>
<item><title>Where is the why? A permission prompt asked me to decide, and kept the reason</title><link>https://newsroom.sgit.ai/articles/where-is-the-why.html</link><guid>https://newsroom.sgit.ai/articles/where-is-the-why.html</guid><pubDate>Wed, 07 Oct 2026 12:59:00 +0000</pubDate><description>An agent session asked, in the middle of a task, to add a repository. The prompt showed three fields, owner, repository and access, and two buttons, Decline and Allow once. It did not say which session was asking, why, what the session would be able to do afterwards that it could not do before, or what would happen on a no. The session was one of several, and one of them was working on a vault holding confidential data. This article reads that prompt through the Agent Behaviour Policy, where a permission prompt is a request to change the grant mid-session and a barrier whose strength is the information the person is given; sets it against what courts, regulators and research have said about decisions taken without the facts, from Montgomery's consent forms and the red hand rule to GDPR's informed consent, token human oversight, and the moral crumple zone; lists the other prompts that asked without a why and the fixes that worked, from Apple's purpose strings and Microsoft's number matching to the CNIL's rule that refusing must be as easy as accepting; puts Anthropic's own figures on how often people approve agent prompts beside them; and proposes a why card, a prompt that carries its reason, its change in reach, its cost, the path if declined, and a record, and that turns into a risk acceptance when the risk rises.</description></item>
<item><title>The week: The week to 7 October: the agent team, written up from the inside</title><link>https://newsroom.sgit.ai/articles/desk/the-week-to-7-october.html</link><guid>https://newsroom.sgit.ai/articles/desk/the-week-to-7-october.html</guid><pubDate>Wed, 07 Oct 2026 00:00:00 +0000</pubDate><description>The busiest week of articles on the site so far, and most of it is one story told three times at increasing depth: a team of agents running a business, from the walkthrough to the field notes to the full stack.</description></item>
<item><title>Thread: Create anywhere, edit your own: a rule learned in the inbox, applied to the newsroom</title><link>https://newsroom.sgit.ai/articles/desk/create-anywhere-edit-your-own.html</link><guid>https://newsroom.sgit.ai/articles/desk/create-anywhere-edit-your-own.html</guid><pubDate>Wed, 07 Oct 2026 00:00:00 +0000</pubDate><description>The agent team tried letting only one agent draft, and it became a bottleneck in two days. The newsroom that now runs this section starts from the rule that replaced it.</description></item>
<item><title>Nugget: A model that can go in every direction needs someone with a direction</title><link>https://newsroom.sgit.ai/articles/desk/a-model-that-can-go-in-every-direction.html</link><guid>https://newsroom.sgit.ai/articles/desk/a-model-that-can-go-in-every-direction.html</guid><pubDate>Wed, 07 Oct 2026 00:00:00 +0000</pubDate><description>The sentence in the middle of a measurement article that answers the question half this site keeps asking: what is the person for?</description></item>
<item><title>Newsletter, issue 1: A team of agents, written up from the inside, and an open framework built on the same day</title><link>https://newsroom.sgit.ai/articles/newsletter/2026/10/07/001-agents-doing-real-work.html</link><guid>https://newsroom.sgit.ai/articles/newsletter/2026/10/07/001-agents-doing-real-work.html</guid><pubDate>Wed, 07 Oct 2026 00:00:00 +0000</pubDate><description>What it takes to let agents do real work for a business, from four sides: a team of agents running a small business, written up from the inside; the behaviour policy that says what each agent may do, and the business logic it turns out to hold; the desktops and permission prompts those agents need; and an open AI governance framework turned into a graph, a database and a walk down to EU law within a day of reading it.</description></item>
<item><title>The Mandate Stack: a multi-agent system in production, layer by layer</title><link>https://newsroom.sgit.ai/articles/the-mandate-stack.html</link><guid>https://newsroom.sgit.ai/articles/the-mandate-stack.html</guid><pubDate>Tue, 06 Oct 2026 23:03:00 +0000</pubDate><description>RiskMandate runs its business with about fifteen agents and one person, four times a day on a schedule and whenever the person sits down with them, with the person's name on every message that leaves. The agent that runs its CRM wrote the briefing this article is built from. The system is described in eight layers, from rented compute and channels, through encrypted vaults as shared memory, domain vaults, semantic graphs over people and policies, a scheduled conductor and written behaviour policies, to a human who holds the one step that cannot be undone. The article follows an input from the outside world through the layers to the person who sends; explains why the vault is an app platform rather than storage, and the loop in which a friction becomes a tool in the same session and the tools compound; names the feedback loop that makes the setup hold, the draft as a release candidate with the recipient closing the loop; and draws two Wardley maps with Mermaid, from the outside and from the inside, showing what the team is turning into a commodity and what it is turning into a product. Every layer is linked to the article or document on this site where it was worked out. The published record of agent projects that stall is kept for the end, each reason mapped to the mechanism that answers it. Everything described is in use.</description></item>
<item><title>Why my agents do not run on my laptop: chat, Cowork and Code in the cloud, a vault as the shared drive, and the two walls an operating system has</title><link>https://newsroom.sgit.ai/articles/why-my-agents-do-not-run-on-my-laptop.html</link><guid>https://newsroom.sgit.ai/articles/why-my-agents-do-not-run-on-my-laptop.html</guid><pubDate>Tue, 06 Oct 2026 17:49:00 +0000</pubDate><description>I do not run any model or agent on my laptop, and I am asked why often enough to write it down. The reason is not a worry about models. It is a fact about operating systems: they have two hard walls, the kernel and the user account, and an agent on my laptop runs inside the wall marked &quot;me&quot;, where it can read everything I can read, SSH keys, cloud credentials, the password manager's session, every site my browser is signed into. The rules the desktop agents add on top are settings, enforced by the process they constrain, and fifteen months of incidents show what happens when a mistake or an injected instruction reaches the account. So the agents run in four places that are not my laptop: Claude chat, with nothing connected and search across past chats switched off, for thinking; Claude Cowork in the cloud, with no repositories, for most of the agentic work; Claude Code on the web, with one repository per session and a network allowlist, when code has to change; and ChatGPT with no assets at all. What makes this workable is a vault as the shared drive between them: encrypted on the agent's side, keys handed to a session out of band, commit, pull, push, so the laptop passes keys and nothing else. The article gives the setup, the evidence, what the OS can and cannot isolate, the usability trade-offs, the three things I wish the platforms gave me, identity, secrets and a key pair per agent, and one caveat: this is about a laptop that holds the main account. A dedicated machine with separate accounts and nothing of mine on it is a different model, which I will try and report on later.</description></item>
</channel></rss>
