The 4 Layers That Decide Which SDK a Coding Agent Uses

Jun Liang Lee — Sun, 06 Sep 2026 22:17:43 +0000

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.

DEV Community: Jun Liang Lee