Appearance
Learning Paths: Three Routes
This site has 40-odd pages. If you start from page one and read straight through, chances are you'll zone out somewhere in the third article of the components chapter — not because the content is bad, but because reading cover to cover is simply the wrong way for a working engineer to learn an engineering discipline. What you need isn't a library; it's a route map.
Everything on this site falls into one of four kinds: concept-building (the guides), mechanism-explaining (the components), evidence-providing (case studies and papers), and behavior-changing (practice and career). People in different situations should consume them in entirely different orders and at entirely different depths. This page lays out three pre-assembled routes — find the one that matches your situation and go.
text
What's your situation?
│
┌──────────────────────┼──────────────────────┐
▼ ▼ ▼
Interview in 1-3 Free time, want to Already building
months switch careers agents at work
│ │ │
┌──────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ 1 Job-Hunt │ │ 2 Career │ │ 3 Desk │
│ Sprint │ │ Switch │ │ Reference │
│ ~2 weeks │ │ ~6 weeks │ │ use as needed │
├──────────────────────┤ ├──────────────────────┤ ├──────────────────────┤
│ career track │ │ Guides → Comps │ │ Hit a problem │
│ + top components │ │ → Cases → Practice │ │ → check the index │
│ + hands-on demo │ │ + weekly checks │ │ → back to work │
├──────────────────────┤ ├──────────────────────┤ ├──────────────────────┤
│ Output: polished │ │ Output: can explain │ │ Output: today's │
│ resume + 10 │ │ the whole system + │ │ problem solved │
│ interview answers │ │ a portfolio │ │ │
└──────────────────────┘ └──────────────────────┘ └──────────────────────┘The three routes aren't mutually exclusive
A common real-world trajectory: use the site for a few months through the Desk Reference, decide to switch roles and work through the Career Switch, then run the back half of the Job-Hunt Sprint in the final stretch before interviews. A route is navigation, not train tracks.
Route 1: Job-Hunt Sprint (~2 weeks)
Who it's for: You have an agent engineering interview within 1–3 months, you're already a working engineer (backend, full-stack, or ML all work), and you have no large blocks of free time — just evenings and weekends.
Core approach: An interview ultimately tests two things: whether you can explain an agent system clearly, and whether your resume and delivery can get you past the screen. So this route works backward from the job description and real interview questions, aiming not for completeness but for full coverage of the high-frequency topics — plus an answer to "why" for every one of them.
Mainline: the career module's four pages
| Order | Page | What to take away |
|---|---|---|
| 1 | JD List: open roles at major companies | What the target role actually asks for; copy down the skill keywords that keep recurring |
| 2 | Knowledge Map | Map those keywords onto this site's pages and generate your personal catch-up list |
| 3 | Resume Analysis | Rewrite your project experience to its standard, foregrounding harness-related decisions |
| 4 | Interview Questions | Save it for self-testing at the end — don't open it on day one |
Sides: the most-tested components + one hands-on demo
Judging by how topics are distributed across JDs and interview question sets, these four component articles cover most of the "harness side" of the exam. Read them in this order:
- Context Engineering — a staple of nearly every agent interview; the trade-offs among compression, truncation, and injection should be ready to reel off without thinking;
- Tool Systems — how you write tool descriptions and handle returned results is the dividing line between "has called APIs" and "has built agents";
- Observability — "a production agent is behaving oddly — how do you debug it?" is the question that separates senior candidates;
- Subagents — when a multi-agent architecture earns its keep and when it's over-engineering; the interviewer is waiting for you to say "it depends" and then supply the criteria.
If you add just one more, make it The Agent Loop — it's the foundation under everything else.
A resume with nothing behind it won't survive scrutiny. Spend a weekend getting Build Your Own Harness running: the v1 minimal loop under examples/ in the repo is only a few dozen lines, v2 adds tools, v3 adds planning and memory. Run each layer and tweak something at each one, and you'll own a hands-on project you can narrate for five straight minutes in an interview.
The two-week rhythm
Week 1 (understanding + resume):
- Mon–Wed: JD List → Knowledge Map; walk out with your personal catch-up list;
- Thu–Fri: read the four component articles in the order above; after each one, close the page and record yourself explaining its core mechanism on your phone — re-read wherever you stumble;
- Weekend: get build-your-own running from v1 through v3; finish the first revision of your resume against the Resume Analysis criteria.
Week 2 (delivery + self-testing):
- Mon–Wed: Interview Questions — answer each one yourself before comparing; flag whatever you can't answer and loop back to the corresponding component page;
- Thu–Fri: mock interviews with a friend, or voice-recorded self Q&A; drill the "why" questions (why compress instead of widening the window? why aren't more subagents always better?);
- Weekend: lock the resume; package the demo project into a repository you can show.
Acceptance criteria after two weeks
You should end up holding three things: a resume rewritten to agent-role standards, a mini-harness repository that runs and that you can explain, and answers to 10 interview questions where you can articulate the trade-offs. Missing any one means the corresponding step got shortchanged.
Route 2: Career Switch (~6 weeks)
Who it's for: You have relatively ample time (8–10 hours a week), want to complete the switch within 1–2 quarters, and would rather build real foundations than take shortcuts.
Core approach: Knowledge in agent engineering has a dependency graph — without understanding the loop you can't parse context engineering; without understanding the components you can't see what case studies are actually doing; without having dissected a case you can't write your own design principles. This route is ordered by dependency, with an acceptance check each week — fail it and don't move on.
| Week | Content | Acceptance check |
|---|---|---|
| Week 1 | The four guides: What Is a Harness → Model vs. Harness → History → Anatomy | You can explain to a colleague who has never heard the term what the model handles and what the harness handles, and back it with one concrete example |
| Week 2 | Component foundations: The Agent Loop → Context Engineering → Tool Systems | You can draw the minimal agent loop on a whiteboard and name at least three ways to handle a full context window, with the cost of each |
| Week 3 | Intermediate components: Planning → Memory → Subagents → Model Routing | You can articulate how the three planning modes differ, and when to spin off a subagent versus when a todo list is all you need |
| Week 4 | Final three components + case studies: Permissions, Skills, Observability; read the Claude Code and SWE-agent case studies closely, then pick two more from Cursor, OpenHands, Aider, and Devin | Given any agent product, you can break down its loop structure, tool set, and context strategy, and call out one design decision you find dubious |
| Week 5 | The five practice pages: Build Your Own Harness → Harness Tutorial → Design Principles → Common Pitfalls → Evals in Practice; the goal is a small agent, built this week, that solves a real pain point from your day job | Your demo runs on someone else's machine, and you can say exactly which inputs it fails on |
| Week 6 | Papers + career wrap-up: read the ReAct material in Core Papers closely and cherry-pick from Frontier Papers; then run the career module: Knowledge Map → Resume Analysis → Interview Questions | You can explain the through-line from ReAct to today's todo lists; your resume and your 10 answers meet the Job-Hunt Sprint's acceptance criteria |
A hard requirement for week 5
The hands-on week is the only part of the six that cannot be compressed. Somewhere in those four component articles you'll pick up an "I already get this" feeling — and it will shatter the first time you let the model drive a shell tool on its own. Until an agent's runaway behavior has personally educated you, the switch isn't finished.
If you're genuinely squeezed, you can halve the week 4 case studies and the week 6 papers — but do not cut the guides, the components, or the hands-on week. They're this route's load-bearing walls.
Route 3: Desk Reference (builders already on the job)
Who it's for: You're already doing agent-related development; problems arrive in units of "I'm stuck today"; you have neither the need nor the patience to read through everything.
How to use this route: when you hit a problem, find its entry page in the table below, read just enough to unblock yourself, and leave. No rabbit holes. Rabbit holes are for weekends.
| The problem you hit | Go read |
|---|---|
| Tool results are too long and the context window blows up fast | Context Engineering (compression and truncation strategies) |
| The model forgets the original goal and drifts further off course | Planning & Task Decomposition (the todo list mechanism) |
| Unsure which tools to give the agent, or how to write tool descriptions | Tool Systems |
| Want the model to remember user preferences or cross-session info | Memory Systems |
| One agent can't cover it all; want to split it up but fear over-engineering | Subagents |
| The agent must perform risky actions — how should the approval flow work? | Permissions & Human-in-the-Loop |
| Production behavior is strange; not sure how to debug or record traces | Observability |
| Don't want to pay frontier-model prices for trivial tasks | Model Routing |
| Want to feed the team's domain knowledge to the agent | Skills |
| Can't decide between LangGraph and writing your own loop | Framework Comparison |
| Need to build one from scratch | Build Your Own Harness |
| The agent is great one day and terrible the next; want a real eval system | Evals in Practice |
| No idea how to write CLAUDE.md or a system prompt | Writing CLAUDE.md |
| Want to see how mature products solved the same problems | The case-study chapter: Claude Code, Cursor, Devin, LangGraph, Coze, Manus, Dify, and four more — ten case studies in all |
| Interviewing or being interviewed and need an assessment framework | Interview Questions |
| Blanking on a term | Glossary |
| Hunting for external tools or prompt examples | Resource Directory, Prompt Archive |
Bookmark this page
The Desk Reference lives and dies by its reuse rate. Bookmark this page — not any single component article. This page is the site's switchboard.
Two Notes
The paths aren't hard rules. The week counts and orderings assume a typical background: backend engineers can skip chunks of the tools material; folks from ML backgrounds can speed-run Model Routing; PMs moving into the role should spend double time on the guides and case studies. The bar is always whether you pass each week's check — not which page the calendar is on.
Watch the freshness dates. Agent engineering has the shortest half-life of any engineering discipline this site has covered — job-market data, case breakdowns, and paper lists all go stale. Some pages in the career module and the case-study chapter carry a dataAsOf field in their frontmatter (the month the data was current), also displayed at the top of the page. Before citing a specific opening, score, or product behavior from them, glance at that date: anything older than a quarter should be treated as a "trend reference" rather than "current fact," and verified against official sources. Conceptual content (what a harness is, how the components work) decays far more slowly and is safe to lean on long term.
Further Reading
- What Is an Agent Harness — the shared starting point of all three routes
- Anatomy of a Harness — the whole-site content map, cross-indexed with this page
- Job Hunting & JD Analysis — the module behind Route 1's mainline
- Core Papers — the primary sources for week 6 of Route 2
- Design Principles — worth returning to after finishing any route, to check yourself against