Reuse the method. Respect the client boundary.

A delivery team should not have to relearn its craft on every engagement. But a useful lesson from one client does not make that client's information available for another.

The practical challenge is separating the method from the evidence that produced it. That separation needs a decision and an owner, not just a shorter summary.

Two records, two audiences

Consider an illustrative technical-scoping review. A team learns to check dependency ownership before estimating a migration. The client's architecture, commercial terms, and launch dates belong with that engagement. A general checklist for finding unclear dependencies may be useful across the firm.

Keep those as separate records. The client record preserves the evidence and context. A proposed firm-wide skill describes the method using neutral examples and only the information approved for broader use.

Removing the client's name is not enough. A distinctive system diagram, unusual transaction volume, or quoted negotiation can still reveal whose work it was.

Before importing or sharing knowledge

Use this checklist for each new engagement:

1. Confirm authority. Ask the responsible owner which material may be used, for what purpose, and by whom. Record the agreed retention and removal process before importing anything.
2. Choose a narrow source set. Start with approved documents or excerpts for one workflow. Exclude credentials, unnecessary personal information, and unrelated client material.
3. Check the actual access path. Verify who can read the source, room, memory, and agent feed. A room's name is not proof of an access boundary. Test with the intended account or key.
4. Review the proposed general method separately. Remove client facts, source quotes, identifiers, and sensitive examples. Have an authorized reviewer explicitly approve the remaining method for its intended audience.
5. Test retrieval and revisit access. Check that client-scoped questions return the intended material and cannot retrieve another client's records. Repeat relevant checks when membership, scope, or source content changes.

If a boundary cannot be confirmed, keep the material out of the pilot until it can.

Reuse does not require copying the evidence

A general skill can say, "Ask who owns each external dependency before estimating delivery." It does not need to include a client's supplier names or the incident that prompted the question.

Use a synthetic example to test the checklist. Keep any confidential evidence behind its original access boundary, and do not place a sensitive source link inside a broadly shared skill. Useful methods should explain their limits, not borrow authority from inaccessible client detail.

Apply this to a small pilot

For agency delivery, start with one authorized client workflow in Rooms and a named reviewer. Them AI is Mac-only for now. Free during the beta (invite-only).

In the current beta, human room and memory access is organization-wide. A room is not a private boundary for individual members. Client-scoped MCP feeds restrict agent retrieval to that client's approved records plus approved firm-wide material. Use only material your workspace members are authorized to see, and confirm source support and feed configuration during onboarding. Do not assume automatic redaction or treat an AI-generated draft as approval to share.

The companion guide explains how to preserve a decision's sources, owner, and version before deciding whether its reasoning should become a reusable skill.