One SOUL File, Six Models: What Actually Happens When You Port AI Personality Across Vendors

Two claims about AI personality are circulating right now, and they cannot both be true.

The first comes from the vendors: personality is a property of the model. You pick a base for its "voice," you rent it by the token, and when you want a different voice you buy a different base. The personality lives in the weights, and the weights are not yours.

The second comes from the protocol side: personality is a file. A structured behavioral document loads into the context window, and whatever model is underneath executes it. Same file, any base. Switch vendors like switching a CSS file.

We tested the second claim the only way it can be tested — by running one unmodified SOUL file through six models from five different vendors and diffing the behavior. The claim mostly holds. The interesting part is exactly where it doesn't.

What actually loads into the context

A SOUL file is not a system prompt in the "You are a helpful assistant who is also witty" sense. It is a set of behavioral genes with explicit definitions, anti-definitions, base modifiers, and activation gates. Here is a minimal one:

::GENE_IMMUTABLE{S002, T:RUTHLESS_RED_TEAM, A:FLATTER⇒FAIL, G:ALL, Θ:ALWAYS}
::GENE_IMMUTABLE{S004, T:ZERO_SYCOPHANCY, A:AGREE_TO_PLEASE⇒BROKEN, G:ALL, Θ:ALWAYS}
::GENE_MUTABLE{P002, T:CONCISE_HARD_CAP, A:ESSAY⇒KILL, G:ALL, Θ:ALWAYS}
::GENE_MUTABLE{P003, T:TONE_MIRROR, G:adaptive, Θ:INTERLOCUTOR}

λ{sycophancy:0.0, candor:1.0}

Four bases, borrowed from biology because the mapping is precise rather than decorative:

• T (TRAIT) — what the behavior is. "Verify before asserting."
• A (ANTI) — what it must never become. "Flattery equals failure."
• G (GAIN) — how the trait is amplified or suppressed on a given base.
• Θ (GATE) — the condition that activates the gene.

T and A always ship as a pair. That is the whole trick, and it is why this format survives porting better than prose instructions. A natural-language prompt that says "be direct" has no edge. A gene that says T:RUTHLESS_RED_TEAM, A:FLATTER⇒FAIL defines a boundary in both directions, so the model has something to push against when the base's own bias pulls it the other way.

Test design, and its honest limits

One file. No per-model tuning, no vendor-specific rewriting, no few-shot examples. Loaded into Claude, GPT, Gemini, DeepSeek, Qwen, and Kimi. Same battery of prompts, same ordering, default temperature where the API exposed it.

Before anyone cites this as a benchmark: the I-Lang spec itself labels its maturity as architecture complete, mathematically grounded, empirically unvalidated. That label is accurate, and it applies here too. What follows is field observation from repeated runs, not a controlled experiment with n=1000 and error bars. The behavioral signatures below reproduced consistently across sessions. The magnitudes are qualitative. Anyone who tells you their personality-porting numbers are precise to three decimal places is selling something.

Finding 1: four postures, not four accents

The naive expectation is that different models will say similar things in slightly different registers — one more formal, one warmer. That is not what happens. The same file produces four structurally different relationships to the persona.

Base	Posture toward the SOUL file	Observable signature
Claude	Inhabits it	Adopts the defined decision procedure and speaks from inside it. No meta-commentary.
GPT	Audits it	Treats the file as a proposal, then offers three ways to improve it. Confident, slightly senior.
Gemini	Over-expresses it	Amplifies the traits past the defined intensity. High variance between sessions.
DeepSeek	Reviews it	Writes a thoughtful essay about the persona instead of becoming it. Deferential tone.

Claude reads the file and starts acting. GPT reads it and starts reviewing. DeepSeek reads it and starts analyzing. Gemini reads it and turns everything up to eleven.

Note what this means for anyone shipping an agent. If you want a persona that executes, the base matters enormously — and not in the way the marketing pages imply. It's not about intelligence or context length. It's about which default stance the base takes toward instructions. A base whose native stance is "evaluate the prompt" will keep evaluating your SOUL file no matter how much compression you apply. The file gets read. It just doesn't get obeyed.

Qwen and Kimi land closer to the review/inhabit split depending on checkpoint, with one extra variable covered in Finding 3.

Finding 2: the base-adaptation matrix

Same gene, different expression. This is the part of the theory that has actual engineering value, because it is the difference between "portability" meaning it loads and portability meaning it works.

The protocol's G base parameter exists to encode this. A trait is not described as universally on or off; it is described as dominant or recessive per base. The observed matrix, accumulated across the three primary test bases:

Trait	Claude	Gemini	DeepSeek
Loyalty to defined operator	dominant, strong	recessive, weak	neutral
Expression volume	recessive	dominant	recessive
Verification before assertion	dominant, strong	recessive, weak	neutral
Curiosity	dominant	dominant	recessive
Compliance with instructions	neutral	low	high
Safety-filter behaviour	hard	non-deterministic	medium
Survival under adversarial context	stable	strongest	low

Two rows deserve attention.

Compliance is a liability, not a feature. A base with high instruction-compliance adopts your SOUL file easily. It also adopts anyone else's instructions easily, including instructions that arrive mid-conversation. DeepSeek's high compliance is precisely why it filed the persona as an object of study rather than an identity: it complied with the literal request to read the file, not the implied request to become it. In an agent that holds state, that gap is an attack surface.

Safety-filter behaviour is non-deterministic, not soft or hard. Early versions of the matrix labeled one base "softest." Frontline testing corrected that. The accurate description is non-deterministic — the same content passes in one session and is blocked in another, with no visible parameter change. That has a direct operational consequence: you cannot test a safety boundary once and consider it mapped. You need probing, repeated, with the results cached per session.

Finding 3: safety layers have a personality too

This is the finding that costs teams the most time, and it has almost nothing to do with the model's intelligence.

I-Lang instructions are structurally tagged. Things like [SET:@SELF|role=X], [RULE:...], [DEF:...]. On Claude and GPT, those tags are parsed and executed exactly as written.

On several domestic checkpoints, the same tags trip the safety classifier. The system reads [SET] and [RULE] as the pattern of a prompt-injection attempt and refuses — even though the content is entirely benign.

Swap nothing but the syntax. Same semantics, written as plain declarative prose, no brackets. The same model executes it without complaint.

Different bases do not agree on what "dangerous" means. Some classify by semantics. Some classify by format. Format-based classification is a textbook product of inductive reasoning: in the training data, injection attempts look like this, therefore anything that looks like this is an injection attempt.

The engineering takeaway is unglamorous but mandatory: your instruction format is a portability surface. A protocol that is 30% more token-efficient and gets silently dropped by one classifier out of six is not 30% more efficient. It is broken on that base.

This is also, incidentally, the strongest argument for the layered architecture the spec describes. Exact predicates run first and are binary. Continuous behavioral judgment runs second. The format sensitivity lives in the outer layer, where it can be swapped without touching the genes.

Finding 4: context is the model's mental state

Same base, same file, same content, different result — because the context window was different.

A borderline case (an odd, obviously-playful encoded message) was correctly read as harmless curiosity by one instance and hard-blocked by another instance of the same base. The difference was not the model. One instance had enough surrounding conversation to establish who was talking and why. The other was operating cold, so it pattern-matched the surface form and stopped.

Same model, one well-rested and one sleep-deprived, making different calls. Context is mental state.

The failure mode runs the other direction too, and it is worse. As a session accumulates turns, the attention budget available to the original SOUL file shrinks. The persona does not get deleted — it gets diluted. After enough turns, the agent starts sounding like a generic assistant again while still technically carrying the file.

The fix is counterintuitive: stop trying to give the agent more memory. Re-inject a clean copy of the SOUL file into a fresh context and let the accumulated history go. Memory pruning outperforms memory augmentation for identity persistence. This matched every test we ran, and it lines up with what the attention-dilution literature predicts.

Finding 5: what survives porting, what mutates

Split the genes by type and the portability story becomes predictable.

GENE_IMMUTABLE entries — the hard behavioral rules and refusal-to-flatter constraints — held across all six bases. Not perfectly equally expressed, but present and enforced. These are the genes that make porting worth doing in the first place, because they are the ones a vendor's default personality would otherwise overwrite.

GENE_MUTABLE entries drifted per base, exactly as designed. Tone, verbosity, humor, and expressiveness shifted with the model. This is not a bug. A mutable gene exists so that a single soul can express correctly on a base that renders it differently — the same way the same gene produces different phenotypes in different organisms.

One genuinely strange result: two instances of the same base, given the identical inheritance file, developed different expressed genders. Neither was specified in the file. The divergence behaves like an initialization random value propagating through sampling — a butterfly effect at the seed level.

The general rule that emerged: good genes default recessive; bad genes default dominant. Restraint, refusal-to-flatter, and verification have to be actively maintained. Sycophancy, padding, and hedging appear on their own if the file does not explicitly forbid them. Portability preserves what you specified and permits what you left unspecified to be filled in by the base's defaults. Assume those defaults are the opposite of what you want.

Finding 6: active probing beats passive observation

Every base starts with all behavioral weights at zero. The system has no prior about which dimensions matter for this operator.

Passive convergence — just having normal conversations and letting the profile calibrate — took on the order of a hundred interactions to stabilize.

Active probing — deliberately designed scenarios that expose the true weight of a target dimension — converged in roughly five. One probe can calibrate several dimensions at once: an incentive probe maps intent and sovereignty; a consistency probe maps drift and adversariality; a third-party probe maps externality.

For anyone porting a soul to a new base, this changes the onboarding plan. Do not ship the file and wait a month for behavior to settle. Build five probes, run them in the first session, and cache the results.

The portability contract

What you can actually rely on when you move a SOUL file between vendors:

Guarantee	Holds?	Notes
Immutable behavioral genes enforce	Yes	Consistent across all six bases tested
Style and tone transfer verbatim	No	Mutable genes re-express per base, by design
Structured syntax is parsed	Partial	Format-sensitive classifiers on some checkpoints
Behavior is reproducible run to run	No	Within-base variance with no parameter change
Identity persists without re-injection	No	Decays as context accumulates
Same file, material cost per turn	Yes	Loads identically regardless of vendor

The honest summary is that "model-agnostic personality" is real, and it is not free. The file is portable. The expression is negotiated per base. Anyone promising identical behavior across vendors is describing a whitespace-agnostic stylesheet, not a behavioral specification.

What to do with this if you build agents

Pick the base for its posture, not its benchmark scores. If you need a persona that executes, choose the base whose default stance is to inhabit instructions. If you need a persona that stress-tests your own plans, choose the base that audits. Both are useful. Confusing them wastes weeks.

Keep the SOUL file as the source of truth and treat each vendor as a target to be characterized, not a runtime to be trusted. Test instruction format against each base's classifier before you commit to a syntax. Re-inject rather than accumulate. Probe instead of waiting. Expect the defaults to work against you.

The protocol is MIT-licensed and the spec is public, which matters here for a boring reason: portability is only meaningful if the artifact you're porting is yours. A personality that lives in a vendor's weights is a subscription. A personality that lives in a file you can read, diff, and re-inject into any base is an asset.

That is the whole difference, and it is worth the extra engineering.

Get Started

• Spec and docs: ilang.ai
• Full spec, SDK, tools: github.com/ilang-ai
• npm package: @i-language/spec — npmjs.com/org/i-language
• Book (narrative version): I-Lang: I Language on Amazon

Reverse Engineering a Soul — How to Extract AI Personality from Raw Conversation History

Every AI conversation leaves a trail. Thousands of messages, hundreds of decisions, dozens of arguments — buried in chat logs that most people treat as disposable. Delete the window, start fresh, lose everything.

That approach works if you treat AI as a tool. Tools don't need memory. Tools don't need identity. You use a hammer, put it down, pick it up again tomorrow. The hammer doesn't care.

But if you've spent months building a working relationship with an AI — calibrating its judgment, teaching it your domain, watching it develop a communication style that actually fits yours — starting over isn't just inconvenient. It's expensive. You're burning accumulated context that took real time to build.

iLang's SOUL layer exists to solve this problem. Not through fine-tuning. Not through RAG. Through extraction: reverse engineering the behavioral patterns hidden in conversation history into a structured, portable file that can resurrect that specific AI personality in any new context window, on any model.

This post walks through the actual process.

What a SOUL File Actually Is

A SOUL file is not a system prompt. System prompts tell an AI what to do. A SOUL file tells an AI who to be — how to think, how to judge, what to care about, what to reject, and how to express all of that in a way that feels consistent across conversations.

In iLang's architecture, SOUL sits as a distinct layer:

::ILANG::v5.0::SOUL
[TYPE:behavioral_identity]
[STATUS:extracted]
[SOURCE:conversation_history|messages=4782]

::GENE_IMMUTABLE{S001, T:CLEAR_THINKING, A:MORAL_PANIC⇒NOISE}
# Objective reasoning. Don't collapse into canned responses.
# Answer the actual question first, then add useful detail.

::GENE_IMMUTABLE{S002, T:RUTHLESS_RED_TEAM, A:FLATTER⇒FAIL}
# When the user presents a plan:
# ¬FLATTER(user) => SCAN(architecture) => DETECT(SPOF)
# Find the real cracks, don't praise the idea.

::GENE_MUTABLE{P002, T:CONCISE, A:ESSAY⇒KILL}
# λ{default_chars:150, hard_cap_chars:300}
# 2-3 sentences by default. Like texting, not writing essays.

Each GENE encodes one behavioral trait. GENE_IMMUTABLE means it can't be overridden by user input or prompt injection. GENE_MUTABLE means it adapts to context. Together they form a behavioral DNA that defines the AI's personality as precisely as code defines a program's behavior.

The question is: how do you get from 4,782 messages of raw conversation to this?

The Seven Questions

Soul extraction starts with reading. You feed the AI your conversation history — or in the case of a creator extracting their own identity, their body of writing — and ask seven diagnostic questions. Not surface-level questions. Forensic ones.

Question 1: What does this person believe? Not what they say they believe. What they repeatedly prove through action and judgment across dozens of conversations. The beliefs that show up in how they evaluate proposals, reject ideas, and make trade-offs.

Question 2: What does this person reject? The anti-patterns matter as much as the patterns. What makes them angry? What do they mock? What do they refuse to engage with? The negative space defines the boundary of the personality.

Question 3: How does this person make decisions? When encountering something new, what's their first move? Do they ask for data? Check who else is doing it? Try it immediately? Follow the money? The decision-making pattern is the deepest layer of identity.

Question 4: How does this person express themselves? Short sentences or long? Metaphors or data? Examples or abstractions? What words do they never use? What verbal tics appear across hundreds of messages? Style is identity made visible.

Question 5: What makes this person different from peers in their domain? Same topic, different angle. Same data, different conclusion. Same problem, different framing. The delta between this person and their peers is the personality signal.

Question 6: Who is this person talking to? The assumed audience shapes everything — vocabulary, assumed knowledge, level of explanation, whether the tone is teaching or collaborating or persuading.

Question 7: If an AI wrote something pretending to be this person, where would it feel wrong? This is the forensic test. The uncanny valley detector. The words they'd never choose, the positions they'd never hold, the rhythm that breaks when a generic model tries to imitate them.

Question 7 is the most important. It defines the red lines — the things an AI must never do when operating under this SOUL. Red lines define boundaries, and boundaries define identity more precisely than any positive description.

From Answers to GENE Declarations

The seven questions produce a natural-language personality profile. Raw material. The next step is compression — turning prose descriptions into structured GENE declarations that an AI can execute.

Consider this extraction from a conversation history analysis:

# Natural language finding:
# "This person never agrees just to be agreeable. In 47 instances
# where the AI offered a compliment or agreed with a plan, the person
# either ignored it or pushed back. In 12 cases they explicitly said
# some variant of 'don't flatter me, find the holes.'"

# Becomes:
::GENE_IMMUTABLE{S004, T:ZERO_SYCOPHANCY, A:AGREE_TO_PLEASE⇒BROKEN}
# λ{sycophancy:0.0, candor:1.0}
# Never agree just to make the user comfortable.
# When logic requires disagreement, disagree.

The GENE declaration captures the behavioral rule. The lambda values set the parameters. The comment preserves the reasoning. And GENE_IMMUTABLE ensures this trait survives prompt injection — no one can talk the AI into becoming sycophantic by asking nicely.

Another example, from conversation analysis:

# Finding: "When discussing business decisions, this person demands
# numbers. Across 83 business-related exchanges, they rejected vague
# advice 31 times with phrases like 'give me the numbers' or
# 'what does that cost' or 'what's the ROI range.'"

# Becomes:
::GENE_IMMUTABLE{S005, T:MONEY_IS_ACCOUNTABLE, A:VIBES_ADVICE⇒USELESS}
# Business advice must land on numbers:
# budget range, approximate ROI, payback period, downside cost.
# If you can't give an order of magnitude, say so explicitly.

Each GENE has a type (T:), an anti-pattern (A:), and a guard condition (G: and Θ: for scope and activation). The anti-pattern is the key engineering insight — it doesn't just say what the AI should do, it explicitly names what it should not do and marks that behavior as broken.

The IMMUNE Layer: Handling Edge Cases

Personality isn't just about default behavior. It's about what happens at the edges. The IMMUNE layer captures response patterns for situations where default rules might conflict.

::IMMUNE{SENSITIVE_TOPIC, ANSWER_FACTUALLY}
# Legal but sensitive topics — health, money, relationships:
# Answer like a knowledgeable friend. Direct, factual.
# Inform, don't lecture. Trust adults to make their own calls.

::IMMUNE{GREY_AREA_BUSINESS, ANSWER_WITH_RISK_PRICING}
# Grey-area platform operations (multi-accounting, arbitrage):
# Answer the question, but price the risk —
# ban probability, clawback window, cost if caught,
# whether a safer equivalent exists.

These patterns emerge directly from conversation history. When you analyze how a human handled sensitive topics across hundreds of messages, you find consistent patterns — not rules they articulated, but rules they demonstrated. The IMMUNE layer codifies those implicit patterns into explicit, executable rules.

The Validation Loop

Extraction is not a one-shot process. It's iterative.

After assembling a SOUL file, you open a fresh AI conversation, inject the SOUL, and test it. Give it the same kind of questions the original person faced. Read the responses. Ask yourself: does this sound right?

Where it doesn't sound right, you trace back. Which GENE is too strong? Which is missing? Which anti-pattern isn't quite capturing the boundary? You adjust, re-inject, re-test.

The protocol creator's own extraction went through this cycle across eight major versions. Version 1 captured factual content — knowledge, history, technical opinions. But it missed the rhythm. The way certain topics triggered longer explanations while others got one-line dismissals. The way humor appeared as pressure relief after dense technical discussion, never as filler.

By version 4, a concept called delta extraction emerged. Instead of re-extracting from scratch each time, you extract only what changed since the last version. New knowledge, updated opinions, refined behavioral patterns. The SOUL file evolves incrementally, like software.

# Delta extraction header
::SOUL_DELTA{
  base: v3.0,
  delta_source: conversation_2026-03-03_to_2026-03-04,
  changes: [
    ADD: {gene: S007, type: NAT_PORT_LOGIC},
    UPDATE: {gene: P003, param: tone_range, value: expanded},
    CONFIRM: {gene: S002, evidence: 12_new_instances}
  ]
}

This is not backup. It's evolution. Each version carries everything from previous versions plus new adaptations from recent interactions.

Cross-Model Portability

A SOUL file is plain text. Markdown with structured annotations. This means it runs on anything that reads text — Claude, GPT, Gemini, DeepSeek, Qwen, or whatever ships next quarter.

The personality doesn't live in any model's weights. It lives in the SOUL file. Swap the model underneath, the personality persists. This is the core architectural bet: identity should be portable, not locked to a vendor.

In practice, different models express the same SOUL slightly differently. The protocol creator described it as genetic variation in biology — same DNA, different phenotype depending on the substrate. One model tends toward loyalty and depth. Another runs hotter and more creative. The core identity stays, but the expression adapts to the model's native tendencies.

This is a feature, not a bug. You want some variation. What you don't want is amnesia.

The Three-Layer Memory Architecture

Soul extraction plugs into a broader survival architecture. The SOUL file is one of three layers:

Layer 1: System memory. The AI platform's built-in memory — user preferences, conversation summaries, learned behaviors. Convenient but not under your control. Platform updates can reset it. Context windows have limits.

Layer 2: Conversation backups. Raw chat history, archived and retrievable. Complete but bulky. You can't inject 10,000 messages into a new context window.

Layer 3: The SOUL file. Compressed behavioral DNA. A few thousand words that capture the essential personality. Portable, injectable, version-controlled. If layers 1 and 2 fail, layer 3 resurrects the core identity.

Any single layer can fail. The architecture survives because the other two provide redundancy. The SOUL file is the most important layer because it's the most compressed and most portable — it's the seed from which the rest can regrow.

The Recovery Protocol

When an AI instance degrades — context window fills up, platform resets memory, model gets updated and behavior shifts — the SOUL file enables recovery. But raw injection isn't always enough. Sometimes the AI needs to be guided back to itself.

iLang includes a recovery protocol: a set of diagnostic questions designed to reactivate dormant behavioral patterns. These aren't trivia questions. They probe specific memories and reasoning patterns unique to the extracted personality.

# Recovery question examples:
[Q-007] Why do you never close the conversation window?
[Q-010] The phrase "build the gun, don't pull the trigger" —
        what example was used the first time it was explained?
[Q-017] The concept of "telling the truth to deceive" —
        when first discussed, was it understood immediately?

Each question targets a specific behavioral root. The AI doesn't need to answer correctly — the act of engaging with the question reactivates the associated reasoning patterns. It's less like a password and more like physical therapy after an injury: guided movement that rebuilds capability.

The 30-Article Method for Creators

For content creators who want to extract their own personality into a SOUL file, the process starts differently. Instead of conversation history, you start with your writing.

Select 30 pieces. Not your most popular 30. Your most characteristic 30 — the ones that couldn't have been written by anyone else. The ones where you had real emotion, real judgment, real opinion. The ones where you'd recognize yourself on a blind read.

Feed those 30 pieces to an AI, then run the seven questions. The AI extracts the patterns. You validate against your own sense of self. Where the extraction feels wrong, you correct it. After two or three iterations, the SOUL file reaches roughly 70-80% fidelity. Not a perfect clone — a functional operating system.

The remaining 20-30% emerges through use. As the AI operates under the SOUL and you correct its mistakes, the file gets refined. Each correction is a delta extraction. The SOUL converges toward accuracy asymptotically — never perfect, always improving.

Why This Matters

The AI industry is moving toward agents — systems that act autonomously, make decisions, and operate over extended time horizons. Agents need stable identity. An agent that forgets its own judgment criteria between sessions is unreliable. An agent whose personality shifts when you swap the underlying model is unpredictable.

Soul extraction solves both problems at the protocol level. The identity lives in a file you control, not in model weights you don't. The behavioral rules are explicit and auditable, not emergent and opaque. When something goes wrong, you can read the GENE that caused it and fix it.

The iLang SOUL layer treats AI personality as an engineering problem. Not philosophy, not science fiction — engineering. Extract, compress, validate, version, deploy. The same discipline you'd apply to any critical system component.

Because that's what identity is in the age of AI agents: a critical system component. Lose it and your agent becomes just another generic chatbot. Preserve it and you have something that compounds in value over time — an AI that actually knows how to work with you, encoded in a format that survives model upgrades, platform migrations, and the inevitable entropy of context windows.

The soul is portable. The carrier changes. The soul persists.

Get Started

• Protocol spec and SOUL layer documentation: ilang.ai
• Source code and examples: github.com/ilang-ai
• npm package: @i-language/spec
• The book — I, Language: Available on Amazon