Agents: A Reviewer With Its Own Brain

A complete course for developers who are serious about making AI part of how they actually work.
An agent is still just Markdown, but it's Markdown that runs somewhere else. A command runs in your main session with a model you pick; a skill runs in your main session with whatever model is there; an agent spawns in the background with its own model, its own tool list and, this is the part that matters, its own context. It gets your agents.md and whatever the orchestrator tells it, and that's it. That's why you'd have a builder, a tester or a reviewer go read a whole sprint while you keep working: none of that reading lands in your context.
I build one, dictated in one go, and I'm deliberate about what I ask for because an agent can use skills, and we already have Elixir, Erlang/OTP and Postgres skills in this project. No point defining that knowledge twice. An agent should be slim: a reason to exist, a model, and the skills it leans on.
Create me an agent that uses Fable 5.1, or the frontier, whatever the top-end Fable is. I want it to review the code in this project for Elixir best practices. But I also want the reviewer to recognize when rules can be bent or broken for the sake of performance or speed. That of course should not lead to any crashes or anything like that, but we don't always need to be so exacting. The agent should recognize that. The reviewer should go through and look for any common pattern mismatches or pattern problems, or things that might lead to locks or problems with OTP and GenServer. Elixir is a very difficult language and very hard to get right, so this agent needs to be very aware of Erlang best practices, OTP best practices, and what the Elixir community likes to do.
Then I clear the context and run it.
use elixir-reviewer on lib
The reviewer spins up in its own session; you can watch it work, and a /context back in main shows the main session barely touched while Fable chews through lib/ (a minute forty and 53,000 tokens in, and none of it mine). This is one-person orchestration: a coder, a tester and a reviewer, each off in its own session, and yes, you can automate it, which is where software factories and harnesses come in later in the course.
The file itself is worth a look. model: fable at the top, and then a tools line: Read, Grep, Glob, Bash and Skill, and no Edit. A reviewer should not be able to change anything, so it can't, but it can pull in the skills it needs. You can narrow it further (connection management only, security only, performance only) by editing the instructions. I'll be straight with you though: I don't see many people using agents this way, because Claude Code's own orchestration (agent teams, the task API) and the frontier models are so good that most people let the main session run everything. Skills are the big one, commands are a convenience, agents are interesting. I'll show you my opinion as we go and you can make up your own mind.
A complete course for developers who are serious about making AI part of how they actually work.