Seeding a new assistant deliberately

The new account is open and it knows nothing about you. Left alone it will accumulate some of that knowledge over months, incidentally, the same way the last one did.

You can do most of it in an hour on the first day instead, because you already wrote the material down while leaving the old account. This is what that material is for.

Do it in one sitting, not as you go

Set aside an hour before you start sending real work.

The reason is that the first two weeks on a new assistant are where people form a judgement, and a cold account produces a misleading one. Seeding deliberately means the fortnight tests the new assistant against your actual context rather than against nothing, and the parallel period then measures something worth measuring.

The material for this is already assembled if you did the leaving properly. Instruction file, prompt library, reference folder, and the load-bearing memory list.

Load the instruction file first

Paste your instruction file into whatever the new product offers for standing instructions.

Two adjustments as you do it. Cut the workarounds — clauses that existed to correct a specific behaviour of the old assistant, which are now fixing a problem you may not have. And check length: standing instruction fields have limits, they vary, and the limit is worth discovering now rather than by truncation.

If the file is longer than the field allows, split it: the durable statements about you go in the standing instructions, and the situational parts become named sections you paste when relevant.

Then the memory list, as statements

The load-bearing items from the old account’s memory go in as explicit declaratives, not as a request to remember.

There is a real difference. “Remember that I work in logistics” asks the product to store something, which it may or may not do and which you cannot audit. A line in your standing instructions saying you work in logistics is a fact that applies to every conversation, verifiably, and it survives the next switch.

Where the new product has its own memory feature, let it accumulate on its own. Do not try to pre-load it by narrating your life at it — that produces a list of stored facts you did not choose and cannot easily review.

Attach the reference documents

Whatever persistent place the new product offers for reference material, populate it from your own folder.

If there is no such place, that is fine and changes only convenience: you attach per conversation, from the folder, as you always did on the days the old setup was not helping either.

One thing worth doing regardless: name the documents in your standing instructions. “There is a style guide; when writing external copy, ask for it if it is not attached” makes the assistant’s ignorance visible rather than silent, which is what you want in the first fortnight.

Write a short context brief

One page, kept in the same folder, describing your work in the terms you actually use: what you do, the recurring projects, the people whose names come up, the systems you deal with, the vocabulary that is specific to your setting.

Its job is to be pasted at the start of a substantive new conversation, so the assistant is not deducing context from the question. This is the closest portable equivalent to what the old account had accumulated — not because it is the same thing, but because it is the part of it that was expressible in words.

Keep it short enough that pasting it is not a decision. A page you use beats three pages you skip.

What moves

WHAT MOVES — seeding a new account

  · Instructions, prompts, reference
    documents, memory list
                    → move, as files you already own.
                      This is the entire payoff of
                      writing them down.

  · Old workarounds inside those files
                    → STAYS BEHIND deliberately. Strip
                      before pasting.

  · Accumulated calibration on the old side
                    → STAYS BEHIND. Seeding shortens the
                      cold start; it does not remove it.

  · Whatever the old product inferred and
    never showed you
                    → STAYS BEHIND. Not expressible, so
                      not transferable.

  · Narrating context at the new memory
    feature to pre-load it
                    → produces stored facts you did not
                      choose. Use instructions instead.

Verify the seeding with one real task

Take something you do regularly and run it, once, and read the output against what you would have expected from the old setup.

You are checking three things: that the standing instructions are being applied at all, that no stripped workaround left a gap, and that the format matches what you actually need. Any of those failing is a five-minute fix on day one and a fortnight of low-grade friction if you find it later.

Note what needed changing. That note is the beginning of the list of what broke, and most early entries turn out to be seeding problems rather than capability problems.

Keep the files as the source

The point of the hour is not that the new account is configured. It is that the configuration exists as files outside it.

So when you improve an instruction in the product, improve it in the file the same day. That habit is what makes the next switch an hour of pasting rather than a month of reconstruction, and it is the only part of this whole process that compounds.

What seeding cannot do

It cannot give you the year. The new assistant has a page of context where the old one had a long accumulated model of your work, and for a few weeks the difference shows in small things — the questions it asks that the old one would not have needed to, the assumption it gets wrong that you had stopped having to state.

That gap closes on its own, slowly, and nothing accelerates it much. Naming it in advance is what stops you misreading it as a defect in the destination.