Claude Agent SDK vs LotsAgent: What the 2026 Rename Actually Changes

Claude Agent SDK vs LotsAgent: What the 2026 Rename Actually Changes

In early 2026, Anthropic renamed the Claude Code SDK to the Claude Agent SDK. The package name changed, the documentation moved, and the marketing shifted from "a CLI harness for coding" to "a framework for building AI agents." That second part is the load-bearing change. It signals that Anthropic is positioning the Claude Agent SDK as a serious candidate for production agent work, not a developer tool bolted to a terminal. Developers who only saw the old Claude Code SDK are now looking at the same primitives under a new banner and asking a reasonable question: is this enough, or do I still need an agent platform?

The short answer is that the SDK is a much better starting point than it used to be, and it is still a code-level toolkit, not a platform. The Claude Agent SDK ships a production-quality agent loop, the tool use protocol, MCP integration, subagent spawning, and prompt caching. It does not ship durable execution, observability, multi-channel deployment, or the permission and identity layer that production agents need to run unattended. If your team has the engineering capacity to build and operate those layers, the SDK is a strong foundation. If you want a working agent on email, Telegram, API, MCP, and webhooks without writing orchestration code, the build-vs-buy decision looks different.

This post is a clear-eyed comparison of the Claude Agent SDK and LotsAgent for developers and product teams making that decision in 2026. It walks through what each option actually delivers, what each forces you to build yourself, and where the line falls between "I can ship this on the SDK" and "I need a platform underneath it."

What the rename actually changed

The rename was not cosmetic. Anthropic's migration guide lists the package moves: @anthropic-ai/claude-code is now @anthropic-ai/claude-agent-sdk, claude-code-sdk is now claude-agent-sdk, and the documentation has been reorganised out of the Claude Code docs and into a dedicated Agent SDK section. The Python type ClaudeCodeOptions is now ClaudeAgentOptions, the default system prompt is no longer Claude Code's, and the SDK now exposes an explicit "framework for building AI agents" framing in its overview. Anthropic describes the new positioning as covering legal assistants, finance advisors, customer support, SRE bots, and security reviewers — not just coding tasks.

For developers, the practical impact is that the Claude Agent SDK is now an official option for non-coding agent work. It exposes the same agent loop, tool harness, and context management that power Claude Code, programmable in Python and TypeScript. The migration is mostly mechanical — uninstall the old package, install the new one, update imports — with the v0.1.0 breaking changes limited to type renames and the default system prompt. If you were holding off on the SDK in 2025 because "Claude Code" sounded like an IDE plugin, that objection is gone. One operational note: starting 15 June 2026, Agent SDK usage on Claude subscription plans draws from a separate monthly credit pool rather than your interactive usage limits, which changes the cost shape for subscription-based builders.

The Claude Agent SDK: what ships, what it leaves to you

The Claude Agent SDK is built on two packages: claude-agent-sdk, the higher-level agent harness extracted from Claude Code, and anthropic-sdk-python / the TypeScript equivalent, the core API client. Together they give you a stable foundation: an iterative agent loop, built-in tools (Bash, Read, Write, Edit, Glob, Grep, WebSearch, WebFetch), MCP integration over stdio or HTTP, subagent spawning via AgentDefinition, prompt caching, and a hook system (PreToolUse, PostToolUse, Stop, SessionStart, SessionEnd) for intercepting tool calls.

What the SDK does not give you is a platform. Anthropic's own hosting guide for the Agent SDK is unusually direct about this: "Agent SDK agents are long-lived processes that spawn tool calls across many API round-trips. Without telemetry you cannot see which tools ran, how long they took, or what data they touched." That sentence is the SDK's production gap in one line — and the hosting guide is the manual for closing it yourself. The gaps the post must cover:

• No durable execution. The agent loop runs inside a prebuilt CLI binary bundled in a platform-specific wheel. There is no built-in checkpointing, no resume from the last successful step on failure, and no workflow retry layer. Anthropic documents durable execution as a feature of Managed Agents — the hosted service, not the SDK.
• No production observability. Tracing, metrics, and structured logging are not first-class. You wire them yourself through the hook system or external tooling, and you are responsible for the cost of running that pipeline.
• No cross-session state by default. Conversation history lives in the current session. Carrying context across runs is your problem. The general Anthropic Memory Tool exists as a separate primitive, not a built-in SDK capability.
• No built-in multi-agent coordination beyond subagents-as-tools. The desired pattern of a coordinator delegating to specialists with scoped write access is achievable, but the handoff semantics, retries, and shared context are application code. Anthropic's own context engineering post acknowledges that as context length grows, "models may show reduced precision for information retrieval and long-range reasoning" — which means the compaction and retrieval logic for long-running agents is your job.
• No RBAC, no per-agent permission scoping, no audit trail by default. You implement these in the application layer. The SDK has a permission_mode switch, not a permission model.
• No multi-channel deployment. The SDK runs in your process. Wiring it to email, Telegram, webhooks, and an API surface is a separate engineering project.

In other words, the Claude Agent SDK is a high-quality toolkit for developers who want to build a platform. It is not a platform.

What LotsAgent ships by default

LotsAgent is built on a different assumption: that most teams want a working agent, not a framework to assemble one. The platform handles identity, memory, tools, channels, durable execution, and observability so the developer describes the workflow rather than wiring the runtime.

Concretely, the platform delivers:

• Agent Builder — describe the agent in plain English, the platform configures identity, role, goals, and system prompt, you review before anything runs.
• Persistent memory — user-specific and agent-specific, with text storage on all plans and vector storage on Pro.
• 100+ tool integrations via Composio — Gmail, Slack, GitHub, Google Calendar, Google Drive, and hundreds more — without writing a single integration.
• MCP server — your agents can call external MCP services, and external systems can call your agents via MCP. The integration layer is covered in detail in the MCP server for AI agents post.
• Durable execution powered by Inngest — every execution is checkpointed, retries from the last successful step on failure, and the full execution history is logged. This is the difference between an agent that survives the real world and one that needs babysitting; the durable execution post goes deeper on the pattern.
• Multi-channel deployment from one setup — web UI, email (each agent has its own inbox), Telegram, API, MCP server, and webhooks. Build once, run everywhere.
• Subagents for multi-agent workflows with structured handoff and continuation, covered in agent orchestration.
• Audit trail and human control — every action is logged, irreversible actions require explicit configuration, and the HTTL (human-to-the-loop) model means agents act, humans decide. The pattern is unpacked in the agent that has no identity can't be trusted and the operating model for accountable automation.
• Any model, no lock-in — OpenRouter, OpenAI, Anthropic, or bring your own key. Switch models per agent.

The price for that completeness is that the platform makes opinions about how agents should be built, scoped, and observed. For teams that want those opinions handled, it is a force multiplier. For teams that want to own every layer themselves, it is more opinion than they want.

The 5 dimensions that actually matter for a build-vs-buy decision

A feature checklist is not useful until you weigh the dimensions that decide whether an agent runs unattended in production or dies in pilot. Here is where the two options differ on the work that matters.

1. Persistent memory and context

Claude Agent SDK. Conversation history lives in the current session. There is no built-in concept of "this user prefers short replies" or "we discussed this lead three days ago." Anthropic's Memory Tool is available as a separate primitive and gives the agent a /memories directory to read and write, but you wire it into the agent loop yourself. Anthropic's own context engineering post is candid that as the context window fills, models "may show reduced precision for information retrieval and long-range reasoning" — so the curation, compaction, and retrieval logic for long-running agents is your engineering problem.

LotsAgent. Persistent memory is a first-class capability, scoped per user and per agent. The agent remembers context across every run. You decide what gets stored, for how long, and when to forget. The deeper mechanics are in AI agent memory.

2. Tool integrations

Claude Agent SDK. You wire tools yourself. MCP support is solid, and the SDK can call MCP servers over stdio or HTTP/SSE — that is a real win and it is one reason the SDK is worth taking seriously. Beyond that, every integration against Gmail, Slack, GitHub, your CRM, your internal APIs is a project you build, maintain, and break when the upstream API changes.

LotsAgent. 100+ integrations are pre-wired via Composio. You add the tools the agent needs through the chat interface. The 100+ tools post covers the pattern.

3. Durable execution and failure handling

Claude Agent SDK. No built-in checkpointing. When something fails mid-workflow — a network timeout, an API error, a token limit — you handle the retry logic in your application. Anthropic ships durable execution as part of Managed Agents, the hosted runtime — not the SDK. Builders in 2026 typically wrap the SDK in Trigger.dev or Inngest to get the same effect, which is fine if you are already running one of those systems and not fine if you wanted to avoid the platform layer entirely.

LotsAgent. Every execution is checkpointed. The agent resumes from the last successful step on failure. The execution history is logged for debugging. This is what makes the difference between an agent you can leave running overnight and one you check on every hour.

4. Multi-channel deployment

Claude Agent SDK. The SDK runs in your process. Putting the same agent on email, Telegram, an API endpoint, and a webhook receiver is a separate engineering project on top of the SDK.

LotsAgent. One agent setup, every channel: web UI, email, Telegram, API, MCP, webhooks. The email triage workflow walks through the pattern in practice.

5. Audit, identity, and human control

Claude Agent SDK. You build this yourself. The hook system gives you interception points, but permission scoping, identity, audit logging, and human approval gates are application code. Anthropic's secure deployment guide is the closest thing to a built-in reference, and it is a checklist of things to wire, not a feature.

LotsAgent. Every agent has a unique identity with its own handle, inbox, and permission scope. Every action is logged with a full audit trail. Reversible and irreversible actions are configured separately — agents do not execute irreversible actions without explicit configuration. The operating model for accountable automation post covers the governance pattern, and the agent identity post explains why the identity layer is a first-class control, not an afterthought.

The same workflow, two paths: lead qualification

The differences are easier to see with a concrete example. Take a lead qualification workflow: a new lead arrives in Gmail, the agent reads the email, checks context against the CRM, scores the lead, drafts a personalised reply, and routes qualified leads to a human reviewer.

On the Claude Agent SDK

You would:

1. Implement a Gmail watcher (Pub/Sub or polling).
2. Wire the CRM integration through MCP or a custom tool.
3. Build the scoring logic in the agent prompt and a small Python helper for the deterministic parts.
4. Build the email-drafting tool, including the send-vs-draft guardrail.
5. Stand up a human approval step — Slack notification, review queue, or your own UI.
6. Add durable execution, retry, and idempotency so the workflow resumes correctly on failure. The SDK hosting guide treats this as your problem to solve.
7. Build the audit log.
8. Wire the API and webhook surfaces so the same workflow can be triggered from your product.

A team with two engineers and a sprint can do this. A team without that runway will be assembling it for weeks.

On LotsAgent

You describe the workflow in plain English. The Agent Builder configures the agent. You add Gmail and CRM as tools, enable the human review step for outbound replies, and set the lead-score threshold. The agent runs across email, API, and webhooks from the same setup. The audit log and durable execution are already on.

The outcome is the same. The effort and the time-to-first-real-run are not.

When the Claude Agent SDK is the right choice

The rename did not turn an SDK into a platform. If you already have the platform layer in your stack — durable execution on Inngest or Temporal, observability through your existing toolchain, deployment to email and Telegram already wired — the Claude Agent SDK slots in as a high-quality agent harness with first-class MCP support and Anthropic's tool use protocol. For teams deeply invested in Anthropic models who want full control of the runtime, who prefer to own the platform layer, and who have the engineering capacity to maintain it, the SDK is a strong default.

The legitimate SDK use cases are real:

• You are building a custom agent platform for your product and want Anthropic's agent loop as the foundation.
• You have strict requirements on model routing, data residency, or runtime behaviour that an opinionated platform cannot meet.
• You want deep integration with internal systems that are easier to wire through the SDK than to expose via pre-built connectors.
• You have the engineering capacity to operate the platform layer, including on-call coverage when something fails.

When a platform like LotsAgent is the right choice

For most teams evaluating the Claude Agent SDK in 2026, the honest answer is that they want the agent, not the framework. The platform-layer work is what kills agent projects in pilot, and the durability of that work is what determines whether an agent runs unattended or needs constant supervision.

A platform is the right choice when:

• You want the agent running on email, Telegram, API, MCP, and webhooks without assembling the deployment layer yourself.
• You need durable execution, retry, and audit logging as defaults, not as a project.
• You want human review steps and scoped permissions configured per agent without writing the guardrail code.
• You have a specific workflow to automate and want the time-to-first-real-run measured in hours, not sprints.
• You want to keep your options open on model choice — Anthropic for some agents, OpenAI for others, an open-source model for cost-sensitive runs.

The decision framework

If you are evaluating the Claude Agent SDK against a full agent platform like LotsAgent, the practical filter is five questions:

1. Do you want to build the platform layer or run the agent? If the answer is "run the agent," the SDK is the wrong starting point.
2. Do you already have durable execution, observability, and RBAC in your stack? If yes, the SDK is a clean fit. If no, you will build them.
3. What channels does the agent need to run on? The SDK runs in your process. Every additional channel is a project.
4. How much custom control do you need over the agent loop and tool use protocol? If "a lot," the SDK is the right tool. If "as long as it works," a platform gives you that without the build.
5. What is your time-to-first-real-run budget? A platform compresses this to hours. The SDK is a sprint-scale project for any non-trivial workflow.

If you are mid-build on the SDK and wondering whether to keep going, the honest benchmark is: how much of the platform layer have you already built? If durable execution, observability, RBAC, and multi-channel deployment are still TODO, the build cost from here is comparable to the switching cost to a platform. If those are already in place, the SDK is the right place to stay.

FAQ: Claude Agent SDK vs LotsAgent in 2026

Does my existing Claude Code SDK code keep working after the rename? Yes, for trivial cases. The official migration guide calls out two v0.1.0 breaking changes: the Python type ClaudeCodeOptions is now ClaudeAgentOptions, and the SDK no longer uses Claude Code's system prompt by default — you opt back in with systemPrompt: { type: "preset", preset: "claude_code" }. For most projects, the migration is a 10–30 minute find-and-replace plus dependency bump. Larger codebases with custom tool registrations or deep system-prompt assumptions should plan a half-day to verify behaviour.

How long does it actually take to move from the SDK to a platform? Most teams we have watched through this switch measure the migration in hours, not weeks. The shape of the work: rebuild the agent description in the new platform, reconnect tools, port any custom prompts, replay a few sample executions to verify behaviour, then turn off the SDK-based runtime. The hard part is usually not the move — it is identifying which platform features (durable execution, identity, audit) you were quietly rebuilding yourself and just stopping.

Can I bring my own Anthropic API key to LotsAgent? Yes. LotsAgent supports BYOK for OpenAI and Anthropic (and routes through OpenRouter for other providers), so you can keep direct control of model spend and billing. BYOK is optional — LotsAgent also provides model access by default, so a non-technical operator can start without touching keys at all. The pricing page covers the breakdown: LotsAgent runs on prepaid credits with no subscription — $1 is 1,000 credits and $10 gets you 10,000 to start, and each run's exact credit cost is shown after it executes (bring your own model key and runs cost no credits).

What does the Claude Agent SDK actually cost to run? Two layers. Model usage: token cost, billed by Anthropic directly (or via Bedrock, Vertex, Azure AI Foundry — the SDK supports all four). Platform usage: starting 15 June 2026, Agent SDK calls on Claude subscription plans draw from a separate monthly Agent SDK credit pool rather than your interactive limits, so heavy SDK use is no longer subsidised by your subscription the way it was during the Claude Code SDK era. LotsAgent has no subscription — prepaid credits ($10 for 10,000, or free with your own model key) comfortably cover a small team's first workflow and scale straight into production traffic as you top up.

Is the Claude Agent SDK open source? No. The SDK is a proprietary client library that calls Anthropic's hosted Claude API. The migration is one-way — once you build on the SDK, you are coupled to Anthropic's runtime. If model portability matters, the equivalent on LotsAgent is a per-agent model switcher (Anthropic, OpenAI, OpenRouter, BYOK) and a single API surface that does not change when you change the model underneath.

Should I wait for Anthropic Managed Agents instead? It depends on what "wait" costs you. Managed Agents gives you durable execution and Anthropic-hosted orchestration, but you give up the ability to run the agent on your own infrastructure, your own channels, or your own compliance boundary. If the workflow is internal and Anthropic-hosted is acceptable, Managed Agents is a fair middle path. If you need email, Telegram, webhooks, or an audit trail your auditor can read, the gap Managed Agents closes is real but smaller than it looks.

---

Build once. Run everywhere.

The Claude Agent SDK in 2026 is a strong foundation for teams that want to own the agent platform. For most teams, the more useful question is not "which SDK do I use" but "which platform lets me ship a working agent this week." LotsAgent is built for the second question. You describe the workflow, the platform handles the runtime, and your agent runs across every channel you actually use — email, Telegram, API, MCP, webhooks — from the same setup.

Create your first agent free at lotsagent.com. No subscription and no infrastructure to wire up — prepaid credits ($10 for 10,000) when you are ready to run, or bring your own model key.

---

Sources

• Anthropic — Agent SDK overview
• Anthropic — Migrate to Claude Agent SDK
• Anthropic — Hosting the Agent SDK
• Anthropic — Securely deploying AI agents
• Anthropic — Effective context engineering for AI agents
• Anthropic — Introducing the Model Context Protocol
• Trigger.dev — Claude Agent SDK setup guide
• Hatchworks — Claude Agent SDK and Managed Agents: Where to Run Production