AI accounts have quietly become something they were never really designed to be.
Repositories of work.
Not source-code repositories, at least not usually.
Something less obvious.
A long-running AI account can contain months or years of conversations about architecture, design decisions, debugging discoveries, specifications, experiments, rejected approaches, research, prompts, customer ideas, and explanations of why something was built the way it was.
For someone using AI casually, losing access to that account might be inconvenient.
For someone using AI as part of serious development work, it can be something quite different.
It can mean losing access to part of the project's history.
That leads to a fairly simple rule:
Your AI account is not a backup.
It doesn't matter how much valuable information is in there.
If the only copy lives inside somebody else's application, behind somebody else's authentication system, you don't really have a recovery plan.
The conversation became work product
This change happened gradually.
When I first started using AI for programming, a conversation was mostly temporary.
Ask a question.
Get an answer.
Try some code.
Move on.
That isn't how I work with AI now.
A serious project conversation may contain decisions that took hours to reach.
It may explain why one architecture was chosen over another.
It may contain discoveries about an old codebase that would be expensive to rediscover.
It may define terminology that becomes important throughout the project.
It may document a failed approach so another worker doesn't repeat it.
It may contain a handoff from one stage of development to another.
Sometimes the conversation is effectively the laboratory notebook for the project.
That makes it work product.
And once something becomes work product, we should start asking the same questions we would ask about any other project asset.
Where does it live?
Who controls it?
Can I recover it?
Can I move it?
What happens if the service disappears tomorrow?
What happens if I simply cannot log in?
Access is not the same as possession
Cloud services are wonderfully convenient because we don't have to think very much about where things live.
Open the browser.
Log in.
There it is.
After doing that hundreds of times, it is easy to develop a sense that the information is somehow ours in the same way that a file on our own system is ours.
But there is an important distinction.
You may own the information.
That doesn't necessarily mean you control access to the copy.
Your ability to reach it may depend on a password, a second authentication factor, an email account, a phone number, an identity provider, an account status, or a support process operated entirely by somebody else.
Normally all of that is invisible.
Then one piece breaks.
Suddenly, information you thought of as being right there is on the other side of a locked door.
Two-factor authentication changes the failure mode
Two-factor authentication is a good thing.
I use it.
The problem is not that accounts should have weaker security.
The problem is that stronger security creates another dependency, and every dependency needs a recovery path.
If the second factor stops working, there has to be another trustworthy way for the legitimate account owner to regain access.
That sounds obvious until you encounter a situation where the authentication process itself becomes the thing standing between you and the account.
At that point, the problem is no longer merely that you cannot start another conversation.
You cannot get to what is already there.
Export is useful, but export is not a recovery strategy
Most serious cloud services provide some way to export information.
That's useful.
But an export feature only protects you if you use it while you still have access.
An export option sitting behind the same account you cannot reach isn't much of a recovery system.
This is where developers, in particular, should recognize an old lesson.
A backup you have never made is not a backup.
A recovery procedure you cannot reach during the failure is not a recovery procedure.
The fact that a service technically supports data export does not mean your important work is protected.
The valuable parts should escape the conversation
This does not mean every AI conversation needs to be archived forever.
Most of mine don't.
There is plenty of temporary material.
Questions.
Experiments.
Ideas that went nowhere.
Routine troubleshooting that stops mattering the minute the problem is fixed.
But some conversations cross a line.
They produce something that the project will need again.
A design decision becomes architecture.
An experiment becomes a proven pattern.
A discussion becomes a specification.
A complicated repair produces knowledge about why the failure occurred.
A series of decisions defines what the next worker must preserve.
When that happens, the durable result should move somewhere durable.
For a software project, that might mean the repository.
It might mean project documentation.
It might mean a handoff document.
It might mean a design note.
It might simply mean keeping a local copy of an especially important conversation.
The exact mechanism matters less than the principle.
The only copy should not remain trapped inside the conversation that created it.
AI memory isn't project storage either
The same distinction applies to AI memory and persistent project context.
Those features can make AI dramatically more useful.
I rely on context heavily.
It saves enormous amounts of time when an AI already understands the terminology, architecture, constraints, and history of a project.
But useful context is still not the same thing as authoritative project documentation.
If the AI remembers that a component must work a particular way, that's helpful.
If the repository contains the specification explaining that requirement, that's durable.
If an AI remembers which package became the accepted source authority, that's convenient.
If the project records identify that package explicitly, another worker can recover the state without depending on that memory.
AI context should make it easier to continue the work.
It should not be the only thing that makes continuation possible.
Could you switch AI providers tomorrow?
There is a useful test for this.
Imagine that tomorrow morning your current AI service is unavailable to you.
Not necessarily gone forever.
You just cannot use it.
Could you take your current project to another AI system and explain where things stand?
Could you identify the source authority?
Could you provide the important design decisions?
Could you explain what has already been tried?
Could you tell the new AI what must not change?
Could you continue working?
If the answer is no because the only coherent history of the project is inside hundreds of old conversations, you have accumulated a dependency that deserves attention.
The goal isn't to make switching providers effortless.
Different AI systems have different capabilities and different ways of working.
The goal is to make the project recoverable.
This is not really about one provider
A recent experience involving a developer I know happened with an AI service and prompted me to think more seriously about this.
But the lesson isn't specific to one company.
The same thing can happen with any hosted AI service.
Or GitHub.
Or an email provider.
Or a cloud storage system.
Or almost anything else where valuable information lives behind an account you do not completely control.
The difference is that many of us already understand the need to back up source code, documents, databases, and photographs.
We haven't necessarily developed the same instinct about AI conversations.
That made sense when those conversations were disposable.
It makes less sense when they contain months of development history.
The goal isn't to save everything
I'm not advocating a giant archive containing every conversation you have ever had with an AI.
That would probably create a different problem.
The goal is to recognize when a conversation has produced something durable.
At that point, extract the durable part.
Put important architecture into project documentation.
Put source code into source control.
Put decisions into design notes.
Put accepted requirements somewhere the next worker can find them.
Keep local copies of conversations that have continuing value.
Make sure your project can explain itself without requiring access to one particular AI account.
That is enough.
Treat AI like infrastructure
I think this is part of a larger transition we're going through.
For a long time, AI was something we experimented with.
Now, for many developers, it is infrastructure.
It participates in design.
It writes code.
It analyzes systems.
It helps manage projects.
It carries context from one task to another.
Once something becomes infrastructure, failure planning becomes part of using it responsibly.
We don't need to assume the provider will fail.
We don't need to assume support will fail.
We don't need to assume authentication will fail.
We just need to recognize that any of them can.
And if the thing on the other side of that login matters, we should have our own copy of the parts we cannot afford to lose.
Keep what matters somewhere you control
A recent account lockout involving a developer I know made this risk much more concrete.
A two-factor authentication problem left him unable to reach an AI account containing work he cared about.
The painful part wasn't simply losing the ability to ask the AI another question.
It was realizing that existing work was on the other side of that login.
That's the part worth remembering.
AI conversations can become valuable work product long before we consciously start treating them that way.
So don't wait for the lockout to discover which conversations mattered.
If the conversation matters, keep your own copy.
Related field note
The companion Field Note looks at the account lockout that prompted this Guide and what it revealed about allowing valuable project history to accumulate behind a login you do not control.