The usual way to give expert knowledge to a coding agent is to write a Markdown file and trust that the agent reads it. That works until the document grows: every token of guidance is a token that isn't available for the code, for the conversation history or for the output. Context is a scarce resource, and large skills consume it even when the task doesn't need them. [Modern Web Guidance](https://github.com/GoogleChrome/modern-web-guidance-src), the Chrome team's project to stop agents from writing outdated patterns, inverts that pattern. Its main skill holds no knowledge: it holds instructions for going out to find it. And the search engine is an embeddings model that runs locally, with no network and no API keys. It's an interesting catalogue of guides, but what grabs me is the architecture underneath, because it's replicable in any project that needs to bring domain knowledge to an agent. ## The inverted pattern The numbers in the published package explain the decision well. The `modern-web-guidance` distribution includes 139 Markdown guides that add up to about 975 KB of text, in the order of a quarter of a million tokens. Loading all of them isn't an option: they don't fit, and even if they did, filling the window with 138 irrelevant guides degrades the model's attention on the one that does matter. The `SKILL.md` that gets installed is 5.6 KB. Of that, the `description` block in the frontmatter is about 1,000 characters, in the order of 250 tokens, and it's the only part permanently in context. The body of the skill loads only when the agent decides to activate it, and what it holds isn't a guide, it's two commands: ```sh # Step 1: search for relevant use cases npx -y modern-web-guidance@latest search "" # Step 2: retrieve the full guide by ID npx -y modern-web-guidance@latest retrieve "" ``` > Right here we can already see a dependency on Node and npm. The agent uses about 250 tokens at all times, about 1,400 once it activates the skill, and only then decides which specific guide is worth putting into context. Search returns the `tokenCount` of each candidate, so the agent itself can reason about the cost before asking for it. The project also keeps a _megaskill_, a single document with all the content concatenated, for agents that can't run commands. It's the plan B, not the main solution. ## Local semantic search, no network and no API keys The `search` command doesn't call any API: it runs an embeddings model inside the Node process. The model is `all-MiniLM-L6-v2`, a small BERT from the sentence-transformers family that produces 384-dimension vectors. It's converted to a TensorFlow.js Graph Model and sits inside the npm package: 22.5 MB of weights in `group1-shard1of1.bin` plus 576 KB of topology. Unquantized, in float32, a decision the repository justifies as maximum accuracy parity with the original model. Two details of the conversion matter. The graph has the _mean pooling_ and L2 normalization layers baked in, so the output tensor is already the final normalized vector and there's no post-processing in JavaScript. And the BERT tokenizer resolves with `local_files_only` against a cache that also ships inside the package, so there isn't a single request to Hugging Face at runtime. ```js // serving/lib/tfjs-embedder.ts (simplified) await setBackend("cpu"); this.model = await loadGraphModel(ioHandler); this.tokenizer = await BertTokenizer.from_pretrained( "Xenova/all-MiniLM-L6-v2", { local_files_only: true } ); ``` The index is precomputed at build time, not at query time. Each guide is split by headings and each fragment is embedded with a prefix that gives it context about where it lives: ```js const embeddingText = `${id} (${category})\nFeatures: ${featuresUsed.join(", ")}\n\n${chunk}`; const vector = await embedder.embed(embeddingText); ``` The result is serialized into a 5.6 MB `use-cases.vectors.gen.json.gz` that ships with the package. On each search, the CLI computes the embedding of the query, walks the vectors in memory calculating cosine similarity, drops anything below 0.3 and returns five results. Since there are several fragments per guide, it groups by ID and keeps the highest similarity of each one: the fragments compete with each other, but the guide shows up only once. There's no vector database and no approximate index. At this volume, a loop over an array and a dot product are enough. Why embeddings and not `grep`? Because the agent asks by intent and the guides are written with specification vocabulary. This query shares no meaningful word with the guide that answers it: ```console $ npx -y modern-web-guidance@latest search "close a popup when the user clicks outside of it" [{"id":"light-dismiss-a-dialog","description":"Create a modal dialog that can be closed via light dismiss (i.e. clicking or tapping outside of the dialog)","category":"ui-behaviors","featuresUsed":["