The third engine. Product and content both run on context, and most of what a team learns, in meetings, user research and surveys, never reaches the place the work happens. This loop writes it down, files it where the work lives, and brings it back the next morning.
Four movements again. The raw material is what the team learns, from a meeting to a round of user research to a survey: capture it, organize it, run the day from it, and review what stopped.
Select a step to see how it works.
From what the team learns to owned work
Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.
Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.
The main path
Context, feedback, or a rule
A shared store
What the loop produces
The step described below
Selected step
Governance
What it is
The written rules for who may change the record, and how.
How I run it
Humans own git; agents only write files. An agent can draft a note, move a to-do or propose a change. Whether any of it becomes part of the record is a person's decision.
01Capturemeetings, user research, findings and surveys
What it is
Getting what the team learns into a form the rest of the loop can read: what was decided in a meeting, what user research turned up, what a survey showed, and the findings that come out of any of them.
How I run it
Meetings are recorded and transcribed when everyone in them agrees; some never are. User research, findings and survey results go into the same record rather than a research folder nobody opens. Nobody is on note duty, and nothing depends on somebody remembering.
02Ingestionrecords, and one to-do per owner per action item
What it is
Turning raw input into structured records that a person or a program can act on.
How I run it
For meetings it is automated: a job turns each transcript into notes and atomic to-dos in per-project folders, one file per owner per action item, with deterministic ids so a rerun changes nothing. A research or survey finding gets the same shape: filed by project, with the action it implies given one owner.
03Classificationproject tags, blockers, and misfiled items moved
What it is
Deciding where each record belongs and what state it is in, so nothing waits in a pile marked miscellaneous.
How I run it
Project tags are inferred, each item is classified, and blockers are detected from the words people use: waiting on, blocked by, owes. A reclassifier re-scores misfiled items and moves them so git records a rename, and it refuses to downgrade a real project to the catch-all.
04The vaultnotes, decisions and specs in one place, in git
What it is
The single source of truth: notes, to-dos, decisions and specs in one store, versioned in git. The same store the product and content engines read.
How I run it
Every recurring job that touches it has a written spec with an explicit must-not list. The sync from the vault into the knowledge base never touches the vault, never pushes to main and never auto-merges.
05Shared accessthe team and its AI tools read the same record
What it is
Everyone who needs the record can read it, including the AI tools they work with, without a copy drifting somewhere else.
How I run it
A read-only server over the vault, on a private network, lets teammates and their LLM tools query the same brain. Read-only is the point: the team gets all of the context, and the record keeps one way in.
06Daily briefingopen items, yesterday's meetings, and the numbers
What it is
A generated summary of what is open, what changed and what the numbers say, ready before the day starts.
How I run it
Every morning a briefing assembles the open items, yesterday's meetings and the metrics, which sync from analytics into daily, weekly and monthly files. The first thing anyone reads is the state of the work.
07Gap finderwhat silently stopped, surfaced a few times a day
What it is
A monitor for the automation itself: it looks for work that should have happened and did not.
How I run it
A few times a day it inspects the schedules and the tools and surfaces what silently stopped. A pipeline that fails loudly gets fixed. The one that quietly stops running is the expensive kind, because nothing tells you.
08Decisionsa person makes the call, and it is written back
What it is
The call a person makes on the work the loop surfaced, recorded with its reason.
How I run it
Every piece of work has one owner and a stage, and anything that reaches a public surface waits at a gate. In my own practice the review before the gate is a separate automated auditor that never did the work, and the gate itself is my approval. A rejection is logged with its reason.
↺ What gets decided goes back into the vault and onto the next morning's briefing, so the next meeting, research round or survey starts where the last one ended.
Underneath all of it
Governance
The written rules for who may change the record, and how.
Most of what a team learns never reaches the place the work happens. What was agreed in a meeting, what users said in a research session, what a survey turned up, the reason a date moved: it stays in a call, a slide deck or somebody's head.
So all of it counts as input. Meetings are recorded and transcribed when everyone in them agrees, and some conversations are never recorded at all. User research, findings and survey results go into the same record instead of a separate folder nobody opens. None of it is the product. It is raw material for the next stage, worth keeping only because something reads it on the team's behalf.
One to-do per owner per action item
Whatever the source, the record takes one shape: filed by project, with each action it implies given exactly one owner. One file per owner per action item, so an item can be closed without editing anyone else's.
Meetings are the part that is automated. An ingestion job turns each transcript into notes and atomic to-dos, and its ids are deterministic, so running it twice on the same transcript is a no-op. That matters more than it sounds. A job that is safe to re-run is a job somebody will actually re-run on the day it breaks.
What gets filed is a proposal, not a commitment. The owner on an item is a reading of who should do it, from a transcript or from a finding, and that reading can be wrong, so the file is where the discussion about the item starts rather than where it ends.
Tools
Fireflies records and transcribes the meetings
Git versions the folders, so a moved item shows up as a rename
Output
Notes, and one to-do file per owner per action item, in per-project folders
Check
Deterministic ids, so a rerun on the same transcript changes nothing and a partial run can simply be run again
Two
Organize
File it where the work lives
Each item gets a project tag and a class, and blockers are detected from the words people actually use: waiting on, blocked by, owes. A blocker that is written down is one somebody can clear.
Misfiled items are the slow failure of any filing system. A reclassifier re-scores them and physically moves them, so git records a rename rather than a copy, and it will not downgrade a real project to the catch-all, because the catch-all is where items go to be forgotten. The index rebuild is deterministic, so two runs always agree.
The vault holds the rules as well as the work
Notes, to-dos, decisions and specs sit in one store, versioned in git. It is the same source of truth the other two engines read from, which is how a decision from a meeting, or a finding from user research, reaches what gets built or written next.
Every recurring job that touches it has a written spec with an explicit must-not list. The sync from the vault into the knowledge base never touches the vault, never pushes to main and never auto-merges. Writing down what a job must never do is what lets it run while nobody is watching.
Humans own git; agents only write files
That is the governance, written down. An agent can draft a note, move a to-do or propose a change. Whether any of it becomes part of the record is a person's decision, made in a commit a person owns.
It sounds restrictive, and it is what makes the rest safe to automate. A record that agents can rewrite is a record nobody can trust, and a record nobody trusts stops being read.
Three
Run
The team and its tools read the same record
A read-only server over the vault, on a private network, lets teammates and the AI tools they work with query the record directly. Nobody keeps a private copy that drifts, and nobody asks in a thread for something that is already written down.
Read-only is deliberate. The team gets all of the context, and the record keeps one way in.
Tools
Tailscale is the private network the vault server is reachable on
Output
Query access to the whole record for teammates and the AI tools they use
Check
Read-only: the server hands the record out and takes nothing in
Start the day from the state of the work
Every morning a briefing assembles the open items, yesterday's meetings and the numbers, with metrics synced from analytics into daily, weekly and monthly files beside it.
It does the one job a status meeting mostly exists for, telling people what changed. That leaves meetings for the part that needs people in the room, which is deciding.
Four
Review
Watch the automation, not only the work
A gap finder inspects the schedules and the tools a few times a day and surfaces what silently stopped. Loud failures get fixed. The pipeline that quietly stops running is the expensive one, because nothing says so until somebody asks where the numbers went.
Failing safe is part of the design. When a run cannot verify its own state, it writes nothing and logs why, rather than overwriting records it could not read.
A person makes the call
The loop surfaces work. It does not decide it. Every piece of work has one owner and a stage, and anything that reaches a public surface waits at a gate. Whoever reviews a piece of work is never whoever did it: in my own practice that is a separate automated auditor, followed by my approval at the gate, and on a team it would be a different person.
A rejection is logged with its reason, so the same proposal cannot come back next week unchanged. What was decided goes back into the vault and onto the next briefing, and that is what makes it a loop.
The gate is for individual pieces of work. A recurring workflow that publishes on a schedule was approved once, as a workflow, and its pages and posts do not each wait here; the content engine says where that line sits.
One piece of work, traced
A real item from my own practice, from the moment the system found it to what happened after my approval, with subscriber details left out. It started from a gap the system noticed rather than from a meeting, which is why it shows the review and the gate so clearly.
Found8 August 2026
A scheduled triage run ranked an open gap first: two newsletter issues, written and voice-checked in June, had never been sent. It re-checked the gap's numbers against the live systems instead of restating them, and found them partly out of date.
Proposed8 August
It wrote a work packet with one owner, the social worker, plus the goal, the tasks, what was out of scope and the acceptance criteria. Because sending reaches real subscribers, the packet carried a gate: whatever happened next, it stops at me.
Approved to start8 August
I approved the proposal, which moved it to briefed and handed it to its owner.
Delivered11 August
The worker built the send-ready issue as a file in the vault. One criterion asked it to create a draft in the email service, and it refused, because it does not write to outside services unattended; it named the conflict in its delivery instead of quietly skipping the box. It also corrected a claim in the packet it was given: the send path the packet said had never been built had in fact been used once.
Audited11 August
A separate auditor, which did none of the work, re-opened the deliverable rather than trusting the summary. Five of six criteria passed, and it judged the sixth a correct refusal the packet had not anticipated, not a miss. It declined to create the draft itself, for the same reason. Status: accepted.
Gate11 August
Accepted work that touches a public surface does not release itself. It waited for me with two flags carried up from the delivery: the issue asked readers to reply before a reply address was confirmed, and it promised a weekly send day the pipeline had not kept. I approved it at the gate.
Outcomemid-September
Approval is not sending. Five weeks later the issue still had not gone out: the send is a manual job, and it was still on my list, with the two flags as the checks to make before it goes. The system did its part and stopped at the one step it is not allowed to take, and that is where the delay sits.
Where this breaks
What it does not do
The loop only knows what reached it. A meeting nobody agreed to record, a decision made in a hallway, or research that stayed in a slide deck is not in it.
A to-do nobody took on is noise, and a system that files forty of them a week teaches people to ignore all forty.
The gap finder can tell you a job stopped. It cannot tell you whether the job still mattered, and that call stays with a person.
It records what a team says. A team that avoids decisions will not start making them because of it; the avoidance just becomes easier to see.
Seeing it run
MixShift is this engine inside a company: the meeting ingestion, the reclassifier, the daily briefing, the gap finder and the read-only vault server, with fifteen scheduled pipelines built on top of them. I built the pattern on my own practice first, and the same architecture still runs it.
Half an hour, no deck. Where your current loop leaks, which stage would pay back first, where automation would actually help, and what still needs a person to look at it before it ships.