You spent an afternoon getting a custom assistant right. The tone is correct, it asks for the right inputs, and it stopped making the mistake that annoyed you in week one.
Then the product changes.
Google is replacing Gems with skills in Gemini. Its current transition guidance says Gems for adults with personal Google Accounts will transition on November 17, 2026, become read-only, and be removed on December 17. Work and school accounts follow in 2027. Google says Gems and supported knowledge files will transition automatically, subject to file-type and size limits. On a separate track, OpenAI’s October 14 deprecation notice schedules the listed GPT-4o, GPT-4o mini, GPT-4.1 and GPT-4.1 mini API snapshots, and their fine-tuned versions, for shutdown on January 14, 2027. Check the listed model IDs rather than assuming every model with a similar name has the same deadline.
None of this is unusual. Products evolve, features get consolidated, models retire. The instructions you refined are the durable part. The feature that stores them is a container.
Keep the canonical version of your important AI instructions in a plain file you control. Treat each product’s custom assistant, project, or skill as an adapter that points to — or is copied from — that file.
What is actually at risk
An automatic migration usually carries over the instruction text. The risk is in everything around it:
| Asset | Why it matters | What can go wrong in a migration |
|---|---|---|
| Instruction text | The behavior you tuned | Usually carried over; check that formatting and order survive |
| Reference files | Examples, style guides, source material | Google transfers supported files within a 100 MB total limit; unsupported files are omitted and the largest files are removed first if the total is too large. Keep your own copies and verify what transferred |
| Default tools and settings | How the assistant starts working | Settings may map differently or not at all |
| Sharing | Who else relies on it | Check who can use the recreated skill; verify access in the destination instead of assuming the previous sharing setup still applies |
| Your reasoning | Why each rule exists | Often omitted from the product instructions unless you write it down |
The last row is the expensive one. A year from now, you will not remember why the assistant was told to avoid a certain phrase or always ask for a deadline. The product never knew either.
Separate the instruction from the container
The pattern is the same one described in One Router, Many Agents: one maintained source, thin adapters per tool.
For a reusable assistant, an illustrative canonical file might look like this:
# Proposal reviewer
## Purpose
Review client proposal drafts before they are sent.
## Inputs
- The draft proposal
- The client's original request
## Steps
1. Check that every requested deliverable is addressed.
2. Flag pricing, dates, or commitments that need confirmation.
3. Suggest cuts for anything the client did not ask for.
## Output
A short list: must fix, should fix, optional.
## Constraints
- Do not rewrite the whole proposal.
- Do not invent prices or dates.
## Why these rules exist
- Full rewrites lost the author's voice in earlier reviews.
- Invented dates once reached a client draft.
## Adapters
- Gemini: skill created from this file — last checked YYYY-MM-DD
- Other assistant: project instructions copied from this file — last checked YYYY-MM-DDThis is an example structure, not a required format. The two sections that matter most are Why these rules exist and Adapters: the first preserves reasoning no product stores, the second tells you where copies live when something changes.
If the tools you use support it, the open Agent Skills format packages instructions as a folder with a SKILL.md file. A plain Markdown file is still a reasonable canonical source; choose whatever your tools can actually read, and verify it in a fresh session.
A 15-minute exercise before the next migration
Pick your three most-used custom assistants in any product.
- Copy the instruction text into a new Markdown file, one per assistant.
- List the reference files it depends on and keep your own copies of anything you would not want to lose. Google’s guidance for Gems with knowledge files is worth reading before you rely on automatic migration.
- Write one line per important rule explaining why it exists.
- Record the adapters: which products hold a copy, and the date you last checked them.
- Run a comparison test. Give the product version and a fresh session using your canonical file the same input. Note any difference in behavior.
Step 5 is the one people skip. A migrated assistant that looks the same can still behave differently, especially if the underlying model has changed. The comparison tells you whether the migration preserved what you cared about.
After the migration
When your Gems transition to skills, or any similar change happens:
- Open each migrated item and compare it with your canonical file, not with your memory.
- Re-run the comparison test from step 5.
- Fix differences in the canonical file first, then update the adapter.
- Update the last checked date.
If the product version drifts from your file, your file wins unless you decide the change is an improvement. Then update the file, so the improvement survives the next migration too.
What this does not solve
A canonical file does not make different products behave identically. Models differ, tool features differ, and some product settings have no plain-text equivalent. It also does not migrate anything for you: copying instructions into each tool is a manual step, and you should check each tool’s own documentation for how it loads instructions.
What it does give you is a recovery point. When a feature is renamed, a model retires, or you switch tools, you start from a maintained file instead of starting from scratch.
Start with the assistants you would miss
You do not need to export everything. Start with the three assistants you would miss, write their canonical files this week, and add the adapter list to each.
For a structure that keeps instructions, project memory and handoffs together across tools, explore the KOS Starter Kit. Pair it with One Router, Many Agents to keep those instructions from drifting once they live in one place.