LangSmith is a good tool. It's just not a prompt management tool. Teams that try to use it as one discover that distinction the hard way — usually when they need to roll back a bad prompt at 11pm and find out there's no production rollback button.
What LangSmith is actually built for
LangSmith is an observability and tracing platform for LLM applications. Its core job is to log runs, trace chains, and help you debug why a particular invocation went wrong. That's genuinely useful work. If you're running LangChain pipelines and want to inspect what happened at every step of a chain, LangSmith is purpose-built for that.
Prompt storage was added because it was a natural fit for the workflow: you're already logging runs, so why not store the prompts that drove them? But "natural fit for the workflow" and "built for the job" are different things. A hammer can drive a screw if you try hard enough.
The versioning problem
Prompt versioning in LangSmith is shallow. You can save a prompt and you can see previous saves, but the interface isn't designed around the version-as-first-class-citizen model that prompt management actually requires. There's no side-by-side diff between two arbitrary versions. There's no clear signal about which version is in production right now versus which version you're experimenting with.
This matters more than it sounds. As we covered in why you should version control your AI prompts, the failure mode isn't that you lose prompts — it's that you lose context. You had a prompt that worked well for six weeks. Someone edited it. Now quality has dropped and nobody can articulate what changed, because there's no diff to look at. You're reconstructing from memory and Slack threads.
Dedicated prompt management tools treat each edit as a discrete version with a full history. You can compare version 12 against version 7 directly, see exactly what changed line by line, and publish any previous version back to production in one click. That workflow doesn't exist in LangSmith because it wasn't designed around it.
No real production promotion model
This is where the gap becomes expensive. In a real deployment, you need a clear separation between the prompt you're editing and the prompt your users are hitting. You need to be able to say: "this is version 14, it's live in production, and if it degrades I can roll back to version 13 in 30 seconds without a code deploy."
LangSmith doesn't have that model. Prompts live in LangSmith's hub, and you pull them by name. But there's no formal concept of a "production version" that's separate from "latest." If you're pulling the latest version of a prompt by name, any edit immediately becomes what your users get. If you want environment separation, you're managing it yourself — with naming conventions, with multiple copies of the prompt, with whatever workaround your team invents.
That's not prompt management. That's prompt chaos with better logging.
Compare that to fetching a prompt via a proper API with explicit version control behind it:
import { SuperPrompts } from 'superprompts';
const sp = new SuperPrompts({ apiKey: process.env.SUPERPROMPTS_API_KEY });
// Always serves the published production version
// Roll back in the UI and this call immediately returns the previous version
const prompt = await sp.getPrompt('customer-support-agent');The call itself is simple. The power is what happens server-side: there's a designated production version, you can change it without touching code, and you can reverse that change instantly. That's the feature. The API call is just the interface to it.
Cross-provider evaluation is missing entirely
Here's a scenario that's increasingly common: your team is evaluating whether to switch from GPT-4o to Claude 3.5 Sonnet for a specific use case. You want to run your current prompts against both models and compare outputs against expected answers.
LangSmith doesn't support this. It's tied to the LangChain ecosystem, and its evaluation tooling is focused on chain evaluation, not cross-provider prompt comparison. You can run evals, but you're running them within whatever provider setup you've already configured. Swapping providers for a comparison test is a code change, not a UI action.
This matters because provider switching is no longer exotic — it's a normal part of keeping AI products competitive. As we looked at in production AI prompt testing, the prompts that work well in development against one model often behave differently against another. You need a tool that treats multi-provider testing as a first-class feature, not an afterthought.
Tools built specifically for prompt management let you define a question and an expected answer, then run the same prompt against OpenAI, Anthropic, Gemini, and Mistral simultaneously. You see which model handles your prompt best without writing a single line of evaluation harness code. LangSmith has nothing comparable.
The observability-first design shapes everything
The root issue isn't a missing feature list. It's that every design decision in LangSmith flows from its core purpose: tracing and debugging. That makes it excellent at what it does. But prompt management requires a different set of design priorities.
Prompt management needs the editor to be the center of the experience. It needs version history to be surfaced prominently, not buried. It needs the concept of "published to production" to be an explicit, auditable action. It needs evaluation to be something you run before you publish, not after you debug a failure.
LangSmith puts traces at the center. Prompts are an adjacent concern. When you try to run a prompt-management workflow inside a tracing tool, you end up fighting the product's mental model at every step.
What the right tool looks like
A prompt management tool treats the prompt itself as the unit of work. Editing, versioning, evaluating, and publishing are all first-class operations in the UI. The API exists to serve whatever is currently designated as the production version — and that designation can change without a deploy.
SuperPrompts does this with a section-based editor where you can organize prompts into structured pieces, compare any two versions side by side, and publish or roll back from the version history in one click. The multi-provider evaluation means you can test the same prompt against OpenAI and Anthropic before it ever goes live, rather than discovering the regression in production traces.
If you're already using LangSmith for tracing — keep using it. It's good at tracing. But don't let it become your prompt store by default just because it was the tool you already had open. That's how you end up with prompt management that breaks at scale and a rollback story that's just "edit the prompt and hope."
The wrong tool for the job doesn't become the right tool because you've used it long enough. Prompts are production artifacts. Treat them that way.
SuperPrompts gives every prompt a full version history with side-by-side diffs, one-click production rollback, and cross-provider evaluation before you publish. Try it free and manage your prompts like the production artifacts they are.