Keep the reasoning, not just the result.

A finished proposal tells you what the team recommended. It may not tell you which alternative they rejected, whose constraint mattered, or what would make the recommendation wrong. Those missing details are often what the next person needs.

Preserving judgment means keeping enough context to question a decision, not just repeat it.

Record the conditions, not just the conclusion

Consider an illustrative commerce project. A team chooses a staged checkout rollout because an upcoming campaign leaves little recovery time. The useful record is not simply "Use a staged rollout." It connects that choice to the campaign calendar, the rollback test, and the person responsible for accepting the risk.

On the next project, those conditions may differ. A recommendation without its conditions can become an accidental rule.

A decision record worth keeping

Before approving a decision for reuse, check these five things:

1. State the choice and its scope. Name the project, affected system, and conditions under which the decision applies. Separate confirmed facts from assumptions.
2. Keep the supporting sources. Link to the relevant document or discussion and retain the passage that supports the claim. A link to a long folder is not enough.
3. Name an owner. Choose someone who can explain the reasoning and confirm whether it still applies. The author and the accountable owner may be different people.
4. Label the version. Use a clear name such as "Checkout rollout decision v2." Record what changed, when, and why. Do not leave two contradictory records looking equally current.
5. Set a reason to review it. A changed dependency, contract, deadline, or policy may matter more than a calendar reminder. State what would invalidate the recommendation.

The test is simple: could a colleague explain when not to follow this decision?

When a decision becomes a skill

Memory is what is true. A skill is how you work. The checkout decision belongs in memory; the method for evaluating a rollout may deserve a skill.

Repeated wording alone is not a reason to create one. Look for a recurring judgment with identifiable inputs, decision rules, a useful output, and a clear review boundary. Write down the exceptions as carefully as the normal path.

For example, a rollout-review skill could ask for traffic assumptions, rollback evidence, and launch constraints before producing a recommendation. It should not inherit one client's deadline as a universal rule. Test the method on a different example, then have its owner review it before wider reuse.

Start with one workflow

Rooms give people and agents a shared place to discuss the work. Start with one recurring decision from your team's workflow, rather than trying to preserve every conversation.

Them AI is Mac-only for now. Free during the beta (invite-only). Confirm source support during onboarding, and plan for human review of extracted memories and proposed skills. A generated summary still needs checking against its sources.

For client work, read how to reuse a method without carrying confidential details with it.