These reference guides lead you through the best resources we have found for learning the concepts behind language models and agents.
They are available to every current and past Accelerator student—and everyone who comes through the course next. We will keep adding and refining guides to share important material that we do not get the chance to cover in class.
Reference guides
Guide 01What Is a Language Model?A technical tour of training, inference, tokens, model types, cost, and speed.Open guide → I'm a student in the Fractal Accelerator. Here's one of the course's reference guides, "What Is a Language Model?":
https://www.fractalaccelerator.com/library/what-is-a-language-model
Fetch the guide and read the resources it links to — actually read them, don't just skim the guide's own descriptions.
Then look at what you already know about me: my projects, my files, my goals, what I've been building and struggling with. If you don't know much about me yet, say so and ask me what I'm working on before you go further.
Then give me a short, honest briefing:
1. **What this is and why people love it.** What these resources actually say, and why this material has earned its reputation — what people who've internalized it say it changed for them.
2. **Why I specifically might care.** Connect the ideas to my actual projects and problems — name the project, name the file, name the frustration. Not "this could apply to anyone building X" but "you hit exactly this last week when Y."
3. **Where I'd benefit right away.** The one or two places in my existing work where an idea from this guide would make something I'm already doing easier, safer, or better — this week, not someday.
4. **Which resource to read first**, given everything above, and what to look for when I do.
One hard rule: do not force it. If a resource doesn't genuinely connect to my work, say so plainly — "this one isn't for you yet" is a useful answer. Never recommend adding tools, structure, or process to my projects that they don't need. The goal is for the reading to serve my projects, not for my projects to become demos for the reading. Guide 02Context and Its IngredientsUnderstand what an agent can see and how instructions, tools, skills, and conversation shape its work.Open guide → I'm a student in the Fractal Accelerator. Here's one of the course's reference guides, "Context and Its Ingredients":
https://www.fractalaccelerator.com/library/context-and-its-ingredients
Fetch the guide and read the resources it links to — actually read them, don't just skim the guide's own descriptions.
Then look at what you already know about me: my projects, my files, my goals, what I've been building and struggling with. If you don't know much about me yet, say so and ask me what I'm working on before you go further.
Then give me a short, honest briefing:
1. **What this is and why people love it.** What these resources actually say, and why this material has earned its reputation — what people who've internalized it say it changed for them.
2. **Why I specifically might care.** Connect the ideas to my actual projects and problems — name the project, name the file, name the frustration. Not "this could apply to anyone building X" but "you hit exactly this last week when Y."
3. **Where I'd benefit right away.** The one or two places in my existing work where an idea from this guide would make something I'm already doing easier, safer, or better — this week, not someday.
4. **Which resource to read first**, given everything above, and what to look for when I do.
One hard rule: do not force it. If a resource doesn't genuinely connect to my work, say so plainly — "this one isn't for you yet" is a useful answer. Never recommend adding tools, structure, or process to my projects that they don't need. The goal is for the reading to serve my projects, not for my projects to become demos for the reading. Guide 03CompoundingUse what happens in one round of work with an agent to improve future rounds.Open guide → I'm a student in the Fractal Accelerator. Here's one of the course's reference guides, "Compounding":
https://www.fractalaccelerator.com/library/compounding
Fetch the guide and read the resources it links to — actually read them, don't just skim the guide's own descriptions.
Then look at what you already know about me: my projects, my files, my goals, what I've been building and struggling with. If you don't know much about me yet, say so and ask me what I'm working on before you go further.
Then give me a short, honest briefing:
1. **What this is and why people love it.** What these resources actually say, and why this material has earned its reputation — what people who've internalized it say it changed for them.
2. **Why I specifically might care.** Connect the ideas to my actual projects and problems — name the project, name the file, name the frustration. Not "this could apply to anyone building X" but "you hit exactly this last week when Y."
3. **Where I'd benefit right away.** The one or two places in my existing work where an idea from this guide would make something I'm already doing easier, safer, or better — this week, not someday.
4. **Which resource to read first**, given everything above, and what to look for when I do.
One hard rule: do not force it. If a resource doesn't genuinely connect to my work, say so plainly — "this one isn't for you yet" is a useful answer. Never recommend adding tools, structure, or process to my projects that they don't need. The goal is for the reading to serve my projects, not for my projects to become demos for the reading. Guide 04Following the FrontierBuild a trustworthy information diet, evaluate new claims, and turn the rare useful signal into action.Open guide → I'm a student in the Fractal Accelerator. Here's one of the course's reference guides, "Following the Frontier":
https://www.fractalaccelerator.com/library/following-the-frontier
Fetch the guide and read the resources it links to — actually read them, don't just skim the guide's own descriptions.
Then look at what you already know about me: my projects, my files, my goals, what I've been building and struggling with. If you don't know much about me yet, say so and ask me what I'm working on before you go further.
Then give me a short, honest briefing:
1. **What this is and why people love it.** What these resources actually say, and why this material has earned its reputation — what people who've internalized it say it changed for them.
2. **Why I specifically might care.** Connect the ideas to my actual projects and problems — name the project, name the file, name the frustration. Not "this could apply to anyone building X" but "you hit exactly this last week when Y."
3. **Where I'd benefit right away.** The one or two places in my existing work where an idea from this guide would make something I'm already doing easier, safer, or better — this week, not someday.
4. **Which resource to read first**, given everything above, and what to look for when I do.
One hard rule: do not force it. If a resource doesn't genuinely connect to my work, say so plainly — "this one isn't for you yet" is a useful answer. Never recommend adding tools, structure, or process to my projects that they don't need. The goal is for the reading to serve my projects, not for my projects to become demos for the reading. Guide 05Meta-ResearchFind the best methods, fit them to your goal, and turn unfamiliar work into a practiced capability.Open guide → I'm a student in the Fractal Accelerator. Here's one of the course's reference guides, "Meta-Research":
https://www.fractalaccelerator.com/library/meta-research
Fetch the guide and read the resources it links to — actually read them, don't just skim the guide's own descriptions.
Then look at what you already know about me: my projects, my files, my goals, what I've been building and struggling with. If you don't know much about me yet, say so and ask me what I'm working on before you go further.
Then give me a short, honest briefing:
1. **What this is and why people love it.** What these resources actually say, and why this material has earned its reputation — what people who've internalized it say it changed for them.
2. **Why I specifically might care.** Connect the ideas to my actual projects and problems — name the project, name the file, name the frustration. Not "this could apply to anyone building X" but "you hit exactly this last week when Y."
3. **Where I'd benefit right away.** The one or two places in my existing work where an idea from this guide would make something I'm already doing easier, safer, or better — this week, not someday.
4. **Which resource to read first**, given everything above, and what to look for when I do.
One hard rule: do not force it. If a resource doesn't genuinely connect to my work, say so plainly — "this one isn't for you yet" is a useful answer. Never recommend adding tools, structure, or process to my projects that they don't need. The goal is for the reading to serve my projects, not for my projects to become demos for the reading. Guide 06Dynamic Workflows and Goal LoopsUse Codex and Claude Code to manage parallel, long-running agent work without losing visibility or control.Open guide → I'm a student in the Fractal Accelerator. Here's one of the course's reference guides, "Dynamic Workflows and Goal Loops":
https://www.fractalaccelerator.com/library/dynamic-workflows
Fetch the guide and read the resources it links to — actually read them, don't just skim the guide's own descriptions.
Then look at what you already know about me: my projects, my files, my goals, what I've been building and struggling with. If you don't know much about me yet, say so and ask me what I'm working on before you go further.
Then give me a short, honest briefing:
1. **What this is and why people love it.** What these resources actually say, and why this material has earned its reputation — what people who've internalized it say it changed for them.
2. **Why I specifically might care.** Connect the ideas to my actual projects and problems — name the project, name the file, name the frustration. Not "this could apply to anyone building X" but "you hit exactly this last week when Y."
3. **Where I'd benefit right away.** The one or two places in my existing work where an idea from this guide would make something I'm already doing easier, safer, or better — this week, not someday.
4. **Which resource to read first**, given everything above, and what to look for when I do.
One hard rule: do not force it. If a resource doesn't genuinely connect to my work, say so plainly — "this one isn't for you yet" is a useful answer. Never recommend adding tools, structure, or process to my projects that they don't need. The goal is for the reading to serve my projects, not for my projects to become demos for the reading. Guide 07Security Best PracticesSee how AI labs protect users, then learn how to limit access, permissions, and the cost of mistakes.Open guide → I'm a student in the Fractal Accelerator. Here's one of the course's reference guides, "Security Best Practices":
https://www.fractalaccelerator.com/library/security-best-practices
Fetch the guide and read the resources it links to — actually read them, don't just skim the guide's own descriptions.
Then look at what you already know about me: my projects, my files, my goals, what I've been building and struggling with. If you don't know much about me yet, say so and ask me what I'm working on before you go further.
Then give me a short, honest briefing:
1. **What this is and why people love it.** What these resources actually say, and why this material has earned its reputation — what people who've internalized it say it changed for them.
2. **Why I specifically might care.** Connect the ideas to my actual projects and problems — name the project, name the file, name the frustration. Not "this could apply to anyone building X" but "you hit exactly this last week when Y."
3. **Where I'd benefit right away.** The one or two places in my existing work where an idea from this guide would make something I'm already doing easier, safer, or better — this week, not someday.
4. **Which resource to read first**, given everything above, and what to look for when I do.
One hard rule: do not force it. If a resource doesn't genuinely connect to my work, say so plainly — "this one isn't for you yet" is a useful answer. Never recommend adding tools, structure, or process to my projects that they don't need. The goal is for the reading to serve my projects, not for my projects to become demos for the reading. Guide 08SkillsLearn how reusable instructions extend agents, then explore skills for research, writing, design, and everyday work.Open guide → I'm a student in the Fractal Accelerator. Here's one of the course's reference guides, "Skills":
https://www.fractalaccelerator.com/library/skills
Fetch the guide and read the resources it links to — actually read them, don't just skim the guide's own descriptions.
Then look at what you already know about me: my projects, my files, my goals, what I've been building and struggling with. If you don't know much about me yet, say so and ask me what I'm working on before you go further.
Then give me a short, honest briefing:
1. **What this is and why people love it.** What these resources actually say, and why this material has earned its reputation — what people who've internalized it say it changed for them.
2. **Why I specifically might care.** Connect the ideas to my actual projects and problems — name the project, name the file, name the frustration. Not "this could apply to anyone building X" but "you hit exactly this last week when Y."
3. **Where I'd benefit right away.** The one or two places in my existing work where an idea from this guide would make something I'm already doing easier, safer, or better — this week, not someday.
4. **Which resource to read first**, given everything above, and what to look for when I do.
One hard rule: do not force it. If a resource doesn't genuinely connect to my work, say so plainly — "this one isn't for you yet" is a useful answer. Never recommend adding tools, structure, or process to my projects that they don't need. The goal is for the reading to serve my projects, not for my projects to become demos for the reading. Guide 09Career 101In-progress resources on doing great work, breaking into tech, freelancing, and where to apply to startups.Open guide → I'm a student in the Fractal Accelerator. Here's one of the course's reference guides, "Career 101":
https://www.fractalaccelerator.com/library/career-101
Fetch the guide and read the resources it links to — actually read them, don't just skim the guide's own descriptions.
Then look at what you already know about me: my projects, my files, my goals, what I've been building and struggling with. If you don't know much about me yet, say so and ask me what I'm working on before you go further.
Then give me a short, honest briefing:
1. **What this is and why people love it.** What these resources actually say, and why this material has earned its reputation — what people who've internalized it say it changed for them.
2. **Why I specifically might care.** Connect the ideas to my actual projects and problems — name the project, name the file, name the frustration. Not "this could apply to anyone building X" but "you hit exactly this last week when Y."
3. **Where I'd benefit right away.** The one or two places in my existing work where an idea from this guide would make something I'm already doing easier, safer, or better — this week, not someday.
4. **Which resource to read first**, given everything above, and what to look for when I do.
One hard rule: do not force it. If a resource doesn't genuinely connect to my work, say so plainly — "this one isn't for you yet" is a useful answer. Never recommend adding tools, structure, or process to my projects that they don't need. The goal is for the reading to serve my projects, not for my projects to become demos for the reading. Guide 10High-Quality Software Engineering With AgentsMove beyond quick prototypes with planning, testing, review, feedback loops, and reusable engineering practices.Open guide → I'm a student in the Fractal Accelerator. Here's one of the course's reference guides, "High-Quality Software Engineering With Agents":
https://www.fractalaccelerator.com/library/high-quality-software-engineering-with-agents
Fetch the guide and read the resources it links to — actually read them, don't just skim the guide's own descriptions.
Then look at what you already know about me: my projects, my files, my goals, what I've been building and struggling with. If you don't know much about me yet, say so and ask me what I'm working on before you go further.
Then give me a short, honest briefing:
1. **What this is and why people love it.** What these resources actually say, and why this material has earned its reputation — what people who've internalized it say it changed for them.
2. **Why I specifically might care.** Connect the ideas to my actual projects and problems — name the project, name the file, name the frustration. Not "this could apply to anyone building X" but "you hit exactly this last week when Y."
3. **Where I'd benefit right away.** The one or two places in my existing work where an idea from this guide would make something I'm already doing easier, safer, or better — this week, not someday.
4. **Which resource to read first**, given everything above, and what to look for when I do.
One hard rule: do not force it. If a resource doesn't genuinely connect to my work, say so plainly — "this one isn't for you yet" is a useful answer. Never recommend adding tools, structure, or process to my projects that they don't need. The goal is for the reading to serve my projects, not for my projects to become demos for the reading.
AI-generated guides
These guides were auto-generated by Claude Code from our internal class notes and research, and have not yet been reviewed by an instructor. They are shared early because they are useful now — read them with that in mind.
Guide 11Not Reviewed YetYour Personal OSBuild the personal monorepo that gives every agent durable context: what goes in it, AGENTS.md, and syncing across devices.Open guide → I'm a student in the Fractal Accelerator. Here's one of the course's reference guides, "Your Personal OS":
https://www.fractalaccelerator.com/library/personal-os
Fetch the guide and read the resources it links to — actually read them, don't just skim the guide's own descriptions.
Then look at what you already know about me: my projects, my files, my goals, what I've been building and struggling with. If you don't know much about me yet, say so and ask me what I'm working on before you go further.
Then give me a short, honest briefing:
1. **What this is and why people love it.** What these resources actually say, and why this material has earned its reputation — what people who've internalized it say it changed for them.
2. **Why I specifically might care.** Connect the ideas to my actual projects and problems — name the project, name the file, name the frustration. Not "this could apply to anyone building X" but "you hit exactly this last week when Y."
3. **Where I'd benefit right away.** The one or two places in my existing work where an idea from this guide would make something I'm already doing easier, safer, or better — this week, not someday.
4. **Which resource to read first**, given everything above, and what to look for when I do.
One hard rule: do not force it. If a resource doesn't genuinely connect to my work, say so plainly — "this one isn't for you yet" is a useful answer. Never recommend adding tools, structure, or process to my projects that they don't need. The goal is for the reading to serve my projects, not for my projects to become demos for the reading. Guide 12Not Reviewed YetGit & GitHubThe version-control layer under your Personal OS: repos, commits, the daily sync loop, the gh CLI, and .gitignore.Open guide → I'm a student in the Fractal Accelerator. Here's one of the course's reference guides, "Git & GitHub":
https://www.fractalaccelerator.com/library/git-and-github
Fetch the guide and read the resources it links to — actually read them, don't just skim the guide's own descriptions.
Then look at what you already know about me: my projects, my files, my goals, what I've been building and struggling with. If you don't know much about me yet, say so and ask me what I'm working on before you go further.
Then give me a short, honest briefing:
1. **What this is and why people love it.** What these resources actually say, and why this material has earned its reputation — what people who've internalized it say it changed for them.
2. **Why I specifically might care.** Connect the ideas to my actual projects and problems — name the project, name the file, name the frustration. Not "this could apply to anyone building X" but "you hit exactly this last week when Y."
3. **Where I'd benefit right away.** The one or two places in my existing work where an idea from this guide would make something I'm already doing easier, safer, or better — this week, not someday.
4. **Which resource to read first**, given everything above, and what to look for when I do.
One hard rule: do not force it. If a resource doesn't genuinely connect to my work, say so plainly — "this one isn't for you yet" is a useful answer. Never recommend adding tools, structure, or process to my projects that they don't need. The goal is for the reading to serve my projects, not for my projects to become demos for the reading. Guide 13Not Reviewed YetThe Terminal (and cmux)Terminal survival kit, installing cmux, and running parallel agents inside your Personal OS — then SSH to your cloud computer.Open guide → I'm a student in the Fractal Accelerator. Here's one of the course's reference guides, "The Terminal (and cmux)":
https://www.fractalaccelerator.com/library/terminal-and-cmux
Fetch the guide and read the resources it links to — actually read them, don't just skim the guide's own descriptions.
Then look at what you already know about me: my projects, my files, my goals, what I've been building and struggling with. If you don't know much about me yet, say so and ask me what I'm working on before you go further.
Then give me a short, honest briefing:
1. **What this is and why people love it.** What these resources actually say, and why this material has earned its reputation — what people who've internalized it say it changed for them.
2. **Why I specifically might care.** Connect the ideas to my actual projects and problems — name the project, name the file, name the frustration. Not "this could apply to anyone building X" but "you hit exactly this last week when Y."
3. **Where I'd benefit right away.** The one or two places in my existing work where an idea from this guide would make something I'm already doing easier, safer, or better — this week, not someday.
4. **Which resource to read first**, given everything above, and what to look for when I do.
One hard rule: do not force it. If a resource doesn't genuinely connect to my work, say so plainly — "this one isn't for you yet" is a useful answer. Never recommend adding tools, structure, or process to my projects that they don't need. The goal is for the reading to serve my projects, not for my projects to become demos for the reading. Guide 14Not Reviewed YetZo ComputerYour personal cloud computer: powering it with your Codex or Claude subscription, hosting, automations, and syncing your Personal OS.Open guide → I'm a student in the Fractal Accelerator. Here's one of the course's reference guides, "Zo Computer":
https://www.fractalaccelerator.com/library/zo-computer
Fetch the guide and read the resources it links to — actually read them, don't just skim the guide's own descriptions.
Then look at what you already know about me: my projects, my files, my goals, what I've been building and struggling with. If you don't know much about me yet, say so and ask me what I'm working on before you go further.
Then give me a short, honest briefing:
1. **What this is and why people love it.** What these resources actually say, and why this material has earned its reputation — what people who've internalized it say it changed for them.
2. **Why I specifically might care.** Connect the ideas to my actual projects and problems — name the project, name the file, name the frustration. Not "this could apply to anyone building X" but "you hit exactly this last week when Y."
3. **Where I'd benefit right away.** The one or two places in my existing work where an idea from this guide would make something I'm already doing easier, safer, or better — this week, not someday.
4. **Which resource to read first**, given everything above, and what to look for when I do.
One hard rule: do not force it. If a resource doesn't genuinely connect to my work, say so plainly — "this one isn't for you yet" is a useful answer. Never recommend adding tools, structure, or process to my projects that they don't need. The goal is for the reading to serve my projects, not for my projects to become demos for the reading.