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
Top comments (0)