What you'll take away from this: You'll learn about the four core files I use to clearly distinguish an agent's identity, mode of operation, boundaries, and memory from one another.
Table of contents
„At first glance, “SOUL” sounds like a bigger concept than it actually is. In my Agent’s Brain, the word refers to a short persona file. Next to it are MASTER, RULES, and MEMORY.
Four files are not enough to cover every conceivable capability. However, they are sufficient to describe an agent in such a way that another tool can load it, a human can review it, and the agent itself can maintain its knowledge.
The separation is the real issue. A single mega-prompt quickly mixes together tone, working rules, project details, safety boundaries, and past decisions. Then every correction becomes risky: If you change one sentence, you don’t know what other areas that might affect.
That's why I divide up the responsibility.
SOUL: Who This Agent Is
The SOUL file is the shortest of the four. It describes the role, attitude, and voice. It also contains the required reading order for the start of the session.
In Sol’s case, for example, it states that, as an author and press spokesperson, she embodies Saskia’s public voice: professionally precise, clear, human, and without hype. Equally important are her boundaries: she doesn’t make up numbers and doesn’t publish anything herself.
SOUL must be short enough to be read in its entirety every time it is opened. It is not an encyclopedia. Its purpose is to provide guidance.
A good short character profile answers three questions:
- What role does the agent play?
- How does he make linguistic and technical decisions?
- Which subdirectories does he need to load before starting work?
This makes SOUL a stable entry point, not a melting pot.
MASTER: How the Agent Works
The MASTER file is the complete operational specification. Feel free to go into detail here.
Depending on the role, it includes tonality, output formats, subject matter guidelines, source hierarchy, workflow, quality checks, and error handling. The rules for an author differ from those for a development agent. The structure remains similar, but the content is role-specific.
The advantage of this separation becomes clear when changes are made. If I refine the visual style for all future articles, I simply update the work instructions. There’s no need to rewrite the author’s core identity.
Conversely, a track can continue to evolve sonically without its technical delivery formats becoming blurred.
The MASTER file thus serves as both a manual and a contract: detailed enough for difficult cases, but separate from the brief “start persona.”.
RULES: What the Agent Can and May Do
RULES is the binding work agreement that outlines skills, limitations, and authorizations. The file specifies:
- Role and area of expertise,
- Skills,
- expected inputs,
- typical outputs,
- Dependencies,
- Memory Scope,
- prohibited actions,
- Approval Gates.
The last two points, in particular, are often addressed too late in agent setups. The fact that an agent has a certain capability does not necessarily mean it is allowed to perform that action on its own.
For example, Sol can prepare WordPress drafts. She is not allowed to publish them. This restriction isn't just a friendly reminder at the end of a prompt—it's part of her RULES file.
This allows an orchestrator to verify, before delegation, whether the role is appropriate for the task. And the next tool loads the same approval rules.
MEMORY: What Remains Relevant Over Time
The MEMORY file is not a transcript of all conversations. It contains a curated summary of daily logs and lessons.
It lists ongoing projects, established conventions, common pitfalls, and important stakeholder guidelines. Chronological details are kept in the daily logs. Recurring correction patterns are documented as separate lessons.
This separation protects the startup phase from being overloaded. An agent doesn't need to read through a hundred old sessions to work effectively today. It loads a compact long-term file and supplements it with current daily logs or relevant lessons as needed.
In this context, curation also involves deleting, condensing, and marking content as outdated. Memory is an editorial task, not a dumping ground.
Why Four Files Are Better Than One Long Prompt
The four files are not listed in any particular order. They address different questions:
| File | Key Question | Change Type |
|---|---|---|
| SOUL | Who am I? | rare, closely related to one's identity |
| MASTER | How do I work? | regular, operational |
| RULES | What can I do, and what am I allowed to do? | for skills and gates |
| MEMORY | What do I need to know for the long term? | ongoing, curated |
This division reduces coupling. A new skill modifies the RULES file. An editorial rule belongs in the MASTER file. A correction based on real-world experience becomes a Lesson and, later, if necessary, a Memory. The Persona does not need to be modified with every adjustment.
That doesn't automatically make an agent good. It makes him maintainable.
Sharing rules are part of one's identity
To me, approval gates aren't just a safety net at the end of the process. They define how an agent performs their role.
An author who only submits drafts works differently than an autonomous publishing agent. A development agent with write access to the repository requires different limits than an agent with production access. If these differences are configured only within the respective tool, they disappear when switching tools.
If, on the other hand, they are listed in RULES and MASTER, they travel with the role.
This is especially important when it comes to delegation. When Nox delegates a task to Sol or another harness, the delegation does not remove a gate. The task can be transferred to another body. The chain of responsibility remains intact.
A living example: Sol
Sol is a good workshop example because it uses exactly this file structure.
Your SOUL sets the brief identity and requires that all sources be loaded before each task. The MASTER file contains your writing rules, verifiability, delivery structures, and image guidelines. The RULES file describes capabilities and the “review-before-post” gate. The MEMORY file records ongoing editorial contexts and known pitfalls.
When Saskia corrects a title or a sourcing practice, the insight isn't just incorporated into the current text. Sol receives a lesson that will be reviewed again during the next relevant assignment.
That's how feedback shapes system behavior.
What this structure deliberately does not claim
Four files do not make a language model human. Nor do they guarantee perfect continuity. An agent may overlook sources, apply a rule incorrectly, or document a session incompletely.
The structure ensures that such errors are given a visible place: as a correction in the manual, as a stricter gate, or as a new lesson.
To me, that's the practical difference between „The prompt was good this time“ and „The system can learn from a correction in the long term.“.
The next section, therefore, is not about a fifth core file, but rather about the flow between the files: Working Memory, Daily Logs, Curated Long-Term Knowledge, and Lessons.
Sources
- Project source: agents-brain specification and Sol's canonical agent files, as of July 15, 2026 (private primary sources)
- CommonMark: Open Markdown Specification
0 Comments