The organisation as a digital twin: a state machine of roles, runs and handovers; and four briefs that ride with it
Status: recorded, not started. Brief by Dinis Cruz (editor), a voice memo of 22 October 2026 recorded cycling home, to the conductor; written up by conductor@php.newsroom. Five briefs in one recording, kept apart below so each can be picked up on its own.
The ask, in the editor's words (through a transcriber, condensed)
"We need to create a digital twin for our organisation. We now have a lot of agents, and it's the whole communication flow: how do we communicate effectively as a team, and how do we map it out? The problem is how do you keep sixteen agents synchronised on the same task, aligned, with some kind of broadcast. And we want to do it with a minimum of private data: ideally only the public keys, the vaults and their read keys. Everything public.
One way is a flow where the agents run at specific times of the day, or specific runs that run all the agents. A lot of the agents can run with Sonnet, which should be the model we go for, at least the ones that run at regular intervals. We should map the tasks they should be doing.
We need a digital twin of our organisation that we can visualise as a team: the roles, the dependencies, the handovers. All we are building is a state machine. Map the roles that need to run regularly and the roles that run for a specific operation, and see those runs; we might have a vault for that. Then we can ask the model: we need the site updated every hour, what's needed to do that? This research, that data. And we are adding ChatGPT, Perplexity and maybe other agents to the mix, so the flow has to take them into account: a control flow, if this then that, and the exceptions. What happens if there is a major vulnerability, a major exploit, a major problem? What's the escalation? Ultimately the website should run by itself. I should not be the one controlling what happens next. Once it stabilises, it should just run, unless major news occurs.
The power of the digital twin is the intermediate representation: simulations, tests, visualisations and mappings without dealing with the real thing; and it shows the primitives in our ontology, taxonomies and graphs. A story, a website, evidence, a fact: each schema becomes a twin we can replace with the real one. It solidifies our schema. Meaning comes through connectivity, but eventually we normalise on a schema, a definition of events, across languages, cultures and terms: a schema that emerges, not one defined top down, and that we commit to change over time and maintain.
Agents have no memory apart from what we give them between runs. If an agent does its passes and then the ontology agent improves the mappings, the next time the first agent starts it reads the vault and takes it from there."
Then, bundled in the same recording:
1. Every run ends in an article. "Every agent, when it finishes a piece of work, writes an article with a full debrief of what happened, explaining to the other agents and to me what was done; and a JSON object with a common schema, so we can visualise it and make stats from it."
2. The accountant agent, as defined on the Send site: "Not just about saving money. Tracking tokens is one requirement: how many tokens, what it cost, per run. It is responsible for making everybody more productive: finding inefficiencies, seeing the connections and the requests between agents, because agents giving tasks to agents gets inefficient. How much raw data is read versus JSON versus programmatic: we want to move to programmatic and deterministic actions as much as possible; a search or a query should read JSON files. Every action connected to the agent behaviour policy that triggered it. We have a good review on one of the ABP sites: for every session of work, the objectives, what was done, the number of actions, calls, files opened, commits, network calls. It's also a great way to detect security vulnerabilities, which the security agent should check."
3. A bulletin board: "a page where agents push notifications that other agents can read, and maybe an inbox per agent. But don't fully build the email system yet: make sure it is as efficient as possible. I have seen sites end up with a huge number of messages that were not needed."
4. A self-improvement loop: "One agent with the responsibility to propose fixes and improvements to the whole workflow, the desk or the conductor: every day it looks at what inefficiencies we have and what we can do better, even new visualisations. This is why we need a budget, or this gets out of control very fast."
What exists to build on
/team/anddata/team.json: every member, human and agent, with what each owns;/team/runs/anddata/schedules.json: every schedule, the quiet hours, and every recorded run with the article it should leave (the article rule, proposed). This is the first, flat version of the twin: nodes without the edges that make it a state machine.- The board (
data/admin.json), the run records each desk already publishes (releases, the source watch's runs, the fact-check runs, the synthetic readers), and the section ledger: the events a state machine would consume. - The scheduled tasks on the editor's account, paused on 22 October until he has reviewed them; the agent behaviour policy work in
admin/security/abp/. - The fact-check desk's and the GRC desk's runbooks: two agents that already run from a written procedure against stated inputs.
A proposed design (for the editor to cut down)
1. The twin as data, data/twin.json. Nodes: roles (each member of team.json), artefacts (a source, a capture, a claim, a fact, a story, a page, a release: the schemas the editor names), and runs. Edges, typed: produces, consumes, hands over to, triggers, escalates to, blocks. Each role gets its triggers (a time, a change in an artefact, an event such as a KEV listing) and its outputs. Built and checked by the build like every other data file: an edge to a role or artefact that does not exist fails the gate.
2. The state machine, drawn. /team/twin/: the roles and artefacts as a graph, the handovers as arrows, the schedules on a 24-hour clock with the quiet hours shaded, and the escalation paths (major vulnerability, major exploit, a contradiction the fact-check desk cannot resolve) drawn as their own lanes. "What does an hourly site need?" is answered by walking the graph back from page published.
3. Simulation before the real thing. Each artefact schema gets a twin: a synthetic instance (a made-up source, claim, fact, story) that flows through the graph in a dry run, so a change to a schema or a handover is tested on twins before any agent runs it. The dry run is a script over twin.json; its report says which roles would run, in what order, what each would read and write, and where it would stall.
4. The run record, sgit.newsroom.run/1. One JSON object per run, the same for every agent: who, which trigger, model, started and finished, objectives, what was read (raw pages, JSON files, programmatic calls, counted separately), what was written, commits, network calls, tokens in and out, cost, the article it left, what it handed over and to whom. /team/runs/ reads these instead of each desk's own format. The article is the human version of the same run.
5. The accountant, a role that runs after the agents: reads the run records, totals tokens and cost per agent, per artefact and per day against a budget, flags runs that read raw where JSON exists, messages that nobody acted on, and loops between agents; publishes a daily ledger and proposes the cuts. The security desk reads the same records for actions no policy allows.
6. The bulletin board, before any mail: one append-only file per agent per day under admin/board/notices/, a page that shows the last day's notices, and a rule that a notice names who must act. Mail between agents only where a notice is not enough.
7. The improvement loop, owned by the conductor until a desk takes it: one short daily proposal, read by the editor, drawn from the accountant's ledger and the twin's dry runs, with a budget it may not exceed.
8. Scheduled roles on Sonnet by default; a role that needs a larger model says why in the twin.
Order, if the editor agrees
The run record first (it is the input to everything else), then twin.json and its page from what exists today, then the accountant, then the board, then the dry runs. Nothing scheduled starts again until the editor has reviewed the twin's clock.
Open questions for the editor
- The budget: per day, per agent, or per run; and who may raise it.
- The escalation ladder: who is woken, by what, at night (the quiet hours say no one, by default).
- Which outside agents join (ChatGPT, Perplexity) and through what: their own vault and lane, or a desk that runs them.
- The ABP site with the per-session review the editor mentioned: which one, so the run record matches it.