AI Engineer

How We Got LLMs to Recommend Our Open Source Library — Christopher Burns, Inth

1862 summary words 8 min summary Watch video

Start with the signal

8 min read

Summary

At-a-Glance

Verdict: Watch fully
Core thesis: To make an open-source developer library discoverable, understandable, and installable by LLMs and coding agents, treat agent-facing documentation as a first-class product surface: concise navigation files, Markdown delivery, and packaged local docs matter more than a conventional docs site alone.
Why it matters: Agents increasingly influence library selection and implementation, while coding agents often inspect repositories and installed packages rather than visiting websites; this creates a practical distribution and DX channel for developer products.
Best use: Use it as a concise implementation-oriented checklist for making OpenClaw-adjacent tools, libraries, and docs agent-readable, while treating the speaker's attribution and emerging standards as hypotheses to test rather than settled best practice.

Executive Summary

Christopher Burns argues that developer experience is becoming agent experience: the former standard of personally installing and evaluating a tool has increasingly become a prompt-driven workflow in which Claude, ChatGPT, Codex, Gemini, and coding agents select and integrate packages. He presents C15T, his open-source cookie-consent library, as a live example, claiming it grew from roughly 1,200 downloads at an earlier NextConf appearance to millions of NPM downloads, with LLM recommendations becoming its leading reported inbound source after April 13.

His central prescription is not a single GEO/SEO trick but a layered documentation-delivery system. A manually written, concise llms.txt directs agents to the right material; an llms-full.txt supplies a structured index of pages; each web page should have an equivalent Markdown representation; and the site should expose that representation through direct .md URLs, content negotiation for Markdown-accepting clients, and a mode=agent query fallback.

The most operationally relevant point is that coding agents often do not browse product documentation at all. They inspect the repository, installed node_modules, compiled source, and potentially stale model knowledge. Burns therefore bundles Markdown docs into the package and adds an agents.md instruction file that tells agents where to find and validate the relevant documentation. He reports roughly 50% token savings across models from avoiding web search and extracting docs from codebases.

The talk is candid that this ecosystem remains unstable: support for conventions such as Markdown alternates is inconsistent, WebMCP is early, agent-readiness scores fluctuate, and there is no proof that any one optimization causes recommendation growth. The useful conclusion is to build lightweight, versioned agent interfaces now, measure their effects, and iterate instead of waiting for a final standard.

Key Takeaways

Claim: Agent-facing documentation should be treated as a distribution surface because LLM recommendations and prompt-driven installs can now influence developer-library adoption. | Evidence: Burns says C15T's onboarding responses showed Claude, ChatGPT/Codex, and Gemini becoming its number-one inbound source beginning April 13; he reports approximately 3 million NPM downloads, 45% month-on-month growth, and 2,800 production sites using the library. | Implication: For agent tools and developer products, documentation quality should be owned jointly by DX, product, and GTM rather than treated solely as support content. | Caveat: The talk reports correlation from self-reported acquisition data, not a controlled causal study proving that documentation optimizations produced the growth or recommendations.
Claim: A concise, hand-authored llms.txt is more useful than a mechanically generated exhaustive file for orienting an LLM across a large documentation set. | Evidence: Burns reports that roughly 40 good lines outperformed 1,000 lines of noisy generated content in his testing; he frames llms.txt as a directional layer explaining the product and where to find answers. | Implication: Write an explicit agent-oriented overview that prioritizes product purpose, common tasks, key constraints, and the highest-value documentation paths instead of dumping a site inventory. | Caveat: The claimed testing methodology, models, tasks, and reproducibility are not provided.
Claim: Serve documentation in Markdown through multiple retrieval paths because agents fetch structured text more efficiently than they browse and parse HTML. | Evidence: The proposed pattern is a .md counterpart for each standard page, a header declaration that an alternate Markdown version exists, content negotiation that returns Markdown when a client accepts it, and a mode=agent URL-query fallback for clients unable to set headers. | Implication: Build Markdown generation into the docs pipeline, but preserve normal HTML pages and instrument which agent-access routes are actually being used before optimizing heavily for any one convention. | Caveat: Burns explicitly says support for the alternate-Markdown header is uncertain and varies across agents, naming Perplexity and some agents without asserting universal adoption.
Claim: For installable libraries, the package itself is often the most important agent documentation channel because coding agents inspect repos and node_modules rather than visiting the docs website. | Evidence: Burns says agents read repositories, node_modules, compiled source, and stale training data; C15T bundles Markdown docs into node_modules and includes an agents.md file directing agents to the bundled material and asking them to verify it. | Implication: Ship version-matched, locally readable docs alongside every package release so an implementation agent can resolve questions from the exact version it has installed. | Caveat: This pattern is most directly applicable to versioned packages such as NPM, Cargo, and Python libraries; it does not substitute for web documentation for products that agents cannot install locally.
Claim: Local bundled documentation can reduce agent cost and improve implementation reliability by eliminating unnecessary web search and source-code inference. | Evidence: Burns reports nearly 50% token savings across multiple models when agents can access bundled Markdown docs instead of searching the web, locating pages, and extracting content from a codebase. | Implication: Evaluate agent-readiness not only by recommendation or referral outcomes but by task completion, token consumption, tool calls, and error rates in real coding-agent workflows. | Caveat: No benchmark setup, task complexity, or model-specific results are supplied, so the number should be treated as directional.
Claim: WebMCP-like interfaces are the next layer beyond passive documents: agents should be able to query a site through explicit capabilities. | Evidence: LeadType exposes three early WebMCP tools—search docs, get pages, and ask docs—to assemble the relevant documentation context for an agent. | Implication: Prototype narrowly scoped, read-only agent endpoints for documentation retrieval, but avoid making critical workflows dependent on this interface until adoption and security practices mature. | Caveat: Burns characterizes WebMCP as very early, and the talk does not establish broad client support, security requirements, or a stable interoperability standard.
Claim: Agent-readiness is an ongoing operational practice, not a one-time compliance exercise. | Evidence: Burns cites Aura.ai as an emerging agent-readiness tester and notes C15T's score had changed materially over three weeks; his broader framing is a 'utility belt' of small, targeted optimizations rather than a magic SEO tool. | Implication: Maintain a recurring review loop for documentation artifacts, package contents, agent retrieval success, and changing crawler/client behavior. | Caveat: Third-party scoring tools and their criteria are new and volatile, so a score should not be treated as an authoritative measure of LLM recommendation quality.

Detailed Brief

LeadType as a documentation build pipeline

Claims: Burns abstracted the C15T documentation work into LeadType, described as a framework-neutral documentation pipeline rather than a conventional SEO product.; Its intended workflow is to take source .mdx files and generate the collection of agent-oriented artifacts needed for a website.; The speaker says other developer companies are implementing the approach and seeing similar optimization results, though he provides no named case studies or metrics.
Evidence: The command described is effectively 'lead type generate,' which emits the supporting files for an optimized agent experience.; Burns compares the desired documentation quality bar to Stripe documentation: clear enough that integration can proceed reliably.
Caveats: The transcript does not explain LeadType's generated file formats, hosting requirements, licensing, or how it maintains consistency between source docs and package-bundled docs.
Implications: The durable architecture is a single-source documentation system that can emit browser-facing HTML, agent-facing Markdown, indexes, and package-local artifacts from the same versioned source.

Priority order for a non-developer website

Claims: For a standard marketing or company website starting from scratch, Burns prioritizes a Markdown version for every page, followed by llms.txt and llms-full.txt.; He argues that this applies beyond technical documentation: his marketing site also has Markdown equivalents.
Evidence: In audience Q&A, he says many CMSs are not designed for per-page Markdown output and notes that he built a custom CMS to support the pattern.; He asserts that more websites are being visited by agents rather than human users, but supplies no measurement.
Caveats: For nontechnical sites, broad Markdown exposure can surface material that teams may not want indexed or easily extracted; content governance and access controls still apply.; The claim about agents overtaking human website visits is not substantiated in the talk.
Implications: CMS selection and content architecture should include machine-readable publishing requirements, rather than bolting them on after a site launch.

Notable Concepts & Terms

llms.txt: A concise, agent-oriented guide to what a product or documentation set is, which questions it can answer, and where the most relevant material resides.
llms-full.txt: A fuller structured page index, likened by Burns to a sitemap with links and short descriptions, intended to help agents locate documentation.
Twin Markdown pages: A pattern in which a normal web page has a corresponding .md URL so an agent can retrieve low-overhead structured content instead of HTML.
Content negotiation for Markdown: Returning Markdown rather than HTML when a client indicates it accepts Markdown, with an explicit query-string fallback for less capable agents.
agents.md: A package-local instruction file that directs coding agents to version-matched bundled documentation and can specify validation behavior.
WebMCP: An early concept for exposing explicit website capabilities to agents; the example interface provides documentation search, page retrieval, and question answering.
LeadType: Burns's framework-neutral docs pipeline that generates agent-facing documentation artifacts from MDX source files.
Aura.ai: A newly introduced site-testing tool cited as an agent-readiness evaluator; useful as a changing diagnostic rather than a stable benchmark.

Operator Notes / Why Ken Should Care

Audit every OpenClaw-facing repository and package for a versioned agents.md plus bundled, task-oriented Markdown docs; make release CI fail if these artifacts drift from the shipped API or behavior.
Add an agent retrieval benchmark to the docs pipeline: run representative coding tasks against web-only versus package-local documentation and record task success, tokens, tool calls, and hallucinated API usage.
Publish per-page Markdown for public documentation and marketing content, with explicit rules for authentication, private material, and content that should not be exposed through machine-readable endpoints.
Hand-author a short llms.txt for each major product surface; review it as product positioning changes rather than generating it blindly from navigation.
Treat WebMCP-style documentation endpoints as an experimental read-only interface and conduct threat modeling before exposing any account, deployment, or mutation capability.
Use Aura.ai or similar tools as a periodic regression signal, but set internal success criteria around observed agent task outcomes and referral/installation attribution rather than third-party scores.

Source/Metadata

Title: How We Got LLMs to Recommend Our Open Source Library — Christopher Burns, Inth
Transcript words: 4319
Duration seconds: 987
Timestamp note: No timestamps or chapter markers were present in the supplied transcript. The transcript also contains a substantial repeated segment after the Q&A.

Search this video Resume transcript at 0%

Full transcript 2394 words · 19 min read