Parlant vs Claude Agent SDK
Parlant vs Claude Agent SDK
The Claude Agent SDK is the toolkit behind Claude Code. It gives an agent tools, a loop for working through a task, and a record of what it has done, so it can investigate problems, edit files, and run commands.
Parlant is built for a different job: conversations with your customers that follow your business rules.
Your coding agent can build a customer-facing agent on either. The difference is how much it has to invent and get right on its own before customers can rely on the result.
- Why your coding agent might suggest the Claude Agent SDK, and what Parlant does differently
- Whether you can keep using Claude models with Parlant
- What your coding agent would have to build, and what that means for your customers
- What each costs to run, and when the Claude Agent SDK is the better choice
If your coding agent suggested the Claude Agent SDK, these are probably your questions:
My coding agent suggested building on the Claude Agent SDK. Why would I use Parlant instead?
The SDK behind Claude Code is a good choice for what it was designed for: agents that read files, edit code, and run commands to complete a task. Talking with your customers is a different job. The agent has to follow your policies while the customer changes topics, pushes for exceptions, or changes their mind, and every promise it makes has to be one your business can keep.
Parlant is built for that job. You describe how the agent should behave as policies, in plain language, and your coding agent adds them to your project. On every turn, Parlant works out which of your policies apply and keeps them in front of the model. It can check an action, like a refund, before it runs, and check a reply before the customer sees it. When a person needs to step in, they can take over the same chat. With the SDK, your coding agent would have to design and build all of that first.
It's also faster for you. On a general agent framework, your coding agent spends its time, and yours, designing and debugging how support conversations should work. On Parlant it starts from that design and goes straight to your rules, so you get to a working agent you can test much sooner.
“Parlant gave us a robust foundation to automate our support without compromising on quality. The speed at which we saw value was truly remarkable.” Arpit Parashar, Deputy Manager, Greenko Group. Read the homepage testimonial.
Can I keep using Claude models with Parlant?
Yes. Parlant works with Claude models directly through Anthropic, and through OpenRouter, its default provider, whose default setup already uses Claude models for many replies. You can also use OpenAI, Gemini, and others, and choose a different model for each job: for example, a fast, inexpensive model for routine replies and a stronger one where the stakes are high. You pay the model provider directly, at its usual prices.
What would my coding agent have to build with the SDK, and why does that matter for my customers?
The SDK gives you permissions that decide which tools may run, and hooks where you can add your own checks. Those are places to put customer-service decisions, not the decisions themselves. Your coding agent would have to design them: which of your policies apply right now, whether the customer actually agreed to this action, whether the action succeeded, and what the agent may tell the customer about it.
That's where your customers feel the difference. Say your policy is "cancel an order only if it hasn't shipped." A tool permission can allow cancellations, but it can't tell whether this order has shipped. And in a long chat, if a summary of the earlier conversation drops the "only if it hasn't shipped" part, a later check may approve the wrong cancellation. Parlant keeps confirmations and policy details in its summaries, reconsiders your policies after it looks up the shipment, and only lets a reply confirm actions that actually happened.
You could have your coding agent build these pieces one at a time. But they depend on each other, so building a few of them puts you on the path to building Parlant yourself, and you'd discover each edge case when a customer runs into it. A coding agent can write the code; it can't tell you what the design should be.
Will the agent follow my rules when customers push back, mix topics, or change their minds?
That's what Parlant is designed for. A customer might ask about a refund, mention that the item arrived damaged, and ask to change their address, all in one message. Parlant brings in the policies for each of those as they come up, and keeps them together in one agent, so the answer to one request doesn't contradict another. When the customer pushes for an exception, your policies are still in front of the model on every reply. Where the wording matters, approved responses keep the agent saying it your way.
The SDK's agent loop is built to work through a task until it's done. Deciding which of your policies apply as a conversation wanders, and keeping them consistent across topics, is design work your coding agent would take on.
What does each one cost to run?
Neither charges a fee per conversation or per resolution. With both, you pay your model provider for what you use, at its usual prices.
Parlant's extra checks add model work only where you turn them on. Checking a reply, for example, takes another model call and makes the customer wait for the finished, checked answer. So you can turn checks on only for the situations that need them, and let adaptive effort spend more only when a conversation becomes sensitive. Spend management tracks what each conversation costs and can cap it. If you'd rather not run servers, the Dashboard hosts your agent for a flat monthly fee per workspace, free while you develop; see pricing.
With the SDK, the cost is the model usage plus whatever your coding agent builds and your team keeps maintaining: the rule checks, the conversation history your customers return to, and the handoff to people. The fair comparison is against the Claude Agent SDK agent you would actually put in front of customers, with those protections in place.
If you have developers on the team: Parlant also lets you customize its built-in prompts and replace parts of the engine without forking it.
When is the Claude Agent SDK the better choice?
When the agent's job is to do work rather than talk with customers: investigating problems, editing files, running commands, or automating internal tasks. That's what the SDK was built for, and it brings Claude Code's tools and agent loop to that work. If your agent mostly works inside your systems, with little back-and-forth with customers, the SDK may serve you better. Parlant fits when the conversation is the product, and the agent has to follow your policies with customers who don't always cooperate.
How can I compare them on my own service?
Pick one part of your service that matters, like refunds or order changes, and ask your coding agent to build it both ways: once in a Parlant project and once with the SDK. Use the same policies and test versions of the same tools.
Then talk to both the way real customers do. Ask for two things at once, change your mind halfway, push for an exception your policy doesn't allow, and ask the agent to confirm something it hasn't done yet. Compare what each one did and said, how long you waited for replies, and what each conversation cost. In Parlant, you can run these conversations as simulations in the Dashboard and see which policies shaped each reply.
Finally, change one of your policies, and see how much work each version needs and whether conversations that worked before still do. Your test may also show that the Claude Agent SDK fits your case better, which is worth knowing too.
Building a Customer-Facing Agent
The following illustration compares coverage of real-world customer-facing needs, as of September 2026. It covers the Claude Agent SDK in Python and TypeScript, which you host in your own application. Each explanation says what's supplied and, for lower scores, what your coding agent would still need to build.
Claude Agent SDK
Parlant
The readiness levels indicate how well each feature is prepared for customer-facing use cases.
- 1/3: Requires adaptation. The feature supplies a foundation, but its approach needs substantial adaptation for real-world customer conversations.
- 2/3: Needs customization. The feature fits the customer-facing need but requires a focused extension of its existing behavior. The explanation names that gap.
- 3/3: Comprehensive. The feature covers the customer-facing need, including practical challenges and common edge cases. Your business rules and integrations still need setup and testing.