The AI agent you’re using has read more code than you have. More languages, more frameworks, more decades of open source. It can sketch a React app, refactor a Rust crate, write a SQL query against a schema it’s never seen. Pattern-matched against a corpus larger than any single human will ever encounter.
It also doesn’t know that your team uses pnpm, not npm. It doesn’t know the auth service moved out of services/auth six months ago. It doesn’t know which of the five “utils” folders is actually authoritative, or that the Logger class is preferred over console.log, or that your migrations have an unwritten rule about never being edited after merge.
That asymmetry is the gap. The agent is broad and shallow. The SME — you, your tech lead, the engineer who wrote the original module — is narrow and deep. The agent’s failures aren’t usually intelligence failures. They’re context failures. It chose a reasonable pattern; it just wasn’t the pattern your team uses. It picked a perfectly good library; it just wasn’t the one already vendored in your repo.
A smarter model doesn’t fix this. A bigger model doesn’t fix this. The next generation of agent will still walk into your codebase blind to the things that aren’t written down.
Context engineering is the practice of closing that gap. Writing down what only you know, in a form the agent can read. Connecting the agent to the systems your team’s knowledge actually lives in (Jira, Postgres, Figma). Encoding the rules that can’t be inferred from the code alone. Isolating the agent’s context so one bad thread doesn’t pollute the next.
Every chapter on this site is a technique for it. Rules. Skills. MCP servers. Subagents. Hooks. Permissions. Plan mode. They’re not features to admire — they’re levers for closing the gap between what the agent is capable of and what it actually knows about your work.
Start with Rules — the simplest lever, the one every major AI coding tool added in the same year. We’ll cover the rest from there.