What Is an AI Agent SDK? A Practical Definition

An AI agent SDK is a software development kit — a package of client libraries, helper functions, and conventions — that makes it easier to build applications where a language model can reason, call tools, hold multi-turn conversations, and return structured output. Instead of hand-rolling HTTP requests and parsing raw JSON, you install a package, call a few typed methods, and the SDK handles authentication, retries, streaming, and message formatting for you.

The short version: an SDK sits on top of a raw API. The API is the underlying HTTP endpoint that accepts requests and returns responses. The SDK is the developer-friendly wrapper around that endpoint — usually distributed as an npm package, a Python library, or similar — that turns "send a JSON payload, parse a JSON response" into "call client.messages.create()."

Why "agent" SDK specifically

Not every SDK is an agent SDK. A plain LLM SDK gives you a way to send a prompt and get text back. An agent SDK adds the pieces needed for a model to act autonomously across multiple steps:

• Tool/function calling — the SDK defines a schema for tools the model can invoke, parses the model's request to call a tool, and gives you a structured way to return the tool's result
• State/conversation management — keeping track of message history across turns so the agent has context
• Streaming — receiving tokens as they're generated instead of waiting for the full response
• Control flow helpers — loops, retries, and stopping conditions for multi-step agent behavior
• Type safety — typed request/response objects so your IDE catches mistakes before runtime

If a library only lets you send a single prompt and get a single completion, it's an LLM SDK, not an agent SDK. The distinguishing feature is native support for tool use and multi-step reasoning loops.

What's typically inside an agent SDK

Most agent SDKs, regardless of vendor, ship with a similar set of building blocks:

1. A client object initialized with an API key
2. A messages/conversation interface for sending user input and receiving model output
3. A tools interface for defining functions the model can call, with JSON schema for parameters
4. A streaming interface for consuming partial output as it's generated
5. Error handling and retry logic built in, so transient failures don't crash your app
6. Usage/metadata reporting so you can track tokens, cost, and latency per call

Here's what a typical agent-style call looks like using an SDK pattern:

const client = new Client({ apiKey: process.env.API_KEY });

const response = await client.messages.create({
  model: "claude-agent",
  max_tokens: 1024,
  tools: [
    {
      name: "get_weather",
      description: "Get current weather for a city",
      input_schema: {
        type: "object",
        properties: { city: { type: "string" } },
        required: ["city"]
      }
    }
  ],
  messages: [{ role: "user", content: "What's the weather in Lisbon?" }]
});

The SDK handles serializing this into an HTTP request, parsing the response, and — if the model decides to call get_weather — giving you a structured tool-call object instead of raw text you'd have to regex out of a string.

SDK vs. raw API vs. framework

These three terms get mixed up constantly:

• Raw API: the HTTP endpoint itself. You can call it with curl or fetch with no library at all.
• SDK: a thin, official (or semi-official) wrapper around that API in a specific language, focused on making requests and responses easier to work with.
• Framework: a higher-level layer (like LangChain or similar orchestration tools) that adds abstractions on top of one or more SDKs — chains, agents, memory stores, retrieval pipelines — often working across multiple model providers.

You don't need a framework to build an agent. Many production agents are just an SDK, a loop, and a handful of tool definitions. Frameworks add value when you need cross-provider abstraction or complex orchestration; for a single-provider agent, the SDK alone is often enough.

When you actually need an SDK vs. just the API

If you're prototyping or your language isn't well supported by an official SDK, calling the raw API directly with fetch or curl is perfectly reasonable — it's just JSON over HTTPS. The SDK becomes worth adopting once you have:

• Multiple call sites that need consistent error handling and retries
• Streaming responses you want typed, not just raw server-sent events
• Tool-calling logic that benefits from schema validation before it ships
• A team that wants IDE autocomplete instead of guessing field names

Where SubToAPI fits

SubToAPI doesn't replace an agent SDK — it sits underneath one. It turns your existing Claude access into a standard HTTPS API with application-scoped keys (sub_live_...), so any Claude-compatible SDK, or your own HTTP client, can talk to it the same way it would talk to a direct provider endpoint. That means streaming, tool use, and usage metadata all work through the same /v1/messages interface — see the messages docs, streaming docs, and tools docs for the specifics.

If you're building an agent and want a dashboard for managing keys, seats, and usage across a team, without changing how your SDK code talks to the model, pricing starts at €9/month for solo use, with team and scale tiers for shared seats. Getting a key takes a few minutes via signup, and the quickstart walks through your first authenticated request.

questions

Is an AI agent SDK the same as an AI agent framework? No. An SDK is a language-specific client library for a single provider's API — it handles requests, responses, streaming, and tool schemas. A framework sits on top of one or more SDKs and adds orchestration, memory, and multi-provider abstraction.

Do I need an SDK to build an AI agent, or can I just use the API directly? You can build an agent with raw HTTP calls — it's just JSON over HTTPS. An SDK becomes useful once you want typed responses, built-in retries, and structured tool-calling instead of manually parsing JSON at every call site.

What's the minimum an SDK needs to be called an "agent" SDK? Support for tool/function calling and multi-turn conversation state. Without those, it's a general-purpose LLM SDK, not specifically an agent SDK, since agents are defined by their ability to act across multiple steps.