The Soul Stack

A construct does not exist in isolation. In practice, agents operate under layers of configuration — a persona that defines who they are, a skill that defines what they are doing right now, a decision framework that shapes how they reason, and a set of project-level rules that constrain all of it.

This is the soul stack: the composition of constructs that produces a specific agent behavior at a specific moment. Understanding how these layers interact is the difference between an agent that works and one that fights itself.

The Layers

When you use Claude Code with a CLAUDE.md in your project, a SOUL.md defining the agent's personality, and a SKILL.md that activates when you invoke a slash command, three layers of instruction merge into a single behavioral output. The agent does not experience these as separate documents. It experiences them as a unified set of beliefs about who it is and what it should do.

The layers, from deepest to most immediate:

Each layer operates at a different timescale. Identity persists for months or years. Project context persists for the duration of the project. Skills activate for a task. The moment lasts for a message. The soul stack is what happens when all four are active simultaneously.

How Layers Compose

When layers agree, the result is seamless. A soul that values thoroughness, a project that requires careful testing, a skill that defines QA workflows, and a user who just asked to test the login flow — all four layers point in the same direction. The agent performs beautifully.

The interesting cases are when they disagree.

Consider an agent with a soul that says “be concise, respect the user's time” and a skill that says “produce a comprehensive 80-item design audit with letter grades for every category.” The soul wants brevity. The skill demands exhaustiveness. What does the agent do?

In practice, the more specific instruction wins. This is the principle of specificity precedence: when two constructs conflict, the one that is more specific to the current context takes priority. The soul sets the default. The skill overrides the default for the duration of the task. When the skill completes, the soul reasserts.

This mirrors how humans operate. A naturally quiet person can give a loud presentation. A naturally cautious surgeon can act decisively in an emergency. The base personality persists, but the situational role takes over when activated. The role does not erase the personality — it modulates it.

When Layers Conflict

Real conflicts happen when constructs were written by different people with different assumptions. A team lead writes a CLAUDE.md that says “always add JSDoc comments to exported functions.” A developer activates a Refactorer skill that says “delete unnecessary comments.” The project construct and the skill construct are in direct tension.

There is no universal resolution for this. But there are patterns:

Safety wins. If a higher layer establishes a safety boundary — “never force-push to main,” “never delete production data” — no lower layer should override it. Safety constraints are non-negotiable regardless of skill activation.

Specificity wins for behavior. A skill that says “in this code review, flag all functions longer than 20 lines” overrides a soul that says “focus on architecture, not line-level details.” The skill knows more about what the user wants right now.

Identity wins for tone. A skill should not change how the agent communicates at a fundamental level. If the soul says “be direct, skip pleasantries,” a QA skill should not produce flowery prose about how wonderful the code is before listing the bugs. The skill changes what the agent does, not who the agent sounds like.

The Garry Tan Pattern

Garry Tan's gstack is the best public example of a well-designed soul stack. He built twelve constructs that share a common soul — a set of “Prime Directives” including zero silent failures, mandatory diagrams, and observability as scope — while each skill defines a radically different persona and workflow.

The CEO Reviewer and the QA Engineer share the same values but operate completely differently. The CEO Reviewer challenges the scope of the problem. The QA Engineer tests the implementation systematically. The shared directives create coherence. The different skills create specialization. This is what a healthy soul stack looks like: consistent values, diverse capabilities.

The alternative — twelve constructs with no shared foundation — produces an agent that feels like a different person every time you switch tasks. That is not composability. That is chaos.

Designing for the Stack

If you are writing constructs, think about which layer you are operating at:

If you are writing a soul, keep it timeless. Values, communication style, decision-making principles. Nothing project-specific. Nothing that expires. A good soul could be loaded into a different model on a different harness in three years and still make sense.

If you are writing a project construct, keep it factual. Architecture decisions, naming conventions, tooling choices, access patterns. Things that a new team member needs to know. Things that change when the project changes.

If you are writing a skill, keep it operational. Inputs, steps, outputs, edge cases. A skill should be self-contained enough that it makes sense without the soul, even though it performs best with one.

The soul stack is not something you design all at once. It emerges as you add constructs over time. The art is in maintaining coherence as the stack grows — ensuring that each new layer reinforces rather than contradicts the ones beneath it.

This is, ultimately, the same challenge that organizations face with culture. Values at the top, practices in the middle, tools at the bottom. When they align, the organization feels effortless. When they conflict, everything grinds. The soul stack is organizational design for AI agents.

Related: Agents, Constructs, and the Words Between explores the terminology in depth. The Constructs That Run a Company shows soul stacks in practice at every company stage.