Zambo vs LangSmith for agent records: tracing a run vs proving one to a client.
Pick by the reader. LangSmith traces a run for the team that built the agent: spans, prompts, and debugging detail inside your own workspace. Zambo records a job for the person who must check it from outside: steps with saved results, source states, and a client decision, in receipts a third party can recompute. Many teams run both.
The honest comparison starts with what each tool is for, because the marketing categories overlap and the jobs do not. LangSmith is an observability and evaluation platform for LangChain and general agent work: you instrument runs, inspect traces, debug failures, and score outputs. Its reader is you, the builder, during development and incident response, and for that reader it is deep in ways a receipt record is not trying to be.
Zambo's record starts where the trace's usefulness to an outsider ends. A trace lives in the builder's workspace, reads as engineering, and is authored within the builder's own stack. A Zambo handover is one link a client opens in a browser: the steps as delivered, the sources behind them with their states, your gaps labelled, and the client's acceptance recorded on the same object. The receipts under it (AER-1, IETF Internet-draft-zambo-aer1-21) recompute at a public page, so the check does not run inside anyone's vendor account.
So the decision rule is a sentence: if the record's reader is your own team, tracing wins; if the reader is a client, an auditor, or a dispute, the verifiable record wins. Pick LangSmith if your pain is debugging and evaluating agents you build. Add Zambo when the work leaves the building and someone who does not trust your stack must be able to check it.
Table: tracing a run vs proving one
Criterion | LangSmith | Zambo. Primary reader | Your team | Your client and other checkers. Core object | Trace of a run | Handover of a job, receipts per step. Debugging depth | Deep: spans, prompts, evals | Step results and source states. Client can open it without an account | No | Yes, one link. Third party can recompute the record | No | Yes, public verify page. Client decision recorded on the record | No | Yes, acceptance on the handover. Best at | Building and fixing agents | Delivering and proving work. Rule: choose per reader, not per category.
Worked example
The Zambo side of the table is openable now: https://zambo.dev/handover/45434a17-4afc-486a-9646-e689bcee4297 shows a job record with its client decision, readable by someone with no account in any builder tool. That readability by the paying party is the criterion this comparison turns on.
Frequently asked questions
Can I use LangSmith traces as client evidence instead?
You can export and send them, and sophisticated clients do read traces. The limits are structural: the trace is inside your stack's account, it reads as engineering, and nothing in it records the client's acceptance. It persuades technical readers; the handover persuades the person who pays.
Do the two tools integrate or compete for the same slot?
They occupy different slots: development-time observability and delivery-time evidence. Teams commonly trace with their observability platform while the work runs through the connection that leaves receipts, and the two records answer different questions later.
What if my client is highly technical?
Then send both: the handover as the delivery and decision record, the trace as supporting depth. The acceptance still belongs on the handover, because that is the object whose contents cannot drift after the decision.
By Brennan Zambo, founder of Zambo.
Last verified: 2026-10-17.
Try a handover
A handover gives your client one proof link with verifiable receipts to review, then Accept or Flag.
try it: say 'use zambo to hand this over to <client>' in your ai