Agentic Data Engineering Resources

Resource

What Is an Agent SDK, and How Is It Used in Production Systems?

Learn what an Agent SDK does, how major frameworks compare, and what infrastructure SDK-based AI agents need to work in production systems.

Pedro Lopez

June 24, 2026

Last updated September 3, 2026

Summarize with AI:

An agent SDK is a software development kit that gives developers structured primitives for orchestration, tool execution, state management, and safety controls. It helps teams build AI agents without writing low-level reasoning loops from scratch, but it does not replace the data layer, the integration platform, or the deployment runtime that production systems still require.

TL;DR

An Agent SDK manages orchestration, tool execution, state management, and safety controls so developers do not have to write low-level reasoning loops from scratch.
In production systems, the SDK handles agent behavior at the application layer, but not at the data layer, the integration platform, or the deployment runtime.
Major agent SDKs differ in orchestration style, persistence, protocol support, and durable execution, but they stop short of covering the full production stack.
Whether agents work in production depends on the infrastructure beneath the SDK, including context, authentication, and data access.

What Does an Agent SDK Actually Do?

An agent SDK (Software Development Kit) owns the agent loop: the recursive cycle of model invocation, response inspection, tool dispatch, and re-invocation. Without an SDK, developers building AI agents write roughly 30 lines of boilerplate to manage that cycle manually. They handle logging, retry logic, and termination conditions themselves. One call collapses that work.

Five capabilities define what an SDK provides out of the box:

Agent loop management. The SDK runs the core reasoning cycle. It calls the model, inspects the response, determines whether to execute tools or return a final answer, and repeats until the task completes or a turn limit is reached. For example, OpenAI Agents SDK reduces this to Runner.run_sync(agent, query).
Tool integration. The SDK handles tool dispatch. It auto-generates JSON schemas from function signatures, dispatches tool calls, validates arguments, and feeds errors back to the model as tool results rather than surfacing unhandled exceptions. How tools work in agent systems covers the full lifecycle.
Multi-agent coordination. Handoffs and delegation allow one agent to transfer control to another while preserving the conversation history. The SDK manages context switching without developer code for the transition itself.
Guardrails and safety checks. Input and output validators check boundaries in the agent run sequence. They enforce content policies, format constraints, or domain-specific rules.
State and session management. Session management can track conversation history within a run. Some SDKs include built-in checkpointing.

The Functional Dividing Line Between SDKs and API Clients

A raw API client library (the openai Python package, the anthropic SDK) wraps individual HTTP calls to a model provider. It exposes client.messages.create() with tools, and the developer writes the agent loop: calling the API, handling tool-use blocks, appending results, and looping until the model signals completion.

An agent SDK owns that loop. Use the SDK when your application server needs orchestration, tool execution, approvals, and state management. Use the raw API client for single-inference tasks or multi-vendor model stacks where no single SDK abstracts across providers.

What Are the Major Agent SDKs Available Today?

Several SDKs are commonly used for production agent development today, each built around a different architectural philosophy. The table below compares them across key dimensions, including support for the Model Context Protocol (MCP) and the Agent-to-Agent (A2A) protocol.

SDK	Vendor	Orchestration	Built-in State Persistence	MCP Support	Multi-Model Support	Durable Execution
OpenAI Agents SDK	OpenAI	Agent loops, handoffs, guardrails	No built-in; developer-managed	Hosted MCP support	OpenAI models by default, extensible via custom providers	Via Temporal, Dapr, Restate, DBOS
Claude Agents SDK	Anthropic	Managed server-side loop	Server-managed state	Native (Anthropic co-created MCP)	Claude models primarily; extensible via custom configuration	Via Claude Managed Agents
LangGraph	LangChain	Stateful cyclical graphs	Built-in checkpointing (Postgres, Redis, SQLite backends)	Via LangChain ecosystem	Multi-model via LangChain	Built-in checkpointing
CrewAI	CrewAI	Role-based agent teams	Pydantic BaseModel for typed state; ChromaDB, SQLite for persistence	Native MCP support	Multi-model via LLM provider integrations	Manual durability
Pydantic AI	Pydantic team	Type-safe agent definitions	Explicit message history	MCP and A2A	Multi-model support	Automatic durability
Google ADK	Google	Multi-system agents	Vertex AI Engine	Vertex AI Engine	Gemini models primarily; multi-model via Vertex AI	Managed via Vertex AI

OpenAI Agents SDK uses four primitives for multi-agent workflows: agents, tools, handoffs, and guardrails. Claude Agents SDK provides the infrastructure to build agents with Claude, including support for tool use and sandboxed execution. LangGraph models agents as explicit directed graphs inspired by Google's Pregel system, which gives developers maximum control over state transitions. CrewAI reduces setup time for multi-agent prototyping with role-based agent teams. Pydantic AI ergonomics bring FastAPI-style ergonomics and type-safety guarantees, validating every input, output, and dependency through Pydantic models. Google ADK targets multi-agent systems and supports managed deployment through Vertex AI.

Framework choice matters less than most comparison articles suggest. The data infrastructure beneath the SDK determines whether agents work on real enterprise data.

How Do Agent SDKs Work Inside a Production System?

The runtime loop generally follows a similar pattern across many agent SDKs. The implementation differs by SDK, but the sequence stays consistent.

Prompt construction: The SDK assembles the system prompt, conversation history, tool schemas, and current input.
Model call: The SDK sends the assembled prompt to the model provider and receives text content, tool call requests, or both.
Response inspection: If the model produced a final output with no pending tool calls, the loop terminates. If the model requested a handoff, the SDK switches agents and re-enters the loop.
Tool dispatch: The SDK parses tool names, validates JSON arguments against schemas, and executes tool functions.
Result injection. The SDK appends tool results to conversation history, increments the turn counter, and returns to Step 1.

A long-running agent that makes many tool calls and then encounters an error illustrates why stateless retry logic fails. Without durable execution, the agent restarts from step one and reexecutes completed tool calls, including those that have real-world side effects. The LLM may also produce different tool selections because inference is non-deterministic.

The OpenAI Agents SDK documentation describes core features such as agents, handoffs, guardrails, tracing, and support for built-in and custom tools. OpenAI documents these integrations rather than building native durability. That is the clearest articulation of where the SDK boundary ends.

Where Does SDK Responsibility End and Infrastructure Begin?

The boundary between SDK code and infrastructure becomes concrete when mapped against specific production requirements.

Production Requirement	SDK Layer (Developer Code)	Infrastructure Layer (Separate Systems)
Agent reasoning loop	SDK defines the loop, step sequencing, and handoff logic	The model provider supplies the LLM inference
Tool definition and calling	SDK registers tools, validates schemas and routes calls	Integration platform or agent connectors handle auth, pagination and rate limits
State persistence across sessions	Some SDKs provide checkpointing; others require custom implementation	A database or durable execution system stores state
Multi-source data access	SDK issues tool calls or queries per source	Context layer or integration platform unifies data across sources
Authentication to SaaS APIs	SDK passes credentials to tool calls	Credential vault or managed auth handles OAuth refresh, token rotation
Token budget management	SDK controls prompt construction and response handling	Pre-materialized context layer reduces token volume before the SDK sees it
Multi-tenant data isolation	SDK enforces tenant context per request	Infrastructure enforces workspace-level isolation and row-level permissions
Security boundaries and guardrails	SDK applies input/output validation and guardrail checks	Runtime middleware or deterministic safety layer enforces hard boundaries

Production documentation draws the canonical line: the harness (prompts, tools, skills) supports the model and tool-calling loop, while the runtime (durable execution, memory, multi-tenancy, observability) keeps the agent running in production. The SDK owns the reasoning loop. Infrastructure owns everything that sustains that loop across time, users, and failures.

The production decision that SDK documentation consistently ignores is whether to assemble context at runtime or pre-materialize it. Runtime API assembly means the agent fetches data in real time for each query by calling external APIs at invocation time. Pre-materialized context means data is processed, indexed, and stored in advance, so the agent queries a prebuilt index instead. Anthropic's published guidance on context engineering for agents describes a tradeoff in which runtime exploration is slower than retrieving pre-computed data.

Why SDK-Based Agents Fail in Production

Even with a well-chosen SDK, agents tend to break in production for reasons that sit beneath the reasoning loop. These failure modes most often occur when context is assembled at runtime, but they apply to any SDK-based agent that lacks a dedicated data, credential, and observability layer. Each one compounds as conversations grow longer, tool counts increase, and concurrency rises, which is why pre-materialized context has become a common pattern in production agent systems.

Token Budget Exhaustion

An arXiv study measuring actual token consumption across SWE-bench Verified found an average trajectory of 48,400 tokens across 40 steps per task, with tool messages accounting for 30,400 of those tokens. A GitHub issue filed against the MCP specification repository classifies token bloat from tool schema redundancy as a recognized protocol-level problem.

The problem worsens under retry conditions: once tools execute, the result is concatenated into the trajectory and retained for subsequent predictions, so each retry of a multi-step workflow accumulates more tokens in the context window.

Authentication Complexity and Rot

Authentication failures become harder to diagnose as systems add more workers, more providers, and more concurrent refresh paths. Token expiry, revoked consent, and provider-side limits can all break tool access unless credential handling sits outside the agent loop.

The same fragility shows up as authentication rot over time: when a developer disconnects an integration from their provider's security settings, or an administrator rotates credentials during a security audit, the agent's refresh attempt can be permanently rejected without surfacing as a clear error. OAuth scope enforcement and credential handling need to sit outside prompt-level instructions.

Latency Compounding

Latency in agentic systems often includes both model inference and tool execution overhead, and techniques such as parallel tool calling can reduce the total request time. Per-turn latency tends to increase as conversation prefix length grows, so long-running sessions feel progressively slower even when individual tool calls stay fast.

Reliability Degradation From Compounding Errors

Agent observability tooling built for binary failures (crashes, timeouts, 500 errors) overlooks how agents actually degrade: incorrect tool selection, stale memory and dropped context during handoffs. SDK traces stop at the tool call boundary, so these failures go undetected until outputs visibly break. These failures occur because the SDK assumes context infrastructure already exists. SDKs solve one layer. Production needs more layers.

How Airbyte's agentic platform Fit Into an SDK-Based Production System

Agent SDKs handle the reasoning loop, but they assume a data and authentication layer already exists beneath them. Airbyte's agentic platform fill that gap by serving as the context layer SDK-based agents depend on, pre-materializing business data and managing the credentials that keep tool calls running reliably across users and sessions. Here is how the pieces fit together:

Pre-materialized context: Airbyte's agentic platform pull business data from connected sources into the Context Store, so agents query indexed search instead of crawling APIs at runtime.
Managed authentication. OAuth flows, token refresh, and credential storage are handled outside the agent loop, removing a common source of production failures.
Multiple access surfaces. Agents can connect through the Web app, Agent MCP, Airbyte's Agent SDK, Agent CLI, or API, so the choice of SDK does not constrain how agents access data.
Centralized policy and routing. Teams running multiple MCP-compatible agents can route through the MCP Gateway for unified policy enforcement and authentication.
Measured efficiency gains. In benchmarks, agents using the Context Store required around 40% fewer tool calls and up to 80% fewer tokens compared to native vendor MCPs.

Teams building on these primitives can explore the For Developers hub for SDK references, MCP Gateway setup, and connector patterns.

Conclusion

Every SDK in the current landscape stops at the same boundary: data access, credential management, and context freshness are left to the developer. The production decision that determines whether agents work on real enterprise data is what data infrastructure sits beneath the SDK rather than which orchestration primitives sit on top of it.

Airbyte's agentic platform connect to the SaaS tools a company runs on, unify that data in the Context Store, and make it available through every interface an SDK-based agent can consume: the Web app, Agent MCP, Airbyte's Agent SDK, Agent CLI, or API. Managed OAuth, per-tenant isolation, and pre-materialized indexes mean agents query consistent business context instead of crawling live APIs on every turn.

Talk to sales to see how Airbyte's agentic platform pre-materializes your SaaS data so SDK-based agents query indexed context instead of crawling live APIs, or try Airbyte's agentic platform to start building against the Context Store today.

Frequently asked questions

Is an Agent SDK the Same as an API Client Library?

An API client library wraps individual HTTP calls to a model provider, exposing client.messages.create() and leaving the developer to handle the loop. An agent SDK owns the full cycle: orchestrating tool execution, managing handoffs between agents, applying guardrails, and persisting state across turns. The dividing line is whether the framework runs the agent loop or only the underlying request.

Can I Use Multiple Agent SDKs in the Same Production System?

Most teams standardize on one SDK per agent type to keep observability and state management consistent. Protocol standards like MCP coordinate across frameworks, letting agents built with different SDKs consume the same tool servers. Routing those servers through a shared layer, such as the MCP Gateway, keeps auth, policy, and rate-limiting consistent across SDKs.

Do Agent SDKs Handle Authentication to Enterprise SaaS Tools?

SDKs typically handle credentials in the SDK or connector layer, using automatic credential management and keeping them out of the agent's tool-call context, rather than accepting credentials at each invocation and passing them through to tool calls. They do not manage OAuth refresh, token rotation, or credential storage. Those concerns belong to a credential vault or managed integration platform that sits beneath the SDK.

How Does an Agent SDK Differ From a Workflow Automation Tool?

A workflow tool executes predefined sequences, with the developer determining which tools run and in what order. An agent SDK lets the model dynamically decide which tools to call based on reasoning over the current state. Workflow tools are predictable but rigid; SDK-driven agents are flexible but require infrastructure for state, guardrails, and observability to behave reliably.

What Data Infrastructure Do SDK-Based Agents Need in Production?

At minimum, SDK-based agents need authenticated SaaS API access with managed OAuth lifecycles, a context layer that provides unified, indexed data so agents can query prebuilt indexes, and credential management with automatic token refresh and per-tenant isolation. Without these, agents face token bloat, authentication rot, and compounding reliability degradation. The SDK supplies the reasoning loop; infrastructure keeps that loop running across users, sessions, and failures.