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

Christopher Burns, founder of Inth and creator of the open-source consent-banner library c15t, opens with the limits of his expertise: he is experimenting with what helps agents understand a library and what saves tokens. “Please don't think my accent makes me an expert.” The project gives those experiments a practical setting: consent software designed for developers, with developer experience central to its adoption. 0:12

The signal appeared in a plain onboarding question: how did you hear about us? Responses began spiking from April 13, and Burns reports that recommendations from Claude, ChatGPT, Codex, and Gemini became c15t’s number-one inbound source. These self-reported answers identify a discovery channel; they do not establish which documentation change caused its growth. 2:07

Installation behavior explains why that channel matters. Burns recalls Stripe’s early “Collison install,” where the founders personally completed an integration on a prospective user’s laptop. During Y Combinator, his equivalent was handing people a prompt. A developer asks an agent to do something, the agent recommends installing a library, and the developer accepts. The instructions and documentation that make a library approachable to developers now also help the agent doing the integration.

No single tool fixes every point where discovery or understanding can fail. Burns reaches for Batman’s utility belt: many small tools, each aimed at a particular problem. The collection includes familiar web mechanisms such as sitemaps, RSS feeds, and robots.txt, alongside files intended for LLMs. As the team built more documentation sites, it abstracted the work into Leadtype, an open-source, framework-neutral documentation pipeline. The workflow is straightforward: take .MDX files, run leadtype generate, and produce the agent-facing files around them. Leadtype handles those outputs while the site keeps its own host and UI. 4:38

The first problem is navigation. With hundreds of documentation pages, an agent needs help deciding where an answer is likely to live. Burns recommends writing llms.txt by hand rather than filling it with generated material. The file should communicate what matters to the agent. His testing favored about 40 good lines over 1,000 lines of noise—a practical reason to spend editorial effort on the entry point even when the surrounding pipeline is automated. 6:08

The fuller index serves a complementary purpose. In Burns’s model, agents fetch resources rather than navigate a site the way a person does. An annotated sitemap gives them page links plus a short description of what each page contains. The concise orientation file helps establish where to begin; the expanded index helps select a particular resource for a particular question.

Finding the right page leaves another cost: its representation. HTML is expensive for the agent to consume, so the documentation can offer a Markdown twin. Burns’s concrete example is a Next.js quick-start page. Open its normal URL and receive the website; append .md and receive the Markdown version. The visible change is in what the request returns: the agent can read the documentation without taking in the full HTML representation. 7:08

The page can advertise that a Markdown alternative exists. Burns points to a signal in the header, but does not establish its precise implementation, and notes that support across agents remains unsettled. Discovery therefore needs to be paired with more than one way to request the alternate content.

Three access methods accommodate different clients:

• URL suffix: Append .md and give the agent the Markdown destination directly.
• Content negotiation: Configure the normal URL to return Markdown when the request indicates that it accepts Markdown.
• Query parameter: Offer mode=agent for clients that cannot set request headers.

These methods lead to the same kind of content. Their value is that a client’s HTTP capabilities do not determine whether it can obtain the leaner version. 8:08

A fetchable page still leaves the agent responsible for finding and assembling the relevant context. WebMCP introduces a way to ask the documentation system for help. Burns describes early support in the pipeline for three operations:

• Search docs: Find relevant documentation.
• Get pages: Retrieve selected pages.
• Ask docs: Ask a question using the documentation context collected by the system.

The change is from publishing readable resources to exposing operations an agent can call. This support is presented as early work, rather than an established capability shared by every agent. 9:08

Burns also imagines agents communicating with services over email. That is a forecast about where these interfaces might go; the concrete implementation described here remains the three documentation tools.

The most consequential observation comes next: a coding agent working with a library may never visit its documentation website. Burns finds agents reading the repository and node_modules instead. Their training data can be stale, so they inspect compiled source to work out what the installed library can do. Improving the website alone misses this local reading path. 10:04

c15t moves the explanation into the installed package. It bundles Markdown documentation and includes an AGENTS.md file that tells the agent where to find it. Consider the c15t Next.js task Burns describes: previously, an agent could infer behavior from compiled code or search for documentation elsewhere. Once directed to the bundle, it can read the package guidance, locate the relevant Markdown, and check that the material matches what it is working with. The answer becomes available in the environment the agent already inspects.

Availability still leaves a discovery problem. Leadtype’s current README recommends that consumers add an instruction to their own project’s root AGENTS.md: when working with the library, read node_modules/YOUR_PACKAGE/AGENTS.md first because its documentation matches the installed version. The README reports that agents read the bundle only about 29% of the time when left to discover it unaided, versus roughly 90–100% with that root pointer. These are current project evaluation results, separate from the recording’s measurements; they make the consumer-side instruction a consequential part of the setup.

Where does the agent go for context before and after that change? The comparison below follows the same installed-library task through two routes. The guided local route begins with the consuming project’s instruction, follows the package’s AGENTS.md, and reaches bundled Markdown. The other route asks the agent to reconstruct behavior from source or find an answer on the web. Proximity makes the documentation available; the explicit pointer helps the agent choose it.

Burns reports almost 50% token savings across multiple models when agents pull Markdown from the codebase instead of searching the web. The task set and token baseline are unspecified, so this is a project measurement rather than a general benchmark. The mechanism removes work from the retrieval path: the agent can follow a local pointer to the relevant files instead of searching for the right material. 11:04

This approach also works without a separate skill. A skill can add an explicit instruction to look in node_modules; the consuming project’s root guidance provides another way to direct the agent there. For a frequently changing library, the practical decision is to distribute explanations with the module and tell consumers how to point their agents at them, rather than rely entirely on the agent’s memory or its willingness to visit the website.

The pipeline’s use extends beyond library documentation. Burns also uses it on his marketing website, where every page has a Markdown version, and suggests the same approach for a Markdown-backed blog. Documentation is the common starting point, but the delivery problem applies anywhere an agent needs to read website content.

Readiness checkers offer a way to find further improvements. Burns mentions a Cloudflare checker and shows a score of 59 from another checker he prefers. That score had been higher three weeks earlier, and he presents the movement as part of a changing field. The number is a snapshot under evolving expectations, rather than a permanent certification of agent compatibility. 13:03

The closing advice is to keep making useful improvements without waiting for perfection. Models, agents, and conventions change fast enough that even these slides cannot stay definitive. A short index, a Markdown alternative, or a local documentation bundle each addresses a specific obstacle. Burns’s confidence rests in continuing that work, not in having finished the problem.

The audience question brings the advice back to an ordinary website: where should an agency start if its client is not selling a developer tool? Burns first emphasizes offering a .md version of every page where possible, then calls llms.txt the “first shout” and places the fuller index second. These are complementary starting points rather than a strict implementation sequence: give agents a useful map and readable destinations. 14:40

The constraint is often the CMS. Many systems do not naturally produce Markdown pages. Burns jokes that his own solution was building a CMS his team wishes he had never built, but his recommendation does not require following that detour. The orientation files can be written manually even when the site does not use Markdown internally, and maintainers can find other ways to create the extra files. Start with what the publishing system can support and make the content easier to fetch.