Detailed content
🧑🍳 Skill = 1 verb; agent = the chef
The essential difference: a a skill is a verb — one task. At some point, several related skills deserve to become their own entity, equipped with judgment: the agent. It's not a single skill; it's a specialist that orchestrates several skills, in the right order, deciding which one to use.
🌱 New here?
One agent is a role — think of it as an “employee” in your OS, specializing in one part of the domain. Orchestrate means choosing and running skills in the right sequence, like a chef who decides which tool to pick up and tastes the dish before serving. The skill is the knife; the agent decides when to cut.
How to read: the big box (purple) is the agent; the three smaller ones (cyan) are skills — each one a verb. What the agent adds isn't another verb: it's the judgment which one to call, when, and with what review.
Why learn
Because confusing a skill with an agent is the mistake that inflates cost and fragility. If the task is a single verb, it’s a skill—creating an “agent” for it is overkill. An agent is justified only when there are multiple skills to coordinate with judgment. Keeping this boundary in mind prevents the anti-pattern that opens Track 1: jumping to agents too soon.
Key concepts
🚪 The Review Gate Before Anything Goes Out
What makes an agent trustworthy isn’t just what it does—it’s the review gate (review gate) before anything goes out into the world. Every agent that produces something that will go out (an email, a report, a launch) passes through a checkpoint: you or another agent checks it before it’s sent.
How to read: the agent's draft doesn't go out directly. It goes through review (the purple diamond). “Yes” moves on to the world; “no” (red) goes back to the agent for rework. This loop is what keeps nonsense from reaching the customer.
💡 Who reviews
The reviewer can be you (human in the loop, giving final approval) or another agent — the skeptical reviewer in topic 6. In serious domains (money, legal), the gate is mandatory; it’s what supports trust in the agent.
Why learn
Because an agent without a gate is an uncontrolled risk. With the review gate, you gain autonomy without losing control: the agent works, but nothing irreversible happens without a check. It’s the equivalent, in the agent layer, of the read-only hack in the tools layer—security by design.
Key concepts
🔼 Promote only a routine you already do by hand
The criteria for when to create an agent are straightforward: only promote a routine to an agent if you already does by hand today, with skills that already exist for it to orchestrate. It's the same “start manually” idea as the skills layer, one level up — an agent isn't where you start; it's where you end up.
✓ Ready to become an agent
- ✓You already do this routine by hand, repeatedly.
- ✓Skills already exist for the agent to orchestrate.
- ✓There is a clear review gate before sending.
✗ Theater agent
- ✗An agent for something you’ve never done by hand.
- ✗No skill underneath — just a promise.
- ✗It looks powerful, but it doesn't deliver anything reliable.
⚠️ Course mistake #1, again
Most people start with the agent layer—the last one they should touch. An agent is an “employee” that only makes sense to hire after you’ve built context, skills, and rules. Without that foundation, the agent has nothing to rely on.
Why learn
Because it’s the check on enthusiasm. Agents are the “cool” part, so the temptation to start with them is huge. Promoting only real routines, with ready-to-use skills underneath, ensures that each agent is a real worker—not a decoration that impresses and fails.
Key concepts
🔀 Agent vs workflow vs disposable sub-agents
Not every task deserves a permanent "employee." Before creating an agent, ask: do you really need an agent, or just a process that runs once in a while? A one-off audit of hundreds of files might be a dynamic workflow, not a fixed agent. And when you need more brute force, you scale up disposable sub-agents.
A permanent role you “hire.” It makes sense for recurring routines that require judgment—e.g., the response agent.
A one-off process, set up for a specific task—e.g., auditing hundreds of files once. No “employee” needed.
When you need much more firepower, spin up several throwaway agents for the workload, then discard them.
🔎 The scale of the choice
Think at scale: one large task → workflow. Recurring routine that requires judgment → fixed agent. Workload spike that requires parallelism → disposable sub-agents. Choosing the right form avoids creating a permanent "employee" for a job that happens once.
Why learn
Because “agent” isn’t the only answer—or always the best one. Treating everything as a fixed agent fills the OS with roles that rarely run. Distinguishing agents, workflows, and sub-agents helps you choose the right form for each workload, saving context and maintenance.
Key concepts
🗂️ Examples: response agent and deep research agent
In Freedom OS, the agents grew out of routines the author already handled by hand. They show the living layer: each agent is an "employee" with a clear job, and new ones keep appearing as the OS matures.
Why learn — how the agents emerged
Response agent
Has access to Gmail (via CLI). When the author says "scan my email," it looks at agency messages, gathers the 10 right documents, and drafts the replies — the author just reviews and sends (review gate).
Deep research agent
Constantly monitors changes in passport and residency laws. When a country changes its legislation (e.g., Turkey's new tax law), it flags that citizenship as worth revisiting.
A living OS
Every part is highly intentional, with review gates. The agents didn’t come about all at once: they were put to work one by one as routines took shape.
💡 The through line
Notice: the response agent uses a CLI (Gmail) and several skills (find a document, draft one). It was only possible because the layers below it—context, skills, tools—already existed. It’s all of Track 3 converging in one agent.
Why learn
Because real examples bring the agent out of the abstract. They show that an agent is a worker with a clear scope—not a “magic AI”—and that it relies on the skills and tools you’ve already built. It’s your model for designing the first agent in your OS.
Key concepts
🛡️ Review Gates: The Skeptical Reviewer
The gate from topic 2 gets a name when the reviewer is another agent: the skeptical reviewer (devil's advocate). It's an agent designed to "chew you out before the accountant"—or the client: it reviews the work with an adversarial eye before anything goes out.
✓ With a skeptical reviewer
- ✓Your OS "roasts" you before the error leaks.
- ✓Less back-and-forth with the accountant/client.
- ✓The agent finds the source of the problem before you do.
✗ No adversarial gate
- ✗The mistake only shows up when the accountant complains.
- ✗Rework and friction with the recipient.
- ✗The “self-selling” agent doesn’t question itself.
🔎 Real case
In Tax OS, before sending a ledger to the accountant, a skeptical reviewer checks whether anything looks strange. In consulting, the reviewer can take on the client voice — a named agent with the contact, informed by all synthesized meetings — and sometimes you want several adversarial reviewers, not just one.
Why learn
Because the skeptical reviewer is what turns autonomy into trust. It lowers the chance of an error reaching the people who matter, reduces tedious interactions (the kind that kill what you love doing), and lets you truly delegate. It’s the review gate in its most powerful form.
Key concepts
🧠 Smarter models → less instruction, maybe no agent
One point that changes how you manage the layer: agents change over time. As models get smarter, the same agent needs less instruction for the same result—or it may no longer be needed, because Claude Code or Codex already does that natively.
💡 Revisit, don’t accumulate
Ask from time to time: "does this agent still need all these instructions? Does it still need exist, or does the model already handle it on its own?". Treating agents as permanent forever is the path to bloat; revisiting them keeps the OS lean.
🔎 What decays by domain
Remember Track 1: each layer decays at its own pace. Agents change as models evolve; identity tends to be more static; context may need monthly updates. Knowing what decays (and when) is part of keeping the OS alive.
Why learn
Because it protects you from accumulation. If you never revisit your agents, you end up with a fleet of “employees” that a newer model might make unnecessary. Periodic audits—less instruction? still needed?—are what keep the agent layer proportional to what you actually need.
Key concepts
📄 Copy-run: the skeleton of an AGENT.md
Time to sketch your first agent. An agent lives in a file AGENT.md (in the folder agents/ from the OS) with clear parts: the role, the skills that orchestrates, the order, o review gate and the limits. Copy the outline below and fill it in for a routine you already do by hand.
Copy and fill in — agents/<nome>/AGENT.md
Objective: sketch an agent that orchestrates the skills you already have, with a review gate before anything is sent.
Create the file and replace what’s inside < >:
--- name: <nome-do-agente> role: <o funcionário que ele é, ex.: "agente de resposta de e-mail"> --- ## Quando empregar <a rotina que eu JÁ faço à mão hoje e quero delegar> ## Skills que orquestra (já existem) - /<skill-1> — <o que faz> - /<skill-2> — <o que faz> ## Ordem de operação 1. <primeiro passo> 2. <segundo passo> 3. produzir um RASCUNHO (nunca enviar direto). ## Review gate (obrigatório) - nada sai sem revisão: <eu confiro / um revisor cético confere>; - se reprovar, voltar ao passo <N> e refazer. ## Limites (never) - <ex.: nunca enviar e-mail sem meu OK>; - <ex.: só LER do CRM, nunca escrever>. ## Done-check - <como sei que o agente fez um bom trabalho>.
How to verify: read the file and confirm the five parts—role, skills, order, review gate, and limits. If the review gate or if a "skill" doesn’t actually exist in your folder skills/, the agent isn't ready yet: go back and build the foundation first.
💡 Tip
The “produce a DRAFT (never send directly)” block + the review gate are the heart of safety. Without them, you have an agent that acts unchecked. Always start with the gate enabled and only relax it once you trust it—never the other way around.
Why learn
Because it closes Track 3 with an artifact of your own. By filling out this outline, you bring the three action layers—skills (3.1), tools (3.2), and agents (3.3)—together in a single document with judgment and review. From here, you move on to Track 4, where the /os-coach builds all of this with you, layer by layer.
Key concepts
✅ Module summary
Next track:
Track 4 — Step by step: build your OS with /os-coach 🛠️