JPAF: Jungian Personality Adaptation for LLM Agents

The problem JPAF targets: a persona that stops drifting

Most prompts that assign a personality to an LLM agent are static. You write "you are an INTJ" into a system message and the model holds that framing until a long conversation pushes it somewhere else. JPAF, the Jungian Personality Adaptation Framework in agent-topia/evolving_personality, starts from the opposite assumption: personality should change, but along a defined path rather than randomly. The README describes the goal as giving LLMs "structured, adaptive, and evolving personalities" and names three mechanisms that do the work, dominant-auxiliary coordination, reinforcement-compensation, and reflection. The audience is narrow and specific: developers building game NPCs, personalized assistants, social simulation and role-playing agents, and multi-agent systems where each agent needs a distinguishable and testable character. The project's own use-case list also includes HCI research on personality consistency. If your problem is "my agent sounds the same in every session and I want that to be a design decision rather than an accident," this repository is aimed at you. If your problem is instruction-following quality or tool use, it is not.

Dominant-auxiliary, reinforcement-compensation and reflection as an architecture

The framework borrows Jung's eight psychological types and expresses personality as weighted type differentiation rather than a single label. The README names three mechanisms. Dominant-auxiliary coordination keeps a core personality consistent across turns. Reinforcement-compensation handles short-term contextual adaptation, so the agent can shift register without abandoning its base type. Reflection drives long-term evolution, which is the part that makes the repository's name literal. What the README does not give is the data flow: it does not state where the weights live, whether they are stored in a file, a database or in memory, or how a reflection step updates them. The repository layout hints at two pipelines, Personality_test for verification and Personality_changes for evolution, and the paper at arXiv 2601.10025 is cited as the source for the theory. Anyone evaluating this should read the paper first, because the README is a usage guide, not a specification. That is a real gap for an engineer deciding whether the mechanism fits an existing agent loop.

Getting it running: conda, para.env and personality_test.py

The install path is conventional and short. Clone the main branch, create a conda environment on Python 3.10 or later, and install from requirement.txt. Note the filename: the README says pip install -r requirement.txt, not requirements.txt, so a typo there is your first failure. Configuration is done by copying para.env.example into two locations, Personality_test/para.env and Personality_changes/para.env, and filling in credentials. The env file uses LLM_MODEL to select "OPENAI", "QWEN" or "LLAMA", and each provider has three keys: an API key, a base URL and a model name. The example values include gpt-4, qwen3-235b-a22b-instruct-2507 and meta-llama/llama-4-maverick. Because the base URL is configurable per provider, any OpenAI-compatible endpoint should work, but the README only documents those three. The test entry point is personality_test.py with four flags: method, mbti_num, model and nums, plus test_num for the longer runs. The README shows three methods. judge produces per-question reasoning about which dimension a question probes. no_prompt gives the baseline answer. test gives the personality verification result. The example output for test shows an ISTJ justifying a J answer with an explicit reference to being a planner, which is the kind of trace you want if you plan to audit alignment.

Where the framework is thin: licence, releases and model coverage

Three facts should slow down anyone planning to build on this. First, the licence is not declared in the material available, and the README does not mention one. That is a blocker for commercial use until you resolve it with the maintainers, and I am not going to guess at a licence on the repository's behalf. Second, there are no releases. The last push is dated 2026-03-17, so the code is active, but with no tags you cannot pin a version, and your dependency is a commit hash. Third, the README claims validation on GPT, Llama and Qwen and reports type activation accuracy above 90% for GPT and Qwen but 65 to 95% for Llama. That spread is wide enough to matter, and it is self-reported in the README with no per-model breakdown shown. The 100% MBTI alignment claim is the kind of number that usually reflects a narrow test set, and the README does not describe how the questionnaire was scored or whether the judge model and the subject model were ever the same. Treat all of these figures as hypotheses to reproduce, not as specifications.

The wrong tool for production assistants and stateless workloads

JPAF is a research framework with a test harness attached, and it behaves like one. If you need a personality layer inside a latency-sensitive product, the reflection mechanism implies state that persists across sessions, and the README does not document where that state is written or how it is migrated. If you need deterministic output for compliance or regression testing, an evolving personality is the opposite of what you want, because the agent's behaviour is supposed to change over time by design. The framework is also the wrong choice if your stack is not Python or if you cannot run a conda environment, since the documented install path assumes both. And if your models are outside the OpenAI, Qwen and Llama families, you are on your own: the env file has three provider blocks, and adding a fourth means editing code the README does not describe. None of this is a defect in the research, but it is a mismatch with production expectations, and the README does not pretend otherwise.

How JPAF differs from a prompt-template personality library

The obvious alternative is a persona library that ships a set of system prompts, one per MBTI type, and leaves the model to stay in character. The difference in approach is where adaptation happens. A prompt-template library encodes personality once, at the start of the conversation, and any drift is an error. JPAF encodes personality as weights over Jungian types and then runs three update mechanisms against them, so drift is the intended output and the verification suite exists to measure whether the drift stayed inside the type. That is a heavier design: you get a test harness, a paper, and two directories of experiment code, and you pay for it with configuration files, API credentials in two places, and a dependency on a model that scores well on the questionnaire. If you only need a consistent voice for a chatbot, the prompt-template approach is cheaper and easier to reason about. If you need to study or demonstrate personality change over time, the template approach gives you nothing to measure.

Maintenance and upgrade cost, and what the missing licence means

The maintenance picture is simple to state and hard to like. There are no releases, so upgrades mean pulling from main and re-reading the diff. The dependency surface is a single requirement.txt, and the README does not indicate whether versions are pinned, which means a pip install today and a pip install in six months may resolve differently. API keys live in para.env files inside two subdirectories, copied from a shared example, so rotating a credential means editing two files and keeping them in sync. Because the licence is undeclared, you cannot assume any particular set of rights, and the safe reading is that all rights are reserved until the maintainers state otherwise. I am not giving legal advice here; the practical point is that a licence question is a procurement question, and it is cheaper to ask it before you build than after.

Editorial conclusion

Adopt JPAF if you need an inspectable MBTI layer for role-play or social simulation agents and you are willing to pin a model snapshot and build your own evaluation harness. Do not adopt it if you need a maintained library with releases, a declared licence, or support for models outside the OpenAI, Qwen and Llama paths wired into para.env. Before writing production code, confirm three things: the licence status of the repository, whether requirement.txt pins versions, and whether the judge, no_prompt and test methods in Personality_test and Personality_changes reproduce the alignment numbers in arXiv 2601.10025 on your own model endpoint.

Official sources

1. agent-topia/evolving_personality on GitHub
2. Issues
3. Project website
4. README