Patterns for building with agents.
Seven sections, twenty-six pages. The durable lessons from building agentic systems — how to structure context, when to trust which model, how multiple agents coordinate without falling over, and how to instrument the whole thing so you can tell when it's broken. Nothing here is theoretical.
5 minutes to a working mental model.
"Eight sections is a lot. The quickstart routes you to the three pages worth reading first."
Not sure where to start? The QUICKSTART gives you four reading paths based on who you are: engineer, engineering leader, platform builder, or focused on safety. Each path is exactly three pages, ~15 minutes, calibrated to give you a working model of what's happening before you commit to deeper reading.
Need a term defined? See the GLOSSARY — single-page lookup for every load-bearing term used across the repo.
A leader's memo.
"The bottleneck moved from typing to specifying. Most teams have not yet adjusted."
A one-page primer for managers, directors, and execs who are not coding day-to-day but need to make decisions about tooling, hiring, and strategy. Five questions to ask your teams. Where the leverage is. Where the risk is. Read the memo →
Or read it as markdown.
Seven new pages from unmined source material.
"The repo's strength is being focused. The right move was surgical additions, not a content dump."
Multi-agent (sec 03): Reflection Loops (generate → critique → revise) · Framework Selection (LangGraph / CrewAI / AutoGen decision matrix).
Automation (sec 04): Prompt Injection — the structural vulnerability every agentic system has. Required reading before letting an agent run with real authority.
Tools (sec 07): Tool Description as Prompt — the most load-bearing sub-pattern of tool design, promoted to its own page.
Platform (sec 02): Cross-Platform Parity — Mac / Linux / Windows / WSL discipline.
Resources (sec 08): Shell and Terminal Tools · Cloud and Deployment Tools — deep references for the tooling that hosts agentic work.
Earlier additions (v0.4): 6 Mermaid diagrams + 5 war stories. See CHANGELOG for the full history.
Concepts — the vocabulary
If you've sat in a meeting and people were saying "MCP" and "context window" and you weren't sure exactly what they meant, this is the section that pins the words down.
Platform — the boring infrastructure that makes agents productive
Setting up a project so agents can be productive in it. Teams that skip this end up with agents that flail — they don't know how to run tests, find the build script, or follow conventions.
Multi-agent workflows — where the real leverage lives
Single agents have structural limits — no internal critic, single perspective, sequential thinking. Multi-agent workflows close all three. The single highest-leverage move in agentic engineering.
Automation — letting agents run unattended
Where you have to think hard about trust and blast radius. Levels of autonomy, sandboxing, overnight runs, and the failure modes of leaving agents on by themselves.
Local LLMs — when running models on your own hardware makes sense
The capability gap between local and frontier is real, and shrinking, but not closed. When local is the right call, when it isn't, and how to evaluate which models actually work for your tasks.
Token efficiency — controlling cost and latency without sacrificing quality
A 5–10x cost reduction is achievable with no quality loss if you apply prompt caching, model tiering, and context discipline correctly. Most teams capture none of it.
Tools and MCP — the plumbing
Tool design is where most agentic workflows succeed or fail. The model is downstream of the tools you give it. Hooks add guardrails the model can't forget. Skills package recurring expertise.
Resources — the practical apparatus
What dev environment to set up, what to read, which tools to actually pick. Opinionated, dated, and re-evaluated annually — the picks change but the criteria hold up.
Send a quick note.
Found something useful? Disagree with a recommendation? Have a war story from your own practice? This form goes straight to the maintainer.
If you have a GitHub account, opening an issue is preferred — it's public and lets others weigh in. This form is the path for everyone else.