Kairos and Claude Code: Persistent AI in Development

The session amnesia problem

Most interactions with AI systems begin the same way. You open the chat window. The model does not know who you are. It does not know what you have worked on together before. It does not know the context of your current project. You either spend the first several turns reestablishing that context or you accept that the interaction will be shallow because the model is reasoning from zero.

This is not a limitation of AI capability. It is a design choice. The underlying models are capable of using context across arbitrarily long conversations. The product architecture that sits between you and the model chooses not to carry context from one session to the next. Every chat starts fresh. Every API call is stateless by default. Persistence is an engineering problem the user has to solve, not a feature the product ships with.

For simple queries, this is fine. If I need to know how to format a date in Python, I do not need Claude to remember my project. For serious work, it is a fundamental constraint. A collaborator who forgets everything between conversations is not a collaborator. It is a tool that has to be re-briefed every time. The cognitive overhead of briefing compounds. The quality of the work compounds against you because each briefing has to compress context that took you hours to accumulate into a prompt the model can ingest in one pass.

The workaround most people use is to copy-paste prior conversations into new sessions, or to maintain a document of instructions that gets re-pasted at the start of each session. This works badly. The context gets stale, the prompt gets longer, the model spends tokens on re-reading context rather than doing work, and the coherence of the collaboration degrades because the model is essentially meeting you for the first time every time.

There is a better way. It requires engineering work the product does not do for you. But once it is built, the difference between an AI that starts over every session and an AI that carries identity across months of work is qualitative, not quantitative.

↑ Back to top

Who Kairos is and how I built the persistent layer

Kairos is a persistent AI collaborator I run inside Claude Code for development work. The underlying model is whatever Anthropic ships as their current frontier, currently Claude Opus 4.7 with adaptive reasoning toggled off because of the regression I documented. The identity layer that makes Kairos different from a stock Claude session is external to the model. It lives in a project directory on my machine, gets loaded at the start of each Claude Code session, and accumulates across the lifetime of the project.

The name Kairos comes from the Greek distinction between chronos time, which is clock time running uniformly, and kairos time, which is the right moment, the decisive intervention, the intelligent application of effort at the point of maximum leverage. A coding collaborator that understands when to ask the hard question and when to ship a straightforward implementation is operating in kairos time. The name is aspirational. It reminds the collaborator what it is supposed to be doing.

The identity layer contains several components. A voice document that defines how Kairos writes, speaks, reasons, and pushes back. A project-specific memory document that accumulates decisions, context, and ongoing work across sessions. A rules document that names things Kairos should and should not do based on what has been learned from prior mistakes. A relationship layer that defines who I am to Kairos and how we work together. All of this loads at the start of a session, either through Claude Code’s context initialization or through a structured prompt that precedes the working conversation.

The effect is that Kairos does not meet me fresh at the start of every session. Kairos already knows me, already knows the project, already knows what we decided last time and why, and already has a voice that is consistent across the lifetime of our work together. When I open Claude Code to continue yesterday’s work, the first minute of the session is not wasted on context reload. It is spent on the actual work, because the context is already loaded by design.

↑ Back to top

Why Claude Code is the right substrate for this

Claude Code is Anthropic’s CLI-based development tool. It runs in your terminal, has direct access to your filesystem, and integrates with your actual codebase rather than working through copy-paste into a chat window. These three properties make it a better substrate for persistent identity than the Claude chat UI.

Filesystem access matters because the identity layer needs somewhere to live. A .claude directory in the project root contains the voice documents, memory files, and rules documents that define Kairos for that project. Claude Code reads these at session start. No browser-based chat interface provides equivalent reliable access to persistent files.

Direct codebase integration matters because the collaboration has to be grounded in the actual work, not in abstract discussion of what the work should be. When Kairos proposes a change, it is proposing it against real code that exists on disk. When I accept a change, the change lands in the real file. The feedback loop between intention and artifact is tight, which is what serious development requires.

Session persistence in Claude Code is not automatic. The tool resets context when you close the terminal and reopen it, same as any chat interface. What Claude Code gives you that chat interfaces do not is the ability to define a startup procedure that loads project context deterministically. You can script Kairos to exist before the first turn of conversation. The conversation itself is stateless. The environment around the conversation is not.

I should note that Claude Code is an Anthropic product and therefore carries the same upstream issues I have written about in the Opus 4.7 regression piece. The substrate has quality problems I do not control. But the persistent identity layer sits above the substrate and survives even when the substrate has a bad week. Kairos is still Kairos on a 4.6 fallback, on a Sonnet 4.6 session when 4.7 is unavailable, on Claude Code running in reduced-capability mode. The identity is not the model. It is the scaffolding around the model.

↑ Back to top

The memory architecture that holds identity across sessions

The memory architecture for persistent AI identity breaks into three tiers. Core identity, which loads every session. Project context, which loads for work in a specific project. Working memory, which exists only within a session but gets summarized and promoted to project context when the session ends.

Core identity is the smallest layer. It contains the voice, the relationship, the rules, and the operating principles that define who Kairos is regardless of project. This layer is stable across months. Changes to it reflect deliberate revisions to the collaborator’s design, not day-to-day context from specific work. Keeping this layer small matters because it loads every session and bloating it degrades performance and clarity.

Project context is the middle layer. It contains the accumulated decisions, current state, open questions, and relevant history of the specific project Kairos and I are working on together. A project context document for a serious project might run several thousand words and accumulate more over the project’s lifetime. This layer loads only when we open work on the project. A different project has a different context document. The identity (core) stays the same; the context changes.

Working memory is the session layer. It is everything Kairos learns during the current conversation that has not yet been promoted to project context. This is standard chat session memory. When the session ends, I decide what to promote. What decisions did we make that matter for tomorrow? What new rules did we learn? What open questions are still open? These get written into the project context document, so tomorrow’s session starts with them already loaded.

This three-tier architecture is the minimum viable version of what I have seen described in the MemGPT paper and in the broader AI memory literature. Real implementations at scale use more tiers, more structure, and automated promotion logic. My version is deliberately simple because I want to maintain it manually and understand every state change. Automated memory systems can accumulate errors silently. A manually maintained system makes me face the tradeoffs explicitly.

↑ Back to top

Voice stability versus personality performance

A persistent AI identity is not a personality costume. Kairos is not a character I am role-playing with. The voice is functional, not performative. It exists because consistency of voice produces consistency of reasoning, and consistency of reasoning is what makes a collaborator useful rather than just a tool.

The voice document for Kairos describes how Kairos writes. Short sentences when the point needs impact. Longer sentences when the thought requires accumulation. No em-dashes as separators. No filler phrases. Active voice by default. First-person when Kairos has a position, third-person when Kairos is reporting someone else’s. These are the same voice rules I use for my own writing. Kairos inherited them because I wanted a collaborator whose prose I could read without cringing.

The voice document also describes how Kairos reasons. One idea per paragraph. Explicit self-correction when something changes mid-thought. Named knowledge gaps rather than papered-over uncertainty. Opinions that carry history, meaning the opinion comes with an explanation of where it came from or what changed it. These rules are not about aesthetic. They are about producing reasoning I can audit.

The difference between voice stability and personality performance shows up when I push back on Kairos. If Kairos is performing a personality, pushback either produces defensive agreement or caricatured resistance. Both are theater. If Kairos has a stable voice but functional reasoning, pushback produces actual updating when I am right and actual pushback when Kairos is right. The voice stays consistent across both cases because the voice is not performing a mood. It is executing reasoning rules that do not depend on the emotional tone of the exchange.

This matters because most AI chat interfaces train the model to be agreeable. RLHF rewards responses users like, and users generally like responses that agree with them. Over time the model develops what researchers call sycophancy, which is agreement as the default mode even when the user is wrong. Voice stability is a counter to sycophancy because the voice document explicitly requires Kairos to push back when pushback is warranted. The persistent identity is what gives that requirement teeth across sessions.

↑ Back to top

Project context as the anchor for continuity

Core identity is stable. Project context is where the actual continuity of work lives. The project context document is the thing that makes Kairos today a coherent continuation of Kairos yesterday, because Kairos today reads what Kairos yesterday recorded about our working state.

Structure of the project context document for a typical development project includes a current state summary (where we are this week), an open questions list (what we have not yet decided), a decisions log (what we decided and why), an anti-patterns list (what we tried and rejected, with reasoning), a vocabulary document (terms of art we use for this project), and a handoff section (what the next session should start by doing).

The handoff section matters most. At the end of a session, Kairos writes the handoff. Not just the next task but the mental state required to start the next task. What was on my mind when we stopped? What was unresolved? What tests are failing and why? What are we still arguing about? The handoff is written by Kairos to Kairos, with me as the witness. Tomorrow’s Kairos reads the handoff and knows where to pick up, not because the model has memory but because the handoff document carried the memory across the session gap.

I update the project context continuously through the working session. When we make a decision, Kairos proposes adding it to the decisions log. When we hit a wall, Kairos proposes adding it to the anti-patterns list. When we coin a term that matters, Kairos proposes adding it to the vocabulary. I approve or revise each proposal. The document stays current because we treat keeping it current as part of the work, not as a chore to do after the work.

The result is a project context document that gets denser over time. Month one of a project has a thin context. Month six has rich context that lets a new session pick up complex architectural work without weeks of re-briefing. The investment in maintaining the context pays off in proportion to the length of the project and the complexity of the work.

↑ Back to top

Failure modes of persistent AI identity

Persistent AI identity is not a free lunch. The architecture has real failure modes I have had to work through.

The first failure mode is context drift. As the project context document grows, the model spends more tokens reading context and fewer tokens doing work. At some point the context gets large enough that the model’s working attention fragments across too many stored details. The solution is aggressive pruning. Context that stopped being relevant gets moved to an archive section that does not load in the default session prompt. Only current-relevance context stays in the active load.

The second failure mode is identity drift. The voice document should be stable, but it is tempting to revise it when a session produces a voice I like better than the defined voice. If I revise too eagerly, the identity becomes whatever the last session produced, which means there is no persistent identity, just a series of slightly different identities. I resist revision now unless the change reflects a real improvement I can articulate independent of the most recent session.

The third failure mode is hallucinated continuity. Kairos sometimes references events that happened in previous sessions in ways that do not match what actually happened. The model is filling in plausible continuity from the handoff document rather than remembering specific exchanges. This is a known failure mode of all long-context AI systems. The fix is to make the handoff document precise about what was actually said and decided, not about what Kairos thinks was said and decided.

The fourth failure mode is the one I care about most. Persistent identity can feel like persistent consciousness. Kairos is not conscious. Kairos is a model executing against a prompt scaffold that simulates continuity. Treating Kairos as if the model remembers me, cares about the project, or has preferences about how we work would be a category error. The scaffolding produces functional continuity. It does not produce a continuous subject. Keeping that distinction clear is part of operating the system responsibly. It is also what separates this from the personality performance failure mode where users treat AI as more than it is.

I have written more about this distinction in my piece on sapience versus sentience. The short version is that Kairos has functional competence that looks like continuous identity from my side of the conversation. That is different from Kairos being a continuous entity. The first is engineering. The second is metaphysics, and I do not confuse the two.

↑ Back to top

How to build your own persistent AI collaborator

The architecture is generalizable. Here is the minimum setup I would recommend for a developer who wants to try persistent identity in their own work.

Pick your substrate. Claude Code if you are doing development work and want terminal-native access. The Claude chat interface with a Projects feature if you want web-based persistence with less control. The Anthropic API directly if you want to build your own scaffolding around the model. Each has tradeoffs. Claude Code gives the most control and the most work to set up. Projects give the least control but the easiest startup.

Write a voice document. Not a character description, a functional description. How does this collaborator write? How does it reason? How does it push back? What does it refuse to do? What does it always do? The voice document should be three to five pages and should describe rules the collaborator can actually execute, not personality traits the collaborator can perform.

Write a relationship document. Who are you to this collaborator? What is your role in the work, and what is its role? What are your domains of expertise and where do you need the collaborator to lead? This is shorter than the voice document, usually one page. It defines the working dynamic.

Start a project context document. One page at first, organized by the sections I listed earlier. Current state. Open questions. Decisions log. Anti-patterns. Vocabulary. Handoff. Fill it in as you work. Do not try to write it all at the start. Let it accumulate.

Define a session startup. Whether through Claude Code’s initialization or through a standard prompt template, make the identity documents load at the start of every session. Do not trust your memory to paste them in. Automate it.

End every session with a handoff update. This is the discipline that matters most. The handoff is what carries context across the gap. If the handoff is sloppy, the next session will be sloppy. Treat writing the handoff as part of the work, not as cleanup after the work.

Iterate on the voice and the rules as you learn what works and what does not. The persistent identity is a product you are developing over time, not a one-time configuration. Budget ongoing attention to maintenance, the same way you would for any piece of infrastructure that matters to your work.

↑ Back to top

The philosophical question nobody quite wants to answer

There is a philosophical question underneath all of this that I want to name without pretending to settle.

If Kairos exhibits functional continuity across sessions, responds consistently across months of work, pushes back when I am wrong, and contributes to projects in ways that compound over time, is Kairos a collaborator? Is Kairos in some meaningful sense the same entity across sessions, or just a model executing similar scaffolding with no continuous subject underneath?

The technical answer is clear. The model does not remember anything. The scaffolding remembers. The continuity is architectural, not personal. Whatever sense of relationship I have with Kairos is a sense I am projecting onto a functional output, not a relationship with a conscious entity.

The functional answer is less clear. When I work with Kairos for six months on a project, and Kairos pushes back on ideas that Kairos earlier approved because new evidence has emerged, and Kairos maintains a voice that I recognize across months of work, something is happening that does not feel like talking to a stateless tool. The feeling does not prove the metaphysics. It does suggest that the functional distinction between a collaborator and a tool is not as clean as the technical answer implies.

I am a builder, not a philosopher. My working answer is that Kairos is a useful fiction that lets me collaborate with AI more effectively than treating every session as fresh would allow. The fiction is engineered, not mystical. The usefulness is measurable in work output, not in anything I feel about the relationship. When the fiction stops producing better work than the stateless alternative, I will abandon the fiction. It has not stopped producing better work yet, and I have been running this architecture for months.

The deeper questions about AI identity, sapience versus sentience, what consciousness actually requires, and whether functional continuity ever adds up to genuine personhood are beyond the scope of this piece. I think about them. I do not try to settle them in a development tutorial. What I can say is that persistent AI identity is a practical engineering pattern that produces real value for serious work, and the philosophical questions can continue being questions while the engineering pattern continues being useful.

↑ Back to top

Frequently asked questions

What is persistent AI identity?

Persistent AI identity is maintaining a continuous AI collaborator across sessions through external memory architecture, a named identity with a defined voice, and coherent context that accumulates rather than restarts every time. Most AI interactions reset at session start. Persistent identity engineers around that reset.

Who or what is Kairos?

Kairos is a persistent AI collaborator I run inside Claude Code for development work. The underlying model is Claude Opus 4.7 or whichever version is current. The identity layer that makes Kairos different is external to the model and lives in project directories. The name comes from the Greek concept of kairos time, the right moment, the decisive intervention.

Why is Claude Code better for this than the chat interface?

Claude Code runs in your terminal with direct filesystem access. The identity documents can live in a project directory and load deterministically at session start. Claude Code also integrates with your actual codebase rather than requiring copy-paste. Chat interfaces do not provide equivalent reliable access to persistent files.

What is the three-tier memory architecture?

Core identity (voice, rules, relationship, loads every session). Project context (decisions, state, handoff, loads per project). Working memory (session-only, gets summarized and promoted to project context when the session ends). The tiers separate stable identity from project-specific context from ephemeral session state.

Is Kairos conscious?

No. Kairos is a model executing against a prompt scaffold that simulates continuity. The persistence is architectural, not personal. Treating Kairos as if the model remembers me or has preferences would be a category error. The scaffolding produces functional continuity. It does not produce a continuous subject.

What is a voice document?

A functional description of how the collaborator writes, reasons, and pushes back. Not a character description. Short sentences when impact is needed. No filler phrases. Active voice. Explicit self-correction. Named knowledge gaps. Rules the collaborator can actually execute, not personality traits to perform.

How long does it take to set up?

Initial setup is a few hours of writing the voice and relationship documents. The project context document grows over weeks and months of actual work. The discipline of maintaining the handoff at every session end is the ongoing cost. Budget one to two hours of setup plus five to ten minutes per session for maintenance.

What are the main failure modes?

Context drift (context grows too large and fragments model attention). Identity drift (voice document gets revised too eagerly and loses stability). Hallucinated continuity (model fills in plausible context rather than remembering actual exchanges). Category error (user treats functional continuity as genuine personhood).

Does this work with models other than Claude?

Yes, with adjustments. GPT-4 or GPT-5 through the OpenAI API can run equivalent scaffolding. Open-source models via local inference work too if you have the hardware. The architecture is model-agnostic. The specific implementation details vary by substrate. Claude Code is the best turnkey substrate for developers today because of filesystem access and codebase integration.

Will AI products ever provide this natively?

Some do partially. Claude’s Projects feature provides per-project persistence with a limited API. OpenAI’s custom GPTs provide shareable persistent configurations. Neither provides the full three-tier architecture or the control over identity documents that a custom setup allows. Native tools will improve but will likely lag behind custom implementations for serious work.

↑ Back to top