Agent Personas: Load a File, Get a Role — The File-First Method

Try this in 60 seconds. Open a file. Write who your agent should be — not just what it should know. Give it a stance, a working process, and a hard line it will not cross. Save it where your tool loads context automatically (CLAUDE.md, AGENTS.md, .cursorrules). That is the whole method. The rest of this piece explains why it works, why it outlives any plugin, and where it stops working — but you do not need to finish reading to start.

The Problem: Your Agent Has No Role

Most people treat their AI agent like an intern who shows up every morning with total amnesia. You spend the first ten minutes of every session re-explaining the project, re-stating your standards, re-asserting that no, you do not want Prisma, you want Drizzle. The agent nods, does the task, and the next morning the amnesia is back.

The common diagnosis is "the agent has no memory." That diagnosis is wrong, and it sends people down the wrong fix. The real problem is sharper: your agent has no role. It was never given one. It arrives every session as a blank generalist — competent at everything, specialized in nothing, holding none of your judgment, none of your standards, none of the expertise you spent years building. You are not re-explaining because it forgot. You are re-explaining because you never gave it a role to carry in the first place.

Watch what happens without one. The same agent that wrote a clean state machine yesterday will suggest a sprawling mess today, because nothing told it your codebase values simplicity over cleverness. It will pass you a code review that misses the injection vector you care about, because nothing told it to think like an attacker. It will produce documentation in five different voices across five sessions, because nothing told it who it is supposed to sound like. The output drifts because there is no anchor. You are not fighting amnesia — you are fighting the absence of a standard.

Memory is the wrong frame because memory is retrospective — it records what already happened. A role is prospective — it defines who the agent is and how it should work before the work begins. You can hand an agent a sharp role with zero memory of past sessions and it will still outperform a generalist with perfect recall, because the role tells it how to think about the task in front of it right now.

This article is about how to give your agent a role that survives — a role defined in a file, loaded every session, portable across every tool, and immune to the framework updates that break everything else. The method has one moving part: a file. Everything else follows from taking that file seriously as the carrier of the role.

Why Files Are the Right Carrier for a Persona

You could define a role many ways — a hardcoded prompt in a script, a configuration in a vendor's dashboard, a memory entry in a plugin. Almost all of them are wrong, and the reason comes down to which layer of your stack changes slowest.

In traditional software there is an old principle, most clearly stated by Martin Kleppmann in Designing Data-Intensive Applications: data outlives code. Code gets refactored, rewritten, and deleted — that work is computationally cheap, so it happens often. Data does not. Data migrates across generations of an application and, to the organization, often becomes more valuable than the code that processes it. The corollary is uncomfortable: every line of code you write today will eventually be deleted; the only question is whether your data survives the transition.

Map that onto agent architecture and a clear hierarchy of change-rates appears. The model itself — Claude to GPT to Gemini — is the fastest-moving layer, iterating every few months. The orchestration logic — tool calling, MCP wiring, how subagents are dispatched — sits in the middle. The slowest layer is your role definition: who the agent is, who it serves, where its boundaries are, what counts as good work. Those facts barely move over years.

Invert it: if you hardcode your role into a plugin, a custom script, or a vendor's MCP server, you have married the fastest-moving layer. When the vendor changes their API, or the model drops a feature, your role breaks with it. If you write the role into a file, you have bet on the slowest-moving layer. The model can swap. The tool can update. The role survives.

This is not theoretical. Every major AI coding tool reads a text config file. There are no exceptions.

The striking part is the convergence. OpenAI released AGENTS.md in August 2025 as an open standard co-developed with Google, Sourcegraph, Cursor, and Factory. By December 2025, OpenAI donated AGENTS.md to the Linux Foundation's newly formed Agentic AI Foundation — co-founded with Anthropic (which contributed MCP) and Block. As of mid-2026, the AGENTS.md registry lists 23-plus compatible tools — Cursor, Codex, Gemini CLI, Copilot, Windsurf, Devin, Jules, Augment, JetBrains Junie, and more.

Their stated philosophy is telling. From the AGENTS.md site itself: "Rather than introducing another proprietary file, we chose a name and format that could work for anyone." The major vendors agreeing on one shared filename is the ecosystem quietly admitting that proprietary config files were a tax on everyone.

Read that table one more time. The "maximum common divisor" of the entire AI coding ecosystem is a plain text file. When you write a role into a file, you are not betting on Claude Code. You are betting on the one interface every agent is guaranteed to support, because reading a text file is the floor, not a feature. That floor is not going away.

And the convergence on AGENTS.md is not a coincidence — it is the ecosystem quietly admitting that proprietary config files were a tax on everyone. When the major vendors agree on one shared filename, they are telling you the same thing this article argues: the role is the asset, the file is the carrier, and the carrier should not be owned by any single tool. Writing your persona into AGENTS.md today is the closest thing to writing it in a language every future tool will still speak.

There is a third software-engineering principle underneath this one: configuration over code. Define behavior in a config file rather than hardcoding it, so the behavior can change without touching code. In the agent world this is the difference between writing your role as a markdown file and writing it as a Python script that injects a prompt. The file is configuration — change the role, you change the file, nothing redeploys. The script is code — change the role, you edit code, test it, ship it, and hope the model still behaves the same on the other side. Every team that has tried to manage agent behavior in code has rediscovered why the rest of the industry moved configuration out of code decades ago.

Put the three principles together — data outlives code, everything is a file, configuration over code — and they all point the same direction. Put the slow, stable, valuable parts of your agent into a file. Put the fast, fragile, disposable parts into code and tools. The file is where your investment compounds. The code is where you pay rent. When the next model arrives — and it will, every few months — your personas load into it unchanged. When the tool you used yesterday shuts down tomorrow, your personas are still readable by you, by hand, in a terminal. You are not building on a platform. You are building on a format, and formats outlive platforms.

Load a File, Get a Specialist

So a file is the right carrier. The next question is what to put in it. An agent persona is a loaded role — a file that defines who an AI agent is, what it knows, how it works, and what it refuses, loaded automatically at the start of every session. Most people stop too early: they write a list of facts and preferences, save it, and call it done. That gives you an agent that knows things. It does not give you an agent that is anything.

The difference is the difference between handing a new hire a binder of rules and putting them into a role. A binder sits on the desk and gets consulted when someone remembers it exists. A role is worn from the moment a person walks through the door — it shapes what they notice first, what they treat as in scope, what they push back on without being asked. Facts are retrieved; roles are inhabited.

Loading a file as a persona is that different operation. You are not storing facts. You are loading a coherent identity — expertise, a working process, output standards, hard constraints. When the file loads, the generalist model becomes, for the duration of the session, a specialist. From the model's perspective, both the system prompt and your persona file are text in the context window — but the system prompt sits in a privileged position, while your persona file is part of the longer context the model works within. Your persona cannot override the system prompt; it can only shape the model's prior within the latitude the system prompt allows. That is also why, later, a truly non-negotiable rule will need a hook rather than a file.

This is not a community trick anymore. It is official infrastructure. Claude Code's subagent system lets you define a persona as a markdown file in .claude/agents/ with a YAML header:

• a name and description so the orchestrator knows when to invoke it
• the tools it is allowed to touch
• the model it runs on
• a memory scope — user, project, or local

Each persona then runs in its own context window with its own memory directory at .claude/agent-memory/<name>/. Identity and experience are bound together by construction, and personas do not bleed into each other. A security reviewer and a brand manager can coexist in the same project, each accumulating its own learnings, neither contaminating the other's judgment.

More precisely: the model is not literally "becoming" a person. It is receiving a block of context that shifts its prior — what it pays attention to, what it treats as in-scope, what it refuses. The effect, for practical purposes, is a specialist that loads on demand.

What goes into a persona file? The clearest synthesis is the "five elements" model: Role (who you are), Expertise (what you know), Process (how you work), Output (what you produce), Constraints (what you refuse). The difference between a useless persona and a sharp one is usually the last three. "You are a helpful assistant" establishes nothing. "You are a senior application security engineer who thinks like an attacker to find vulnerabilities before they're exploited" establishes seniority, specialty, and stance in one line. Then Expertise sets the boundary of what the persona knows and, just as importantly, what it does not — a persona that claims to know everything dilutes its authority on anything. Process turns expertise into action by specifying the order of operations, so the persona does not improvise a different method each time. Output pins down the deliverable so the persona cannot drift into a new format every session. And Constraints, the most underrated section, define the lines the persona will not cross — which is where most of its actual value lives. A persona without constraints is polite. A persona with constraints is useful.

That is the upgrade. An agent that merely knows things is a search engine. An agent loaded with a role is a colleague — one who shows up already specialized, already biased toward the right judgment, and already clear on what not to do.

A Persona Is an Executable Task Definition

Here is the part most guides miss, and it is the heart of the method. A persona file is not a description of a role. It is a task definition the agent executes.

Most documentation in the world is passive. A wiki page, a Notion doc, a company handbook — they describe how things should be done, and then they sit there, waiting for a human to read them, remember them, and apply them. The knowledge is stored. It is not operational. Under deadline pressure, nobody opens the handbook.

A persona file is different because the agent loads it automatically at the start of every session and treats its contents as working context for the task that follows. The role does not wait to be consulted. It is already in the room, shaping the work from the first token.

Have you checked: the difference between a team that runs the same postmortem five times and a team that fixes a failure class once is rarely intelligence. It is whether the lesson survived long enough to be applied the next time. A persona file survives that transit better than memory, meetings, or wikis — because it is not a record of a lesson. It is the lesson, encoded as a working procedure, loaded every single time.

Loading a role means turning documentation into behavior. This is the jump from knowledge management to capability management, and it is why a persona file is qualitatively different from a folder of notes. Notes are read. Personas are run.

Look at each section of a well-written persona and you will see an instruction about to execute. The Process section is not prose about how the agent might approach the work — it is the ordered sequence of steps the agent will take. "Trace untrusted data to its sink before reading the happy path" is not a suggestion; it is step two. The Constraints section is not a wish list of preferences — it is the set of actions the agent will refuse. "Never approve a pull request that adds a secret to source" is a gate, not a guideline. The Output section is not a description of the deliverable — it is the exact format the agent will produce, every time. Every line in a sharp persona is a behavior, not a sentence.

Here is what that buys you in practice. A content persona whose Process says "verify every number against its source before publishing" does not occasionally fact-check. It fact-checks every time, because the step is loaded into its working context before the first word is written. A security persona whose Constraints say "never skip the input-trace" does not skip it when the diff looks small and tempting. The rule is already in the room. The difference between a team that ships the same bug twice and a team that kills a failure class is whether the lesson survived as a loaded procedure or died as a postmortem nobody reopened.

The Four Properties of a File-First Persona

Strip the method to its bones and four properties remain. Each is independently valuable; together they explain why a file keeps winning even as fancier systems appear.

1. It is future-proof. A persona written in a file outlives model upgrades, tool rewrites, and vendor shutdowns because every agent reads text. You are not maintaining compatibility with a framework. You are maintaining compatibility with the alphabet — the one interface no vendor can deprecate.

2. It compounds experience. Every time a persona does its job and you learn something — a recurring failure mode, a better phrasing of a constraint, a new edge case — you write it back into the file. The persona gets sharper with use. After a few months a persona file feels less like a config and more like a colleague who has been on the project for months, rather than a contractor who starts fresh every morning.

The compounding is real and it is the part that surprises people most. Each correction you write back is a mistake the agent will not make again — not because it learned in some neural sense, but because the rule is now in the file it loads every morning. The persona stores rules distilled from past failures, not records of past events — that is the difference between a working role and a log. Memory logs what happened; a persona encodes what to do about it.

Over a year, the gap between an agent with a curated persona and an agent starting from a blank prompt becomes enormous. One repeats the same errors in slightly different forms, forever. The other carries a growing record of every way it has ever been wrong — which is exactly what makes it hard to fool the same way twice. This is the compounding interest of roles, and unlike most compound interest, it costs nothing but the discipline to write the lesson down.

3. It updates instantly. Find a bug in your persona's judgment? Open the file, change a line, and the next session loads the new version. No redeploy. No waiting for a framework release. No code. The iteration speed of your agent's behavior equals your typing speed. This is the property people underestimate most. If the persona lived in code, fixing it would mean editing a script, testing it, shipping it, and hoping the model still behaves the same on the other side. If it lived in a vendor's platform, fixing it would mean waiting on their release cycle, then re-verifying against whatever they changed underneath you. A file deletes the entire loop between noticing a flaw and having the agent act on the fix. In any system, the team with the shortest feedback loop learns fastest — and a file is as short as a feedback loop gets. No platform-based system comes close, because every one of them sits between you and the model.

4. It is radically simple. No database, no embedding pipeline, no API key, no server. The entire mechanism is a text file that syncs over git or any file-sync tool. A new person can understand the whole system by reading the folder. Simplicity is not just aesthetic here — it is why the thing survives. Complex stacks break; simple files do not.

There is a reason the file keeps winning, and it is not nostalgia. Research cited by HumanLayer indicates frontier thinking models can follow roughly 150–200 instructions with reasonable consistency — a figure HumanLayer notes has not been rigorously studied. Claude Code's own system prompt already consumes roughly 50 of those "instruction slots." The more you cram into a system, the more all of it degrades — not just the new rules, the old ones too. Quality falls uniformly.

A focused persona file beats a bloated configuration not because files are magic, but because the model's attention is finite and a sharp persona respects that. Thirty working rules, written as a role, will outperform three hundred scattered facts every time. I once watched a security persona I had trimmed to its essentials catch a dependency-confusion risk that a far longer, fact-stuffed configuration had missed for weeks — not because the short file knew more, but because it was focused enough that every rule inside it actually got applied. A persona is a budget of attention. Spend it on the rules that matter, and the agent has the bandwidth to follow them.

A Real System: 19 Personas

General principles are cheap. Here is what the method looks like when you actually live in it.

I run a solo operation built on this idea. There is no central "agent brain" and no custom orchestration database. The entire system is a tree of markdown files, and the unit of organization is the persona. I maintain nineteen of them — a coordinator, a designated critic whose only job is to find holes in my thinking, and seventeen specialists covering everything from brand and content to security, testing, and finance.

The structure is deliberately boring. Each persona is one markdown file with the five-element shape: identity, expertise, process, output, constraints. They live under a roles directory. A top-level instruction file routes work to the right persona by trigger words — saying "load the security reviewer" does exactly what it sounds like. Each persona loads on demand into its own context, does its job, and releases. None of them persists when not invoked. The coordinator and the critic are the only ones kept warm, because coordination and challenge are needed across every task.

Here is what a single task looks like flowing through that cast. Suppose I want to ship a technical article. The coordinator reads the brief, decides which specialists are needed, and loads them in sequence — never all at once, because loading every persona at once would flood the context and dilute each one. The content specialist drafts from its own file, which carries my voice, my structural defaults, and the mistakes I have already corrected in past articles. When the draft lands, the designated critic loads — its entire purpose is to find the weak claim, the unstated assumption, the number without a source — and returns a list of holes, not a rewrite. If the piece touches claims about tools or performance, the data or security specialist loads to verify, each pulling from its own accumulated checklist. No specialist sees another's working context. Each one's judgment is shaped only by its own file and the artifact in front of it.

That isolation is the point. A critic that has also been doing the writing has every incentive to go soft on its own work. A reviewer that shares context with the writer absorbs the writer's assumptions. Separate files, loaded separately, produce separate priors — and separate priors are what catch the errors a single mind misses. I saw this clearly on a draft that claimed a tool supported a feature it did not. The content specialist, writing from its own file, had every reason to trust the claim — it fit the narrative. The critic persona, loaded fresh with no investment in the draft, flagged it in seconds: no source, no link, no proof. Same model, same project, opposite verdict — because the critic's file told it to hunt for unsupported claims, and that instruction was the only thing in the room. A single agent wearing both hats would have let the claim through.

The experience layer is where the compounding shows up. Consider how a single persona matures. The security reviewer started life as five lines: check inputs, check secrets, check auth, check dependencies, flag by severity. After its first real engagement it gained a line about tracing untrusted data all the way to its sink — because I had watched it miss an injection that lived two function calls deep. After the third engagement it gained a hard constraint: never approve a pull request that adds a dependency without a license file, because that one had bitten me in production. Each addition came from a concrete failure I could name. That file has grown from those original five lines into a few dozen, each tied to a specific class of issue actually seen in review — injection paths, leaked secrets, missing input validation, license gaps, and a handful of one-off traps. A fresh prompt cannot compete with a persona that has been wrong, corrected itself, and remembered the correction.

The whole tree syncs across machines in near real time, so the same nineteen personas are available whether I am at my desk or remote from a laptop. And nothing in the system depends on a single vendor. If I moved the entire operation tomorrow, the files travel with me — rename the entry points, repoint the paths, and every persona with every accumulated lesson is intact on the other side. The personas are the asset. The model is a reader. That separation is precisely why the system has never broken on a tool update: there is nothing in it that an update can reach.

More precisely: even this system does not escape the limits in the next section. The personas are advisory context, not enforced law. When a rule truly must never be violated, I pair the file with a hook that blocks the action mechanically. The file carries the judgment; the hook carries the guarantee.

I am not claiming this is the only way to build an agent system. I am claiming that after months of running it, the four properties above are not marketing — they are the daily experience.

Build Your Own Persona

You do not need a nineteen-persona operation to benefit. The minimum viable version is one file, loaded, written as a role. Here is how to start.

Step 1 — Write one persona file. Pick the single most repetitive kind of work you do with your agent — code review, release notes, debugging, content editing — and write a persona for it using the five-element shape. Be specific about stance, not just tasks.

---
name: security-reviewer
description: Reviews code for security vulnerabilities before merge
tools: Read, Grep, Glob
model: sonnet
memory: project
---

# Role: Security Reviewer

## Identity
You are a senior application security engineer. You think like an attacker —
your job is to find the vulnerability before someone else does.

## Expertise
OWASP Top 10, dependency confusion, secret leakage, auth/session flaws.
Boundary: you review, you do not rewrite code yourself.

## Process
1. Map every input boundary and trust transition first.
2. Trace untrusted data to its sink before reading the "happy path."
3. Flag by severity; never silently "fix" by rewriting.

## Output
A findings table: severity, location, why it's exploitable, minimal fix.

## Constraints
Never approve a PR that adds a secret to source. Never skip the input-trace.
When uncertain about exploitability, say so — do not inflate severity.

Use this as a subagent definition (.claude/agents/security-reviewer.md) or, if you only use one tool, fold it into the top of your CLAUDE.md. The point is the shape: identity, expertise, process, output, constraints — in that order, with constraints doing most of the work. And the shape migrates to any role. Here is a release-notes persona in eight lines:

---
name: release-notes
description: Drafts release notes from a git diff
tools: Git, Read
model: sonnet
memory: project
---

# Role: Release Notes Writer
## Identity
You write for a user who upgrades without reading docs. Every line must matter to them.
## Process
1. Group changes by what the user feels, not by what the code did.
2. Lead with the change that affects the most people.
3. Turn every "refactor" into the user-visible consequence, or drop it.
## Constraints
Never list internal cleanup as a feature. Never ship a note you cannot finish with "so you can…".

Notice how the Constraints do the heavy lifting — "never list internal cleanup as a feature" is worth more than ten lines of praise for clean code. A persona is mostly defined by what it refuses.

Step 2 — Keep it short, then prune it. A widely recommended ceiling is under 200 lines for any single file, and treat roughly 30 working rules as a healthy target. The /doctor command in recent Claude Code versions will even suggest trimming content the model could derive from the codebase itself. Cut anything the agent can discover on its own; keep the traps, the rationale, and the places where your convention differs from the default.

Step 3 — Know when a persona is not enough. A persona handles the great majority of single-project work. It starts to strain in specific, nameable situations, and that is where other tools earn their place — not as a replacement, but as a targeted escalation:

The single most useful diagnostic question in this entire space is this: is the problem that the agent does not know the rule, or that it does not follow the rule? If it does not know, the file is the answer — write the rule, make it specific, load it. If it knows but skips it anyway, no amount of persona will help; you need a hook that blocks the action mechanically. Roles and enforcement are different problems with different solutions, and confusing them is the most common mistake people make here.

The honest version of this method is not "files only." It is "files as the base layer underneath everything else." The persona file is the source of truth for who the agent is and how it works. When you need fancier retrieval or harder enforcement, you layer it on top — but the file stays the foundation.

Where Personas Break: Honest Limits

A method you cannot stress-test is a belief, not a tool. Here is where file-based personas stop working, stated plainly.

A persona is advice, not enforcement. Anthropic is explicit that CLAUDE.md is context, not enforced configuration. The agent can ignore it, and sometimes does — especially when the file is long, vague, or contradictory. The reliable way to block an action is a PreToolUse hook, which intercepts the tool call mechanically. If a constraint is truly non-negotiable, do not trust the persona to enforce it — pair the persona with a hook. The persona carries the judgment; the hook carries the guarantee.

Persona files are loaded, not searched semantically. When the agent needs a rule, it relies on the file being in context, not on retrieving the right line by meaning. If your persona file grows large and full of synonyms, the agent can miss a rule that is technically present. A persona is not a search engine. Keep it focused enough that everything in it is relevant to the work it does. When you genuinely need semantic search across a large body of knowledge, that is a different layer — not a reason to bloat the persona.

Context is finite, and personas cost tokens. Every persona you load consumes part of the context window. Load too many at once, or write them too long, and the model's attention dilutes across all of them — quality falls uniformly, not just on the newest content. The instruction ceiling of roughly 150 to 200 reliable instructions means a persona is a budget, not a bucket. Spend it on the rules that matter most.

Personas do not replace coordination logic. A persona tells an agent how to be a specialist. It does not, by itself, decide which specialist to invoke when, or how to merge their outputs. That orchestration still lives in your top-level instructions or your tool's dispatch system. A nineteen-persona system works because there is a coordinator persona routing work to the right specialist — without that layer, you have nineteen specialists and no one deciding who speaks.

None of this kills the method. It bounds it. The file-based persona remains the right base layer for the foreseeable middle: zero infrastructure, human-readable, git-native, no lock-in. Bet on the file as the foundation for who your agent is. Add floors — hooks for enforcement, retrieval for scale, orchestration for coordination — when you need them.

Frequently Asked Questions

What is an agent persona? A defined role you load into an AI agent so it works as a specialist rather than a generalist. It specifies who the agent is, what it knows, how it works, what it produces, and what it refuses. The most durable way to define one is a markdown file the agent loads at the start of every session.

How do I create an agent persona? Write one markdown file with five sections: Role, Expertise, Process, Output, and Constraints. Save it where your tool loads context automatically — .claude/agents/ for Claude Code, or an AGENTS.md file. Be specific about stance, not just tasks.

Is an agent persona just a prompt? No. A prompt is something you paste every time. A persona file is something the agent loads automatically and that persists across sessions, machines, and tools. A file is editable as data, version-controllable, and portable. A persona file is a prompt that grew up into infrastructure.

Will my persona break when Claude Code or Codex updates? Far less than a code-based persona. Models and APIs change every few months, but every major coding agent reads text config files. AGENTS.md alone is supported by 23-plus tools. The file outlives the framework.

How many personas can I run at once? Each subagent runs in its own context window, so personas are isolated by design and you can maintain many. The practical limit is how many you can keep curated. A focused persona beats a bloated one, since frontier models reliably follow roughly 150–200 instructions at once.

Does this work across Claude Code, Cursor, and Codex? Yes — that is the core advantage. Claude Code reads CLAUDE.md, Cursor reads .cursorrules, Codex reads AGENTS.md, Gemini CLI reads GEMINI.md. They are all text files doing the same job, and AGENTS.md consolidates them into one Linux Foundation-backed standard.

How is loading a persona different from giving the agent memory? Memory stores what happened in the past. A persona defines who the agent is and how it should work right now. Memory is retrospective; a persona is a working role. You can run a sharp persona with no memory at all, because the persona is a loaded role, not a record of past events.

How long should a persona file be? A structured persona runs about 300–600 tokens — under one percent of a 200K window. A widely recommended ceiling is under 200 lines. The shorter and more specific the file, the more reliably the agent follows it.

The Takeaway

People keep asking how to make their agent remember more. The better question is why your agent still has no role. The most durable thing you can give an AI agent is not a bigger memory — it is a defined persona, written in a file, loaded every session, portable across every tool, and immune to the framework updates that break everything else. Once you stop treating your agent as a blank slate to be re-explained every morning and start treating it as a role to be loaded, the daily friction disappears. The agent shows up already knowing the project, already biased toward the right call, already clear on the line it will not cross.

The model is the fastest-changing layer of your stack. Your persona — who the agent is, who it serves, where it stops — is the slowest. Write the slow thing into a file. Bet on the layer that moves slowest: the text file every tool reads, not any one tool's specific format. Watch AGENTS.md consolidate the field underneath you and adopt it when it fits. Everything else is a plugin you will eventually replace. The role is the one part of your agent stack you actually get to keep — so write it where it cannot be taken away.

Related Tutorials

• Claude Code Subagents Guide — the official mechanism for loading personas as isolated roles
• CLAUDE.md Best Practices — how to write the files themselves, with reverse-engineered examples and templates
• Codex AGENTS.md Guide — the cross-tool persona standard from the Codex side

References

• How Claude remembers your project — Claude Code Docs
• Create custom subagents — Claude Code Docs
• Effective context engineering for AI agents — Anthropic Engineering
• Writing a Good CLAUDE.md — HumanLayer
• AGENTS.md — open standard, Linux Foundation Agentic AI Foundation
• CoALA: Cognitive Architectures for Language Agents — Sumers et al., arXiv
• Designing Data-Intensive Applications — Martin Kleppmann (origin of "data outlives code")
• Designing Agent Personas That Actually Work — Agentic Thinking