Token Observe vs LangSmith

LangSmith describes its tracing position clearly: the SDK uses an async callback handler that sends traces to a distributed collector, so your application performance is never impacted, and an incident on their side leaves your agent running normally. That is the correct design for the job it does. Telemetry that can stall the thing it is watching is a liability, and a tracing tool that took an estate down would be a worse tool. Everything LangSmith Observability is good at follows from being out of band: you can instrument one service without a change-advisory board, you can sample, you can turn it off.

LangChain evidently agrees that some jobs need the other position, because they now sell one. The LLM Gateway is a beta component that takes the request itself: a Chat Completions, Messages or Responses call to gateway.smith.langchain.com authenticated with a LangSmith API key, routed to a provider by a prefixed model ID, with spend and rate limit policies evaluated on every request and redaction applied to the outbound body. It blocks (a 402 for spend, a 429 with Retry-After for throughput), and a data policy can be set to block a request whose scan times out, though their page states that scanner failures otherwise fail open. Anyone reading this page for a decision should read their gateway documentation directly, because it is the part of their estate that most nearly does what Token Observe does, and it is moving quickly enough that a page checked on 5 October 2026 is a snapshot rather than a standing description.

Token Observe takes the opposite trade for the opposite reason. It occupies the base URL, and the eleven-step path is ordered deliberately: authenticate, resolve the agent, open the trace, sanitise unicode so smuggled invisible characters cannot slip past a detector reading a different string from the one the model will read, run the personal-data and injection detectors, then take one verdict, then enact it, then route, then call upstream, then govern any tool call the model proposes, then meter and record. The verdict is a single point rather than a set of middlewares, and it happens before governed provider egress. A tracing tool tells you afterwards that an agent sent a customer’s card number to a provider; a chokepoint refuses the payload so it never arrives.

The cost of that position is not hidden anywhere in the product’s documentation and should not be hidden here. Being in band means the failures of the evidence layer are the failures of the agents. The boot sequence performs a full streamed walk of the audit chain before the process listens, and a walk that finds intrinsic corruption latches readiness and audit writes unavailable; later governed requests receive a 503 carrying ACP_AUDIT_UNAVAILABLE, restarting does not clear it, and recovery means restoring a database whose chain and independently retained head both verify. A product that exists to produce the record cannot serve traffic it has stopped recording. LangSmith’s tracing, on its own product page’s account, has no equivalent problem because it is not holding anything back, and a reader who wants visibility without a new dependency in the request path should choose accordingly.

LangChain documents redaction in two places, and conflating them makes the comparison useless. The first runs in your process before anything is transmitted to them: LANGSMITH_HIDE_INPUTS and LANGSMITH_HIDE_OUTPUTS as environment variables, hide_inputs and hide_outputs callables on the Client, and a create_anonymizer helper taking regex patterns or callables, with the explicit note that the anonymizer “might incur a performance hit with complex regular expressions or large payloads, as the anonymizer serializes the payload to JSON before processing”. That is redaction whose beneficiary is the boundary between you and LangChain.

The second is the gateway’s, and it defends the same boundary Token Observe does. Their data-policy page states that when a policy enables detection “the gateway scans outbound requests before they reach the LLM provider”, using regular expressions for emails, US phone numbers and US SSNs, Presidio for names, locations and nationality, religious and political groups, and a list of provider credentials and private keys; matches are replaced with SAFE_TO_USE placeholders “in both the request sent to the provider and the LangSmith trace”, and “when the upstream provider returns a successful response, the gateway replaces the placeholders with the caller’s original values”, with streamed responses “rewritten event by event, so de-redaction does not delay the stream”. User messages, tool results and structured tool-call arguments are scanned. Their limits, in their own words: sensitive data the model generates in its response “is not scanned or redacted”; system and developer prompts are skipped, along with tool-call arguments “that arrive as a single JSON string”; traces written directly to the API bypass it; and “scanner failures fail open”, with only a scan timeout able to block a request, and only where the policy is set to do so.

Token Observe’s redaction covers that same egress boundary and extends to the surfaces their page excludes: the system prompt is scanned with the rest of the request, and responses are scanned as well, so a rule fires on an identifier the model produced. The detectors cover eleven sensitive-data classes, of which the card number, the IBAN and the NHS number are checksum-validated, with confidence published per kind rather than implied, and the redaction plan produced by the verdict is applied to the payload on its way to the model provider. The response side is where the engineering sits, because a streamed answer cannot be re-decided once bytes are on the wire: outbound streams pass a hold-back buffer with a 64-character floor and a separate buffer per tool-call argument channel, and the cut is pulled back off anything it would split, so a value that has not finished arriving cannot have its head emitted before the detectors have seen it whole.

Neither product is a data-loss-prevention system and neither should be sold as one. Token Observe’s own material calls its detection a compensating control rather than a customer’s only such system, and its licence disclaims any warranty that the policy, redaction, injection-detection and routing controls identify every instance of what they are designed to detect. The differences that survive are specific and checkable: whether what the model writes back is scanned, streamed or not, tool-call arguments sent as a single JSON string, system prompts, what happens when a scanner fails, and whether the component is in a stable self-hosted release. Those, rather than pattern-list length, are the questions to put to both vendors.

The difference shows up first in retention, and LangChain publishes theirs clearly: base traces at 14 days, extended at 180 for new SaaS traces from 14 September 2026, customisable per workspace on Enterprise up to that maximum, with traces no longer accessible in the UI or the API after expiry and some metadata retained indefinitely for analytics and billing. Those are sensible defaults for a debugging corpus, and the auto-upgrade path (an online evaluator or an automation rule can move a base trace to the extended tier for a fee) is documented. Cloud activity retention is configured to 30 days. Customer-hosted trace retention is unset by default and unset means keep forever; the operator must choose a window. This activity window is not a deletion policy for every table or backup.

It shows up second in what the record is made of. The audit log is hash-chained, so each row’s hash covers its canonical content plus the previous row’s and any edit or deletion breaks verification at a named sequence number; appends take the chain tip inside the same transaction so concurrent writers cannot fork it; an optional Ed25519 anchor seals the head on a schedule and publishes it to a sink you site outside the database administrator’s control. An anchor buys one thing: any copy you kept off-box beats any rewrite made after you took it. The chain is tamper-evident, not tamper-proof, and the compliance export is sealed with a SHA-256 digest rather than signed, so recomputing the digest detects an edit after issue but does not establish who issued the file.

It shows up third in who is allowed to read it and whether that read is itself an event. Pulling up one named person’s prompt history is a privileged read of a personal-data store the customer did not have before they deployed agents, so listing, searching, opening and exporting each append an audit entry naming the actor, the filter as interpreted, the teams the account was effectively authorised for and the number of rows returned. Search is constrained for the same reason it is useful: the translation model’s only permitted output is a JSON filter object validated against fourteen allow-listed keys before it reaches a parameterised query builder, never SQL, because trace content holds prompts, tool arguments and tool results some of which were written by an external party who wanted them read. The cost: the filter cannot group, count or correlate, and misinterpretation replaces injection as the main failure mode, with the explanation shown beside the results being advisory rather than a proof.

The shape is straightforward because the two products consume different things. Your agents keep the LangSmith SDK and keep sending runs and traces to whichever LangSmith deployment you have chosen (cloud with US or EU residency, hybrid with the data plane in your VPC, or self-hosted on Kubernetes), and the developer loop is unchanged. Their base URL changes to point at Token Observe, so the same calls now pass a policy verdict, a redaction plan, a budget check and a recorded decision on their way out. Two records exist afterwards, and they are not redundant: LangSmith holds the reasoning of your application in the detail an engineer needs, and Token Observe holds the decisions taken about it in the form a compliance officer can export.

Token Observe also ingests OpenTelemetry rather than competing for it. The receiver takes OTLP over HTTP for logs, traces and metrics in bounded JSON and protobuf, answers in the request encoding, and attributes every write to the seat or agent credential that presented it. What that feeds is the observed view of a four-view reconciliation (what was declared in the registry, what a manifest locked, what is deployed, and what has been observed), where the difference between the views is the finding. The published limits: protobuf interoperability has repository tests rather than a live collector and vendor compatibility matrix, and the receiver does not attest the device or exporter that produced the telemetry, so collection trust is an open gap and is named as one.

What running both does not buy you is a single pane of glass, and pretending otherwise would set up a disappointment on day three. The two records have different shapes, different retention and different readers, and Token Observe has no trace viewer for application spans, no dataset management, no experiment runs and no evaluation harness to display them in. The integration is deliberately shallow (a base-URL change on one side, an optional OTLP feed on the other), because the alternative is a coupling that makes your tracing tool a dependency of your control plane.