When a developer asks a coding agent to “add payments to my app,” the agent does not simply choose the first SDK it remembers. It may draw on its training data, search the web, inspect machine-readable context, generate integration code, and run that code. At any one of those stages, an SDK can move to the top of the list—or get replaced by a competitor. For developer-tool teams, this changes what “discoverability” means. Good documentation still matters, but documentation is only one part of the decision. Here is a practical model for understanding how coding agents such as Claude Code and Codex choose an SDK. The four-layer decision stack Layer What the agent does What influences the choice 1. Training data Recalls tools and usage patterns from the base model Historical docs, repositories, tutorials, package metadata 2. Web search Retrieves current information when memory is insufficient Search visibility, crawlability, freshness, clear titles 3. Context retrieval Reads structured, task-specific context llms.txt, MCP servers, installed skills, API descriptions 4. Tool execution Installs the package, writes code, and may run it Installation reliability, API design, errors, response quality Most teams have invested heavily in the first layer. The more controllable opportunities are often in layers two through four. Layer 1: Training data creates the shortlist Every coding agent starts with a base model. That model may have learned about an SDK from: Documentation pages Public GitHub repositories Stack Overflow answers Tutorials and blog posts npm, PyPI, or other package metadata This creates a strong advantage for mature libraries. The agent has probably seen their package names, imports, initialization code, and common examples many times. But model knowledge has limits. It can be out of date, overrepresent popular libraries, miss a recently launched SDK, or reproduce a deprecated integration pattern. For an SDK team, a useful test is to ask several models about the product without enabling web search. Check whether they know the correct package, initialization flow, and current API surface. That gives you a rough baseline for the first layer. Training data gets an SDK onto the shortlist. It does not guarantee the final choice. Layer 2: Web search updates the shortlist Coding agents search when the user explicitly asks them to find a tool, when the model is uncertain, or when the task depends on recent versions and comparisons. Vercel's research into AEO tracking for coding agents found that roughly 20% of the prompts it studied triggered web search. Discovery and comparison prompts are especially likely to require fresh information. An agent searching for an SDK will often encounter: Official quickstarts and API references GitHub READMEs Comparison pages Recent implementation tutorials Community posts that show a real use case This layer can fail for surprisingly mechanical reasons. Your docs may block relevant crawlers, rely entirely on client-side rendering, use vague page titles, or bury the working example beneath marketing copy. A page called “Node.js quickstart for Acme Payments” is easier to retrieve and interpret than one called “Getting started.” A complete example in server-rendered HTML is more useful than an empty shell that only appears after JavaScript runs. The practical checks are straightforward: Confirm that public docs are available without authentication Inspect robots.txt for accidental crawler blocks Make important pages readable without client-side JavaScript Give quickstarts and comparisons specific, descriptive titles Keep version-sensitive examples current Layer 3: Structured context narrows the choice Search gives the agent pages. Structured context gives it a compact explanation of what the SDK does and how to use it. llms.txt An llms.txt file can point an agent toward the most useful documentation and explain when the product is a good fit. A small, focused file is more helpful than a copy of the entire documentation site. For example: # Acme Payments API > Payment processing for startups and SaaS products. ## Use Acme for - Subscription billing - Usage-based pricing - A fast Node.js integration ## Quickstart npm install @acme/payments Auth: Bearer token in the Authorization header ## Important docs - Node.js quickstart: https://example.com/docs/node - API reference: https://example.com/docs/api - Error reference: https://example.com/docs/errors The goal is not to manipulate the agent. It is to remove ambiguity: what the SDK is for, which package is official, and where the authoritative instructions live. MCP servers and agent skills An MCP server can expose tools and context directly to a compatible agent. An installed skill can provide preferred workflows, configuration patterns, and error-handling guidance. These mechanisms are especially valuable for newer products. A young SDK cannot retroactively appear in years of training data, but it can provide accurate context to an agent today. Availability alone is not enough, though. Tool names, parameter descriptions, authentication instructions, and returned errors still need to be clear. Structured context only helps when an agent can understand it. Layer 4: Execution proves whether the recommendation works Coding-agent recommendations are different from ordinary chatbot mentions. The recommendation is often embedded in an implementation: npm install @acme/payments import { Acme } from "@acme/payments"; const client = new Acme({ apiKey: process.env.ACME_API_KEY, }); The agent may run the install, type-check the project, execute a request, and inspect the result. If the package name is wrong or the example fails, it has immediate evidence against the choice. Common failure modes include: Failure Likely agent response The package cannot be installed Look for an alternative package The documented import does not exist Search for another example or switch tools Authentication fails without a useful message Struggle to recover or choose a competitor The response shape differs from the docs Rewrite code, lose confidence, or abandon the integration The SDK requires an interactive step in automation Search for a more agent-compatible workflow This makes developer experience measurable in a new way. The question is not only “Can a human follow the docs?” It is also “Can an agent complete the task and recover when something goes wrong?” The highest-leverage improvements tend to be unglamorous: Keep the first install command working Publish one canonical import pattern Provide typed request and response objects Return specific, actionable errors Support non-interactive authentication and configuration Include a small end-to-end example that can actually run A recommendation from start to finish Imagine a developer asks: Add a payment form to my Next.js app. The agent might move through the stack like this: Training data: Recall several established payment SDKs and their typical integration patterns. Web search: Check current Next.js guidance, package versions, and comparison content. Context retrieval: Read an available llms.txt, MCP tool description, or installed skill. Execution: Install the selected SDK, generate the integration, and validate the result. The final recommendation is the product of the whole path. Strong historical awareness can be undone by stale docs or a broken install. A smaller SDK can make up ground with precise context and a clean, verifiable integration. How to audit your own SDK You can turn the four-layer model into a lightweight audit. 1. Test unaided model knowledge Ask multiple models what your SDK does and how to initialize it, with browsing disabled. Record incorrect package names, deprecated methods, and missing use cases. 2. Test retrieval Search for your product using the phrases a developer would use, not only your brand name. Try queries such as: “Node.js SDK for [use case]” “[your product] vs [competitor]” “How to [complete task] in Next.js” Check whether the pages an agent would need are crawlable and clearly titled. 3. Inspect machine-readable context Verify that any llms.txt, MCP server, or agent skill points to current documentation and uses unambiguous tool and parameter names. 4. Run the implementation Give a coding agent a realistic task in a clean repository. Watch the full trace: Which SDK did it choose? Which sources did it consult? Did installation succeed? Was the generated code correct? Could it diagnose authentication and API errors? Did it finish the task without human repair? Repeat the same task across agents. A passing demo in one environment is not yet a reliable developer experience. Where to start If you want a practical order of operations: Fix crawlability and broken quickstarts Publish a concise llms.txt Make install, import, and authentication examples canonical Improve error messages and non-interactive workflows Add comparison and use-case content based on real developer questions Consider an MCP server when it supports a genuine user workflow The broader lesson is simple: coding agents do not merely mention software. They try to use it. SDK discoverability therefore depends on both information and execution. You need enough public evidence for an agent to find and understand the SDK—and a reliable enough product for the agent to prove its own recommendation. If you want the expanded version of this framework, including a layer-by-layer measurement approach, read the original Lightsage guide: How Coding Agents Actually Decide Which SDK to Use. Disclosure: This adaptation was prepared with AI assistance from an original Lightsage article and reviewed by the author before publication.