LLMOps & AI Agent Ops Consulting

You cannot improve what you cannot see — and most agents in production are invisible

Agents fail quietly. A prompt edit ships, quality slips, and nobody notices for weeks because there is no regression suite and no trace to read. We build the layer underneath: end-to-end tracing, evals wired into CI as merge gates, per-task cost accounting, and an audit trail that survives a SOC 2 review.

TRACINGEVALSOBSERVABILITYCOST PER TASKSOC 2CI/CD GATESOPENTELEMETRYDRIFT MONITORING

Traced

Every run reconstructable — inputs, context, tool calls, tokens, latency

Gated

Evals run in CI; a regression blocks the merge, not the customer

Costed

Spend attributed per task and per tenant, not per API key per month

Auditable

Retention-controlled, redacted logs an auditor can actually sample

Agents do not fail loudly. They degrade quietly, and nobody can say when.

The pattern is consistent. A team ships an agent, it works, and for a few weeks everyone is delighted. Then a model version is deprecated and you migrate. Someone tightens the system prompt to fix one loud complaint. The retrieval index is rebuilt with a new chunking strategy. An upstream API starts returning an extra field. None of these throw an exception — the service keeps returning 200s and the dashboard stays green while answers on the long tail get worse. You find out from a customer, weeks after the change that caused it, and by then nobody can say which change it was because there is no record of what the system actually did on any given request.

The root cause is that prompt changes are deploys with no tests. A one-line edit to a system prompt alters behaviour across every request path in the product, and it usually ships with less review than a CSS tweak. The standard defence is that you cannot unit test a language model, which is true and beside the point. You cannot assert one exact string, but you can score a fixed set of real cases, and you can refuse to merge when the score drops. Without that gate, the only regression detector in your system is a user annoyed enough to write in.

Cost degrades the same way — invisibly. Retries, a context window that quietly grew, a tool loop that now takes eleven steps where it took four: the invoice climbs and nobody can attribute it, because spend is measured per API key per month rather than per task, per tenant or per customer. Underneath both problems sits the compliance question. SOC 2 asks who did what, on whose authority, and whether you can prove it. An agent acting on behalf of a user is an actor in that record. If you cannot reconstruct a specific decision months later — inputs, retrieved context, model and prompt version, tool calls, output, approver — that is an audit finding waiting to happen. None of this is exotic. It is the discipline you already apply to every other production service, applied to the part of the stack that currently has none.

Core Capabilities

[01]

Tracing & Instrumentation

Every run captured end to end: the prompt actually sent, the chunks actually retrieved, each tool call with its arguments and result, token counts and latency per span. OpenTelemetry semantics where they fit, so traces land in the stack you already operate.

[02]

Evaluation Harness & CI Gates

A versioned dataset of real cases with graded expectations, scored on every pull request. Deterministic assertions where the answer is checkable, judge models with human-labelled anchors where it is not. A score below threshold fails the build.

[03]

Cost & Token Accounting Per Task

Spend attributed to the unit the business pays for — a resolved ticket, a reconciled invoice, a completed booking — and broken down by model, tool loop and retries, so you can see which step is expensive rather than guessing at a monthly total.

[04]

Audit Trail for Compliance

Append-only records of who invoked what, on whose behalf, with which model and prompt version and which retrieved context. PII redaction at capture, access control on the trace store, defined retention. Structured so an auditor can sample it.

[05]

Prompt & Version Management with Rollback

Prompts, tool definitions and model pins live in version control with review and staged rollout, and every trace records the exact version that produced it. A regression maps to a commit, and rollback is one command that has been tested.

[06]

Drift & Regression Monitoring

Online scoring of live traffic against the same rubrics used offline, with alerts on quality, latency, cost per task and tool error rates. You hear about degradation from a monitor rather than from a customer.

What LLMOps tooling actually covers

These platforms overlap more than their marketing suggests. Here is where they genuinely differ — and where the difference matters if you have a compliance obligation.

LangfuseLangSmithArize PhoenixBuild in-house
TracingTraces, spans and sessions via SDKs or OpenTelemetry ingestFull traces; deepest integration with LangChain and LangGraphOpenTelemetry-native, built on OpenInference conventionsWhatever you instrument, in whatever format you pick
EvalsDatasets, scores, LLM-as-judge, human annotationDatasets, experiments, judges and annotation queuesEval library with prebuilt judge templatesYou write the harness, the graders and the storage
Cost trackingToken and cost per trace, aggregated by modelToken and cost per run and per projectToken usage captured; cost derived from model pricing configOnly if you compute and attribute it yourself
Self-hostableYes — open-source core, Docker or KubernetesYes, on the enterprise planYes — open source, runs locally or in your clusterBy definition
Data residencySelf-host anywhere; managed cloud offers EU and US regionsManaged cloud offers US and EU regions; self-host for full controlYour infrastructure, or the managed Arize platformEntirely yours, including the backup and retention problem
Best whenYou need self-hosting or EU residency without an enterprise contractYou are already on LangChain or LangGraph and want it managedYou are standardised on OpenTelemetry and want to start locallyYour requirements are genuinely unusual and someone owns the upkeep

All three are credible and we work with each; the feature lists converge every quarter, so check current docs before you commit. In practice the decision rarely comes down to features — it comes down to where trace data is allowed to live and whether self-hosting is mandatory. Answer those two first and the shortlist picks itself. And if you are pre-launch with one prompt and ten users, you do not need any of this yet: add basic tracing, ship, and come back when changes start to scare you.

Our Process

01

Trace What You Already Have

Instrument the existing system before changing anything, then read a week of real traffic. Where the latency goes, where the tokens go, where it silently fails. Most teams are surprised by at least one of the three.

02

Build the Eval Set

Turn real failures and representative successes into a versioned dataset with graded expectations. This is the artefact everything else depends on, and it is the step teams try to skip. Building the harness is easy; agreeing on what a correct answer looks like is the work.

03

Gate the Pipeline

Wire evals into CI so prompt, tool and model changes are scored before merge. Quality thresholds, a cost-per-task budget, required review on the files that change behaviour, and a rollback path that has been exercised rather than assumed.

04

Cost & Compliance Instrumentation

Attribute spend to tasks and tenants, apply redaction and retention policies to the trace store, and map the fields you log to the specific SOC 2 criteria your auditor will test. Done once, before the audit window, not during it.

05

Hand Over & Monitor

Dashboards, alert thresholds, a runbook, and a written definition of what degraded means for your system so the on-call engineer is not guessing at 2am. You own the code, the datasets and the data.

Tech Stack

We choose the right tool for the job — not the trendiest one.

Langfuse
LangSmith
OpenTelemetry
LangChain logoLangChain
Python logoPython
Grafana
PostgreSQL
ClickHouse
GitHub Actions

Frequently Asked Questions

What is LLMOps, and how is it different from MLOps?
MLOps assumes you own the model: you train it, you version the weights, you watch for drift against a training distribution. LLMOps usually assumes you do not. The model is someone else’s API and can change underneath you, part of your logic is written in English, and the output is text that can be wrong in ways no validation-set accuracy number will catch. The loop shifts from train-deploy-monitor to trace-evaluate-gate. Version control, CI and observability still apply — they just point at prompts, tool definitions and retrieval instead of weights.
How do you evaluate a system that is not deterministic?
You stop testing for one right answer and start testing that a fixed set of cases still scores above a threshold. Three layers: deterministic assertions where the answer is checkable — did it call the right tool, is the JSON valid, does the SQL run, was the cited document in the retrieved set; a judge model with an explicit rubric where it is not; and a small human-labelled set used to verify the judge still agrees with your people. Run each case more than once, because variance across runs is itself a signal — a case that passes four times in five is not a passing case.
What do you need to log for SOC 2 when an AI agent is in the loop?
Auditors want to reconstruct a specific action months after it happened. Per run that means: timestamp, the authenticated actor and the identity the agent acted on behalf of, the model and prompt version, the inputs and retrieved context, every tool call with arguments and result, the final output, and any human approval. Then the controls around that record — append-only storage, access control on who can read it, a defined retention period, and PII redaction at capture rather than on the way out. SOC 2 has no AI section; it asks the same access, change-management and monitoring questions it always did. The complication is that an agent is a new kind of actor, and most existing log schemas have nowhere to put it.
How do you measure cost per successful task?
Pick the unit of work the business actually pays for — a resolved ticket, a reconciled invoice, a qualified lead — and tag every trace with it. Then sum all tokens spent reaching that outcome, including retries, abandoned attempts, the router or classifier in front, and any online scoring calls. Divide total spend by successful outcomes rather than by total attempts: an agent that burns four failed runs before succeeding costs several times what the per-call number suggests. That is the figure worth putting next to what the same task costs a human, and it is usually the first number that changes an architecture decision.
Can this be self-hosted for data residency?
Yes. Langfuse and Arize Phoenix are open source and run in your own infrastructure — typically Docker or Kubernetes with Postgres, plus ClickHouse once trace volume grows. LangSmith offers self-hosting on its enterprise plan alongside managed US and EU regions. If EU residency is a hard requirement, settle it before you pick a tool, because it eliminates options faster than any feature comparison. Worth remembering that traces contain prompts and retrieved context, which means the trace store frequently holds the most sensitive data in your system and deserves the same controls as the source database.
How long does an LLMOps engagement take?
Instrumenting an existing system and getting traces you can genuinely reason from is usually two to three weeks. Adding an eval set that reflects real failures, wiring it into CI and setting up cost attribution takes another three to five. Compliance-grade audit logging and retention policy typically adds one to two on top. The variable is almost never the tooling — it is how much internal agreement exists about what a good answer looks like.
Do we own the code?
Yes. Instrumentation, eval datasets, CI configuration, dashboards as code and the runbook all land in your repository. The platforms are open source or your own vendor contract, never resold through us. There is no Zenthos component in the request path and nothing to licence from us afterwards. Retainer support is available if you want a second pair of eyes on the eval set as it grows, but it is optional and most teams stop needing it.
Do you work with companies in the US, UK and EU?
Most of our work is with teams in those markets. We overlap with both US coasts and European hours, and we are used to operating inside security reviews, DPAs and vendor questionnaires — including the question about where trace data is stored, which for this service is usually the one that decides the architecture.

Related Articles

View all →

Can you explain what your agent did last Tuesday?

Send us the shape of your system — what it does, what it calls, and what you log today. We will tell you where the blind spots are and what to instrument first. If you already have traces and a working eval set, we will say so and leave you to it.