Continuous improvement in agentic systems

LangSmith sits at the top of most shortlists, and it deserves to. It is also only one layer of a loop that has five other stages, and the stage most teams skip is the one that decides whether the agent gets better.

Introduction

A regional medical equipment distributor put an order intake agent into production last spring. It read inbound purchase orders from email and fax, matched line items to catalog SKUs, checked contract pricing, and drafted the order in the ERP for a human to approve.

The demo was excellent. Six weeks in, approval rates were high and the operations team was happy. By month four they had quietly stopped trusting it. Approvers were opening every draft line by line again, which meant the agent had become a slower version of typing.

The engineering team had dashboards. They knew latency, token spend, and error rate. What they could not answer was the only question that mattered: when did it get worse, and which change caused it?

This is the most common failure pattern in production agent work, and it is not a tooling gap. LangChain’s State of Agent Engineering survey, run across roughly 1,300 practitioners at the end of 2025, found that observability adoption was running far ahead of evaluation adoption: close to nine in ten respondents had instrumented their agents, while only about half were running evals. Traces tell you what happened. Evals are what let you say a change made the system better.

This piece lays out the full loop, every category of tooling that can run it, and the honest tradeoffs. Some of it is opinionated. All of it comes from shipping agentic systems into environments where a wrong answer costs somebody money.

What continuous improvement actually means here

The distinction matters because the two get sold together and budgeted together. A dashboard showing p95 latency and cost per session is genuinely useful and completely silent on whether the agent picked the right SKU. Agent quality is a semantic property. It needs a semantic measurement, applied repeatedly, to the same inputs.

The loop has six stages. Teams that run all six improve predictably. Teams that run three of them improve by luck.

Agent runs fail in the middle, not at the edge. Tool call failures, context truncation, and unbounded retry loops are the dominant incident classes, and none of them surface as an application error.

Stage 1 and 2: instrumentation you will not have to rip out

Standard application performance monitoring cannot see an agent. It sees an HTTP request that took eleven seconds and returned a 200. It cannot see that the agent called the pricing tool with a malformed contract ID, retried three times, silently fell back to list price, and answered confidently.

Agent-aware instrumentation means one span per meaningful step, arranged as a tree that mirrors the actual execution path. The OpenTelemetry GenAI semantic conventions now define exactly that shape. The vocabulary covers the full agent lifecycle, with operations for creating and invoking an agent, invoking a workflow, planning, model calls, retrieval, memory operations, and tool execution. As of mid-2026 the MCP conventions live in the same repository, so a Model Context Protocol tool call shares a trace vocabulary with the agent that issued it.

Agent runs fail in the middle, not at the edge. Tool call failures, context truncation, and unbounded retry loops are the dominant incident classes, and none of them surface as an application error.

Sampling is a design decision, not a default

Two choices here shape everything downstream. First, what counts as a trace. One trace per session versus one per conversation turn is the same traffic priced several times apart, and it also changes what a regression looks like in your data. Second, what you keep. Head sampling throws away the failures you most need. Tail sampling, where you keep every run that errored, exceeded a latency budget, hit a retry ceiling, or received negative user feedback, plus a random slice of everything else, is the pattern that holds up at volume.

Capture outcomes too, not just traces. The approver clicking edit before submitting the ERP draft is the highest quality label your system will ever produce, and it is free. Wire that signal back into the trace as feedback on day one, not in month six when someone asks how you know it works.

Stage 3: error analysis is the stage everyone skips

Here is the uncomfortable part. Before any platform helps you, somebody on your team has to read traces. Not skim a dashboard. Read a hundred failed runs end to end, write a one-line description of what went wrong in each, then group those descriptions into a taxonomy with names.

For the distributor’s order agent, that exercise produced seven named failure modes in an afternoon:

• Unit-of-measure mismatch. Catalog in boxes, purchase order in each.
• Contract ID normalization. Customer writes it with dashes, tool expects without, retry loop with identical arguments.
• Substitution overreach. Discontinued SKU replaced with a similar item nobody authorized.
• Backorder silence. Partially available lines drafted as fully available.
• Multi-page fax truncation. Page two never reached context.
• Freight terms dropped. Present in the email body, absent from the draft.
• Confident list pricing. Pricing tool failed, agent answered anyway.

Those seven names are the most valuable artifact in the whole program. Every one becomes an evaluation case. Every one becomes a metric you can chart over time. Every one gives a product owner language for a conversation that used to be “it feels worse lately.”

Tooling accelerates this without replacing it. Several platforms now cluster traces automatically into recurring behaviors, which turns ten thousand events into a short list of things your agent actually does. LangSmith ships unsupervised topic clustering and error grouping in its insights layer. Laminar built its product around online clustering of extracted signal events. Arize Phoenix has embedding-based clustering and drift detection from its ML monitoring lineage. Use them to find candidate clusters faster. Do not use them to avoid naming the clusters yourself, because the name is where the domain knowledge enters the system.

Stage 4: three layers of evaluation, not one

Agent evaluation is not a single score. Scoring only the final answer tells you an order draft was wrong without telling you that retrieval returned the right catalog page and the model ignored it. Three layers, each answering a different question.

Offline evaluation prevents the regressions you have already named. Online evaluation finds the ones you have not. Neither substitutes for the other.

The judge needs evaluating too

LLM-as-judge is load bearing in every serious agent program, and it is routinely deployed unvalidated. A judge is a classifier. Treat it like one. Label a few hundred examples by hand, measure agreement between your judge and those labels, and report the agreement number alongside the eval score. If a judge agrees with your domain expert seventy percent of the time, a three point movement in your eval score means nothing at all.

Two things reliably improve judge quality: binary or low-cardinality rubrics rather than one-to-five scales, and per-failure-mode judges rather than one judge asked to assess overall quality. “Did this draft carry the correct unit of measure?” is a question a small model answers reliably and cheaply. “Is this a good order draft?” is not.

Regression gates in CI

The part teams underrate before adopting and lean on hardest after: wiring evals into continuous integration so a pull request that drops the score below threshold does not merge. LangSmith integrates with pytest, Vitest, and GitHub workflows for exactly this. Braintrust is built around the same loop. promptfoo, DeepEval, and Inspect AI give you the same gate with no platform at all, as a test suite in your repository.

Once a prompt change is gated like a code change, the nineteen-changes-in-four-months problem stops happening. Not because the team ships less, but because each change carries a number.

Stage 5: what you actually change

An eval score tells you the system is worse. It does not tell you which layer to touch. Teams burn quarters here, usually by reaching for the most expensive intervention first because it feels like the most serious one.

Work up a ladder, cheapest and most reversible first. Change one rung at a time, and re-run the same evaluation set after each change. That discipline is the entire difference between a system that compounds and a system that oscillates.

The ladder is ordered by cost and blast radius. Teams that start at the top usually cannot tell afterward whether it helped.

Rungs one and two do most of the work

The contract ID retry loop in the distributor case was a rung two fix. The tool accepted a normalized identifier, the description did not say so, and the model had no way to learn that from three identical failures. Adding the format to the tool description and making the tool normalize defensively removed an entire failure class. There is an active research line on exactly this, rewriting tool descriptions and instructions so agents select and call tools more reliably, and the practical version of it is a Tuesday afternoon.

Rung five is architectural

When one agent carries too many responsibilities, no prompt edit rescues it. The fix is structural: split the work into bounded domains, each with its own scoped facts, scoped documents, scoped actions, and its own evaluation set. A bounded domain is testable. A general assistant is not. This is the core of how we structure agentic systems at Bitcot, and it is the reason our evaluation sets stay meaningful as scope grows.

Rungs six and seven, honestly

Automated prompt optimization has become genuinely useful. GEPA, presented at ICLR 2026 and built on DSPy, runs your system on a minibatch, reads the execution traces and a textual feedback signal, and evolves prompt candidates along a Pareto frontier instead of using policy gradients. The published results report outperforming the GRPO reinforcement learning baseline by up to twenty percent while using far fewer model rollouts, and it has since been applied across a wide range of domains including clinical text and code generation.

Fine-tuning and reinforcement learning on collected traces sit at the top for a reason. They are the most expensive to run, the slowest to iterate, and the hardest to reverse when the underlying model is deprecated. They are the right answer for narrow, high-volume, stable subtasks where you have thousands of verified examples. They are almost never the right first answer.

Stage 6: gate, release, and watch

The release mechanics are ordinary software engineering applied to a non-deterministic system:

• Version everything that shapes behavior. Prompts, tool schemas, retrieval config, and model identifiers belong under version control with the code, not in a console someone edits live.
• Gate the merge on the eval score, with an explicit threshold and an explicit owner who can override it in writing.
• Shadow before canary for changes to tools with write access. Run the new version against live inputs, compare to the current version, write nothing.
• Canary with online evaluation attached, so the rollout decision reads a quality signal rather than an error rate.
• Keep the failure taxonomy as a live dashboard. Seven named metrics beat one aggregate quality score, because only the named ones tell you what to do next.

And then the loop closes. New traffic, new traces, new clusters, new cases in the set.

The options: LangSmith first, then everything else

Now the tooling question. The category has more credible entrants than it did eighteen months ago and fewer independent companies, which is a combination worth understanding before you sign anything.

LangSmith

LangSmith is the observability and evaluation platform from the LangChain team, and it is the default tracing and evaluation backend if you build on LangChain or LangGraph. It is framework agnostic in practice, with SDKs across several languages and OpenTelemetry ingest, so teams on the OpenAI SDK, the Anthropic SDK, the Vercel AI SDK, LlamaIndex, or custom loops use it too.

What makes it the strongest single-vendor answer for the full loop:

• It covers all six stages in one place. Tracing with thread-level grouping, dataset collection from production traces, offline experiments with side-by-side comparison and regression flags, online LLM-as-judge and heuristic scoring on live traffic, human annotation queues, and alerting.
• CI gating is first class. pytest, Vitest, and GitHub workflow integrations mean an eval score blocks a merge the way a unit test does.
• Failure clustering. The insights layer performs unsupervised topic clustering and error analysis over traces, which cuts the manual triage pass down considerably once you know what you are looking for.
• It kept expanding through 2026. A unified cost view spanning retrieval, tool execution, and downstream API spend rather than model calls alone; a purpose-built trace store for sub-second queries over large trace volumes; deployment and Fleet capabilities that take it past observability into agent operations.

Where it costs you: billing is per seat plus trace volume, with a free Developer tier, a paid tier around thirty-nine dollars per seat, and separate meters for deployment runs, uptime, Fleet runs, and compute. Retention is the other lever, with extended retention priced roughly an order of magnitude above base. Self-hosting and single sign-on sit on the enterprise tier. For a single-step LLM feature it is more platform than the problem needs.

Everything else, by what it is actually good at

Not sure which stack fits your agents?

The right choice depends on where your data must live, which framework you build on, and how mature your evaluation loop is. Talk to a Bitcot engineer who has shipped agents into production and walk away with a build plan that fits your team, not a vendor's roadmap.

Get your free build plan

Evaluation libraries, which are a separate decision

You do not need a platform to start evaluating. These run as test suites in your repository and pair with any tracing backend:

• promptfoo for declarative test cases, red teaming, and CI integration. Acquired by OpenAI in 2026 with open source components continuing.
• DeepEval for agent-aware metrics including tool-call correctness at the span level.
• Ragas for retrieval-specific measures such as context precision, recall, and faithfulness.
• Inspect AI for structured evaluation harnesses with a strong safety and rigor lineage.
• DSPy with MIPROv2 or GEPA when you are ready to optimize rather than just measure.

A team with a good taxonomy, a hundred-case golden set in a repository, and promptfoo in CI is further along than a team with an expensive platform and no eval set. Buy the platform when trace volume, collaboration across non-engineers, and online evaluation on production traffic become the bottleneck, which for most serious deployments is somewhere between month two and month four.

Four questions resolve most shortlists. Whichever branch you land on, instrument to OpenTelemetry so the branch remains a configuration decision.

The consolidation nobody priced into their roadmap

Between March 2025 and May 2026 this category went through the fastest consolidation any AI tooling sub-category has seen. Eight companies in fourteen months.

Three patterns sit behind those deals. Foundation labs buying the evaluation layer, because whoever owns the testing surface influences the model decision underneath it. Infrastructure vendors absorbing the application layer that runs on top of them. And larger dev-tool companies quietly absorbing smaller specialists they already depended on.

The practical consequence for a buyer is simple and it changes selection criteria. Acquisition outcome is now part of diligence. Ask what happens to this product if the company is bought in the next twelve months. The bigger deals have preserved products and accelerated roadmaps. The smaller ones have folded into the buyer’s strategy, with the standalone product going quiet.

What this costs, honestly

Most platforms in this category bill on trace or event volume, and the cost surprises come from three places that are all decided by engineering rather than procurement.

1. Your definition of a trace. A trace is one execution of your application, which may contain dozens of model calls and tool calls. Instrumenting one trace per session versus one per conversation turn is the same traffic priced several times apart. Decide deliberately, then keep it consistent, because changing it later breaks every historical comparison you have.
2. Evaluation runs are billable traffic. A nightly regression run over a couple of thousand examples generates tens of thousands of traces a month on its own. Once continuous evaluation is on, budget somewhere in the range of one and a half to two and a half times baseline volume.
3. Retention. Extended retention typically prices at roughly nine to ten times base. Apply it to the compliance-relevant slice, not to everything.

None of this makes the category expensive relative to what it prevents. It does mean that the number in your first month of production will not be the number in your sixth unless somebody models it up front.

The six mistakes we see most

• Buying the platform before building the taxonomy. A tool cannot tell you that unit-of-measure mismatches matter to your business. Read a hundred traces first.
• One aggregate quality score. It moves, nobody knows why, and it makes every conversation vague. Track the named failure modes separately.
• An uncalibrated judge. If you have never measured your judge against human labels, you do not know what your eval score means.
• Changing three things at once. A new prompt, a new model, and a re-indexed corpus in one release means the result is uninterpretable whichever way it goes.
• Evaluating the final answer only. Most agent failures happen mid-trajectory. Score the steps.
• Treating guardrails as improvement. Blocking a bad output is a control. The agent is still producing it. Guardrails buy time to fix the cause, they are not the fix.

How we run this at Bitcot

Continuous improvement is a phase of our AI Development Lifecycle, not a post-launch add-on, and it is scoped into the build from the first sprint. In practice that means three things are true at go-live rather than six months after it.

Instrumentation is written against OpenTelemetry GenAI conventions from the first agent loop, with content capture configured per span type and redaction in the pipeline, which matters when the traces contain PHI or contract terms. The evaluation set exists before the launch, seeded from the failure modes found during pilot traffic, and it lives in the repository with a CI gate attached. And the failure taxonomy is a shared artifact between engineering and the business owner, which is what turns a quality conversation into a prioritization conversation.

This is also why we quote six weeks rather than four for agentic builds that combine multi-tenancy with write actions. The loop described above is the difference between an agent that demos well and one that is still trusted in month four, and it is real engineering work, not configuration.

Running agents in production without a measurement loop?

Bitcot builds agentic systems for enterprises across healthcare, distribution, financial services, and regulated industries, with evaluation and observability scoped into the build rather than bolted on afterward. If you have agents in production and no reliable way to tell whether last month's changes helped, that is a conversation worth having.

Book a discovery call

The one thing to take away

The tool choice matters less than the loop. A team running all six stages with promptfoo and a self-hosted Phoenix instance will out-improve a team running two stages on the most expensive platform in the category, every time. LangSmith earns its place at the top of the shortlist because it covers the most of that loop in one product, and that is a real advantage when your team is small and your surface area is growing. It is an advantage over the alternatives, not over the discipline.

Pick the stage you are weakest on. For most teams reading this, it is stage three, and the fix costs an afternoon and a spreadsheet.

Frequently Asked Questions