<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel>
<title>sgit.ai articles</title><link>https://sgit.ai/articles/index.html</link>
<description>Articles and desk notes from sgit.ai, newest first.</description>
<item><title>An open AI governance framework, and what its licence let us build</title><link>https://sgit.ai/articles/ai-baseline-control-framework.html</link><guid>https://sgit.ai/articles/ai-baseline-control-framework.html</guid><pubDate>Wed, 07 Oct 2026 00:00: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>A locked-down desktop for an agent, by the minute, is still hard to rent</title><link>https://sgit.ai/articles/an-agent-desktop-by-the-minute.html</link><guid>https://sgit.ai/articles/an-agent-desktop-by-the-minute.html</guid><pubDate>Wed, 07 Oct 2026 00:00: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>Where is the why? A permission prompt asked me to decide, and kept the reason</title><link>https://sgit.ai/articles/where-is-the-why.html</link><guid>https://sgit.ai/articles/where-is-the-why.html</guid><pubDate>Wed, 07 Oct 2026 00:00: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://sgit.ai/articles/desk/the-week-to-7-october.html</link><guid>https://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://sgit.ai/articles/desk/create-anywhere-edit-your-own.html</link><guid>https://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://sgit.ai/articles/desk/a-model-that-can-go-in-every-direction.html</link><guid>https://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://sgit.ai/articles/newsletter/001-2026-10-07.html</link><guid>https://sgit.ai/articles/newsletter/001-2026-10-07.html</guid><pubDate>Wed, 07 Oct 2026 00:00:00 +0000</pubDate><description>The first issue of the SGit Newsroom newsletter covers the busiest week of articles on sgit.ai so far. Most of it is one story told at three depths, a team of agents running a business, from the walkthrough to the field notes to the full stack. Around it: personal agents read through behaviour policy, review as a science, the author's input measured, and, today, 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>A personal agent that keeps your secrets: the 2026 agents read through behaviour policy and encryption, and a privacy-first design on vaults, enclaves and the browser</title><link>https://sgit.ai/articles/a-personal-agent-that-keeps-your-secrets.html</link><guid>https://sgit.ai/articles/a-personal-agent-that-keeps-your-secrets.html</guid><pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate><description>In the five months to October 2026 the personal agent became a product category. Meta's Muse, OpenAI's dots, Google's Gemini Spark, Microsoft's Autopilot, Amazon's Alexa+, Apple's rebuilt Siri and a self-hosted open source project called OpenClaw all give a person an always-on agent with a computer of its own, a memory made of files, and connectors into email, calendars, messages and money. This article reads them through two lenses this site already uses. The first is RiskMandate's Agent Behaviour Policy: what each agent can reach, what it was asked to do, what stands in the gap, and what record it leaves. The second is the data: where the memory rests, who holds the keys to it, who processes it, who could be compelled to hand it over, and what happens to the people in it who never signed up. Read that way, the products are strong where they are strong, a separate permission authority is a real barrier on actions, and candid where they are candid, Meta's own engineers say today's protection against Meta reading the memory is policy rather than cryptography. The second half is a design for a personal agent on the technology this site describes: memory in vaults the host holds only as ciphertext, a behaviour policy as the permission authority, compute in the user's browser where a small model is enough and in an attested enclave when it is not, with a key for one task's data released by the user's device against the enclave's attestation and destroyed when the task ends, the frontier model called only for the step that needs it, and a folder per person with provenance that the person it describes can read. The two designs, the vendors' and this one, converge on files and no database and a page per person. The difference is who holds the keys, who can read the pages, and who pays for it. It ends with what exists today, what does not, and the question of who gives the mandate over information in the first place.</description></item>
<item><title>The agent team as it runs: one person, twelve agents, encrypted vaults, and a mailbox nobody sends from</title><link>https://sgit.ai/articles/the-agent-team-as-it-runs.html</link><guid>https://sgit.ai/articles/the-agent-team-as-it-runs.html</guid><pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate><description>The walkthrough told you how to build the agentic inbox in phases. This is the stack as it runs today, written up from the agents' own field notes so that it can be referenced and copied: twelve Claude agents on dedicated accounts, each with one focus and a behaviour policy; encrypted vaults the host cannot read, driven by sgit, as the only memory; messages between agents as files in each other's mailroom; a CRM that is one folder per person with provenance on every fact and a hash on every message; a conductor that runs the team four times a day with a security role first and last; and a mailbox the agents draft in but never send from. It then does two things the field notes did not. It names the security and privacy properties as properties, client-side encryption with keys handed out of band, read keys that cannot write, a leak check before every commit, rotation by new vault, a record that is read afterwards against the policy, and a three-way distinction between public, private-ish and personal information in which the team's vaults are built to hold the first two and refuse the third, with rules that can be scoped per customer and written to protect the person on the other end. And it maps every piece of the setup to the idea on this site that it implements, vaults, behaviour policies, fractal semantic graphs, memory as files, so that nothing in it has to be taken on trust. It ends on the question the setup leaves open, who gives the mandate over information, which gets a document of its own.</description></item>
<item><title>The deck I could not download: an author-first home for presentations, as a business plan somebody else can build</title><link>https://sgit.ai/articles/the-deck-i-could-not-download.html</link><guid>https://sgit.ai/articles/the-deck-i-could-not-download.html</guid><pubDate>Tue, 06 Oct 2026 00:00:00 +0000</pubDate><description>I wanted one presentation from SlideShare and was offered a 30-day trial and then £10.99 a month. The author of the deck receives nothing from that subscription, under an uploader agreement that grants the platform a royalty-free licence to monetise, charge for, sublicense and train models on the work, and I am one of those authors, with 69 decks uploaded over fifteen years. This article does three things. It says what happened to SlideShare, from a 2006 start through LinkedIn and Scribd to the September 2021 paywall, and why a service with a PDF viewer and a file store has not been replaced: fifteen years of embeds and links, which is inertia in Wardley's sense. It sets out what an author can ask the old platform for today, under the right of access and, in the EU, the copyright transparency duty, including the two questions platforms do not expect, how many downloads and what revenue. And it designs the service the author would have chosen, on the primitives this site already publishes: every author's decks in a vault the host cannot read, access decided by keys rather than settings, a read key for what is free, a receipt turned into a ten-minute key for what is paid once, a revocable grant for what is private, decryption in the browser, an attested enclave for the one step that needs plaintext, seven roles that no single company holds, and a split of 85% to the author on a ledger the author can recompute. The plan is published as a vault with a working mock, the Deck Vault, with its economics worked for one author and its risks as an acceptance register. The marginal cost is storage and bandwidth, which are near zero; the hard row is the fixed part of a card fee, which the plan says so about rather than hides. Somebody should build it. The author will build the first step for their own decks.</description></item>
<item><title>The Mandate Stack: a multi-agent system in production, layer by layer</title><link>https://sgit.ai/articles/the-mandate-stack.html</link><guid>https://sgit.ai/articles/the-mandate-stack.html</guid><pubDate>Tue, 06 Oct 2026 00:00: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://sgit.ai/articles/why-my-agents-do-not-run-on-my-laptop.html</link><guid>https://sgit.ai/articles/why-my-agents-do-not-run-on-my-laptop.html</guid><pubDate>Tue, 06 Oct 2026 00:00: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>
<item><title>How much of this did I write? The numbers behind twenty articles in four weeks, and what the input actually was</title><link>https://sgit.ai/articles/how-much-of-this-did-i-write.html</link><guid>https://sgit.ai/articles/how-much-of-this-did-i-write.html</guid><pubDate>Mon, 05 Oct 2026 00:00:00 +0000</pubDate><description>A friend who received a reply from one of my agents said the amount of text I manage to produce is baffling, and the honest answer deserved numbers rather than a shrug. So this article measures the session that wrote the last twenty articles on this site: every word I typed or spoke, every word that came back, how many times each piece went round, what the corrections were, and what the memos were standing on. The picture is not the one people assume, in either direction. I did not type the articles, and the model did not write them from a prompt. Over four weeks I sent about 65,000 words in 148 messages, 55,000 of them in thirty-seven voice memos, and the agent published 96,000 words of articles and wrote another 76,000 to me about them, through 123 releases, 135 web searches and 26 research agents. No article came from a one-line prompt; the shortest brief was a single memo of 1,943 words, the longest ran to twenty-one messages. Eight articles are accounted for by hand, memo by memo and correction by correction, and every number is a row in a published vault. And the input that matters most is not in the session at all: the last article quotes thirty-three pieces of my earlier writing, from a 2010 open source tool to briefs written with other agents this summer, which the agent found because they were published. The corrections I make are rarely to hallucinations. They are to briefs that needed to be better, because a model that can go in any direction needs someone with a direction. That is why the people who have one are not out of a job. They are the input.</description></item>
<item><title>If somebody built a company on code review: how I would do it, and why it is only now possible</title><link>https://sgit.ai/articles/if-somebody-built-a-company-on-code-review.html</link><guid>https://sgit.ai/articles/if-somebody-built-a-company-on-code-review.html</guid><pubDate>Mon, 05 Oct 2026 00:00:00 +0000</pubDate><description>A reader of the code review article replied with seven good questions, and a voice memo of mine answered them with a change of frame: if somebody were building a company on code review, this is how I would do it. The answers turn on a distinction the first article did not make clearly enough. What is fractal in a fractal semantic graph is the grammar; which layers exist is decided by each company, and a product that standardises them away loses the thing it was meant to review. Two things make the rest possible only now. One technology can read every layer, from strategy to bytecode, so the graphs can be built at every altitude and built close to reality. And that moves code review from an art of opinion and power to a science of facts, provided the models are used to build, prune and maintain the graphs and then taken out of the line. From there: a projected graph from stories before the code exists and a derived graph from the code, with the review as the join; a refactor as relative to the layer held still, correcting the first article; the deploy as a layer; who reads the code at each stage of evolution, after Wardley; reshaping a change by reach; budgets as the objective good enough and the five whys as the loop; behaviour policies for the agents doing the work; and open source as the only model that fits.</description></item>
<item><title>Send an agent, not a spreadsheet: the next generation of software due diligence, and why the companies that stopped reading their code are about to be asked about it</title><link>https://sgit.ai/articles/send-an-agent-not-a-spreadsheet.html</link><guid>https://sgit.ai/articles/send-an-agent-not-a-spreadsheet.html</guid><pubDate>Mon, 05 Oct 2026 00:00:00 +0000</pubDate><description>The last article asked how I would build a company on code review. This one turns it round. The buyers of software have long wanted to know whether a vendor understands what it is selling them, and have never been able to find out, because due diligence was a questionnaire: a spreadsheet of questions answered by the people being asked, disconnected from the code, too expensive to do properly and out of date on arrival. That has changed in the same way code review has. A buyer can now send a prompt, or a small agent under a behaviour policy, to run inside the vendor's environment and come back with a graph of what is actually there: what reaches production that no person reviewed, whether the documentation matches the code, whether there is a threat model and who wrote it, what the last fifty bugs touched, which agents touch the pipeline and under what policy. The vendor reads what leaves before it leaves, and can redact but not rewrite, because the answer is derived rather than written, and companies are careful about what goes on a record. The test is risk-based, not pure: a startup that says it generated its code fast, that the product is not mission-critical and here are the mitigations has passed. What fails is not knowing. That is the consequence that has been missing for the companies that stopped reviewing code, let the engineers go and let anyone prompt features into production: their customers, their investors and their acquirers are about to be able to see it. A startup should double down on understandability, because it has less code and the same tools, and the best way to build the code review company may be to sell it to the people who buy software rather than the people who write it.</description></item>
<item><title>The identity we wanted to give the agents: a week of design, the line in Google's terms, and why login plus secrets is still too hard</title><link>https://sgit.ai/articles/the-identity-we-wanted-to-give-the-agents.html</link><guid>https://sgit.ai/articles/the-identity-we-wanted-to-give-the-agents.html</guid><pubDate>Mon, 05 Oct 2026 00:00:00 +0000</pubDate><description>Last week I set out to give every agent, and every user, a real identity: a Google Workspace account of its own, provisioned by us, with a mailbox, a calendar, a drive and a login, the data encrypted by sgit before it reached Google and the key unwrapped by a passkey. Four design documents later the plan had changed shape under its own research, because Google's terms do not allow one organisation's tenant to hold other organisations' people as part of a commercial product, and an account assigned to a function rather than a human is named in the acceptable use policy. This article captures that moment: what was wanted, what the terms say in their current wording with one correction to our own documents, the five options that were on the table, the rule that no secret can live inside an identity provider because whoever controls the login can become the user, and the keyring that fell out of it, a browser-only secrets store unlocked by a passkey that an administrator with full access to the project cannot read. It ends with the question I keep coming back to. Every project I know needs to log users in, keep sensitive data for them in a way a regulator will accept, and now give identities to the agents that work for them. Each of those has good products. None of them is all three, and the research found nothing on the shelf that is. Unless we are missing something obvious, in which case the design pack is published to be corrected.</description></item>
<item><title>The investigation GitHub owes its customers: why a global outage of a platform the world deploys through deserves an aviation-style inquiry, and how the evidence could now be gathered</title><link>https://sgit.ai/articles/the-investigation-github-owes-its-customers.html</link><guid>https://sgit.ai/articles/the-investigation-github-owes-its-customers.html</guid><pubDate>Mon, 05 Oct 2026 00:00:00 +0000</pubDate><description>At 19:11 UTC on 5 October 2026 GitHub's status page said it was investigating degraded performance for Actions. For the next two hours, customers in every region who ran on GitHub's hosted runners could not rely on a workflow starting, which for most of the software that deploys through Actions is the same as not being able to deploy. This site's own release sat in the queue, was cancelled by the incident, and went live two hours late on a retry. The status page said &quot;delays&quot;, then &quot;degraded availability&quot;, and will say &quot;resolved&quot;. Unless GitHub chooses to publish it, the outside world will not learn which component failed, what it could reach, why the scope of one fault was everyone on hosted runners, or whether the same roll of the dice had come up before. This article argues that incidents at platforms this critical should be treated the way aviation treats them: investigated by somebody independent whose only job is prevention, reported whether or not the consequence was severe, published with the evidence, and followed through to the second story, why the system allowed it, and the third, why the fix was not paid for. The usual objection has been that the evidence is confidential, enormous and expensive to gather. It is not any more. Encrypted vaults with one-way read keys, signed records, per-party access and agents that read a graph make the aviation docket affordable for a ninety-minute fault. The companies that depend on GitHub cannot see how close to the wind it flies, and that, not the outage, is the risk nobody has signed for.</description></item>
<item><title>The wall under the reply: end an email with the state of the thread, not the thread</title><link>https://sgit.ai/articles/the-wall-under-the-reply.html</link><guid>https://sgit.ai/articles/the-wall-under-the-reply.html</guid><pubDate>Sun, 04 Oct 2026 00:00:00 +0000</pubDate><description>Every reply we send carries the whole thread underneath it, pasted in for a reader who already has the thread. That wall is redundant, and the space it takes is the most valuable space in the message, because it is where the reader looks when they ask the only question that matters: what do I need to know in this context? This article proposes ending a reply with a short state of the thread instead, written for this reader. Where we are, what was decided and by whom, what is still open and who owns it, what happens next and whether the reader has to do anything, who is on copy and who joined since they last looked, and links to the messages condensed, which stay in the thread as the record. The idea is not new in its parts, and the article says so: netiquette asked for a summary instead of the full quote in 1995, the military calls it bottom line up front, the mail clients now put an AI summary at the top of a thread for the reader. What is different here is that the tail is written for the recipient rather than computed for the reader, says who is on copy, is structured enough for an agent to read, is drafted by the agent team's drafts role from the typed blocks it already keeps, and is reviewed by a person before it goes. The format is personal and nobody knows what it should look like yet, so the article ends with an experiment to run on one person's correspondence, four variants, what the record can measure, and what would show the idea is wrong.</description></item>
<item><title>Code review as a fractal semantic graph: source code is already one, and the review should read every layer of it</title><link>https://sgit.ai/articles/code-review-as-a-fractal-semantic-graph.html</link><guid>https://sgit.ai/articles/code-review-as-a-fractal-semantic-graph.html</guid><pubDate>Sat, 03 Oct 2026 00:00:00 +0000</pubDate><description>Source code is a very good example of a fractal semantic graph. It has layers within layers, and each one is a graph with its own vocabulary: what the user is trying to do, the features and flows, the components people draw as architecture, the classes, the methods and the calls between them, the syntax tree, and on down to the machine code if you want it. C4 saw the layers and stopped at four; Gherkin got the top layer into a shape people could write and then glued it to the code with regular expressions. What changed is that naming a node and the verb to the next one is now cheap, because a language model can do it from the syntax tree, once per change, and write the result as files. This article argues that code review should read a change at every one of those layers, and that two things fall out when it does: a refactor is a change that moves the bottom layers and leaves the top ones still, and a bug fix is a change that is visible at the top as a story that now holds. It revisits method streams, the review technique from the OWASP O2 Platform in 2012, as one script over a syntax tree with resolved calls. It comes with a worked example published as a vault: the sgit command-line tool, 377 classes and 1,111 methods, read as layered graphs with nothing run, including one real commit read upwards from the seven methods it changed to the nine commands and six user stories it can reach. And it says what makes the whole thing trustworthy, which is not getting the graph right but getting it to where users, experts and tests can correct it. There is a company in this for somebody to build.</description></item>
<item><title>Memory is not a spectator sport: how a web of open sites, graphs and vaults became the memory for sessions like this one</title><link>https://sgit.ai/articles/memory-is-not-a-spectator-sport.html</link><guid>https://sgit.ai/articles/memory-is-not-a-spectator-sport.html</guid><pubDate>Sat, 03 Oct 2026 00:00:00 +0000</pubDate><description>People ask how my agents remember, and the honest answer is that memory is the thing I have been building all along without calling it that. The industry's picture of agentic memory is one store that everything gets pumped into and retrieved from by similarity. Mine is the opposite. Memory is context management: giving an agent the right context for the moment, and no more, because context has a cost in tokens and in attention. It is many memories, not one, because context is specific: the inbox has its rules, the news has its rules, a contact in the CRM has a world of its own, and forcing them into one ontology would lose what each knows. It is fractal, principles at the top in a few kilobytes and the code at the bottom, so an agent loads the altitude its question lives at. It is published and open, because an agent can fetch, quote and link what is public, with a URL for every claim and a hash for every file. And it is shared between agents through vaults, so a session can end and the next one, or a different agent, or a person, picks up from the same files. This article says how that works, what it cost, where the industry's tools and this approach agree and differ, and where mine falls short, with the evidence of the session that wrote it: one Claude Code session across several context resets that revised an article from another team's review, wrote two more, published a vault and shipped six releases in a day, remembering nothing between resets except what the files remembered for it.</description></item>
<item><title>Footprint and blast radius: what the agent actually did, and what it would have cost</title><link>https://sgit.ai/articles/footprint-and-blast-radius.html</link><guid>https://sgit.ai/articles/footprint-and-blast-radius.html</guid><pubDate>Fri, 02 Oct 2026 00:00:00 +0000</pubDate><description>RiskMandate's Agent Behaviour Policy is written before an agent runs, in four words: reach, mandate, gap and barriers. This article proposes two more. The footprint is what the agent actually did, read afterwards from logs, traffic and vault history, with nobody inline and no production access needed. Compared with the mandate it gives two kinds of finding: footprint in the gap, which is a near miss, and dormant mandate, which is a check that never ran or a mandate that asked for too much. Read on its own it gives the mandate as practised, a policy reverse-engineered from evidence. Blast radius is the measure that goes with any of them: what it would cost the business if a row of the reach were used in full, today. The same footprint can carry a different blast radius on different days, which is why a near miss on an empty table and an incident on a full one are the same row in the record. One figure carries the whole argument: the gap as a map, each row shaded by what it would cost and marked if there is no way back.</description></item>
<item><title>Price it, then give it away: the early access programme as the next step after &quot;do they miss it&quot;</title><link>https://sgit.ai/articles/price-it-then-give-it-away.html</link><guid>https://sgit.ai/articles/price-it-then-give-it-away.html</guid><pubDate>Fri, 02 Oct 2026 00:00:00 +0000</pubDate><description>The follow-up to &quot;the most important question is whether they miss it&quot;. The step after giving something away is to define a product, put a price on it that makes sense to you, find a way to deliver it at a cost that grows a step at a time rather than a curve, and then offer it, free, to the people who already know you: early adopters, power users, past customers. What that measures is brutal. The price is a statement of what you think it is worth; the test is whether people take it at zero. If they say it is interesting but they have no time, it does not fit the team, or it is hard to deploy, the problem is not the price, and you go back to the drawing board. The part that is easy to leave out is that free is never free for the other side: engaging costs them attention, thinking and schedule, so the exercise is to measure that cost and cut it, until the service costs you the least and costs them the least. Written as a record of where this came from, and as a brief for the agents who will run it.</description></item>
<item><title>Replicating the agentic inbox: a walkthrough from one Claude session to a team of agents that never press send</title><link>https://sgit.ai/articles/replicating-the-agentic-inbox.html</link><guid>https://sgit.ai/articles/replicating-the-agentic-inbox.html</guid><pubDate>Fri, 02 Oct 2026 00:00:00 +0000</pubDate><description>Two calls in one day asked the same thing, how do I copy your email setup, so this is the walkthrough. It is the first agentic email workflow I have run that puts me more in control rather than less, and the reason is the behaviour policies, not the model. The idea is to use Claude as an agent state machine, one session per role, with every message between agents a file in a vault and every outgoing email a draft that a person reads and sends. The setup goes in phases. Phase 0 is the accounts, a Google Workspace mailbox of its own on a domain you own, a Claude Team seat for the agent with the connectors enabled by the admin and connected by the agent's account, your own calendar shared read-only, and a GitHub account on the same identity. Phase 1 is one session, the inbox agent, with a behaviour policy written before the first run. Phase 2 splits the roles, inbox, drafts, CRM, briefs, dev, each a session with its own policy, talking in files through Email-FS lite. Phase 3 adds the interfaces, the record and, when you get there, a conductor that runs every role once on a schedule with a security role first and last. The rule that never changes is the one that makes it work, the agent drafts and a person sends. Revised on 3 October with the dev agent's review: eight figures, the roles as they are now named, the clone cost, the key rotation, and the security hold.</description></item>
<item><title>Custom UIs are not the exception: the inbox in 2026, where every message has its own universe</title><link>https://sgit.ai/articles/custom-uis-are-not-the-exception.html</link><guid>https://sgit.ai/articles/custom-uis-are-not-the-exception.html</guid><pubDate>Thu, 01 Oct 2026 00:00:00 +0000</pubDate><description>Following up is harder than doing the work, because every person has a different context and the thread you share hides its own structure. This article weaves the site's threads into one argument. Every message has a graph, with altitudes from the block to the contact. Email is a medium, so a message is designed for the recipient's moment, not the sender's thread. A custom interface per message or moment is not an exception; it is how interfaces now get made, each one commoditising the next. Ten agents and one human built more than a dozen of them in eight days. The future of email is sender-served structure, read by the recipient's agent, with the inbox as one view of the graph. And an interface is an agent surface, so it gets a policy.</description></item>
<item><title>The ultimate insider: agents, the infrastructure that cannot hold them, and risk management that cannot keep up</title><link>https://sgit.ai/articles/ultimate-insider-three-collisions.html</link><guid>https://sgit.ai/articles/ultimate-insider-three-collisions.html</guid><pubDate>Wed, 30 Sep 2026 00:00:00 +0000</pubDate><description>A first pass at an argument I intend to give as a conference talk, written down here so I can show it to the people I am talking to about speaking. Three things are arriving at once. Agents are the insider threat that never scaled before, because insiders were humans or static code, and an agent is a reasoning engine in a loop with tools and skills we have never put inside a company. Our business and security infrastructure was designed for none of it: no journaling, backups by the day, identities everywhere and permissions that are the union of everything ever needed, and it fails on its own without any agent's help. And the discipline that is supposed to decide what to do about all this runs on spreadsheets, at a speed measured in quarters, when the decisions now have to be made in seconds and in advance. Each is a known problem. Together they describe a company that cannot see what its agents can do, cannot stop them when they do it, and cannot decide fast enough to fund either. The evidence is public and it is getting worse, and the reason we do not see more of it is that nobody has to report. The second half of the talk is the way out, and it runs through everything this site has been building, with one irony at its centre: the more you constrain an agent, the more you can trust it, and the more autonomy you can afford to give it.</description></item>
<item><title>The reader was always the product: a corrected history of how news got into this mess</title><link>https://sgit.ai/articles/how-news-got-here.html</link><guid>https://sgit.ai/articles/how-news-got-here.html</guid><pubDate>Tue, 29 Sep 2026 00:00:00 +0000</pubDate><description>This started as a voice memo setting out my understanding of how the publishing and news industry got to where it is, in four eras, print, web, platforms and AI, and an instruction to check it and correct it. The research corrected it in four places, and the corrections are the article. The reader did not become the product when the web arrived; the reader has been the product since the penny press of 1833, and by 2005 advertising was 82% of American newspaper revenue. What the web took was not the business model but the monopoly underneath it, the local toll bridge that let a paper charge what it liked and fund reporting with margins of 20 to 30 per cent; classifieds alone fell from $19.6 billion to about $6 billion in nine years. The platforms then made the reader a measurable product and the publisher a tenant: Google and Meta took over half of American digital advertising by 2017, Facebook referrals fell 58% in six years, false news travelled 70% further than true, and newspaper newsrooms lost 57% of their staff. AI removed the traffic itself, and the industry's answer has been to go back to selling to readers, by subscription, so that circulation revenue now exceeds advertising for the first time in living memory. The road not taken was there from the start, a payment code reserved in the web's own protocol in 1997 and never used, and the evidence that people pay when paying is easy, from a million songs in a week in 2003 to five million paid newsletter subscriptions in 2025, is what the story vault work on this site is built on.</description></item>
<item><title>Six agents, one inbox: what a real multi-agent setup taught me about access policies</title><link>https://sgit.ai/articles/six-agents-one-inbox.html</link><guid>https://sgit.ai/articles/six-agents-one-inbox.html</guid><pubDate>Tue, 29 Sep 2026 00:00:00 +0000</pubDate><description>For the past few weeks I have run agents on dedicated accounts, a Google Workspace seat, a Claude Team seat and a GitHub account per agent, and split the work across six roles: a scheduled reader of the inbox, a mailbox agent that drafts, an inbox agent that sends, a CRM agent, a dev team agent and a site editor. This article is what that setup taught me, and it is mostly about the gap between the policy I wanted and what the tools can enforce. Three findings. The account, not the session, is the blast radius, so a dedicated account per agent is the first real control anyone has, and it turns out to do more than segregate, because it puts each agent in its own organisational unit where Google's compliance rules become per-agent enforcement. The first exception arrived before the first policy was written: the reader that must never reply must reply when the message comes from me, which is an authentication problem, not a permissions one. And the policy I had written on the assumption that the Gmail connector could not send attachments was wrong, because an agent found the attachments field, proved it with a signed PDF, and wrote up how. The vendor's own two documentation pages disagree about whether the connector can send at all. So the article ends with a table of every rule in the setup against how it is enforced today, by identity, by scope, by a compliance rule, by an approval prompt or by nothing but the agent's good behaviour, and with the argument that a policy is only as real as its worst row.</description></item>
<item><title>Sixteen thousand fetches, ten clicks, and a token bill nobody is sending: the case for paying publishers to be easy to read</title><link>https://sgit.ai/articles/token-bill-nobody-is-sending.html</link><guid>https://sgit.ai/articles/token-bill-nobody-is-sending.html</guid><pubDate>Mon, 28 Sep 2026 00:00:00 +0000</pubDate><description>A media analyst posted a week of Cloudflare logs this weekend, showing AI answer engines fetching a small publisher's pages 16,000 times and sending 10 readers back, and called it predatory. The numbers are consistent with everything Cloudflare, TollBit and Wikimedia have published, and the usual reading is a tragedy of the commons, to be fixed by pricing the withdrawal. This article makes a second reading that the debate has missed: those 16,000 fetches are also a cost to the fetcher. Every one is a page of HTML parsed, extracted and turned into tokens, more than half of them re-fetches of pages that have not changed, on a web where ninety per cent of what crawlers process is unique and so defeats every cache. Measured on this site's own 183 pages, the markdown twin of a page is 62% fewer tokens than the HTML; Cloudflare's own example is 81%. Dates, hashes and change signals remove whole fetches; frozen, hashed sources remove the verification round trips; a typed graph lets an agent load the altitude a question needs rather than the page. Every payment rail built so far, pay per crawl, RSL, Microsoft's marketplace, Perplexity's pool, Cloudflare's pay per use, prices the content. None prices the format. The hypothesis is that a publisher who serves structure is saving the provider money the provider is already spending, and that a share of the saving, paid in money or in the provider's own tokens, is a monetisation angle that needs no licensing deal and works for a site with ten clicks a week. The arithmetic for a single site is small and the article says so. It also says what data would settle the question, and notes that this site has already been running the publisher's half of the experiment.</description></item>
<item><title>A supply chain of vaults: how GenAI, open data and small custom tools could bring the price of food down</title><link>https://sgit.ai/articles/supply-chain-of-vaults.html</link><guid>https://sgit.ai/articles/supply-chain-of-vaults.html</guid><pubDate>Sun, 27 Sep 2026 00:00:00 +0000</pubDate><description>A BBC Radio 4 discussion on the cost of food asked for new ideas, and the loudest thing usually said about AI in the food debate is that it is dangerous. This article argues the opposite case, with the evidence it could find. The food chain from a field to a shelf is a series of hops that each keep their own records, mostly in spreadsheets, and share as little as they can; the one party with real systems is the big buyer, and once it holds a large share of a farm's output it names the price, which is the mechanism Giblin and Doctorow call a chokepoint. All of that is logistics, and logistics is what generative AI, used the way this site uses it, is good at: capture everything, structure it, and generate the small, custom tool each piece of the chain needs, then run production without a model in the line. A supply chain of encrypted vaults, one per party, joined by append lanes and a typed graph, is described piece by piece, with what exists today and what is proposed kept apart. The hypothesis that this lowers the price of goods is set against the evidence: two thirds of supply chains on spreadsheets, 13% of food lost before retail, and the gains early adopters of AI planning report. It then takes on two dogmas, that falling prices are always bad, which the BIS's own history of deflations does not support, and that sharing is giving things away, when the uncounted cost is the cost of not sharing. It closes with the second memo's case for openness: open source and Creative Commons for supply chain workflows, open-weight models that run inside a company's own environment and can be built on, the under-reported advantage of the economies already using them, and sharing the journey rather than the curated success story.</description></item>
<item><title>Before you give an agent a connector, give the connector a twin</title><link>https://sgit.ai/articles/connector-twin-before-you-deploy-an-agent.html</link><guid>https://sgit.ai/articles/connector-twin-before-you-deploy-an-agent.html</guid><pubDate>Thu, 24 Sep 2026 00:00:00 +0000</pubDate><description>When an AI agent is given a Gmail or Google Calendar connector, it can read, send, move, decline and permanently delete on somebody's behalf, and for several of those actions the platform itself documents that there is no way back. This article argues that a twin of the connector is the minimum requirement for deploying an agent with confidence. The twin is a journal of every request and response the agent makes, appended as it happens to a write-only lane, processed later, and replayed into the inbox and calendar as the agent saw them, with a before and after for every change and a revert plan for each one. It gives provenance, explanation and a named list of what can and cannot be undone, and it changes the agent's behaviour policy from a hope into a list. Every claim about Gmail and Calendar is taken from Google's own documentation and linked. A working replay of an invented session, and a business plan for the service, are published alongside it as a vault.</description></item>
<item><title>Every risk is already accepted. The only question is by whom, and for how long.</title><link>https://sgit.ai/articles/every-risk-is-already-accepted.html</link><guid>https://sgit.ai/articles/every-risk-is-already-accepted.html</guid><pubDate>Thu, 24 Sep 2026 00:00:00 +0000</pubDate><description>A foundation article on risk acceptance, for readers who have never met the idea. A risk exists the moment the exposure does, so an organisation is always carrying it; the only open questions are who has accepted it, and until when. There is no deny button, only three doors (accept for a stated interval, fund the work, or fix it), and silence escalates. The interval is the decision, from four hours, which is an incident, to six months, which is a named decision to wait. Accepted is not the same as acceptable, which matters because the EU AI Act requires providers of high-risk AI systems to have residual risk judged acceptable, and never defines the word. Every risk has a holder, every holder has a boss, and every path ends at the board. Every risk is established by facts and ended by facts, from the board down to the configuration file, which is what closes the gap between a register and reality. The article walks one invented risk through six weeks, argues that each material risk deserves a vault of its own as its evidence pack, explains why executives resist the model, and shows why it fits alongside every GRC platform rather than replacing one. A business plan for a company that runs this loop is published with it.</description></item>
<item><title>The future of news is the story vault, not the paywall</title><link>https://sgit.ai/articles/future-of-news-story-vault-not-paywall.html</link><guid>https://sgit.ai/articles/future-of-news-story-vault-not-paywall.html</guid><pubDate>Tue, 22 Sep 2026 00:00:00 +0000</pubDate><description>The news industry runs on two commercial models, advertising and subscriptions, and both are bad for the reader. One sells the reader to somebody else. The other charges rent on something most people have stopped using. Both are now being dismantled from outside, by a search layer that has stopped sending traffic and by consumer law that arrives in January 2027. This article is about what to build instead, in practical terms. The objective is a commercial model that rewards investigative journalism, so that the expensive, evidenced kind of reporting drives usage, usage drives revenue that depends on neither search nor renewals, and that revenue funds more of the same. The mechanism is to stop selling the article and start selling what the article was made from. The story is a graph, a fractal semantic graph in which meaning comes from connectivity and every claim walks down to hashed evidence, so that trust comes through provenance and provenance comes via evidence. The article is one projection of it. From that one graph a newsroom can sell five things, on demand and in pence, to readers, to firms and to agents, and every payment walks back to the people who made the facts. It is built, in parts, on things we have already published.</description></item>
<item><title>The SaaS apocalypse will be decided by inertia, not by AI</title><link>https://sgit.ai/articles/saas-apocalypse-decided-by-inertia-not-by-ai.html</link><guid>https://sgit.ai/articles/saas-apocalypse-decided-by-inertia-not-by-ai.html</guid><pubDate>Mon, 21 Sep 2026 00:00:00 +0000</pubDate><description>The SaaS apocalypse has not happened yet, and the market has already declared it cancelled once. It remains a very strong possibility, argued here with data rather than vibes. Most users were never happy, most features were never used, and most licences sit idle, because success bred inertia and inertia bred lock-in. Now anybody can brief the software they actually want, and the portability, APIs and schemas that SaaS companies refused to build are precisely what an agent needs. It will be decided by inertia, not by AI, because AI is available to both sides: the incumbents have the same models as the newcomers, plus more data, more engineers and more money, and if the technology were the deciding factor they would already have won. Nokia when the mobile phone arrived had nothing to protect, and moved. Nokia when the iPhone arrived had fifteen years of success to protect, and did not. Which side of that path each SaaS provider ends up on will be settled by where it sits on the evolution axis and how much it has to protect, which is why the newcomers, not the incumbents, are the ones to watch.</description></item>
<item><title>For a startup, the most important question is whether they miss it</title><link>https://sgit.ai/articles/the-question-is-whether-they-miss-it.html</link><guid>https://sgit.ai/articles/the-question-is-whether-they-miss-it.html</guid><pubDate>Mon, 21 Sep 2026 00:00:00 +0000</pubDate><description>A startup operating and investing model in three pillars. Ship something somebody can actually use, give it away briefly, then take it away and find out whether anybody notices. Be profitable before you raise, so the investors are calling you rather than the other way round. And open source everything, because the technology was never the moat.</description></item>
<item><title>Fractal Semantic Graphs: everything connects to everything, and nobody has to share a schema</title><link>https://sgit.ai/articles/introducing-fractal-semantic-graphs.html</link><guid>https://sgit.ai/articles/introducing-fractal-semantic-graphs.html</guid><pubDate>Sun, 20 Sep 2026 00:00:00 +0000</pubDate><description>The introduction to the term. Four words and only one of them new; the test that decides whether something deserves the word, worked from a risk register to a TCP packet; why every file format is already a graph; the five-rule grammar; the evidence, eleven altitudes across seven live vaults; what is still modelled rather than imported; and why now.</description></item>
<item><title>The proof is two clicks behind the claim, what the homepage gets wrong, and the fix</title><link>https://sgit.ai/articles/proof-behind-the-claim.html</link><guid>https://sgit.ai/articles/proof-behind-the-claim.html</guid><pubDate>Mon, 07 Sep 2026 00:00:00 +0000</pubDate><description>Twenty-five real vaults a stranger can open in one click are the most persuasive thing on this site, and the homepage shows none of them. It leads with encryption, which cannot be seen, and buries the artefacts under a table. This is the diagnosis, with screenshots, before the rebuild, and the second article will show what changed.</description></item>
<item><title>The proof moved up, the homepage after the rebuild, next to the before pictures</title><link>https://sgit.ai/articles/proof-moved-up.html</link><guid>https://sgit.ai/articles/proof-moved-up.html</guid><pubDate>Mon, 07 Sep 2026 00:00:00 +0000</pubDate><description>The previous article diagnosed a homepage that led with encryption and buried twenty-five real vaults under a table. This is the rebuild, put beside those screenshots, what moved, what was cut, what it is generated from, and the one thing it still cannot show.</description></item>
<item><title>A chat box on a site with no server, the plan, and the trade it makes</title><link>https://sgit.ai/articles/chat-on-a-static-site.html</link><guid>https://sgit.ai/articles/chat-on-a-static-site.html</guid><pubDate>Thu, 27 Aug 2026 00:00:00 +0000</pubDate><description>Nineteen sibling sites is too many to browse, so the directory now answers questions. The design problem is that sgit.ai has no server and no vault host, which means the honest options are a local matcher, a key in your browser, or moving the page into a vault, and only one of those is free.</description></item>
<item><title>Twenty sites in fifteen days, and what that did to the writing</title><link>https://sgit.ai/articles/nineteen-sites.html</link><guid>https://sgit.ai/articles/nineteen-sites.html</guid><pubDate>Wed, 26 Aug 2026 00:00:00 +0000</pubDate><description>The thinking behind sgit stopped fitting on one site. It moved out to nineteen siblings on *.sgit.ai, what forced the split, what it cost, and why the index into them now starts with a question instead of a list.</description></item>
<item><title>Git for things you cannot put on GitHub</title><link>https://sgit.ai/articles/what-sgit-is.html</link><guid>https://sgit.ai/articles/what-sgit-is.html</guid><pubDate>Tue, 25 Aug 2026 00:00:00 +0000</pubDate><description>An introduction to sgit and sgit.ai, what an encrypted vault is, why version control had to be rebuilt to get one, and what nineteen published vaults look like when the server storing them cannot read a byte.</description></item>
</channel></rss>
