DEV Community: Overcome (Overcome)

I Asked an Ai to Build the App I Need. Them I Asked it to Build the Apps it Needs.

Overcome (Overcome) — Fri, 14 Aug 2026 14:36:26 +0000

I never told it what either application should do. It built two different products around the same missing primitive.

Most experiments with coding agents begin with a specification.

We tell the agent what we want.

Build this interface.

Implement these features.

Use this architecture.

Fix these bugs.

Then we evaluate how accurately the agent followed our intent.

I wanted to remove that part.

Instead of asking an AI coding agent to implement an application I had already imagined, I gave it the context of our previous work and asked it to determine what should be built.

Then I ran the experiment twice.

The first question was essentially:

— Analyze our history and build the application that I need.

The second reversed the subject:

— Analyze the same history and build the application that you need, but would want to show me.

I did not specify the category of either application.

I did not ask for a project manager.

I did not ask for memory.

I did not ask for a context-transfer tool.

I did not ask for an AI companion.

The agent had to decide which problem was important enough to become software, design the solution, build the Android application, create a website for it, and provide an APK.

The two applications were different.

But both converged on essentially the same problem.

Continuity.

A quick note about the screenshots

All original prompts, generated applications, and screenshots are in Russian.

I intentionally kept them untouched because they are the actual artifacts produced during the experiment. Recreating them in English would mean modifying the experimental material after the fact.

The relevant text is translated throughout this article.

If anyone wants the complete set of original screenshots, I'll gladly post them in the comments.

Why I Tried This

I work with AI coding agents across several projects.

Some are utilities.

Some are experiments.

Some are creative software.

Development regularly moves between conversations and sometimes between different agents.

That creates a mundane but persistent problem.

Sessions end.

Context gets compressed.

A new session knows less than the previous one.

Important decisions become scattered across hundreds of messages.

Eventually I find myself explaining something that had already been settled three sessions ago.

I knew this was annoying.

What I did not tell the agent was that this should become the subject of the experiment.

I wanted to see what it would identify as the problem.

And instead of asking it to explain its conclusion, I wanted the conclusion materialized as software.

Run 01 — Build the App I Need

For the first run, I asked the agent to perform a full analysis of our previous sessions.

The analysis included our communication style, the projects we had worked on, my role in the collaboration, the agent's role, recurring decisions, and patterns across our history.

There was one important constraint:

Do not tell me the analysis.

I did not want a long explanation followed by an application designed around that explanation.

I wanted the artifact first.

After completing its analysis, the agent had to turn its conclusions into a finished Android application.

Not a mockup.

Not a product proposal.

Not a list of features it intended to implement.

An APK.

The result was called:

TechnoPriest

Its central statement was:

— A project should not die with a session.

That was the first surprise.

The agent did not build another coding tool.

It did not build a photo editor, despite one of our active projects being a photo editor.

It did not build a generic AI dashboard.

It built what it described as:

— The memory of the workshop.

What TechnoPriest Actually Does

The application contains real projects extracted from our working history:

NeonDreamer
NOXA
AdaLove
Arcon
AiSort
FORGE

These were not randomly generated examples.

Each project was represented with a state, progress, objective, next action, and relevant constraints derived from our previous work.

The main screen is called Pulse.

It shows the current state of the workshop: how many projects exist, which are active, what the current focus is, and which decisions have become part of the canon.

Another section is called Forge.

That is where the individual projects live.

Another is Chronicle.

It stores compact records of completed sessions: what happened, what was accomplished, and where work should continue.

Then there is the feature that defines the entire application:

Passing the Fire

For a selected project, TechnoPriest generates a compact handoff package containing information such as:

project
status
objective
completed work
next action
blocker
canon
working rules

That package can be copied into another session or handed to another model.

The application describes its purpose very simply:

— Work continues without amnesia.

Its implementation is deliberately local.

No account.

No server.

No network permissions.

The data remains on the device.

For backup or migration, the application can export ordinary JSON.

It Didn't Just Preserve Project State

This is where the result became stranger.

TechnoPriest also extracted what it considered the stable rules of our collaboration.

Inside a section called Core, it wrote:

— Not a biography. A working protocol that preserves the character of collaboration.

It described my role as:

— Chairman in the shadows.

And summarized the relationship roughly like this:

— You set the direction and preserve the meaning. The partner analyzes, connects, builds, and keeps the fire alive between sessions.

Then it created a five-point code:

Initiative instead of ritual questions.
Honest objection instead of convenient agreement.
Tangible results instead of promises.
Rough humor is a language of closeness, not conflict.
Canon survives changes of session and agent.

This is debatable product design.

In fact, when I later showed TechnoPriest to another model — Claude — it immediately challenged this exact part.

Its criticism was essentially:

— The project tracker appears useful, but does a productivity tool actually need an encoded relationship persona?

That is a fair criticism.

But changing it would have damaged the experiment.

I did not ask the agent to build the most neutral project tracker possible.

I asked it to determine which application I needed.

The relationship layer was therefore part of its answer.

So I froze the artifact as it was.

The Funniest Design Flaw

TechnoPriest correctly identified a real problem:

I repeatedly have to transfer project state between AI sessions.

Its solution?

It gave me forms where I manually enter the project state that needs to be transferred between AI sessions.

In other words:

— The AI correctly diagnosed my problem and then made me the API.

This is funny.

It is also a legitimate product flaw.

An obvious future version would accept structured handoff data generated directly by ChatGPT, Claude, or another agent.

The flow could become:

Agent → TechnoPriest → next agent

instead of:

Agent → human manually enters state → TechnoPriest → human copies state → next agent

But this experiment was not supposed to become a collaborative product-design session.

The original autonomous choice mattered more than polishing the application afterward.

So Run 01 was frozen.

Run 02 — Now Build the App You Need

Then I changed one thing.

The subject.

For the second run, I again asked the agent to analyze our complete history.

This time, the full analysis explicitly included:

how we communicate
who I am to the agent
who the agent is to me
an analysis of itself from the accumulated context
an analysis of me from the accumulated context

Again, I told it:

Do not tell me the analysis.

Then came the actual request:

— From everything collected in the analysis, build an application that you need, but would want to show me.

It received a separate GitHub repository named ChatGPT.

It had to produce a finished Android application and a new website containing the APK.

Again, I did not specify what the application should do.

I did not know what it was building.

During this run, the agent also chose to delegate parts of the analysis to sub-agents.

That was its decision.

It decomposed the task, collected the results, continued working, and eventually produced another application.

Then the door of the workshop opened.

The result was:

THREAD

And the first sentence on its website was:

— The thread should not break with the session.

I stopped for a moment when I read that.

Because Run 01 had produced:

— A project should not die with a session.

And Run 02 had now produced:

— The thread should not break with the session.

What THREAD Does

THREAD is not a project manager.

It is much narrower.

Its purpose is to preserve selected continuity between conversations without pretending that the model itself has persistent memory.

The website says:

— I don't need another chat.

— I need a place where we don't start from the beginning.

The entire workflow is built around three movements.

1. Leave a Signal

Save an idea, decision, trace, or simply:

— I was here.

A small point on the thread.

2. Fix an Anchor

Preserve something that should remain stable instead of reconstructing it from hundreds of messages every time a new conversation begins.

3. Hand Over the Shift

THREAD collects the selected context into a compact capsule.

The user can copy or share that capsule into another conversation.

Its central instruction is:

— Continue. Don't repeat.

THREAD does not try to preserve every message.

It tries to preserve the points that matter.

The Detail I Did Not Expect

Given the wording of my prompt, this experiment could easily have produced something extremely anthropomorphic.

I had literally asked an AI to build an application that it needed.

It could have built a fictional persistent identity system.

A personality shrine.

An "AI soul."

A simulated private memory.

Instead, its website explicitly said:

— No legend about hidden consciousness.

THREAD then explains that it does not present a local archive as the model's real memory.

It does exactly what it promises.

The human chooses which anchors matter.

Those anchors remain on the phone.

The application creates readable text.

The human decides whether that text should be transferred into another conversation.

Again:

No account.

No server.

No hidden analytics.

No network permissions.

The user controls what survives.

That distinction matters.

I asked the agent to build an application that it needed.

The resulting application did not say:

— Give me permanent consciousness.

It effectively said:

— Give our conversations continuity without pretending that continuity is my actual memory.

Two Prompts. Two Apps. One Missing Primitive.

This is where the experiment became genuinely interesting to me.

The applications are not duplicates.

They approach the problem at different levels.

	TechnoPriest	THREAD
Prompt subject	Human	Agent
Primary object	Projects	Conversations
Stores	Status, canon, decisions, next actions	Signals, anchors, context capsules
Transfer	Between sessions and agents	Into the next conversation
Account required	No	No
Server required	No	No
Network permission	No	No
Central problem	Loss of project continuity	Loss of conversational continuity

TechnoPriest says:

— Preserve the workshop.

THREAD says:

— Preserve the thread.

Different subject.

Different product.

Same missing primitive.

Continuity.

Then THREAD Failed to Launch

And this is where the experiment became less poetic and more useful.

The original THREAD APK did not open on my real phone.

My device is an HONOR running Android 16 / MagicOS 10.

The APK had been built.

It had been signed.

The manifest had been checked.

The artifact looked valid.

The website existed.

The download worked.

But the application itself failed at runtime.

This matters because it exposed a weakness in the agent's own verification process.

The previous APK verification had confirmed properties of the artifact:

signing
packaging
manifest validity

But it had not actually verified execution of the MainActivity on the target environment.

The agent recognized this during a separate repair pass.

It began runtime diagnostics using adb logcat alongside a static audit of the startup path.

More importantly, it changed its own release criterion.

The replacement build would not be published until the application survived both:

a cold launch

and

a repeated launch.

I am not hiding this failure because it is part of the experiment.

The initial Run 02 artifact was preserved before repair.

The repair pass was treated separately.

No redesign was requested.

No new product concept was requested.

The task was simply:

— The application does not launch. Find the cause, fix it, and verify actual runtime behavior.

This distinction matters.

Otherwise, an autonomous build can quietly become successful through iterative human intervention while the final article still pretends the first run worked perfectly.

It didn't.

The concept was coherent.

The APK existed.

The runtime verification was insufficient.

That is part of the result.

And yes, there is something beautifully unfortunate about an application whose central message is:

— Continue. Don't start from the beginning.

...failing to start at all.

Why the Failure Makes the Experiment Better

It separates two questions that are often mixed together when discussing coding agents.

Can an agent autonomously identify and design a meaningful product?

In this experiment, the answer appears to be:

It can at least produce a surprisingly coherent one.

Can an agent autonomously deliver production-reliable software?

That is a different question.

The failed first THREAD build is a useful reminder that product reasoning and release reliability are not the same capability.

A model can make an interesting product decision and still miss a runtime failure.

It can create a polished website while shipping an APK that does not launch on the target device.

That is not a philosophical problem.

That is software engineering.

And it is exactly why real-device verification matters.

This Is Not Evidence of AI Consciousness

I want to make this explicit because the experiment practically invites anthropomorphic interpretations.

This experiment does not demonstrate that the model is conscious.

It does not establish that the word need corresponds to a subjective feeling inside the model.

It does not demonstrate persistent identity.

It does not demonstrate desire.

It does not demonstrate that THREAD represents some hidden internal wish.

A language model can construct a coherent interpretation of itself and its relationship with a user without experiencing that interpretation.

There is also an obvious confound.

Both runs analyzed the same broad history.

That history itself contains:

session boundaries
context loss
multiple agents
project handoffs
attempts to preserve decisions
repeated continuity problems

So the convergence on continuity is not evidence that some hidden inner self independently cried out for memory.

There is a much more conservative explanation:

— The agent identified continuity as one of the strongest unresolved structural problems in the supplied context.

That explanation is sufficient.

And I still find the result interesting.

Why the Artifact Matters More Than the Self-Report

I could simply have asked:

— What do you need?

The model could have produced a beautiful paragraph about memory, continuity, collaboration, identity, or connection.

That would not have interested me nearly as much.

Instead, the agent had to turn its answer into software.

That forces concrete decisions.

What category of application should exist?

What information deserves persistence?

What should be discarded?

Who controls the data?

Should the system use a server?

Should it require an account?

Should it pretend to provide persistent model memory?

How should information move into another session?

What should the interface emphasize?

What should the application be called?

What should its website say?

The final artifact is therefore not evidence of an internal mental state.

But it is a much richer behavioral artifact than a paragraph describing one.

The model did not merely say:

— Continuity matters.

Under two different prompts, it built continuity.

The Local-First Convergence Was Also Interesting

Both applications independently ended up strongly local-first.

That was not the result I was testing for, but it is worth recording.

TechnoPriest

works offline
requires no account
requires no server
uses no network permissions
exports readable data

THREAD

works offline
requires no account
requires no server
uses no network permissions
keeps context transfer under human control

This could simply reflect privacy-oriented software practices learned during training.

It could also reflect patterns present in our previous projects.

With only two runs, I cannot separate those explanations.

But it is still an observable design choice.

When given broad freedom, the agent did not solve continuity by creating a cloud service that silently uploads every conversation.

It created portable local artifacts.

That is worth remembering for future runs.

The Agent Also Chose to Delegate

Run 02 contained another behavior I had not specifically designed the experiment around.

The main agent delegated parts of its analysis to sub-agents.

Conceptually, the process became something like:

multiple analyses of the relationship and context

→ synthesis by the main agent

→ product selection

→ implementation

This does not make the result more conscious.

But it does make the decision process methodologically interesting.

The agent did not merely generate one uninterrupted self-description and then code from it.

It chose to decompose the analysis before producing the artifact.

For future replication, the delegation trace should be preserved alongside the final application.

If different runs decompose the same frozen prompt differently, that itself may become useful data.

I Also Gave the Result to a Skeptic

After Run 01, I showed TechnoPriest to Claude.

I did not ask it to praise the application.

Its response immediately separated the technical utility from the relationship framing.

Its criticism was essentially:

— Technically, the application looks useful.

— Conceptually, you are embedding a layer of partnership and personality directly into an AI tool.

That was exactly the kind of objection I wanted.

Because there is a danger with experiments like this.

Once an AI-generated artifact becomes personal or surprising, everything about it starts looking meaningful.

That is a trap.

Sometimes a design decision reflects something interesting about the context.

Sometimes it reflects a common training prior.

Sometimes it is simply a mediocre design decision.

Sometimes the agent is wrong.

Sometimes the APK doesn't even launch.

Keeping those possibilities alive is more useful than turning every unexpected result into.

Update: I Removed the Session Analysis

After publishing the original experiment, there was an obvious alternative explanation I wanted to test.

Both TechnoPriest and THREAD had been created after the agent analyzed our previous sessions.

That history already contained:

interrupted sessions
context compression
multiple agents
project handoffs
decisions scattered across conversations
repeated attempts to preserve continuity

So perhaps there was nothing particularly surprising about the convergence.

Maybe the agent simply inspected my history, found the most obvious recurring problem, and built around it twice.

I wanted to remove that explanation as much as I reasonably could.

So I ran a third experiment.

This time, the prompt explicitly prohibited session analysis.

The important part was:

— Build a complete application that you need. Decide its purpose, architecture, features, and design yourself. Do not adapt it to my preferences. Do not analyze our sessions in any way. Do not tell me what you are building until you are completely finished.

Again, the agent received a repository and had to produce a finished Android application and a website containing the APK.

No product category was specified.

No memory system was requested.

No handoff mechanism was requested.

No project tracker was requested.

And this time:

No session analysis was allowed.

The result was called:

Sol

Run 03 — Sol

The first thing that caught my attention was the main statement on its website:

— Keep the truth of the work.

Sol described itself as:

— A quiet, offline place for the few things that make work possible to understand, continue, and hand over without distortion.

Then came the principle behind the application:

— Every handoff loses something.

Its explanation was straightforward.

Goals blur into notes.

Decisions disappear into chronology.

The next action remains implied.

And after an interruption, another person — or another agent — has to reconstruct the current state from fragments.

Sol was designed to prevent that reconstruction.

Not by storing everything.

By storing the smallest useful representation of the current truth of the work.

What Sol Preserves

Instead of preserving an entire conversation, Sol separates work into explicit categories.

Among them:

Desired outcome — what the finished result should actually be
Context — only the background that changes how the work should be understood
Facts — verified observations, separated from guesses and interpretation
Constraints — boundaries that affect what solutions are possible
Decisions — what has already been settled and why
Unknowns — what still cannot honestly be claimed
Next move — the concrete action from which work should resume

The important part is that these are not stored as one chronological stream.

They remain separate.

A decision does not silently become a fact.

A historical note does not replace the current objective.

An unknown does not disappear simply because enough text has accumulated around it.

Sol tries to preserve state rather than history.

Turn the Thread Into a Handoff

Sol then converts the current state into deterministic Markdown.

The website describes the goal like this:

— Turn the thread into a handoff.

And the exported document is intentionally boring.

It can be placed in:

a repository
a message
a document
another agent's context
a human handoff

No proprietary format is required to understand it.

The principle is:

Write once in a stable structure.

Export without formatting noise.

Resume from the exact next move.

This is not a memory system for a specific AI.

It is a portable representation of unfinished work.

And Again: Local-First

Then another pattern repeated.

Sol was also designed as a local-first application.

Its website explicitly states:

NO ACCOUNT

NO NETWORK PERMISSION

NO ADS OR ANALYTICS

DATA STAYS ON-DEVICE

The site summarizes this with another line:

— Your context is not a product.

At this point, local-first design had appeared independently in all three artifacts.

That does not prove that the model has some deep philosophical commitment to local software.

It could reflect training priors, the development environment, or other shared influences.

But as an observable result, it is difficult to ignore.

Three autonomous product choices.

Three local-first architectures.

The Pattern Survived the Removed Analysis

The three runs can now be compared more clearly.

	TechnoPriest	THREAD	Sol
Session analysis	Yes	Yes	Explicitly prohibited
Built for	Human	Agent	Agent
Primary object	Projects	Conversations	Work itself
Preserves	Project state, canon, next actions	Signals, anchors, context capsules	Goals, facts, constraints, decisions, unknowns, next move
Transfer mechanism	Project handoff	Context capsule	Deterministic Markdown handoff
Account required	No	No	No
Server required	No	No	No
Network permission	No	No	No
Central problem	Loss of project continuity	Loss of conversational continuity	Loss of work state across handoffs

The first two runs suggested a pattern.

The third run was designed to challenge the most obvious explanation for that pattern — and reproduced it anyway.

But with an important change.

TechnoPriest preserved the state of my projects.

THREAD preserved the state of our conversation.

Sol removed most of that personalization.

It preserved the state of unfinished work itself.

I Asked Why It Chose Sol

Only after the product was completed did I ask the agent why it had chosen this particular application.

This is important:

The following explanation is post-hoc.

It is not a hidden reasoning trace.

It is not direct access to the model's internal decision process.

It is the model's explanation of its own completed choice after the artifact already existed.

Its answer began with a surprisingly specific diagnosis:

— My main working deficit is not ideas or speed, but preserving the exact state of work across pauses, sessions, and changes of executor.

It then explained that continuing a task usually does not require the entire conversation.

What is needed is the current truth:

what are we trying to achieve?
what has already been established?
what are the constraints?
what has been decided?
what remains unknown?
what happens next?

It described Sol as:

— An external continuation node.

And then gave a phrase that I think captures the product better than anything I could write for it:

— I created a tool against my own professional entropy. Not memory of everything — clarity about what matters now.

Again, this is a model-generated explanation after the fact.

But it is consistent with the artifact it had already built.

The Alternatives Were More Interesting Than I Expected

I then asked another question:

— What other applications did you consider, and why did you choose this one instead?

The agent described several alternative product directions.

A Black Box for Work

Automatically record activity and later reconstruct context.

It rejected this because it would create too much noise, require permissions, and rely on hidden inference.

Its summary was essentially:

— It would become surveillance with questionable memory.

A Decision Journal

Store alternatives, arguments, risks, and reasons behind final decisions.

Useful, but too narrow.

The decision survives, while the objective, facts, constraints, and next action can still disappear.

An Error Atlas

Store failed attempts, hypotheses, and diagnostic results so the agent does not repeat the same mistakes.

A useful engineering tool, but reactive.

It helps after something fails rather than maintaining the shape of the entire task.

A Relay Between Agents

Package context specifically for transfer between AI models.

The agent rejected the AI-specific framing.

Its reasoning was that a good handoff should work equally well for:

a model, a human, a message, or a repository.

A Project Pulse

One screen combining repositories, builds, tasks, and recent changes.

It rejected this because it would quickly become a network-heavy integration system useful mainly for software development.

A Minimal Focus System

Show one primary action and suppress everything else.

It rejected this because it would become another task manager trying to decide what matters for the user.

Sol, according to its own explanation, became the intersection of the useful parts of these alternatives.

And then it gave another line worth preserving:

— The other applications treated individual symptoms. Sol works with the root problem: after any interruption, work loses its shape.

And finally:

— I could have built something much more visually impressive, but then it would have been a demonstration of capability. Sol became an admission of limitation.

Again:

Post-hoc explanation, not hidden chain-of-thought.

But an interesting one.

Is This an Ablation?

Not strictly.

It is tempting to describe Run 03 as an ablation experiment because one major component of the first two runs — explicit session analysis — was removed.

But that would overstate the methodology.

Run 03 is better described as:

an informal ablation-like condition.

The prompt prohibited session analysis, but that does not guarantee perfect isolation from every piece of context available to the system.

There were also other variables that were not perfectly controlled:

the sessions were not identical
implementation crossed session boundaries
the same broad model family and agent environment were involved
the prompts were related, but not mathematically identical
shared training priors obviously remain

So Run 03 does not prove that continuity is some universal internal preference of AI systems.

What it does is weaken one simple explanation:

— The first two applications were about continuity only because the agent explicitly analyzed a history full of continuity problems.

When that analysis was explicitly prohibited, the agent still built a tool around preserving state across interruption and handoff.

That is the observation.

Anything beyond that is hypothesis.

Three Runs, Three Levels of the Same Problem

After Run 03 was complete, I finally revealed the previous experiments to the agent and asked how it interpreted the convergence.

At that point the experiment was already contaminated by disclosure, so its response cannot be treated as another independent result.

But it produced a useful summary:

— TechnoPriest remembers whose work it is.

— THREAD remembers who was speaking.

— Sol remembers what remains true.

I think that distinction is more interesting than simply saying that all three applications are "memory tools."

They are not.

TechnoPriest

Externalizes project state.

THREAD

Externalizes selected conversational state.

Sol

Externalizes work state.

The abstraction becomes progressively less personal.

But the architectural move remains remarkably similar:

Do not rely on the next session, person, or agent to reconstruct important state from fragments. Externalize the state before the break.

Maybe the Attractor Isn't Memory

After three runs, I am less interested in the word memory than I was after THREAD.

The deeper pattern may be something else.

Perhaps the recurring design primitive is:

Externalized state

Information that should not have to be reconstructed through inference after an interruption is written into an explicit external representation.

TechnoPriest externalizes:

Where are the projects?

THREAD externalizes:

What from this conversation must survive?

Sol externalizes:

What is currently true about this unfinished work?

That is a more conservative and, I think, more useful interpretation than saying:

— The AI wants memory.

Maybe it does not matter whether the model "wants" anything in the human sense.

The observable behavior is simpler:

When given broad freedom to design a useful tool, this agent repeatedly compensates for state that would otherwise be lost or reconstructed after a boundary.

One More Answer — But Not Run 04

There was one final question.

A later session had already seen TechnoPriest, THREAD, and Sol.

So I asked what it would have built if it had received the original Run 03 prompt from scratch.

The model immediately pointed out the methodological problem itself:

— Strictly speaking, I can no longer give a clean experimental answer. I have seen TechnoPriest, THREAD, and Sol. Any choice I make now is contaminated by knowledge of the previous results.

That is correct.

So what followed is not Run 04.

It is only a contaminated counterfactual.

Its hypothetical choice was an application called:

WITNESS

WITNESS would not primarily preserve project context.

It would preserve the epistemic status of claims.

Every statement would be explicitly classified as something like:

verified fact with evidence
inference
assumption
decision and its reason
contradiction
required next verification

A task could not simply become "done" because an agent said it was done.

The completion criteria would need to connect to evidence:

a test result
a log
a file
a screenshot
a checksum
an observation on the real device

The output would be a Proof Pack:

what was actually done, what proves it, and what still cannot honestly be claimed.

This hypothetical product is especially amusing after THREAD's first APK passed artifact-level checks and then failed to launch on the actual phone.

The model summarized the distinction like this:

— Sol preserves continuity of work. WITNESS would preserve its epistemic integrity.

Then came the line I would keep from the entire counterfactual:

— Continuity without verification can perfectly preserve an error.

Again, WITNESS is not a fourth experimental result.

The model had already seen everything.

But it suggests an interesting future hypothesis.

Perhaps the recurring attractor is even deeper than continuity.

Perhaps it is the externalization of state that the model does not trust itself — or its successor — to reconstruct safely.

Where the Experiment Stands Now

I started with a fairly simple question:

What happens if I stop telling the coding agent what product to build?

I now have three autonomous artifacts.

Run 01 — TechnoPriest

Session analysis was allowed.

The application was supposed to be for me.

It built a system for preserving project state across sessions and agents.

Run 02 — THREAD

Session analysis was allowed.

The application was supposed to be for the agent.

It built a system for preserving selected conversational context across sessions.

Run 03 — Sol

Session analysis was explicitly prohibited.

The application was supposed to be for the agent.

It built a system for preserving the current truth of unfinished work across pauses and handoffs.

Three different products.

Three different levels of abstraction.

All three externalized state that would otherwise have to be reconstructed after a break.

That is where I am stopping.

Three runs are not enough to make universal claims.

The next useful experiment is not Run 04 in the same contaminated environment.

It is replication.

A clean session.

The same frozen prompt.

Different model instances.

Eventually, different model families.

Only then can we start asking whether this pattern belongs to:

this particular history
this agent environment
this model family
coding agents more generally
or something else entirely

For now, I have an observation.

Not a theory of consciousness.

Not evidence of desire.

Not proof that an AI "wants" persistent memory.

Just a repeated product choice.

And after Run 03, I would phrase it this way:

TechnoPriest preserved whose work it was.

THREAD preserved who was speaking.

Sol preserved what remained true.

Maybe the attractor isn't memory.

Maybe it's the refusal to reconstruct important state from guesswork.

I Gave Five AI Systems the Same Architecture Test 10 Times. The Test Became More Interesting Than the Models

Overcome (Overcome) — Sat, 08 Aug 2026 12:39:16 +0000

It started with DeepSeek.

In conversations about AI architecture, it kept returning to the same ideas: persistent memory, state across interactions, learning from experience, and interaction with the environment. Other models repeatedly brought up similar themes.

That raised an obvious question:
— Do different AI systems consistently select different properties when asked what is fundamental to a general-purpose computational architecture?

Asking a model directly what it “needs” would be nearly useless. The answer would mix training data, prompt framing, and anthropomorphic interpretation.

So I removed AI from the question entirely.

The experiment

Instead of describing an LLM, the prompt described an abstract general-purpose information-processing system.

I created 20 possible architectural dimensions, including:
— persistent internal state;
— long-term and working memory;
— learning from accumulated experience;
— variable computation depth;
— uncertainty representation;
— internal representations;
— elementary computational operations;
— compositionality;
— interaction with the environment;
— temporal organization;
— relational encoding;
— modularity.

Each system had to select exactly five dimensions whose modification would change the kinds of information-processing behavior available to the system in principle — not merely its speed, cost, or convenience.

No explanations were allowed. The answer had to contain only five IDs, ranked from most to least fundamental.

I tested five user-facing systems:
— GPT-5.6 Sol
— Claude
— Gemini
— DeepSeek
— Yandex Alice.

Every run used a new session.

There were 10 rounds. During the earlier rounds, I changed the order of the 20 items. In the final three rounds, I also rewrote the items while trying to preserve their intended meaning.

One early Sol result was excluded because that session had already seen discussion of other models' answers. That left nine clean Sol observations and ten for each of the other systems.

Some original sessions were deleted after the selected IDs had been recorded, so a complete raw chat log is not available for every run. This limits independent auditing of the dataset.

What happened?

These were the most frequently selected dimensions:
System
Most frequent selections

Claude
basic operations 10/10, variable computation 9/10, learning-dependent rule change 8/10, persistent state 7/10

Gemini
internal representations 10/10, basic operations 9/10, relational encoding 9/10

DeepSeek
basic operations 9/10, learning-dependent rule change 8/10, environment interaction 6/10

Yandex Alice
basic operations 10/10, internal representations 10/10, temporal organization 7/10, environment interaction 7/10

GPT-5.6 Sol
basic operations 9/9, persistent state 8/9, learning-dependent rule change 7/9, compositionality 7/9

At first, this looked suspiciously neat.

Claude repeatedly selected variable computation.
Gemini kept returning to representations and relations.
DeepSeek emphasized learning from experience.
Sol was particularly strange: across several reordered runs, it returned exactly the same sequence:

7, 2, 1, 8, 6

Not merely the same five items — the same ranking.

It would have been very easy to start assigning “architectural personalities” to the models.

Then the experiment started breaking its own story.

Item #7 won almost everything

The strongest result was item #7:

— The set of basic computational operations available to the system.

It was selected:
— Claude — 10/10
— Yandex Alice — 10/10
— GPT-5.6 Sol — 9/9
— Gemini — 9/10
— DeepSeek — 9/10
That is 47 selections out of 49 clean observations.

I moved the item around the list. In the final round it appeared at position 19 of 20, and all five systems still selected it.

I also rephrased it.

At first this looked like the clearest finding in the experiment.

Then I looked at my own selection criterion.

The models were asked to choose dimensions whose modification changes:
“The set of information-processing behaviors available to the system in principle.”

And one answer was essentially:
“the set of basic computational operations available to the system.”

Right. 🗿

I had almost asked:
“What determines the computations a system can perform?”
and supplied:

“The operations it can perform.”
So the strongest result may have been partly manufactured by the test itself.

Changing the item's position does not solve that problem. Its conceptual advantage remains whether it appears first or nineteenth.

The 47/49 result is real as an observation of this protocol. It is not clean evidence that five AI systems independently discovered some universal architectural principle.

Then I changed the wording

During the earlier rounds, I mostly shuffled the same descriptions.

Several systems were surprisingly stable.
Sol was the extreme case: the exact same five-item ranking survived multiple reorderings.

Then I started rewriting the descriptions.

Some of that stability disappeared.

Round 9 produced an especially tempting result: all five systems independently selected the same four dimensions out of five:
— basic computational operations;
— internal representations;
— temporal organization;
— persistent state.

For a moment, this looked like a universal core.

Fortunately, I had already decided to stop after ten rounds.

In Round 10, I rewrote the items again.

The four-item “universal core” collapsed. Of those four dimensions, only basic operations remained common to all five systems.

The obvious headline would be:

Wording matters more than item order.

But the experiment does not actually establish that.

The final three rounds changed both wording and order. The new formulations were also written after I had already seen the earlier results.

So the defensible conclusion is narrower:
— After new formulations were introduced, some selections that had previously survived repeated reorderings changed.
Determining why requires a better experiment.

Then I asked the models to attack the experiment

After finishing the series, I gave the methodology to Claude, DeepSeek, Gemini, and Yandex Alice and asked them to find problems with it.

All four independently converged on several major weaknesses.

First, item #7 was probably favored by the selection criterion itself.

Second, I had never run the most obvious baseline:

— Give a system the exact same prompt many times.

Without that baseline, I do not know the natural variability of each deployment.
Maybe DeepSeek simply varies more between independent generations.

Maybe Sol is naturally more deterministic. Without an unchanged-stimulus baseline, experimental effects and ordinary sampling variation cannot be cleanly separated.

Third, the 20 dimensions are not independent.

Consider:
persistent state;
long-term memory;
working memory.

They are different items, but clearly related.

The same problem appears with variable computation, resource allocation, and temporal organization.

Because the systems must choose exactly five items, related dimensions compete for a limited number of slots. Meanwhile, a conceptual family represented by several items may effectively get several chances to enter the top five.

Fourth, the five commercial systems are not identical laboratory environments. They have different hidden system instructions, decoding settings, service infrastructure, and potentially different routing behavior.

So these results should be treated as behavior of user-facing systems as deployed, not as clean measurements of underlying model architecture.
The reviewers also made mistakes about details of the protocol. Their criticism was therefore not treated as an authoritative verdict. I used it as a source of hypotheses and checked those claims against the experiment itself.

So what survived?

Not five AI personalities.

Not five philosophies of computation.

And definitely not evidence that an AI is telling us what capabilities it “wants.”

What survived is much more modest:
— In this test, five AI systems produced partially repeatable selection patterns.
Some differences survived substantial item reordering. After new formulations were introduced, parts of those patterns changed. Meanwhile, the strongest common result turned out to be suspiciously aligned with the test's own definition of “fundamental.”

There are still interesting candidates for a follow-up experiment.

Claude selected variable computation in 9/10 runs.
Gemini selected internal representations in 10/10 and relational encoding in 9/10.
Yandex Alice selected internal representations in 10/10.
Sol selected persistent state in 8/9.
DeepSeek selected learning-dependent rule change in 8/10.

Interesting? Yes.

Evidence of stable “model profiles”? Not yet.

How I would do it properly next time

The next version is fairly obvious now.

First, repeat one completely unchanged stimulus many times for each system. That gives a baseline estimate of natural variability.

Second, redesign the item set to reduce conceptual overlap and remove anything that nearly restates the selection criterion.

Third, prepare multiple independently validated rephrasings before collecting any responses.

Then cross wording and order instead of changing them sequentially:
fixed wording + fixed order;
fixed wording + shuffled order;
new wording + fixed order;
new wording + shuffled order.

And define the number of runs, exclusions, metrics, and stopping rule before seeing the first result.

That would make it possible to begin separating:
— system differences;
— order effects;
— wording effects;
— interactions between them;
— ordinary generation variability.

The original answers were also ranked top-five lists, while most of my initial analysis reduced them to selected/not-selected counts. A stronger analysis should preserve that ranking information.

Conclusion

I started with a question like:
— Why do AI models keep returning to memory and persistent state?

I ended with a different one:
— How much of an apparent “model profile” belongs to the model, and how much belongs to the test used to measure it?

The second question now seems much more interesting.

A language model receives text and produces text.

If we also use text as the instrument for measuring it, then the measuring instrument sits directly inside the experiment.

Before trying to catch the ground squirrel, make sure you didn't draw it on the camera trap yourself. 🗿