Detailed content
🧱 The 6 layers — overview
Every AIOS, no matter how different the domain, is built from the same 6 layers. Thinking in layers is what takes the OS from a "bucket of loose prompts" and turns it into a system with named parts—each with a clear role that you build and audit separately.
🌱 New here?
A layer is just one type of thing that goes into your OS—a grouping. The "pie chart" is the author’s metaphor: imagine everything that makes up an OS as a whole pizza, with each layer as a slice. The module’s key insight is that the slices are different sizes and change by domain. Each term here (Identity, Substrate, Rules…) is defined in detail in Module 1.3 (the glossary) — here you just get the map.
How to read: the 6 slices add up to 100%, but none is the same as another. In this example (a tax OS), Context dominates because the domain revolves around laws and documents. In another domain, a different slice would be the largest. The green slices are the foundation; the blue ones, a action — you’ll see this division in Topic 5.
The 6 slices, one sentence each
Why learn
Because it’s the skeleton of the entire course. Tracks 2 and 3 are literally one layer per module; Track 4 has you build them in order. If you leave here with the map of all 6 layers in your head, everything else becomes “filling in the slices.”
Key concepts
🍕 Why the pizza is NOT divided equally
The author’s exact phrase is direct: "the pie chart isn't divided evenly". The 6 layers exist in every OS, but the weight each one depends on the domain. Giving them all the same effort is the fastest way to spend time in the wrong place.
✗ Equal slices (the mistake)
- ✗Give all 6 layers the same attention, "to be thorough."
- ✗Copy the distribution of a ready-made OS to another domain.
- ✗Polish agents while the context, which is the bottleneck, is empty.
✓ Custom pizza (the way)
- ✓Ask: Which layer matters most here?
- ✓Focus the effort on the part that carries the domain knowledge.
- ✓Keep small slices small—and that's okay.
💡 The two questions that guide the slice
Before building any OS, ask the course’s two guiding questions: "which layer matters most here?" e "what will rot faster?". The first tells you where to invest; the second, what will require maintenance. Together, they shape your pie better than any template.
Why learn
Because it protects your time. The difference between an OS that “turned out great over the weekend” and one that got stuck almost always comes down to investing in the right slice. Accepting that the pie is uneven lets you prioritize thoughtfully instead of trying to do everything equally.
Key concepts
🪜 The order that works
Slices can be any size, but the build order is almost always the same: you lay the foundation before adding capabilities. In one line: Identity → Substrate & Context → Rules & Hooks → Skills → Tools → Agents. It’s no coincidence that Tracks 2 and 3 of this course follow this exact sequence.
The sequence, step by step
Identity
Define what the OS is before anything else. Without a soul, the following layers have no one to serve.
Substrate & Context
Organize and distill domain knowledge. That’s what makes the OS a specialist instead of generic.
Rules & Hooks
Set the guardrails: what to always do, what to never do, and where to stop deterministically.
Skills
Capture the verbs you repeat most. Now there’s a solid foundation for packaging processes.
Tools & Connections
Decide which threads to send out—skill, CLI, MCP, or API—only when a skill needs to interact with the outside world.
Agents
Finally: roles with judgment that orchestrate skills. They only make sense when there are skills to orchestrate.
💡 The golden rule of order
Behind the scenes first, capabilities later. You don’t give someone arms (agents) when they don’t yet know who they are (identity) or what they know (context). The order exists to keep you from building the roof before the walls.
Why learn
Because the order prevents rework. People who start at the end (agents) end up redoing everything when they realize the foundation is missing. Following the sequence gives you a usable OS at every stopping point—and each layer builds on the previous one.
Key concepts
⚠️ Mistake #1: jumping to Agents too early
The author is categorical: agents are the last layer, not the first — e "most people jump to agents too soon". Agents are the exciting, brilliant part, so it's natural to want to start there. But an agent without a foundation is a smart worker who hasn't been told what the job is.
🌱 New here?
One agent is a “role with judgment”: instead of following one fixed step, it decides which skills (ready-made verbs) to use and in what order, usually with a review checkpoint before anything goes out. That’s why it depends on the layers below: without skills to orchestrate, rules to follow, and context to consult, the agent has nothing to work with. The glossary (Module 1.3) defines agent in more detail.
✗ The shortcut that goes wrong
- ✗Create an “agent that does everything” before you have any skills.
- ✗Relying on the judgment of an OS with no domain context.
- ✗Give autonomy without rules—the agent makes mistakes quickly and at scale.
✓ The path that holds up
- ✓Identity, context, and rules first—the stable foundation.
- ✓Then add 1 or 2 real skills for the tasks you repeat most.
- ✓Only then, an agent to orchestrate what already exists and works.
⚠️ The typical symptom
"I built an amazing agent and it gives generic answers / does stupid things." The problem is almost never the agent — it’s the lower layers that were left empty. The fix isn’t to tweak the agent: it’s to go back and fill in context and rules.
Why learn
Because this is, according to the author, the most common mistake of all. Knowing about it beforehand saves you from building the shiny toy first and having to take everything apart later. You gain the patience to do the “boring” part that makes the fun part work.
Key concepts
🏗️ Static vs. dynamic layers
The 6 layers fall into two groups. The first three are the (static) foundation — the “back of house,” the behind-the-scenes parts that change slowly. The last three are the action (dynamic) — the arms that execute. That’s exactly why this course has a Track 2 (foundation) and a Track 3 (capability).
How to read: the green column (foundation) is what you build first and rarely change; the blue column (action) is what executes and keeps evolving. The arrow reminds you of the rule: the foundation supports the action — without a solid left side, the right side doesn’t work.
Why learn
Because this division organizes your thinking and the course. When you know whether you’re working on the foundation (something that changes slowly) or the action (something that keeps evolving), you can calibrate how much effort and maintenance each part deserves.
Key concepts
🧭 How the distribution changes by domain
The best proof that the pie is uneven is to see real domains side by side. Each has a slice that carries more weight—and that completely changes where you invest your effort. This is a preview of the Track 5, where each domain becomes a complete module.
| Domain | Slice that dominates | Why |
|---|---|---|
| Tax OS 🧾 | Context (~34%) | Runs on laws, audits, and compendiums — plenty of material to distill. |
| Sales OS 📈 | Tools + Skills | ~30% context, but most of the weight goes to scrapers, enrichment, and qualification. |
| Content OS 🎬 | Balanced | Title, brief, and repurposing factory—more even slices. |
| Consulting OS 💼 | Rules & Hooks | Customer voice and review gates require rigorous quality control. |
| Freedom OS 🗽 | Local models | Sensitive data (certificates, passports) don't go to the cloud. |
💡 The pattern behind the numbers
Don't memorize the percentages — they're examples. What matters is the default: knowledge-heavy domains weigh more on Context; prospecting domains weigh more on Tools; domains exposed to risk weigh more on Rules. Finding the dominant slice of the your the domain is the work.
Why learn
Because it gives you a frame of reference. After seeing five different versions of the same pizza, you can recognize your own distribution faster—and enter Track 5 already knowing where each domain tends to concentrate weight.
Key concepts
🔀 "Order of operations": where to start
The order of Topic 3 (Identity first) is the default, not a rigid law. In practice, sometimes you need to organize the context before writing the identity — because only after reviewing the domain material can you clearly say what the OS is. This is “order of operations”: the sensible sequence, with conscious exceptions.
🌱 New here?
"Order of operations" is an expression borrowed from mathematics (the order in which you solve a calculation). Here, it means the order in which it makes sense to build the layers. The point is: there’s a good default order, but your domain may call for a small adjustment — and that’s fine, as long as it’s a considered choice, not a mess.
✓ Identity first when…
- ✓You already know the domain and audience well.
- ✓The OS is more about tone and rules than data.
- ✓You can describe the essence without consulting files.
↔ Context first when…
- •There’s a “dumpster fire” of files to organize.
- •Identity only becomes clear after seeing the material.
- •The domain is knowledge-dense (e.g., tax, legal).
💡 How the course solves this for you
In Track 4, the skill /os-coach decides the “order of operations” for you: it asks 2–3 questions and chooses whether to start with identity or context. You don’t need to get the order right from memory—you just need to know it exists and why it sometimes changes.
Why learn
Because it removes rigidity. Anyone who treats the order as law gets stuck when the domain doesn’t fit. Understanding that it’s a “default with conscious exceptions” lets you adapt without guilt—exactly the spirit of “more art than science” in Module 1.1.
Key concepts
✅ Module summary
Next module:
1.3 — Essential glossary: each term defined with a sentence + analogy 📖