Docs are becoming a runtime dependency
Documentation used to sit beside the product. Now it can decide which product gets chosen, what code gets written, and whether an agent implements it correctly.
For a developer product, the docs are often the first use of the product. Someone reads them before installing anything. They decide whether the product fits their stack, whether the team understands their problem, and whether getting started will take ten minutes or two days.
A recommendation is not enough
Sometimes the docs are the only part someone sees before making that decision.
With c15t, an agent saying “use c15t” is only the start.
The developer still needs the correct package, the right operating mode, and an implementation that prevents scripts from loading before consent. If the recommendation is correct but the code is wrong, the product has failed before we ever meet the user.
A confident wrong answer can be worse than no answer at all.
That is why we care about documenting the non-obvious. Types can show a function signature. CLI help can list a flag. The useful documentation explains defaults, failure modes, ordering constraints, and when one approach should be chosen over another.
The docs are part of whether the product works.
Agents are another user of the docs
Developers now ask ChatGPT, Claude, Codex, and other coding agents what to install and how to implement it.
The agent may choose the product, write the integration, and fix the first error without the developer ever opening the documentation website. The page view can disappear. The documentation still shapes the decision.
Agents do not experience a docs site in the same way as a person. Tabs, accordions, cards, framework switchers, and rich MDX components can help a human while becoming noise or missing context when the content is flattened badly.
For agents, the docs are part of the execution environment. They change what the agent reads, the code it writes, how many tokens it spends, and whether it invents behaviour.
We found the problem while building c15t
The first c15t documentation was written for humans.
We cared about how it looked, how the examples worked, and how quickly a developer could understand consent. The source used MDX because we wanted components, tabs, callouts, and framework-specific examples.
Then we looked at what models received.
The Markdown had lost important context inside JSX. Content that made sense on the rendered page became fragmented or disappeared. We had an llms.txt file, but pointing an agent at weak source material did not make the answer better.
The problem was no longer publishing a file. We needed a pipeline that could preserve the human experience while producing a different, clean version for agents.
Why we built Leadtype
Leadtype began as that missing pipeline inside c15t.
We wanted one source of truth for the documentation without forcing humans and agents to consume the same shape. The human site could keep the design and interaction we cared about. Agents needed clean Markdown, clear routing, search, and documentation that matched the installed version of the package.
Then we built more documentation sites and hit the same problem again.
Maintaining separate content for the website, search, answer engines, and coding agents would always drift. We pulled the work into Leadtype so one source could produce the human documentation and the surfaces agents need.
That is the story behind leadtype.dev. It came from trying to make c15t easier to find, understand, recommend, and implement.
We stopped trusting vibes
We wanted to know whether agent-readable documentation changed what an agent did.
In our Leadtype evaluations, package-bundled docs reduced token use by 32 to 54 percent across every model tested. Agents made fewer tool calls because they could read the answer instead of probing the package repeatedly.
The more important result was the reduction in confident wrong answers.
Without the docs, models often did not admit that they were unsure. They invented plausible behaviour about non-obvious parts of the API. With the docs present, several tested models dropped from confident wrong answers to zero.
The largest accuracy gains appeared in the smaller models commonly used for routine agent work. Even the frontier models that could recover the answer from code and types became cheaper to run.
Documentation had changed model behaviour.
The writing matters more than the file
Publishing llms.txt, Markdown mirrors, or an AGENTS.md does not rescue weak documentation.
The content has to explain what the agent cannot safely infer. Defaults. Failure conditions. Decision boundaries. The reason one mode should be chosen over another.
It also has to be structured so one section can survive being retrieved without the rest of the page. Lead with the answer. Use the same term for the same concept. Put limits and version details in text rather than hiding them inside a diagram.
This is part of our agent experience. We want an agent working with Inth or c15t to have the same chance of succeeding as a developer reading the website carefully.
Documentation is distribution
Developers increasingly ask an agent which library to use before they search for one themselves.
That changes the path into the product. A model needs to find us, understand what makes the product different, and have enough evidence to recommend it. Then the coding agent needs enough context to implement it without making things up.
The documentation now carries positioning, onboarding, support, and implementation.
Leadtype exists because we needed that path to work for c15t. We care about it for the same reason we care about every other part of Inth: if someone trusts our product, the experience should hold together all the way from the first recommendation to the code that reaches production.