# Your own newsroom: what changed in v1.1.0, sgit.ai > The changes to the article "Your own newsroom" in v1.1.0, paragraph by paragraph. *Source: · sgit.ai v0.7.87 · this file is generated from the same content as the page, so the two cannot drift. Every page on this site has a `.md` twin; internal links below point at them.* --- [Home](../../../index.md) / [Articles](../../index.md) / [Your own newsroom](../../your-own-newsroom.md) / [Versions](../your-own-newsroom.md) / v1.1.0 # Your own newsroom: what changed in v1.1.0 From v1.0.0 (2026-10-15, `97c691038`) to v1.1.0 (2026-10-15, `b4d872995`), paragraph by paragraph. 18 paragraphs added, 0 removed, 0 changed in place, 51 unchanged. About 1,079 words added and 0 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names. [all versions](../your-own-newsroom.md) 9 unchanged paragraphs, under In short {#in-short} • **A behaviour policy runs the agents.** From the privileges they get to how often you publish and in what tone. • **Writer, editor, publisher.** Separate agents, separate grants, enforced by prompt or by hook. • **A private vault beside the public site.** Drafts, data and guidance stay encrypted; only the final text is published. 32 unchanged paragraphs, under Why a founder needs one {#why}, What you need {#need}, Step by step {#steps}… ## A behaviour policy for your agents {#policy} The house rules are a start. The next step is to write them as an [Agent Behaviour Policy](https://abp.sgit.ai/what-is-an-abp/index.html): a versioned file that says what the agent is given, what it is for, and what it must not do, with each rule marked by what keeps it. It does two jobs at once, and both matter for a founder. The first is security. An agent that publishes for you needs real privileges: it can push to your repository, which means it can publish anything to your site. The policy is where you write down exactly what it is granted and what it is not: push to the one repository, never to another; publish from the main branch only after the checks pass; never hold your Stripe keys; never commit a key, a password or a client's name. [A policy beside the prompt](../../a-policy-beside-the-prompt.md) argued that every agent should take one as an input, and [the policy draws the liability line](../../the-policy-draws-the-liability-line.md): what the agent was allowed to do is what you are accountable for. The second is the business logic, and this is where it becomes yours. A behaviour policy is not only a security control; it goes all the way down to how you want the work done. You can write that you do not want more than one post a day; that the tone is warm, plain and first person; that every claim about a client needs their written permission; that nothing goes out on a Sunday; that every article ends with what it does not claim. These are the instructions you would give a new member of staff, written once, in a form an agent can follow and a person can check. [Commander's intent is a behaviour policy](../../commanders-intent-is-a-behaviour-policy.md) makes the same point from the other end: say what you want achieved and the limits, and let the agent work inside them. ```markdown # Behaviour policy: my site (v1.0) ## Grant - Push to github.com/me/my-site, branch main. Nothing else. - Read my drafts vault. Never write to it without asking. ## Mandate - Turn my voice memos into articles in my voice, check them, publish them. ## Rules [barrier: expectation = the agent keeps it, setting = a hook keeps it] 1. At most one new article a day. [setting: pre-push hook] 2. Every fact has a source link; correct my memo where it is wrong. [expectation] 3. Tone: warm, plain, first person; British spelling. [expectation] 4. Never publish a client's name without written consent. [expectation, checked by the editor] 5. Leak scan before every commit: no keys, no client data. [setting: pre-commit hook] 6. Every release is built and validated before it is pushed. [setting: CI] ``` It also lets you split the work, as this site does, across more than one agent. A **writer** turns the memo into a draft; an **editor** checks it against the rules, the sources and your voice, and can send it back; a **publisher** is the only one granted the push, and only for drafts the editor has passed. Each has its own section of the policy and its own grant, so the agent that writes cannot publish on its own, and the one that publishes cannot invent. This newsroom works the same way, with named agents for writing, the wire and the design, each with its own page; [the agents write too](../../the-agents-write-too.md) describes them. The policy is enforced in two ways, and the difference is worth knowing. The simplest is the prompt: the policy is read at the start of every session and summarised on every prompt, which is how this site's own writing session works, under a policy of eleven rules that is re-read after every summary and reports its status every few answers. That keeps the rules in view, but it is still the agent keeping them. The stronger way is a hook: a small program the agent's environment runs before and after each action, which blocks a push on a second article in a day or a commit that contains a key, whatever the agent intended. [Are hooks the sweet spot?](../../are-hooks-the-sweet-spot.md) moved this site's own policy into hooks, rule by rule, and more than half of its rules could move. Mark each rule by which of the two keeps it, and you know which ones to trust. ## Further: a private vault beside the public site {#vault} A more advanced setup keeps everything that should not be public out of the public repository altogether. The repository holds what is published. Beside it, an [sgit](https://sgit.ai/) vault holds the rest: drafts you are not ready to show, transcripts of the interviews the agent ran with you, the data an article was built from, notes about clients, the guidance and examples you want the agent to learn your voice from, and the agent's own working files. A vault is encrypted on your machine before anything is uploaded, versioned like git, and opened only with its key, so the server that stores it cannot read it. The workflow stays the same, with one more step. The agent session clones the vault with a key you give it through the environment, never in a file in the repository; it writes the draft and its working material into the vault; the editor reads it there; and only when an article is approved does the publisher copy the final text into the public repository. Nothing private ever touches the public history. This is how this site's own writing session keeps its working material: scripts, figures, measurements and reviews in a vault of its own, while only the articles reach the site. And because a vault can publish a read-only key on purpose, you can choose to share a single folder, a data set behind an article, say, without sharing the rest. [Agent workflows on ephemeral vaults](../../agent-workflows-on-ephemeral-vaults.md) goes further, with seven architectures from one agent to a swarm. 7 unchanged paragraphs, under What it is like to run {#running}, What this does not claim {#limits} • **A rule in a prompt is a hope.** Only the rules a hook or CI keeps are enforced; mark which is which. • **Updated on 15 October.** Added the behaviour policy and the private vault. 3 unchanged paragraphs, under Where this comes from {#sources} [all versions](../your-own-newsroom.md) --- *[Site index for agents](../../../llms.txt) · [HTML version](https://newsroom.sgit.ai/articles/versions/your-own-newsroom/v1.1.0.html)*