DEV Community: Sohachi

I Tried to Put AI Into the Race. Then I Realized It Didn't Need AI.

Sohachi — Tue, 22 Sep 2026 15:42:16 +0000

In the previous post, I started working out what EvoWild Run is actually supposed to be as a game.

Raise Creatures. Breed them. Continue their lineages across generations.

Race them on Courses with different conditions, then use the results to influence the next breeding decisions.

Eventually, players may also be able to create Courses themselves.

But one major question was still unresolved:

What does the player actually do after the race starts?

I left that question open in the previous post.

What Is EvoWild Run Actually Supposed to Be?

So that is where I started this time.

I don't want the player directly controlling the Creature during the race

The first decision was that EvoWild Run should not become a game where the player directly controls the Creature after the start.

Move left and right.

Press an acceleration button.

Time your inputs through corners.

If I make that the core of the race, the player's action-game skill starts becoming more important than the Creature they actually bred.

What I want to matter more is:

what kind of Creature you raised
which Creature you chose to enter
which Course you selected
what strategy you prepared
what you learned from the result
how you changed the next generation

So the rough structure became:

Breed → choose a Creature → choose a strategy → watch the race → analyse the result → feed it back into the next decision

Up to this point, the idea is still fairly close to a horse-racing game.

Then I wondered: what if AI made the decisions during the race?

That led to an AI idea.

If the human player is not directly controlling the Creature, perhaps an AI prepared by the player could observe the race and make decisions instead.

For example:

the path ahead is blocked
the remaining distance is getting short
the Creature is heavily fatigued
an outside path is available

The AI could respond with commands such as:

CONSERVE
MOVE OUTSIDE
ATTACK

The AI would not directly move the Creature.

The structure I had in mind was:

text AI / Agent ↓ evaluate the situation ↓ issue a command ↓ Creature attempts to execute it ↓ Race Engine determines the actual result

That is where the idea of a Race Agent started.

But it felt strange for only AI users to have an Agent

The next problem was obvious.

What happens to players who do not use AI?

If AI users have a Race Agent while everyone else uses a completely different system, then I effectively have two different race systems inside the same game.

So I changed the idea.

Every racing Creature should have a Race Agent.

A normal player would not need to write an Agent File.

They could simply choose understandable options in the game UI, such as:

push forward / standard / hold back at the start
conserve / standard / aggressive base pace
prefer inside / natural / prefer outside
wait / look for an opening / overtake aggressively in traffic
early / standard / late spurt timing

Beginners could use simpler presets.

Internally, those choices would be converted into a common Agent File.

An advanced player could instead write the Agent File directly.

Or they could ask ChatGPT, Claude, Gemini, a local model, or another AI to create one.

The important part is:

an Agent created through the normal UI and an Agent created with AI eventually become the same kind of Agent File.

AI users do not get access to special commands.

From the Race Engine's point of view, they are the same thing.

And then I realized the Agent didn't actually need to be AI

This was the point where the idea changed.

Suppose the Agent File contains a rule like this:

`text
remaining distance <= 400m
AND
fatigue < 70%

↓

ATTACK
`

That is not AI.

It is just checking conditions and selecting a predefined command.

Games have been doing variations of this for a long time: instead of directly controlling a character, the player defines tactics, priorities, commands, or rules in advance.

The name Race Agent sounds AI-related, but the runtime system itself does not actually need AI.

So I had started with:

What if I put an AI Agent into the race?

And after breaking the idea down, I ended up with:

The race does not need AI running inside it at all.

What remained was essentially a tactical command system.

I don't think Live AI is necessary at the beginning either

It would still be possible to connect an external AI during the race and let it make decisions in real time.

But then a different set of problems appears:

API latency
connection failures
differences between models
differences between free and paid AI services
API costs
dependency on external services
competitive fairness

I would be designing a racing game, but suddenly the price and performance of external AI services would also become part of the competitive environment.

So for the initial version, I think this is enough:

Create an Agent File before the race, then let the Race Engine execute it.

Live AI can be reconsidered later if there is a reason to add it.

Just because AI is involved somewhere does not mean an AI model needs to be running throughout the race.

AI can still help create the Agent instead of running it

I did not remove AI completely.

I moved it to a different part of the process.

For example:

`text
Creature abilities
Past race results
Current Course conditions
Existing Agent File

↓

External AI

↓

Improved Agent File

↓

Validator

↓

Race Engine
`

A player could ask an AI to analyse a Creature's previous races and produce an improved strategy.

A player who does not want to use AI could create the same kind of Agent through the normal game UI.

So:

AI is optional.

It can help with strategy creation and analysis.

But the game rules themselves can still work without it.

At least for now, that seems like a much better fit for EvoWild Run.

This feels a little like the blockchain question again

EvoWild Run originally started from me thinking about blockchain games.

The question was not:

If this is a blockchain game, where do I put the token and NFTs?

It was:

Does this game actually need blockchain at all?

I seem to have ended up doing something similar with AI.

I started with:

Could AI make the race more interesting?

Then I separated the idea into its actual components and found that the Race Agent did not need AI in the runtime.

But the Race Agent itself survived.

So the next question became:

If this is now just a tactical command system, how do I make it interesting enough to become part of the game rather than just another settings screen?

That is what I started thinking about next.

What Is EvoWild Run Actually Supposed to Be?

Sohachi — Sat, 19 Sep 2026 16:16:43 +0000

In the previous post, I wrote about how a horse-racing idea gradually turned into a game about fictional creatures, breeding, lineage, and racing:

What Kind of Game Makes History and Inheritance Matter?

The provisional name for the project is EvoWild Run.

At this point, the basic form I had in mind was:

fictional Creatures
individual differences between them
raising and training
breeding
traits passed from parents to offspring
bloodlines that develop across generations
racing those Creatures

None of those mechanics are new by themselves.

Breeding games, horse-racing games, and raising games have been doing similar things for a long time.

So from here, the question became less about trying to invent a completely new mechanic and more about gradually deciding:

What kind of game should EvoWild Run actually be?

It is a Blockchain Game, but I am not starting with Tokens or NFTs

EvoWild Run originally came from me thinking about a more basic question:

What actually makes something a Blockchain Game?

Because of that, there are several things I decided from the beginning.

Connecting a wallet will not be required to participate in the game.

There will be no game-specific Token.

Creatures will not be issued as NFTs.

Play-to-Earn will not be the purpose of the game.

That does not mean I have decided not to use Blockchain.

It is almost the opposite.

The experiment is:

Can Blockchain have a meaningful role in a game even when the game is not built around Tokens, NFTs, or Play-to-Earn?

At least for now, I do not want the game to revolve around selling Creatures as NFTs and trading them.

I also do not want players to need a wallet just to start playing.

What I am currently thinking about is whether Blockchain could be connected to things that are meant to persist over time, such as Creature history, bloodlines, and later, Course history.

But I still do not have an answer to the question:

Does this game actually require Blockchain?

That is still part of the experiment.

A Creature is not completely determined at birth

One of the central ideas is that Creatures change across generations.

The rough cycle is:

Genetic information → abilities and traits of an individual → race results → choosing the next parents → the next generation

Traits from the parents affect the next generation.

A Creature is born.

The player raises it.

It races.

The player looks at the result and decides which individuals should become the next parents.

Then another generation begins.

That cycle repeats.

But I do not want the game to become:

Find the individuals with the highest numbers, breed them together, and repeat.

If that happens, the game eventually becomes a search for one universal optimum.

That made the race side of the game more important.

I still have not decided exactly what kinds of races there will be

This part is still open.

I have not decided on a fixed list such as:

sprint races
endurance races
obstacle races

or anything like that.

What I have decided is that I do not want the same type of Creature to be optimal in every race.

Race conditions could differ in things such as:

total distance
Course width
corner sharpness
length of straights
elevation changes
surface
number of corners
bottlenecks
weather
surrounding environment

For example, a long straight might make top speed more important.

A Course with many sharp corners might favor different abilities.

Large elevation changes might make climbing ability or endurance more important.

A narrow section might make positioning matter instead of pure speed.

Mud, sand, snow, and other surfaces could make different types of aptitude important.

The goal is not:

One Creature is strongest everywhere.

It is closer to:

A Creature may be strong under one set of conditions, but not under another.

If the Course changes, breeding direction can change too

This made the Course itself important.

The rough idea is:

Course conditions → different abilities and traits become advantageous → race results change → different parents are selected → bloodlines develop in different directions

For example, if Creatures compete for many generations on Courses with tight corners, players may start breeding bloodlines that perform well under those conditions.

A Course dominated by long straights could push breeding in a different direction.

Mud or snow could make traits that were previously unimportant suddenly valuable.

So even if the basic game is still about raising and breeding Creatures, changing the competition environment can change what players consider a "good" individual.

Then maybe players should be able to create Courses too

From there, I started wondering whether Courses need to be fixed by the game at all.

So I added the idea of letting players create race Courses themselves.

The current idea is not unrestricted 3D creation.

It would start with a modular system using predefined Course parts.

For example:

Straight
Left Curve
Right Curve
Uphill
Downhill
Narrow
Wide
Bridge
Tunnel
Mud
Sand
Grass
Rock
Snow

Players could combine them into something like:

Straight → sharp curve → uphill → mud section → long straight

A Course Builder itself is not a new idea.

Games have had course editors for a long time.

What matters for EvoWild Run is that a player-created Course would not just be scenery or a playground.

It could become part of the competitive environment that influences breeding.

A player could breed a Creature for an existing Course.

But they could also create an environment designed to test a particular Creature or bloodline.

Then another player might breed a completely different bloodline that performs better on that Course.

If that happens, history starts to exist on the Course side as well as the Creature side.

Who created the Course?

When was it created?

What races were held there?

Which Creature holds the record?

Those kinds of histories may also become part of the game.

Current game structure

This is the current system diagram.

It is not a final architecture.

It is simply a snapshot of the design at this point in development.

View the current live design:

EvoWild Run — Game Structure v0.1 on Whimsical

The diagram itself will probably change as more parts of the game are decided.

I plan to keep updating it as part of the actual design process.

The game is still far from fully defined

Right now, EvoWild Run is moving toward a structure where players:

raise Creatures

breed across generations

test them under different race conditions

use race results to influence future breeding

and eventually create competitive environments themselves

But many things are still undecided.

What kinds of races will actually exist?

How much can raising change a Creature?

Where is the boundary between inherited traits and development through training?

What does the player actually do during a race?

What should be recorded on Blockchain, and what should remain in a normal database?

The project is still at the concept stage, so these things may change.

But the starting idea has not changed:

Do not start by building a game around Tokens and NFTs.

Build the game first, then find out whether Blockchain has a meaningful reason to exist inside it.

That is still where EvoWild Run is starting from.

What Kind of Game Makes History and Inheritance Matter?

Sohachi — Fri, 18 Sep 2026 15:01:45 +0000

In my previous post, If Blockchain Isn't Required, When Is It Better Than a Database?, I changed the question again.

I had stopped looking for a game that was strictly impossible without blockchain and ended up with a different idea:

What if the goal isn't Blockchain Required, but Blockchain Preferred?

A normal database can reproduce a lot of the same functionality.

But maybe blockchain becomes more meaningful when things like these matter to the game itself:

Who controls the authoritative record?

Who controls the history?

Can other people verify that history?

What remains if the original operator disappears?

Can someone else use the data and continue building on top of it?

So the next question was:

What kind of game could make those things part of the actual gameplay?

This was where I finally started thinking about a concrete game.

The first idea was horse racing

The first thing that came to mind was horse racing.

I don't remember exactly why.

I'm currently building a horse-racing-related website called Where Horses Run, so that may have been a big reason.

Horse racing was probably just already somewhere in my head.

At the same time, I had just been thinking about things like history, inheritance, and identity.

Horse racing already has bloodlines.

There are parents, offspring, and generations.

A horse's past and pedigree are part of how people understand that individual horse.

So maybe that connected naturally with what I had been thinking about blockchain.

But I don't want to invent a clean explanation after the fact.

It may also have been nothing more than a random idea.

A horse-racing game isn't a new idea

Of course,

raising horses,

breeding them,

building bloodlines,

and entering them in races

is nothing new.

Horse-racing games have been doing this for decades.

So at this point, I didn't feel like I had invented some new kind of game.

It was more like:

While thinking about blockchain, horse racing appeared as an existing game genre that seemed unusually compatible with some of those ideas.

Then, while thinking about the horse-racing concept, another thought appeared.

What if they weren't horses at all?

From horses to fictional creatures

Concept illustration only — the creature design has not been decided.

The idea shifted from real horses to fictional creatures.

Again, I don't remember exactly why.

Maybe it was because there are already so many conventional horse-racing games.

Maybe fictional creatures simply seemed to offer more freedom in terms of abilities, appearance, and behavior.

Or maybe it was just another random idea.

But changing the racers from horses to fictional creatures opened up a much larger design space.

Each individual could have different abilities.

They could have different personalities or temperaments.

They could be better or worse on different courses or under different conditions.

Some traits could be inherited from their parents.

Mutation-like variation could exist.

Players could build bloodlines over many generations.

None of those ideas are new by themselves either.

There are already plenty of games about raising fictional creatures, breeding them, and creating individual variation.

The part I found interesting was somewhere else.

It accidentally connected back to the earlier idea

A creature can have parents.

Those parents can have parents.

Generations can continue.

An individual can have a history of races and results.

Ownership can change.

And eventually, that individual can become the parent of another generation.

At that point, the things I had been thinking about earlier —

Identity

History

Inheritance

— could exist naturally inside the game.

You can attach history to a weapon or a card too.

Who owned it before?

Which tournament was it used in?

Those records can exist.

But with a living individual, the past can become more than additional metadata.

The past can become part of what the individual is now.

Who its parents were can affect the current individual.

And the current individual can then affect the next generation.

I didn't choose fictional creatures because I had calculated that they were the perfect answer to the blockchain question.

The order was the opposite.

I thought of horse racing.

Then horses became fictional creatures.

And only after that did I realize:

This might fit the Blockchain Preferred direction surprisingly well.

That was roughly how it happened.

Still just a fairly ordinary breeding-and-racing game

At this point, the game idea was basically:

There are fictional creatures.

They have individual differences.

They can reproduce.

They have bloodlines.

They can be raised.

And they race.

Honestly, that still doesn't move very far beyond existing breeding games or horse-racing games.

The reason to use blockchain was also still only:

“It seems like it might fit this kind of design better.”

Nothing stronger than that.

But for the first time, the abstract blockchain discussion had turned into something that looked like an actual game.

Around this point, I started calling the project:

EvoWild Run

It's still only a working title.

And then the next problem appeared.

What is the race itself supposed to be like?

If players raise creatures and enter them into races, what do they actually do during the race?

Do they directly control the creature?

Does it run completely automatically?

Is the result determined only by stats?

That became the next part of the design to figure out.

If Blockchain Isn't Required, When Is It Better Than a Database?

Sohachi — Thu, 17 Sep 2026 15:47:09 +0000

In my previous post, Is There Actually a Game That Requires Blockchain?, I ended up changing the question.

Not:

Blockchain Required?

But:

Blockchain Preferred?

I still hadn't found a game that I could confidently say was technically impossible without blockchain.

Axie Infinity, Gods Unchained, The Sandbox — the core game systems could all, at least in principle, be implemented with a normal server and database.

Play-to-Earn didn't solve the problem either.

So it would be easy to stop there and say:

Maybe games simply don't need blockchain.

But something about that conclusion bothered me.

Being able to reproduce the same functionality with a database is not necessarily the same as saying that nothing changes when you replace blockchain with one.

So I started thinking about that difference instead.

What happens with a normal database?

Imagine a game with a single character.

That character has information such as:

Who owns it?

When was it created?

What has happened to it?

Who owned it before?

What achievements does it have?

In a normal game, all of this can simply be stored in the operator's database.

And in most cases, that is probably the better design.

It's faster.

It's cheaper.

It's easier to build.

It's easier to fix when something goes wrong.

For most games, a centralized database makes perfect sense.

But there is one important assumption:

The game operator controls the authoritative record.

The operator ultimately controls the record of who owns the character.

The operator controls its history.

The operator decides whether outside developers can access that data.

And if the service disappears, the operator also determines what happens to that database.

There is nothing inherently wrong with this.

For most games, it's completely fine.

But what if that authority itself matters to the game?

What actually changes with blockchain?

Now imagine that some of the same information is recorded on a public blockchain.

The gameplay might not change at all.

The character could still behave exactly the same way.

But depending on how the system is designed, something important could change:

The game operator would no longer have to be the only party capable of verifying the authoritative record.

Other people could independently verify records such as ownership and transfers.

A developer who has nothing to do with the original game could potentially read that public data and build another tool or game around it.

And if the original operator disappeared, the records that had actually been placed on-chain would not necessarily disappear with the operator's database.

That doesn't mean the operator automatically loses all control.

A blockchain game can still use admin keys, upgradeable contracts, centralized servers, private APIs, or other components controlled by the developer.

So simply putting something on a blockchain doesn't solve the problem by itself.

But it does make a different trust model possible.

So yes:

A database can reproduce the functionality.

But:

It does not necessarily reproduce the same trust model.

That started to feel like a more interesting distinction.

An NFT surviving doesn't mean the game survives

There is another problem here.

Suppose a game character is represented by an NFT.

If the game shuts down but the NFT remains on-chain, it's tempting to say:

“The asset survived.”

But what exactly survived?

If the game server is gone,

if the system that calculates its stats is gone,

if its images or 3D models were stored on a dead server,

if the client no longer works,

or if the actual game rules were never made available,

then the token may survive while the game does not.

An asset surviving is not the same thing as a game surviving.

Using blockchain does not automatically make a game independent from its operator.

You still have to ask:

Which parts are actually independent?

Which parts still depend on the original company's servers?

Which parts can be verified without trusting that company?

And what would someone else actually need in order to continue the game?

Maybe “Required” was the wrong standard

Originally, I was looking for something that was:

Blockchain Required.

A game that simply could not exist without blockchain.

I still haven't found that.

If we allow one trusted operator to control a server and database, an enormous amount can be reproduced centrally.

So perhaps that standard isn't very useful.

A more interesting target might be:

Blockchain Preferred.

A game that can be built with a normal database, but where replacing blockchain with that database changes something important about what the game means.

Maybe history matters.

Maybe it matters that the operator is not the only party capable of controlling or verifying that history.

Maybe it matters that third parties can build on public data without asking the original operator for permission.

Maybe it matters that someone else could continue something after the original operator disappears.

Maybe the identity of something in the game is supposed to outlive a single account, server, or company.

That still doesn't mean:

“This absolutely must use blockchain.”

I'm not there.

Right now, the conclusion is much weaker:

There may be kinds of games where blockchain fits the design better than a normal database.

And that led to the next question.

What kind of thing would make history, inheritance, and persistent identity part of the game itself?

A weapon didn't quite feel right.

A card didn't quite feel right either.

Something whose past affects its present.

Something where things can persist across generations.

That's where the idea finally started becoming more like a game.

Is There Actually a Game That Requires Blockchain?

Sohachi — Wed, 16 Sep 2026 15:33:10 +0000

Is There Actually a Game That Requires Blockchain?

In my previous post, Can a Blockchain Game Exist Without Coins, NFTs, or Play-to-Earn?, I started with a question:

What happens if we forget about coins, NFTs, Play-to-Earn, and all the other things commonly associated with blockchain games, and start with only Blockchain + Game?

Previous post: Can a Blockchain Game Exist Without Coins, NFTs, or Play-to-Earn?

That left me with a harder question:

Is there actually a game that requires blockchain?

So I started looking at some of the obvious examples.

Axie Infinity

Axie Infinity was the first one that came to mind.

The official Axie marketplace describes Axies like this:

“Battle, collect, breed, and befriend these adorable creatures.”

The marketplace itself tracks Axies, owners, listings, genes, breed count, and other properties.

Source: Axie Infinity — Official Marketplace

Breeding goes further than simply creating another character.

According to the official breeding guide, offspring can inherit characteristics from their parents:

“the offspring has a chance of inheriting parts and traits from either parent.”

The same guide describes dominant and recessive genes and the probabilities of those genes being passed to offspring.

Source: Axie Infinity — Axie Breeding Guide

At first, this seems close to what I was looking for.

But then I tried removing the blockchain mentally.

An Axie could still have an ID.

It could still have stats and genes.

Its parents could still be recorded.

It could still be bred.

It could still fight.

It could still be transferred from one player's account to another.

All of that could be stored in a normal database.

The ownership model would be different, of course.

But the game itself would still work.

So Axie seemed to use blockchain in meaningful ways, but I couldn't say that the game was technically impossible without it.

Gods Unchained

Gods Unchained made the distinction even clearer.

It is a trading card game.

You collect cards, build decks, and battle other players.

Blockchain adds ownership, trading, and crypto-related systems around those cards.

But the card game itself doesn't appear to require all of that.

The current official Getting Started guide walks a new player through creating an account, installing the game, and logging in.

After those steps, it says:

“Technically, this is all you need to play the game.”

It then explains what changes if you don't link an external crypto wallet:

“You will not be able to trade (buy or sell cards) without a linked wallet.”

The same section says that without a linked wallet, players also miss features such as the Forge, Weekend Ranked, and Daily Play & Earn.

Source: Gods Unchained — Getting Started

That suggests something interesting:

The game and the blockchain layer can be separated.

Replace the NFT cards with cards stored in a normal account database, and you can still build decks and play matches.

The ownership and economy would be different.

But the basic card game would remain.

The Sandbox

The Sandbox is different again.

Its official LAND page describes the virtual world as being made up of LAND:

“owned by players to create and monetize experiences.”

The same page says there is a fixed supply of 166,464 LANDs and lists uses including hosting games, building multiplayer experiences, housing, and social experiences.

The creator side is also explicit:

“Create NFT Assets, Games, Experiences & More.”

The page describes selling creations through the NFT Marketplace and charging for access to experiences.

Source: The Sandbox — What is LAND?

Those are real differences.

But I tried the same test.

Could a centralized platform let users control virtual plots, build experiences on them, visit other users' creations, and trade those plots?

Yes.

The ownership relationship would change.

The platform operator would become the authority over the database.

But the basic game and creation systems could still exist.

Play-to-Earn Doesn't Solve It Either

I also thought about Play-to-Earn.

Maybe earning something with real value was the part that fundamentally required blockchain.

But that doesn't seem right either.

A centralized game could keep a player's balance in a database and allow rewards to be exchanged or paid out under whatever rules the operator sets.

Blockchain changes important things around that reward:

Who controls it?

Can it leave the game?

Can it be transferred without the game operator?

Can a third party verify it?

But earning something by playing is not, by itself, a blockchain-only mechanic.

So Far, I Haven't Found One

At least so far, I haven't found a game where I can confidently say:

This game is technically impossible without blockchain.

That doesn't mean such a game doesn't exist.

I'm not an expert on every blockchain game, and there may be examples I haven't seen.

But the examples I looked at made me realize that I may have been asking the wrong question.

If we allow one trusted operator to run a server and control a database, that operator can reproduce an enormous amount of functionality.

Ownership.

Trading.

Scarcity.

Breeding.

History.

Rewards.

Even interoperability can be reproduced if the same operator controls all of the systems involved.

So perhaps the useful question isn't:

Can this game exist without blockchain?

Maybe it is:

What meaningfully changes when blockchain is replaced with a normal database?

Who becomes the authority?

Who can rewrite the history?

What survives if the operator disappears?

Who is allowed to build on top of the data?

Maybe that's where the interesting difference actually is.

So I'm changing the question.

Not:

Blockchain Required?

But:

Blockchain Preferred?

That's what I'll try to figure out next.

Can a Blockchain Game Exist Without Coins, NFTs, or Play-to-Earn?

Sohachi — Wed, 16 Sep 2026 15:06:38 +0000

Recently, I saw an announcement on X about a new blockchain game.

I wasn't particularly interested in that project itself.

What caught my attention was the reaction to it.

There have already been a lot of blockchain games. Some have shut down, while others seem much quieter than they once were.

So when another new blockchain game appeared, many of the reactions I saw were fairly cynical.

Something along the lines of:

Another blockchain game?

But that made me think about something else.

What exactly is a blockchain game?

I'm not an expert on blockchain games.

But from the ones I've seen, there is usually a coin or token, NFTs, a marketplace, and sometimes some form of Play-to-Earn.

There is nothing inherently wrong with any of that.

Still, sometimes the order feels backwards to me.

Instead of starting with a game that needs blockchain in order to work, it can look more like this:

There are coins and NFTs, and the game is where they get used.

That led to another question.

Does the game actually need the blockchain?

Owning characters.

Trading items.

Creating scarce items.

Receiving rewards for playing.

Transferring a character you raised to another player.

It seems like all of those things can also be built with a normal server and database.

The same applies to Play-to-Earn.

Giving players something with real value as a reward for playing doesn't seem to require blockchain by itself.

So I started wondering:

Are there blockchain games where removing the blockchain would actually break the game itself?

That made me want to try thinking about the problem in the opposite direction.

Forget the coin for now.

Forget NFTs.

Forget Play-to-Earn.

Forget marketplaces, prices, and speculation.

Forget starting a game by asking the player to connect a wallet.

Take away the things that are commonly associated with blockchain games and leave only two things:

Blockchain + Game

Then start from there.

Instead of adding blockchain to a game, could a game be designed so that removing the blockchain would also remove something fundamental to the game itself?

Could I make something where, when someone asks:

Why not just use a normal database?

there is actually a good answer?

Maybe this is partly a small counterpoint to the usual idea of a blockchain game.

I've started exploring that question by trying to design a game from the opposite direction.

There isn't really a game yet.

That's intentional.

The first problem is simply this:

Can a game be designed that has a real reason to use blockchain at all?

I'm going to document the process from the beginning, including the ideas that don't survive.

The next question is harder:

Is there actually any kind of game that cannot be meaningfully replaced with a normal database?

How Comparing PAM, PLUR, and PROJECTMEM Changed doll's Design

Sohachi — Wed, 19 Aug 2026 16:00:11 +0000

The previous article compared Portable AI Memory (PAM), PLUR's Engram specification, PROJECTMEM, and doll.

The useful result was not choosing a winner. It was deciding which ideas belong in which layer.

Several things I had been calling "memory" were actually different kinds of state with different authority. That distinction changed concrete parts of doll's design.

The five most important changes are these:

confirmed memory was separated from derived recall state;
interchange formats became adapters instead of candidates for Doll State itself;
project experience became its own append-oriented history rather than current project authority;
imported and model-proposed information was kept below user-confirmed authority;
pre-action continuity checks became a separate deterministic read model rather than another execution authority.

This article is about those design changes, not another comparison of the external projects.

1. MemoryRecord Is Not RecallState

PLUR was useful because its Engram design makes retrieval dynamics visible: activation, decay, reinforcement, associations, usage feedback, and search all affect which memory is useful now.

That is a different question from whether the memory itself is still true.

The distinction sounds obvious until a memory system starts storing retrieval metadata next to the memory content and gradually treats both as one object.

In doll, confirmed MemoryRecord content is canonical durable state. Retrieval ranking, activation-like signals, search scores, and other recall signals are derived state. They can change, expire, or be rebuilt without rewriting what the memory says.

That means a memory is not made "less true" because it has not been retrieved recently, and it is not made "more true" because the system used it many times.

It also gives doll a cleaner failure mode. If a search index or future activation cache is lost, recall quality may temporarily degrade, but confirmed memory does not disappear with it.

Recall can be derived from memory. Memory should not be silently rewritten by recall.

2. PAM Became an Adapter Boundary, Not Doll State

PAM made another boundary much clearer.

Its specification explicitly describes PAM as an interchange format rather than a storage format. That is exactly the kind of boundary doll needs at the edge.

PAM v1.0 specification:

https://portable-ai-memory.org/spec/v1.0/

The tempting alternative would be to adopt a portable external schema as the canonical internal database simply because portability matters. But portability and internal authority are not the same problem.

doll therefore treats PAM v1.0 as an adapter target. Imported data is parsed and mapped into a staged form first. Unsupported or ambiguous semantics remain visible. Imported memories do not become normal confirmed MemoryRecords until they pass the appropriate review boundary.

Export works in the other direction: confirmed non-secret memory can be represented in bounded PAM output without pretending that PAM is a complete Doll State Package.

That last distinction matters. A memory interchange export is not a complete continuity export. It does not by itself contain every project, work item, decision, permission, procedure, recovery state, or execution boundary that makes a long-running AI environment resumable.

Use external standards where they fit the boundary. Do not force the internal authority model to become the interchange format.

3. Project Experience Became History, Not Authority

PROJECTMEM sharpened a different problem: project history should survive beyond chat transcripts and should be useful before the same mistake is repeated.

PROJECTMEM paper:

https://arxiv.org/abs/2606.12329

PROJECTMEM source repository:

https://github.com/riponcm/projectmem

That led doll to make project experience a first-class record instead of leaving failed attempts and lessons trapped inside conversation history.

The implemented ProjectExperienceRecord is append-oriented and can represent observations, hypotheses, attempts, outcomes, resolutions, and lessons. Corrections are represented through linked replacement or supersession rather than silently rewriting the semantic history.

ProjectExperienceRecord implementation:

https://github.com/badjoke-lab/doll/blob/main/src/doll/project_experience.py

But the most important part is what the record is not allowed to do.

An experience record does not complete or reopen a WorkItem. It does not change ProjectRecord scope. It does not create a DecisionRecord. It does not approve a required procedure. It does not grant a permission.

That boundary prevents a very easy category error: confusing "this happened before" with "this is the current authoritative state."

Historical experience can be valuable without being sovereign.

4. Imported and Model-Proposed Information Stay Below Authority

Once interchange and project experience are both first-class concepts, another problem appears immediately: what happens when imported or model-generated records make strong claims?

An imported record might say that a project is complete. A model-generated lesson might say that a particular action should never be attempted again. An external memory format might contain an access field that looks similar to a local permission.

doll does not allow those similarities to manufacture authority.

Imported or model-proposed information can be preserved, linked to provenance, surfaced to the user, and used as evidence. But it cannot silently become policy, permission, current work state, or a hard denial.

This is also why mapping loss has to stay visible. If an external concept does not map exactly onto a Doll concept, the system should preserve the ambiguity instead of inventing a clean equivalence.

A field named confidence is a simple example. One system may mean extraction confidence; another may mean user-reviewed trust. Treating those as equivalent because the names match would make migration look cleaner while damaging the authority model.

Preserve imported knowledge. Preserve uncertainty too.

5. ContinuityPreflight Became a Separate Read Model

The PROJECTMEM comparison also made pre-action checks more concrete. It is useful for a system to look at accepted project history before repeating an action that already failed.

But doll already had separate authority boundaries for policy, work state, procedures, permissions, and capabilities. Folding all of that into one new "memory judgment" layer would have made the architecture harder to reason about.

The resulting implementation is ContinuityPreflight: a deterministic, model-independent read model over explicit accepted project and action scope.

ContinuityPreflight implementation:

https://github.com/badjoke-lab/doll/blob/main/src/doll/continuity_preflight.py

It composes existing authoritative signals such as applicable policy denials, WorkItem blockers and incomplete dependencies, required procedure state, permission resolution, and capability safety state. It can also surface directly relevant prior failures from ProjectExperienceRecord as evidence-linked warnings.

The distinction between warning and authority is intentional. A past failed attempt can warn without becoming a permanent prohibition. Imported or model-proposed experience cannot manufacture a hard deny.

And a preflight result of clear does not grant execution permission. The Capability Broker remains the execution authorization boundary.

A continuity check can inform execution without becoming the thing that authorizes execution.

The Comparison Changed the Boundaries More Than the Feature List

None of these changes means doll should absorb PAM, PLUR, or PROJECTMEM wholesale. In fact, the comparison pushed the design in the opposite direction.

The useful pieces belong at different layers:

PAM belongs at the interchange boundary;
PLUR-like activation and retrieval ideas belong in derived recall state;
PROJECTMEM-like project experience belongs in append-oriented work history;
current project state, permissions, policy, and execution authority remain separate;
pre-action continuity is a deterministic composition over accepted state, not a new source of truth.

That is more important than adding another feature named "memory."

What I Deliberately Did Not Adopt

Comparison is also useful because it identifies ideas that should remain external, derived, or later work.

doll does not currently claim a PLUR adapter or PROJECTMEM adapter. MCP is not implemented as part of this work. PAM interoperability does not mean complete state-package interoperability. ProjectExperienceRecord is not a replacement for WorkItem, DecisionRecord, PolicyRecord, ProcedureRecord, or PermissionRecord.

The project also does not claim that Phase 6, Lite v1.0, primary Intel Mac resource acceptance, or a general anti-lock-in standard is complete.

Those limits matter because architectural comparison is easy to turn into a story about a finished universal layer. doll is not there, and this work does not pretend otherwise.

A More Precise Definition of Continuity

The comparison left doll with a more precise definition of what it is trying to preserve.

Continuity is not just the ability to export a list of memories. It is not just a better retrieval algorithm. It is not just a durable project log. And it is not just an agent remembering previous failures.

Those are all useful parts.

But continuity also requires keeping authority explicit: what is confirmed, what is derived, what is historical, what was imported, what is currently blocked, what requires permission, what may execute, and what can be rebuilt after a model, provider, runtime, interface, or machine changes.

Standardize interchange. Derive recall. Preserve experience. Keep authority explicit.

Sources

Previous doll article — Portable Memory Is Not AI Continuity: PAM, PLUR, PROJECTMEM, and doll

https://doll.badjoke-lab.com/notes/portable-memory-not-ai-continuity/

Portable AI Memory — Specification v1.0

https://portable-ai-memory.org/spec/v1.0/

PLUR — The Engram Specification v2.1

https://plur.ai/spec.html

PROJECTMEM paper

https://arxiv.org/abs/2606.12329

PROJECTMEM source repository

https://github.com/riponcm/projectmem

doll — Memory Interoperability, Recall, and Project Experience specification

https://github.com/badjoke-lab/doll/blob/main/docs/spec/03c-memory-interoperability-recall-and-project-experience.md

doll — ProjectExperienceRecord implementation

https://github.com/badjoke-lab/doll/blob/main/src/doll/project_experience.py

doll — ContinuityPreflight implementation

https://github.com/badjoke-lab/doll/blob/main/src/doll/continuity_preflight.py

Canonical doll article:

https://doll.badjoke-lab.com/notes/pam-plur-projectmem-changed-doll-design/

External specifications and project descriptions referenced here were checked for the preceding comparison article on August 16, 2026. This article focuses on doll's resulting design decisions and merged implementation boundaries. It does not imply that PAM, PLUR, or PROJECTMEM endorse doll's architecture.

Disclosure: This article was prepared with AI assistance and reviewed, edited, and approved by the project maintainer.

Portable Memory Is Not AI Continuity: PAM, PLUR, PROJECTMEM, and doll

Sohachi — Sun, 16 Aug 2026 16:37:50 +0000

A few days ago I wrote that AI memory is becoming more portable, but portability is still not the same thing as continuity.

The obvious next question is whether that distinction already exists elsewhere in more concrete technical form.

It does.

Three projects are especially useful to compare with doll: Portable AI Memory (PAM), PLUR's Engram specification, and PROJECTMEM. They overlap with parts of what doll is trying to do, but they start from different problems and make different things canonical.

This is not a ranking and it is not a competitor roundup. The useful question is narrower:

Which ideas should doll adopt, which boundaries should remain separate, and where should interoperability replace another private format?

The short version

The four systems are easiest to understand as different layers:

PAM: how memory can cross system boundaries in a vendor-neutral interchange format.
PLUR / Engram: how persistent memories can be retrieved, activated, reinforced, and allowed to decay over time.
PROJECTMEM: how project experience can be recorded as local event history and used to warn an agent before it repeats a known failure.
doll: how memory, projects, decisions, work state, provenance, permissions, recovery, and model-independent execution state can remain resumable when the model or provider changes.

Those are not mutually exclusive answers.

The most useful result of comparing them is that doll should not try to turn all four jobs into one record type or one proprietary memory format.

PAM: standardize what crosses the boundary

Portable AI Memory is the clearest answer to the interchange problem.

PAM v1.0 defines a vendor-neutral JSON format for moving user memories between systems. Its specification includes provenance, lifecycle state, confidence, relations, access metadata, integrity information, optional conversation files, and optional embeddings.

Specification:
https://portable-ai-memory.org/spec/v1.0/

The most important scope boundary is simple:

PAM is an interchange format, not a storage format.

That distinction fits doll unusually well.

A portable format does not need to become the internal database schema. The internal system can preserve richer local semantics while importing and exporting a stable external contract at the boundary.

That is the approach doll now takes. PAM is treated as an adapter target rather than as Doll State itself. The implemented PAM path is deliberately staged: external data is parsed and mapped, ambiguous or unsupported semantics stay visible, imported memories require explicit review before becoming normal confirmed MemoryRecords, and confirmed non-secret memories can be exported back to bounded PAM v1.0 output.

This matters because a field that exists in two systems is not necessarily authoritative in the same way.

An imported lifecycle label, confidence score, relation, or access declaration may be useful evidence without automatically becoming a doll permission, decision, or policy.

PAM therefore answers an important part of the portability problem without needing to answer the entire continuity problem.

PLUR: memory is not just stored or retrieved

PLUR's Engram specification starts from a different question.

Its Engram model describes an atomic unit of learned knowledge that is individually addressable, activation-weighted, and decay-aware. It specifies activation, decay, reinforcement, associations, usage feedback, and a search pipeline.

Specification:
https://plur.ai/spec.html

The useful idea here is not merely "store more metadata."

It is that what a memory says and how useful it is to retrieve right now are different kinds of state.

Consider a durable memory:

The user prefers local-first tools when the core workflow can remain complete offline.

The content of that memory should not silently change because it was retrieved ten times this week, ignored for a month, or ranked lower by a new search algorithm.

That observation sharpened an important boundary in doll: confirmed MemoryRecord content remains authoritative memory, while recall state is derived and rebuildable.

Ranking, activation-like signals, retrieval scores, and future usage signals belong to the recall layer, not to the truth of the memory itself.

This also means doll does not need to copy PLUR's engine-specific state into its canonical memory schema. A future PLUR adapter can preserve and translate what is meaningful without pretending that every activation or decay parameter is universal memory truth.

PROJECTMEM: project history can act before the next mistake

PROJECTMEM is closer to a different part of doll.

Its paper describes a local-first, event-sourced memory and judgment layer for coding agents. Development history is recorded as append-only typed events such as issues, attempts, fixes, decisions, and notes. The system then projects that history into compact summaries and includes a deterministic pre-action gate that can warn before a previously failed fix is repeated or a known-fragile file is edited.

Paper:
https://arxiv.org/abs/2606.12329

Source repository:
https://github.com/riponcm/projectmem

The key insight is that project memory is not only something an agent searches after it gets confused.

Prior experience can be checked before an action is repeated.

doll now has a related but deliberately separated pair of concepts:

ProjectExperienceRecord stores append-oriented semantic work history such as observations, hypotheses, attempts, outcomes, resolutions, and lessons.
ContinuityPreflight reads accepted project state before a proposed action and can surface a directly relevant prior failure as an evidence-linked warning.

ProjectExperienceRecord implementation:
https://github.com/badjoke-lab/doll/blob/main/src/doll/project_experience.py

ContinuityPreflight implementation:
https://github.com/badjoke-lab/doll/blob/main/src/doll/continuity_preflight.py

But there is an important authority boundary.

A past failed attempt is not automatically a permanent prohibition. Imported project history is not automatically trusted. A model-proposed lesson does not become a policy. A remembered claim that work is complete does not complete the WorkItem.

In doll, prior experience can warn.

Hard blocking still comes from existing authoritative state such as an applicable policy denial, a blocked or incomplete WorkItem dependency, an unapproved required procedure, a permission decision, or a capability safety boundary.

That separation is intentional:

Experience can inform authority without quietly becoming authority.

One word, several kinds of state

The comparison makes "memory" look too broad to be a useful architecture by itself.

At least five different layers appear.

1. Canonical durable state

Things the system is expected to preserve as authoritative user-owned state: confirmed memory, project scope, accepted decisions, work state, permissions, policies, artifacts, and their provenance.

2. Derived recall state

Search indexes, ranking scores, activation-like values, retrieval candidates, and other state that can be rebuilt from authoritative data.

3. Experience history

What was tried, what failed, what worked, what was later corrected, and which evidence supports that history.

4. Interchange formats

External contracts such as PAM that let some of those semantics cross system boundaries without dictating the local storage engine.

5. Pre-action continuity checks

Deterministic checks that ask whether accepted state already contains a blocker, confirmation requirement, incomplete dependency, required procedure, or relevant failure before another action begins.

Combining all five into a single "memory object" would make portability look simpler while making authority harder to reason about.

The hard part is not mapping fields. It is mapping meaning.

Suppose two systems both have a field called confidence.

One may mean model-estimated extraction confidence. Another may mean a user-reviewed trust state. Treating those as interchangeable because the field names look similar would create semantic loss while claiming successful migration.

The same problem appears with:

active versus authoritative;
remembered versus confirmed;
decision versus historical note;
permission versus imported access metadata;
failed attempt versus permanent prohibition;
retrieval score versus memory truth;
conversation history versus current project state.

A continuity system therefore needs to preserve loss and uncertainty, not hide them.

When an external format cannot express a doll semantic exactly, the safer result is an explicit partial mapping, preserved original evidence, or quarantine—not a fabricated equivalence.

Why doll should prefer adapters over another universal format

It would be easy for doll to define its own grand interchange format for memory, projects, decisions, experiences, permissions, conversations, and everything else.

That would also be an easy way to create another island.

Where a useful external contract exists, the better default is to adapt to it.

PAM is already the first general memory-interchange target in doll. PLUR and PROJECTMEM are later interoperability candidates where their semantics match a real boundary. MCP is also later work rather than something that should be smuggled into the core state model just because several adjacent projects use it.

The relevant doll roadmap is here:
https://github.com/badjoke-lab/doll/blob/main/docs/spec/09a-post-imp-083-memory-continuity-roadmap.md

The memory interoperability, recall, and project experience specification is here:
https://github.com/badjoke-lab/doll/blob/main/docs/spec/03c-memory-interoperability-recall-and-project-experience.md

The canonical Doll State can remain richer than any one interchange format while still avoiding gratuitous proprietary formats at the edges.

These projects are more complementary than competitive

PAM is strongest as a portable contract.

PLUR is useful for thinking about retrieval dynamics and memory-use state.

PROJECTMEM demonstrates how local project history can become deterministic pre-action judgment.

doll needs pieces of all three problem areas because its target is broader continuity across models, runtimes, providers, interfaces, and machines.

That does not make doll a superset of those projects. It means its architecture has to decide where their ideas belong without collapsing their different semantics into one internal abstraction.

The resulting rule is simple:

Standardize interchange. Derive recall. Preserve experience. Keep authority explicit.

That is a much more useful foundation for continuity than treating every persistent fact, score, event, and permission as "memory."

What comes next

The comparison has already changed concrete boundaries in doll:

MemoryRecord is separated from derived RecallState;
PAM is an adapter instead of the canonical store;
ProjectExperienceRecord is append-oriented history rather than current project authority;
ContinuityPreflight can use prior failures as warnings without allowing imported or model-proposed experience to manufacture a hard denial.

The next article in this series will focus on those design changes themselves: what changed, what was deliberately not adopted, and which interoperability work remains later.

The larger goal remains the same: the model can change, the provider can change, and the interface can change without forcing the user's durable AI environment to start over.

Sources

Portable AI Memory — Specification v1.0

https://portable-ai-memory.org/spec/v1.0/
PLUR — The Engram Specification v2.1

https://plur.ai/spec.html
PROJECTMEM paper

https://arxiv.org/abs/2606.12329
PROJECTMEM source repository

https://github.com/riponcm/projectmem
doll — Post-IMP-083 Memory & Continuity Roadmap

https://github.com/badjoke-lab/doll/blob/main/docs/spec/09a-post-imp-083-memory-continuity-roadmap.md
doll — Memory Interoperability, Recall, and Project Experience specification

https://github.com/badjoke-lab/doll/blob/main/docs/spec/03c-memory-interoperability-recall-and-project-experience.md
doll — ProjectExperienceRecord implementation

https://github.com/badjoke-lab/doll/blob/main/src/doll/project_experience.py
doll — ContinuityPreflight implementation

https://github.com/badjoke-lab/doll/blob/main/src/doll/continuity_preflight.py

This is a syndicated version of the canonical doll article:

https://doll.badjoke-lab.com/notes/portable-memory-not-ai-continuity/

External specifications, paper metadata, and current project descriptions were checked on August 16, 2026. PAM claims refer to the published v1.0 specification; PLUR claims refer to the Engram v2.1 specification; PROJECTMEM architecture claims distinguish the cited research paper from the current source repository. Statements about how these ideas should map into doll are doll's design analysis, not claims made by the external projects.

Disclosure: This article was prepared with AI assistance and reviewed, edited, and approved by the project maintainer.

AI Memory Is Becoming Portable. Continuity Still Isn't.

Sohachi — Wed, 12 Aug 2026 10:36:27 +0000

Moving your chats is progress. Moving your AI life is a different problem.

AI services are finally starting to make switching less painful.

Google now lets eligible Gemini users import memory-like context and chat history from other AI platforms, including exports from ChatGPT and Claude.

That is real progress.

For a long time, “portability” often meant little more than downloading a ZIP file and keeping it somewhere safe. Now a major AI provider is treating another provider’s history as something that can become useful context again.

But that raises a more important question:

What exactly has moved?

Export is not portability

ChatGPT can export your history and account data.

Claude can export conversation and user data.

Gemini can export chats, generated media, uploads, Gems data, and other activity through Google Takeout.

Those features matter.

But an archive is not a working AI environment.

OpenAI’s own guidance for moving conversations between personal ChatGPT accounts makes this distinction clear. You can upload an exported conversations.json file into a new chat and use it as reference material.

But OpenAI explicitly says this is not a full migration.

It does not recreate the original chats, sidebar structure, settings, memories, GPTs, files, subscriptions, or workspace access.

You can carry the record of the past without recreating the environment that produced it.

Export is not portability. And portability is not continuity.

There are really four different problems

I think AI portability is easier to understand if we separate four layers.

1. Exportability

You can get your data out.

JSON, ZIP, HTML, media files, or another documented archive format.

This protects against total lock-in, but by itself it is closer to backup than migration.

2. Importability

Another system can accept that exported material.

Gemini’s new cross-platform import flow is an important example.

3. Portability

The imported material remains useful in the destination.

It can be searched, referenced, or reused as context instead of sitting there as an inert archive.

This is where the industry is starting to make real progress.

4. Continuity

You can change the model, provider, application, runtime, or machine and still resume from where you were.

Not merely recover what you once said.

That is a different engineering problem.

Chat history is not current state

Imagine someone who has spent a year building software with an AI assistant.

They successfully move ten thousand old conversations to a new provider.

That is valuable.

But does the new system now know:

which issue is currently being worked on;
which pull request is authoritative;
which specification is current;
which design was rejected and why;
which decisions are final and which are provisional;
which failure must not be repeated;
what has already been tested;
what should happen next?

Some of those answers may exist somewhere inside the transcript.

That is not the same as having current state.

A transcript tells a new model what happened.

A continuity layer must also preserve what remains true now, what has been superseded, where a claim came from, and what work is still open.

Chat history is a record of the past. Continuity is the ability to resume from it.

Chat history is not work state

Browser state is a simple example.

When OpenAI ended Atlas, users were told to save important Atlas data before shutdown. Bookmarks would not transfer automatically, open tabs might not transfer, and browser history might not transfer.

Meanwhile, ChatGPT conversation history was separate.

That illustrates a broader point:

The state of an AI-assisted task does not live only in the transcript.

It may also live in:

open pages;
files;
tabs;
repositories;
pending actions;
tools;
local artifacts;
external systems.

Chat history is not work state.

Memory is not the whole continuity layer either

Portable memory is important, but memory alone is still too narrow.

A memory like:

The user prefers concise answers.

is useful.

But compare that with:

Approach B replaced approach A because of constraint X. The decision was accepted in issue 123, and later implementation assumes B unless explicitly superseded.

That is not just “memory.”

It is part of project authority and decision state.

A durable AI environment may need to preserve:

memory and preferences;
project state;
decision history;
provenance;
unresolved work;
relationships between records;
current authority;
recovery information;
tool and workflow state.

Remembering who the user is and knowing where the user currently is in a long-running body of work are related problems.

They are not the same problem.

Provider-to-provider portability is still provider-dependent

Gemini’s importer deserves credit because it reduces switching cost.

But look at the architecture:

ChatGPT / Claude
       ↓
     Gemini
       ↓
  Provider C

ChatGPT and Claude data become portable into Gemini because Google built the importer.

If the user later moves again, Provider C needs to understand enough of the previous provider’s exports to make that migration useful.

This is much better than no portability.

But it is still provider-to-provider portability.

Put the canonical state outside the provider

A different architecture is possible:

         User-owned continuity
 memory / decisions / projects / state
                    ↓
                  doll
        ↙           ↓           ↘
    Local AI     ChatGPT     Gemini / Claude / ...

In this model, the canonical copy of durable state does not live inside whichever AI service happens to be active today.

The provider is a capability layer.

It receives the context it needs, does the work it is good at, and can be replaced later.

The continuity layer remains under the user’s control.

If an import format changes, an adapter can change.

If a model is discontinued, another model can be used.

If cloud access disappears, the durable state does not disappear with it.

What doll is trying to separate

This distinction is central to doll.

doll is not trying to become the foundation model that survives forever.

It is trying to make the foundation model replaceable.

The continuity layer belongs on the user’s side:

memory;
preferences and personality settings;
project state;
DecisionRecords;
provenance;
work state;
user-owned data and recovery state.

The capability layer can change:

local models;
OpenAI;
Anthropic;
Gemini;
future models that do not exist yet.

The principle is simple:

Own the continuity. Rent the capability.

Continuity is harder than portability

None of this means continuity is solved.

It creates harder questions:

What deserves to become durable memory?

How should stale information be superseded?

How should conflicting records be resolved?

Which state is authoritative and which state is only evidence?

How should continuity adapt to models with different context windows, tools, safety boundaries, and capabilities?

How much provider-specific state can be translated before the translation becomes fiction?

Those questions are harder than exporting a ZIP file.

That is exactly why portability and continuity should not be treated as synonyms.

From a portable past to a resumable one

The direction of the industry is encouraging.

ChatGPT, Claude, and Gemini all provide meaningful ways to export user data.

Gemini now goes further by importing memory-like context and full chat histories from other AI platforms.

OpenAI provides a reference-based way to reuse exported conversations in another personal ChatGPT account.

This is not evidence that portability has failed.

It is evidence that portability has become important enough for major providers to build it.

The next question is whether users can own the layer above it.

Your AI should not merely let you export the past. It should let you continue from it.

Sources

Google — Import from other AI platforms to Gemini Apps
https://support.google.com/gemini/answer/16868299?hl=en
OpenAI — Exporting your ChatGPT history and data
https://help.openai.com/en/articles/7260999-how-do-i-export-my-data
Claude Help Center — Export your Claude data
https://support.claude.com/en/articles/9450526-export-your-claude-data
Google — Download your Gemini Apps data
https://support.google.com/gemini/answer/16920332?hl=en
OpenAI — Transfer exported conversations between ChatGPT accounts
https://help.openai.com/en/articles/9106926-transferring-conversations-from-1-chatgpt-account-to-another-chatgpt-account
OpenAI — Evolving Atlas into ChatGPT for browser-based agentic work
https://help.openai.com/en/articles/20001371

Originally published on the official doll site:
https://doll.badjoke-lab.com/notes/ai-memory-portability-continuity/

Frontier AI Is Becoming Infrastructure. Your Memory Should Not Live Inside It.

Sohachi — Sun, 19 Jul 2026 13:31:59 +0000

Until recently, AI was mostly something we used as a service.

We asked it questions.

We used it to write, code, search, summarize, and generate images.

We paid for access through a browser or an API.

But frontier AI is beginning to take on a different role.

In July, the White House formally launched a cybersecurity coordination initiative called GOLD EAGLE. It brings together AI developers, government agencies, critical-infrastructure operators, and open-source software participants to coordinate the discovery and remediation of software vulnerabilities.[1]

This is not just another AI product launch.

It is an early example of frontier AI entering the operational loop of critical infrastructure.

AI is no longer only helping people interact with software.

It is beginning to help decide which vulnerabilities matter, whether they are real, how urgently they should be fixed, and how remediation should be coordinated across systems that society depends on.

That raises a question for anyone building a personal AI system:

If frontier AI is becoming infrastructure, should your memory and work state live entirely inside it?

What GOLD EAGLE is designed to do

The initiative follows Executive Order 14409, signed on June 2, 2026.

The order directed US agencies to form an AI cybersecurity clearinghouse in voluntary collaboration with the AI industry and operators of critical infrastructure.[2]

Its responsibilities include:

coordinating vulnerability scanning;
avoiding duplicated work across organizations;
discovering and validating software vulnerabilities;
prioritizing remediation;
and coordinating the distribution of patches.

The order also directed agencies to improve access to advanced cybersecurity tools for critical-infrastructure operators, including rural hospitals, community banks, and local utilities.

Reuters described the initiative as a coordination group connecting AI developers with providers of essential services such as financial institutions, hospitals, and energy networks.[3]

The Wall Street Journal reported that the platform had already begun operating on July 2 and was being used as a clearinghouse for sharing AI-discovered vulnerabilities and possible fixes.[4]

This means frontier models are moving beyond the role of general-purpose assistants.

They are entering a process that looks more like this:

discover vulnerability
        ↓
validate the finding
        ↓
compare it with other reports
        ↓
decide remediation priority
        ↓
coordinate and distribute a patch

That is not merely content generation.

It is infrastructure operations.

What this does not mean

It is important not to exaggerate what has happened.

GOLD EAGLE is structured around voluntary collaboration.

The US government has not taken ownership of frontier AI companies.

It has not created a rule requiring every model release to receive government permission.

The White House explicitly stated that the executive order does not authorize mandatory government licensing, pre-clearance, or permitting for the development, publication, release, or distribution of AI models.[5]

So the accurate conclusion is not:

The government now controls all AI.

The more defensible conclusion is:

Frontier AI has become important enough that governments, AI companies, and critical-infrastructure operators are beginning to share the same operational systems.

Ownership is not the main issue.

The important change is the role frontier AI is being given.

From access to priorities

I recently wrote about another change in frontier AI.

Anthropic temporarily suspended access to already-released models after receiving a US government directive.

OpenAI introduced GPT-5.6 through a limited preview while working with government officials before broader availability.

China was reportedly considering possible controls on overseas access to its most advanced models.

The central question in those cases was:

Who will be allowed to use frontier AI?

GOLD EAGLE points to a related but different question:

Who and what will frontier AI be expected to serve first?

Protecting hospitals is important.

Protecting energy networks is important.

Protecting banking systems, government infrastructure, and widely used open-source software is important.

Using advanced AI for those purposes may be entirely reasonable.

But as frontier AI becomes connected to national security and essential services, its development and deployment will no longer be shaped only by the needs of ordinary users and software developers.

Its priorities will increasingly be influenced by:

national-security requirements;
critical-infrastructure protection;
government evaluation;
regulated industries;
large institutional users;
and coordinated cyber-defense operations.

This does not mean individual users will suddenly lose access.

It means the priorities of the system are changing.

Cloud AI is not becoming weaker

This is not an argument against cloud AI.

In fact, the opposite is probably true.

If governments, infrastructure operators, and major companies rely on frontier AI, more resources will flow toward it.

The models may become much better at:

analyzing large codebases;
identifying vulnerabilities;
tracing possible attack paths;
comparing findings across systems;
prioritizing security work;
and suggesting remediation.

Cloud AI is unlikely to become less capable because it is becoming infrastructure.

It may become dramatically more capable.

But capability and continuity are not the same thing.

A model may be extremely powerful while remaining outside the user's control.

The provider still determines:

pricing;
access conditions;
supported regions;
API behavior;
product boundaries;
data-export options;
and when a model or interface is replaced.

Users usually do not own the model.

They rent access to its capabilities under the conditions available at that moment.

That arrangement can be completely reasonable.

The problem begins when the user's entire AI environment becomes inseparable from it.

A model is not your AI environment

After months or years of use, an AI system contains much more than a chat interface.

It may contain:

long-term memory;
personal preferences;
response settings;
project history;
previous decisions;
reference files;
tool connections;
unfinished work;
and the context needed to resume that work.

The foundation model is only one component.

The user's actual AI environment is the combination of the model and all the state accumulated around it.

Switching from one model to another may be technically easy.

Reconstructing years of context is not.

A system is not meaningfully portable when its model can be replaced but its memory, settings, and work state cannot.

Own the continuity. Rent the capability.

I think personal AI systems need to separate two layers.

The first is the capability layer.

This is where the model lives.

Use the best model for the task.

Use OpenAI when OpenAI is the best option.

Use Anthropic when Anthropic is better.

Use an open-weight model when control or deployment flexibility matters.

Use a local model when offline operation or minimum independence is required.

This layer can change over time.

The second is the continuity layer.

This should contain the state that allows the user to continue:

memory;
identity and response preferences;
project state;
work history;
reference data;
provider configuration;
portable conversation records;
and the information required to resume interrupted work.

The design principle is simple:

Own the continuity. Rent the capability.

This does not require rejecting cloud services.

It requires avoiding a design where one cloud service is the only system capable of understanding the user's accumulated state.

Why I am building doll

This is one of the reasons I am building doll.

doll is not an attempt to build a foundation model that competes with OpenAI, Anthropic, or major open-model projects.

It is not an attempt to eliminate cloud AI.

The goal is to keep memory, identity, settings, important data, and work state on the user's side while allowing the model underneath them to change.

The intended structure looks like this:

text user-owned memory, settings, data, and work state ↓ doll ↓ local model / cloud model / future model

When a strong cloud model is available, doll should be able to use it.

When a better provider appears, the capability layer should be replaceable.

When external access is unavailable, a local model should provide minimum continuity even if its performance is lower.

The thing that changes should be the reasoning engine.

The thing that remains should be the user's accumulated state.

This is what I mean by local-complete, cloud-optional.

Local operation should be sufficient to preserve the core system.

Cloud models should extend its capabilities rather than define whether it continues to exist.

What remains after the model changes

Frontier AI becoming part of critical-infrastructure cybersecurity is not necessarily a bad development.

If these models can help protect hospitals, banks, utilities, public systems, and open-source software, society may benefit greatly.

It may also make frontier AI more capable, more heavily funded, and more operationally important than it is today.

But the more institutional and infrastructure-like it becomes, the less sensible it is to treat it as though it were a permanent personal possession.

Using infrastructure is not the same as owning it.

Depending on powerful models is not the same as surrendering all continuity to them.

The most important part of an AI system may not be the model.

It may be the part that remains after the model changes.

Notes and Sources

[1] The White House — White House Launches Gold Eagle Initiative for Unprecedented Cybersecurity Vulnerability Coordination
Official announcement of the GOLD EAGLE initiative and its role in coordinating vulnerability discovery, prioritization, remediation information, government agencies, industry participants, and critical-infrastructure defenders.
https://www.whitehouse.gov/releases/2026/07/white-house-launches-gold-eagle-initiative-for-unprecedented-cybersecurity-vulnerability-coordination/

[2] The White House — Promoting Advanced Artificial Intelligence Innovation and Security, Executive Order 14409
The June 2 executive order establishing a voluntary AI cybersecurity clearinghouse and directing coordination of vulnerability scanning, validation, remediation, and patch distribution.
https://www.whitehouse.gov/presidential-actions/2026/06/promoting-advanced-artificial-intelligence-innovation-and-security/

[3] Reuters — US to launch AI and cybersecurity coordination group, White House says
Report on the coordination group connecting AI developers with providers of essential services, including financial institutions, hospitals, and energy networks.
https://www.reuters.com/technology/us-launch-ai-cybersecurity-coordination-group-white-house-says-2026-07-14/

[4] The Wall Street Journal — White House Launches Platform for Companies to Share AI Cyber Threats, Fixes
Report identifying the platform as GOLD EAGLE and describing its operation as a clearinghouse for sharing AI-discovered vulnerabilities and fixes.
https://www.wsj.com/livecoverage/stock-market-today-bank-earnings-07-14-2026/card/white-house-launches-platform-for-companies-to-share-ai-cyber-threats-fixes-rS4BBZz2WNdjBcn9J5pK

[5] The White House — Fact Sheet: President Donald J. Trump Promotes Advanced Artificial Intelligence Innovation and Security
Official clarification that the order does not authorize mandatory government licensing, pre-clearance, or permitting requirements for model development or release.
https://www.whitehouse.gov/fact-sheets/2026/06/fact-sheet-president-donald-j-trump-promotes-advanced-artificial-intelligence-innovation-and-security/

A longer version was originally published on the doll official website.

The Best AI in the World Is Useless If You Can't Access It

Sohachi — Wed, 08 Jul 2026 14:46:23 +0000

China is reportedly considering whether its most advanced AI models should remain freely accessible overseas.

That matters because the United States has already shown what government involvement in frontier AI access can look like.

In the last few weeks, we have seen:

already-released AI models become unavailable because of government policy;
the broad rollout of a frontier model delayed while a company worked with government officials;
and now, reports that China is discussing possible restrictions on overseas access to its own advanced models.

We spend a lot of time asking which AI model is best.

But another question may be becoming just as important:

Will you still be able to use it tomorrow?

China is now discussing the access question

On July 7, Reuters reported that Chinese authorities had met with major technology companies to discuss possible restrictions on overseas access to China's most advanced AI models.

Alibaba, ByteDance, and Z.ai were among the companies reportedly involved in the discussions.

The talks were said to include not only closed models, but potentially more open forms of model distribution as well.

Nothing has been decided.

China has not blocked foreign access to its leading AI models.

The restrictions may never happen.

But the fact that the question is now being discussed is significant.

For the last few years, it was possible to imagine AI becoming something close to a global software market.

American companies would compete with Chinese companies.

Open-weight models would cross borders.

Developers would choose models based mainly on capability, price, latency, context length, and product quality.

That assumption is becoming harder to make with confidence.

Because this is not happening in isolation.

The United States has already shown another version of the same problem.

A model can still exist and become unavailable

On June 12, the US government applied export restrictions to Anthropic's Claude Fable 5 and Claude Mythos 5.

According to Anthropic, the directive required the company to prevent foreign nationals from accessing those models.

Anthropic said it could not reliably determine nationality in real time.

So it suspended access for everyone.

The model did not disappear.

The company did not shut down.

The infrastructure did not fail.

Policy changed, and access disappeared.

The restrictions were later lifted, and Anthropic announced that Fable 5 would return globally.

So this particular interruption was temporary.

But the larger lesson remains.

A frontier AI model can exist, work, and remain technically operational while policy determines whether users are allowed to reach it.

That is no longer a theoretical risk.

OpenAI showed a different version of the same shift

OpenAI's GPT-5.6 rollout followed a different path.

When OpenAI announced the model family on June 26, it did not immediately make the models broadly available.

OpenAI said it had shown the models and its release plans to the US government.

At the government's request, the company began with a limited preview for a small group of trusted partners.

OpenAI also said it did not want this kind of government-access process to become the long-term default.

On July 8, Reuters reported that the broader GPT-5.6 rollout was moving forward after additional testing and discussions between OpenAI and US officials.

The important point is not simply that GPT-5.6 is becoming more widely available.

It is that the timing and scope of a frontier-model rollout became something discussed with government before broad public access.

This does not mean every AI release is now directly controlled by the state.

But national-security policy is moving much closer to the point where advanced AI reaches ordinary users and developers.

What happens if AI stops being one global market?

It is too early to say that AI will split into national blocs.

That outcome is not inevitable.

I hope it does not happen.

But it is no longer difficult to imagine.

One possible future could include:

a US-centered AI ecosystem;
a Chinese AI ecosystem;
separate European regulatory requirements;
different access conditions depending on country, nationality, industry, or organization.

In that world, asking "What is the best model?" is not enough.

You also have to ask:

Can I access it from where I live?
Can my organization use it?
Will the API remain available in my region?
Can I export my data if access changes?
Can I move my work to another model?
What still works if the provider, policy, or network changes?

Today, choosing a provider because it is cheaper or more capable may be completely rational.

The problem begins when years of memory, work, configuration, and dependency are built around the assumption that the same access conditions will continue indefinitely.

Provider lock-in may become a bigger problem than we expected

Developers already understand provider lock-in.

We know that an API can change.

Pricing can change.

Models can be retired.

Terms can change.

A company can shut down a service.

But frontier AI introduces another layer.

The provider may not be the only actor that determines access.

Government policy may influence:

who can use a model;
where it can be used;
when it can be released;
whether overseas access remains available;
and which organizations receive early access.

That changes the continuity problem.

It is no longer only:

What happens if my provider changes its product?

It may also become:

What happens if access to the provider itself changes because of policy?

AI resilience may matter as much as AI performance

None of this is an argument for abandoning cloud AI.

Frontier cloud models are likely to remain more capable than local models for many tasks.

They may offer better reasoning, better coding assistance, larger context windows, stronger multimodal capabilities, and access to infrastructure that most individuals cannot run locally.

Use them.

Use the best model available for the work in front of you.

But using a powerful service is different from designing your entire digital life so that nothing survives when access to that service changes.

I think AI resilience may become as important as AI performance.

That means designing systems where:

models can be replaced;
providers can be changed;
data can be exported;
memory does not exist only inside one company's service;
a local model can provide minimum continuity when cloud access is unavailable;
the user's accumulated state survives even when the reasoning engine underneath it changes.

A local model does not have to beat the best cloud model to be useful in this design.

It can simply keep the system alive.

It can preserve access to the user's own state.

It can provide a fallback path until another source of capability is available.

Why I am building doll

This is one of the reasons I am building doll.

doll is not an attempt to build a foundation model that competes with OpenAI, Anthropic, or Chinese AI labs.

It is an attempt to keep memory, identity, settings, data, work state, and continuity on the user's side while allowing the underlying AI model to change over time.

The design principle is simple:

local continuity first, cloud capability when available.

Cloud models can be used for additional performance.

Local models can provide a continuity path.

The model can change without forcing the user's entire AI environment to disappear with it.

I do not know whether AI will actually divide into national blocs.

I do not know whether future access restrictions will become broader or more permanent.

I hope they do not.

But after the events of the last few weeks, the possibility is harder to dismiss.

The most important AI may not be the smartest one.

It may be the one you can still use tomorrow.

Sources

Originally published in a longer form on the doll website.

The Gate Before the Public

Sohachi — Sat, 27 Jun 2026 11:30:43 +0000

Claude Mythos 5, GPT-5.6, and who gets access before everyone else

In my previous article, “Is Access to Frontier AI Becoming Permissioned?”, I looked at signs that the US government was becoming involved not only in frontier-model safety evaluation, but also in decisions about release timing and early access.

At that point, some of the information surrounding GPT-5.6 was still based on reporting. Anthropic’s Claude Fable 5 and Claude Mythos 5, meanwhile, had been disabled for every customer following a US government directive.

The situation changed again on June 26.

Anthropic announced that Mythos 5 could return for a limited set of US organizations. OpenAI officially introduced the GPT-5.6 family, but began with a restricted preview for a small group of partners at the US government’s request.

Neither development can be summarized as a simple ban or a full reversal.

Anthropic did not restore Mythos 5 to everyone.

OpenAI did not cancel GPT-5.6’s broader release.

What emerged instead was a gate between a finished frontier model and the public.

That gate is not one clearly defined law or licensing system. It is a mixture of export controls, government requests, security reviews, trusted-partner programs, and non-public eligibility lists.

But its practical function is becoming visible:

A frontier model may be ready, working, and commercially valuable while broad public access still depends on a separate review and selection process.

Mythos 5 Has Not Fully Returned

On June 12, the US government issued an export-control directive requiring Anthropic to suspend access to Fable 5 and Mythos 5 by foreign nationals.

The restriction did not apply only to users outside the United States.

It also covered foreign nationals inside the country and Anthropic’s own foreign-national employees.

Anthropic said it could not immediately separate access by nationality with sufficient confidence. To comply with the directive, it disabled both models for every customer.

Anthropic explained the original suspension in an official statement.

On June 26, Anthropic announced that the situation had partially changed.

The company said the government had informed it that Mythos 5 could be redeployed to a set of US organizations that operate and defend critical infrastructure.

Anthropic announced the limited redeployment on its official X account.

Anthropic said it was restoring access for those organizations and would continue working with the government to expand Mythos 5 access and make Fable 5 generally available again.

That wording matters.

Mythos 5 did not return for all US customers.

It did not return for the general public.

Fable 5 also remained unavailable for general use.

The most accurate description is therefore:

Mythos 5 was allowed to return for a limited set of US organizations involved in operating and defending critical infrastructure.

This was not a complete repeal of the original restrictions.

It was a controlled reopening.

“More Than 100 Organizations” Is a Reported Figure

Reuters reported, citing an anonymous person familiar with the matter, that more than 100 companies and institutions would be able to use Mythos 5.

The group reportedly includes several Fortune 500 companies.

That figure should be treated carefully.

Anthropic’s official announcement did not provide a number. It described the recipients only as a set of US organizations that operate and defend critical infrastructure.

The reported total also does not mean that more than 100 US government agencies received access.

It reportedly includes companies, infrastructure operators, institutions, and government organizations.

The complete list has not been made public.

Reuters also reported that organizations on the approved list, their foreign-national employees, and Anthropic’s foreign-national employees would not need new export licenses to use Mythos 5.

Restrictions would remain for organizations outside that list.

Reuters reported the details of the limited return here.

The most important question is not whether the total is exactly 100, 110, or 120.

It is this:

Why were those organizations allowed through the gate while other companies, researchers, and developers remained outside it?

The selection criteria and the full list remain outside public view.

GPT-5.6 Began on the Other Side of the Same Gate

On the same day, OpenAI officially announced the GPT-5.6 family.

The lineup includes:

GPT-5.6 Sol, the flagship model
GPT-5.6 Terra, designed to balance performance and cost
GPT-5.6 Luna, the lower-cost option

OpenAI described Sol as its most capable model.

It said Terra would offer performance competitive with GPT-5.5 at roughly half the price, while Luna would be its lowest-cost model.

But GPT-5.6 did not become broadly available at the time of the announcement.

At the US government’s request, OpenAI began with a limited preview through Codex and the API for a small group of trusted partners.

OpenAI also said that information about participating organizations had been shared with the government.

The company did not publish the names or number of those organizations.

OpenAI described the limited preview in its official announcement.

OpenAI said it still planned to make Sol, Terra, and Luna broadly available within weeks.

GPT-5.6 was therefore not banned.

Its wider release was not permanently cancelled.

What changed was the route to the public:

A government-involved restricted-access stage was inserted before broad availability.

Anthropic’s model was stopped after release and then partially restored.

OpenAI’s model entered a restricted preview before general release.

The timing was different, but both models encountered a gate before reaching a wider audience.

Anthropic and OpenAI Are Not the Same Legal Case

The two cases should not be treated as if the companies received identical orders.

Anthropic had already released Fable 5 and Mythos 5.

A legal export-control directive was then issued, and Anthropic disabled both models for every customer.

Mythos 5 was later allowed to return for a limited set of organizations.

OpenAI’s case was different.

GPT-5.6 had not yet been broadly released. OpenAI consulted with the government and accepted a government request to begin with a restricted preview.

There is no public confirmation that OpenAI received the same kind of export-control directive that Anthropic received.

The timing and legal mechanisms were different:

Anthropic faced a post-release legal restriction.
OpenAI changed its pre-release rollout through cooperation with the government.

That distinction matters.

A compulsory export-control directive is not the same thing as a company agreeing to a government-requested preview process.

But the practical overlap remains significant.

In both cases, the government became involved in determining which organizations could receive frontier-model access first.

For Anthropic, that involvement appeared through the list of organizations allowed to regain access.

For OpenAI, it appeared through the selection of restricted-preview partners.

The gate was built differently in each case.

Its effect was similar.

The New Development Is What Happens Before the Public Arrives

Government regulation of strategically important technology is not new.

Semiconductors, telecommunications equipment, encryption technology, and dual-use products have long been subject to export controls and national-security review.

What is changing is the point at which the government enters the AI release process.

A simplified version of the traditional model-release process looked like this:

Company develops a model
        ↓
Company evaluates safety
        ↓
Company decides pricing, timing, and eligible users
        ↓
Broad release

The emerging process looks more like this:

Company develops a model
        ↓
Company briefs the government on capabilities and release plans
        ↓
Government-involved security evaluation
        ↓
Restricted access for selected organizations
        ↓
Decision on broader availability

This direction also appears in the executive order signed on June 2.

The order calls for classified benchmarks to evaluate advanced cyber capabilities and for a voluntary framework under which developers can provide the federal government with access to models before releasing them to other trusted partners.

It also anticipates cooperation between developers and the government in identifying those trusted partners.

The White House published the executive order here.

The order includes an important limitation.

It states that the framework should not be interpreted as creating mandatory government licensing, preclearance, or permitting for the development, release, or distribution of new AI models.

The United States has therefore not formally created a general rule requiring government approval before every frontier model can be released.

Instead, several different mechanisms are operating at the same time:

legal export controls
voluntary government cooperation
pre-release security evaluation
restricted previews
non-public lists of eligible organizations
trusted-partner selection

There is no single gatekeeper and no single gate.

There is an emerging collection of checkpoints.

Safety Review and Early-User Selection Are Different Questions

There are legitimate reasons to evaluate frontier models before releasing them widely.

Models such as Mythos 5 and GPT-5.6 Sol have strong capabilities in software development, vulnerability research, and long-running cyber tasks.

OpenAI reported that GPT-5.6 Sol achieved performance competitive with Mythos Preview on ExploitBench while using roughly one-third as many output tokens.

That does not mean GPT-5.6 is superior to the final Mythos 5 model in every area.

It is a result from one cyber benchmark against a preview version of the competing model.

OpenAI also said that Sol had not crossed its own “Cyber Critical” threshold.

The model could identify browser vulnerabilities and components needed for an exploit, but it could not autonomously complete an end-to-end working attack during testing.

At the same time, OpenAI acknowledged that benchmark testing may not fully capture what a model can do when combined with tools, other agents, or longer operational workflows.

Pre-release testing and staged deployment can therefore be reasonable.

But testing a model and choosing its first commercial or institutional users are not the same decision.

Organizations that receive early access may be able to begin:

integrating the model into products
automating internal work
developing software
researching vulnerabilities
testing new services

before competitors and independent developers can do the same.

Even a few weeks of early access may matter if the model represents a significant capability increase.

A security process can therefore create a commercial advantage for the organizations selected to participate.

Neither Anthropic’s complete recipient list nor OpenAI’s restricted-preview partner list is public.

The public also does not know:

how organizations are selected
whether additional organizations can apply
why an organization may be rejected
whether there is an appeal process
how long restricted access will last

The problem is not the existence of safety review.

The problem is that review and customer selection are being combined inside a process that remains largely opaque.

OpenAI Does Not Want the Gate to Become Permanent

OpenAI explicitly said that the current access process should not become the long-term standard.

The company warned that such a system could keep its best tools away from:

users
developers
businesses
cyber defenders
international partners

OpenAI did not reject government security testing.

It described the restricted preview as a short-term path toward making the models more broadly available within weeks.

It also said it was working with the administration on a repeatable process for future releases.

Reuters reported that Sam Altman supported extensive safety testing but objected to the idea of the government choosing customers.

Reuters reported on OpenAI’s delayed broader rollout and government involvement here.

That distinction is important.

Testing whether a model presents a national-security risk is one question.

Allowing the government to decide which companies receive the model first is another.

A gate designed for safety can become a gate that distributes competitive advantage.

A Later Public Release Would Not Erase the Precedent

OpenAI may release GPT-5.6 broadly within weeks, exactly as planned.

Anthropic may expand access to Mythos 5.

Fable 5 may eventually return to general availability.

If that happens, the current restrictions may appear temporary.

But a later public release would not erase what happened before it.

A repeatable pattern is now becoming possible:

A developer briefs the government before release.
Government agencies evaluate the model’s capabilities.
A limited set of organizations receives early access.
Broader availability is considered later.

The central issue is not whether GPT-5.6 is delayed for two weeks or four.

It is that the path between a finished model and the public now includes actors beyond the company that built it.

OpenAI itself said it was working on a process that could be used again for future releases.

That means the gate may not be temporary even if a particular delay is.

This Is Not Yet a General AI Licensing Regime

It would be inaccurate to say that frontier AI can no longer be released in the United States without government permission.

Anthropic and OpenAI did not face the same legal process.

GPT-5.6 was not prohibited.

Mythos 5 was not restored to the public.

The executive order describes a voluntary framework and explicitly rejects the interpretation that it creates mandatory licensing or preclearance.

A more accurate description is:

The US government is beginning to participate in frontier-model evaluation, release timing, and restricted early access through several overlapping legal and voluntary mechanisms.

This remains a transitional system.

The rules are not unified.

The selection criteria are not transparent.

The boundary between a government request and a practical requirement is not always clear.

What is new is not merely that AI is regulated.

What is new is that the decision to open the door is no longer always made by the company alone.

Why This Matters to Users and Developers

This is not only a policy issue for AI companies and governments.

Cloud AI access is no longer determined only by price, subscription tier, and terms of service.

Government action may cause:

an already released model to disappear
a planned public release to be delayed
access to differ by country or nationality
access to depend on an employer or approved organization
selected companies to receive capabilities before everyone else

A model can exist, work, and have paying users while access to it remains outside the user’s control.

That creates a separate question from model performance:

Can users continue their work when access conditions change?

I wrote separately about what these events mean for doll’s local-first design and for users who depend on cloud AI continuity:

Being Able to Use Powerful AI Is Not the Same as Being Able to Keep Using It

Conclusion

Anthropic disabled two released models following a US government directive.

Mythos 5 has now returned, but only for a limited set of US organizations connected to critical infrastructure.

OpenAI introduced GPT-5.6 through a government-requested restricted preview before its planned broader release.

The legal mechanisms are different.

The direction is the same.

A frontier model no longer moves directly from the company that built it to the public.

Government security review, policy coordination, trusted-partner access, and release sequencing are becoming part of that path.

This is not yet a completed government licensing regime.

It is not one formal gate with one published rulebook.

But before the public reaches the newest frontier models, a new layer of review and selection is beginning to take shape.

The question is no longer only whether a model is safe enough to release.

It is also:

Who gets through first?