Turing Post turns the agent postmortem into a question of where the fix gets stored

The example in the Turing Post account is small enough to check against your own week. An assistant helping prepare an interview has to know which notes belong to the writer, which came from earlier research, and which information has since changed ^[15]. When it hands back the stale version, the fix is not obvious, because there are four places to put it and they do not behave alike ^[5].

A correction typed into the session changes the answer while the weights stay fixed, and it can vanish when the conversation ends ^[6]. Writing it to persistent memory outside the model makes it retrievable later, and it creates work that never finishes: someone decides what gets saved, how it is found, and when it becomes outdated ^[7]. Editing a reusable instruction, a tool definition or the order of steps reaches every later run of that workflow, and a model can propose that revision and help evaluate it ^[9]. Post-training moves the weights. That can change behavior on tasks that were not in the latest training data, so the article asks for broader evaluation than checking whether one revised instruction works ^[10].

Three of the four leave the weights alone ^[17]. The two questions the article uses to tell the four apart, where a change is stored and which future tasks it can reach, work as the axes of a grid you can draw before approving anything ^[18]. That gives four cells: the session correction that expires; the memory entry that persists but only fires when retrieval matches it; the instruction or tool change that reaches every later run of one workflow; and the weight update that reaches untested tasks.

The one worked example is Salesforce's own. Koa was built by post-training Nvidia's Nemotron-3-Super-120B with reinforcement learning on public and synthetically generated data, and no customer data ^[11]. Workflow specifications shaped the simulated tasks and the criteria used to judge whether the model completed them ^[12]. The checklist applies most directly here: evaluate a change on cases it was not written to solve, because a lasting change can still make the system worse ^[14][13].

Turing Post framed the whole exercise as one question, asking "when we say a system is improving, what exactly is changing, and how do we know the change is actually an improvement?" ^[20]. The piece does not report failure rates or before-and-after numbers for any of the four routes ^[19]. Salesforce covered the flight and hotel; Turing Post says it kept full editorial independence and that Salesforce did not review the article in advance ^[2]. What a team gets is a taxonomy and a checklist, both testable at a desk.

The person this is for is whoever gets paged when the agent is wrong. In a small shop that is one person holding all four routes, and the article makes the same point at both scales, from Salesforce customers whose information sits across many systems with rules that have exceptions ^[16] to one practitioner running a few projects ^[15]. I would add a third question to the article's two: who reverts this change, and how. If nobody can answer, review the fix as if it moved the weights. The cost of that rule is speed, since a stale memory entry one person could delete this afternoon then waits on a reviewer.