The improvement loop: observe, propose, approve, ship, measure

The loop has five stages. You observe what is happening. An agent proposes a specific change. A person approves, edits or rejects it. The change ships through the normal gates. You then measure whether it did what you wanted, and what you learn becomes the next thing you observe. The point of the shape is that the agent proposes and a person decides at the one stage where judgement is needed.

Here is where it stands. Pieces of every stage are built in the product, and some of them we use. A personal loop is built in Cortex and watches one person. Missions, the structured way to run a multi-step piece of work, have one documented run on an isolated validation stack and are not deployed to production. A company-wide loop across code and operations is design intent. We publish no measured outcome, because we have none to publish.

The first source is the Nexus ledger. When we run coding agents through Nexus capture, it records what they did as events on the machine: the tool actions, the file changes and the outcome of each turn. That is in use at Swfte as a record, and it is the closest thing we have to an observation of our own agent work. The second is session and issue observability: events from products go to a service that groups them into issues and uses an AI classifier. It is built in the product.

The third is a personal loop inside Cortex. It watches one person's activity on their own device, finds recurring patterns, and keeps the results on that device. It is built, and it observes one person. It is not a view of a company, and we have not confirmed that it is switched on in the shipped build. People choose what is worth watching. An observation that nobody chose is noise with a good user interface.

A proposal has to be specific enough to approve or refuse. The triage command shows the idea in a small form. Given an issue, it returns a diagnosis with a likely cause, the component and suggested fix text. It does not open a pull request. The personal loop in Cortex goes further and gates its own ideas with four questions: is there evidence, is there a named action, is the cost measured, and is there a way to show it wrong.

If a candidate fails any one of those four questions it is dropped. That discipline is worth copying whatever tool you use: an opportunity without evidence, an action, a cost and a falsifier is a hunch. Missions use the same instinct at larger scale: a plan is priced before launch, so a person approves a cost and a shape rather than a promise. In every case the agent proposes and does not apply.

Approval is the stage the other four exist to serve. In the product it takes several forms: the approval cards that Nexus raises in a chat, the human input and gate steps in workflows, and the human steps in a mission, which has its own final acceptance before a piece of work counts as done. Each of them records who decided. They are separate mechanisms, and the page on approvals explains the differences.

Our own approval practice is smaller. Decisions about a live payment test and about the release signing key are kept by the owner, and a rule in our repositories tells AI assistants to propose before they execute. A person approves. Nothing in this loop lets an agent approve its own proposal, though the platform does not yet enforce that the approver differs from the requester. For now that separation is a team choice.

An approved change is not shipped by the loop. It is shipped by your normal release process, with its tests, its review and its gates. In our Cortex application a merge releases only if the version has been bumped and the gates are green. When hosted CI stopped running for a period, we ran the same gates locally from one script, and we recorded that this left nothing gating a merge in the usual way.

For larger tasks we also write completion gates before the work begins, with a command, an expected result and recorded evidence. These are in use at Swfte. The loop adds no new route to production. If it did, it would be a way round the controls the rest of this site describes. A change that the loop proposes and a person approves still has to pass what any change has to pass.

Measurement is the weakest stage, and we would rather say so. The personal loop in Cortex keeps a ledger of each opportunity as accepted, dismissed or built, and a hit rate follows from it. We have not verified that anyone's outcomes have been measured with it. Missions carry a five-state measure in which unproven is a separate state from missed, so a result you cannot yet judge is not counted as a failure.

That distinction is worth keeping. "We have not shown it worked" and "it did not work" are different findings, and mixing them up leads teams to abandon good changes or to claim wins they have not earned. People judge whether a change worked. They do it against the reason the change was made, written down before it shipped. We publish no measured outcome from any loop, ours or anyone else's.

Here is how we would run one turn of a company-wide loop. It is design intent, not a description of something we have done. Observation shows that a particular error recurs in one product screen. An agent turns that into a proposal: change this check, and here is the evidence. The proposal passes the four questions, so it is not a hunch. A named person reads the evidence and approves it with a note.

The change then goes through the normal tests, review and release. After release, the team compares the error rate with the reason the change was made, and records one of three findings: it worked, it did not, or it is still unproven. That finding is the next observation. If we have a real change of our own to show, it will replace this one: <real example of a shipped improvement from the loop - founder to fill>.

People choose what to watch, because an agent that watches everything finds everything and proves little. People approve, because approval carries responsibility that an agent cannot hold. And people judge whether the change worked, because that judgement depends on the reason it was made, which is a human reason. The agents observe, draft and propose. They do not choose, accept or conclude.

Read the other pages for the parts: internal knowledge for what the loop can see, the engineering workflow for how changes are made, automated review for how problems are found, and approvals for how decisions are recorded. The evidence table below is the plain list of what is in use, what is built and what is still design intent for the loop as a whole.