Repeating the same discovery and clicks after each success retains experience but not an execution asset. In Northstar I connected successful procedures to Python, Jupyter and plugins. The important decision was not merely saving the conversation; it was deciding which success could be reused under which conditions.
A shared name does not establish the same procedure
A similarly named program still needs inspection against the current request. Different sites, steps, parameter keys or postconditions define different work. Names are search hints; the executable definition is the contract. That distinction prevents an earlier user's request from silently becoming an instruction for the current task.
Conversely, creating another program every time a default title or body changes quickly clutters the catalog. Procedure identity must differ from the identity of this content. I started by deciding what sameness means for the reusable definition, rather than merging by name or splitting by a changed label.
Choose what identity removes and what it preserves
recipeIdentity orders object keys before hashing the definition. Display names and ordinary parameter defaults are treated so they do not create a new procedure identity. A special condition such as a text-draft entry point can retain meaning that must not be normalized away. Normalization is not permission to erase every difference.
Step order remains an array: entering and then verifying differs from verifying and then entering. Parameter keys also remain meaningful. Writing these rules in code lets a later maintainer understand the decision behind an apparently simple hash comparison.
Prefer the program already registered
ProgramLibrary.remember reads existing definitions and compares their identities. Preferred registered IDs are considered first; a matching procedure updates usage time and recent intent instead of creating another ID. That keeps plugin registrations and pinned choices from drifting into unnecessary duplicate copies.
A definition whose changed files fail hash verification is not silently reused. Similar-looking steps cannot make an unverified edit inherit the authority of an earlier test. Deduplication and change detection need to work together rather than one undermining the other.
Do not store every conversation as an automatic program
reusableRecipe uses criteria involving step count and action types to identify procedures worth retaining. A meaningful sequence or a file result differs from a single observation or an unverified target. Registering all of them as execution assets would make catalog presence look like success.
Automatic registration also differs from verification by actual replay. Generated Python and notebook companion files do not prove that those files were run again. I checked that distinction in the historical automatic-save and reuse experiment. Separating a draft definition from a verified procedure is part of managing the asset.
Retain failures encountered during reuse
The historical comparison includes a reuse failure on duplicate targets after an initial success. The repaired target condition and original expected outcome were retained, and a new version of the same program was reused. That is not a story in which one success made the task automatic forever. The difference that justified a revision should remain visible.
The embedded CLI's historical contribution also differs from the supervisor's changes to application source. Today the embedded CLI is removed and external Codex supplies judgment. Describing successful reuse must not expand an earlier repair scope into a current guarantee of unattended source repair.
An execution asset that can remain with the company
A request to automate business work can include an expectation that the next person will be able to continue it. The useful retained material is the current input contract, execution definition and version, actual tests and stop conditions. Conversation history can remain evidence for decisions without becoming the complete instruction payload for every run.
I wrote this article from the current identity and remember code and historical reuse records, not a new customer execution. I also wanted the guide to preserve the habit of inspecting an existing program against the present request. A reusable asset helps the next agent find what can be trusted and what needs checking before building it again.