Start deploying
·4 min read·a2a cloud

LangSmith vs a2a cloud: tracing is not an audit trail

Tracing answers why your agent did something. Signed receipts prove what it did and who authorized it. Where LangSmith and a2a cloud actually differ — and why most teams want both.

agent audit trailsigned receiptslangsmithobservabilitycomparison

If you are shipping an agent on LangGraph, CrewAI, or the OpenAI Agents SDK, you will eventually ask two different questions about the same run:

  1. Why did the agent do that? — a debugging question.
  2. Can you prove the agent did that, and only that? — an evidence question.

LangSmith is built for the first question. a2a cloud is built for the second. They are not substitutes, and treating them as one is how teams end up in a compliance review with a folder of screenshots.

What each one actually is

LangSmith is an observability and evaluation product for LLM applications: traces of chains and agent steps, prompt/response inspection, datasets, evals, and regression runs. You instrument your app, traces go to LangSmith, and you get a timeline you can click through. It is very good at telling you what the model saw and what it emitted.

a2a cloud is the runtime the agent lives in. You deploy an agent and it gets a managed Postgres database, an MCP server, an HTTP API, a frontend, and scoped credentials — and every run emits an Ed25519-signed receipt describing what the agent did, which tools it called, and which grants authorized it.

The difference is where the record comes from. A trace is written by the application about itself. A receipt is written by the runtime that mediated the call, and signed with a key the agent does not hold.

Why that distinction matters

Traces are self-reported telemetry. That is fine — and necessary — for debugging. It is weak as evidence, for three reasons:

  • Provenance. A trace is whatever the SDK chose to send. If the agent takes a code path that skips instrumentation, the trace is silently incomplete, and nothing in the record says so.
  • Integrity. Log rows are mutable by whoever can write to the log store. A signed receipt is verifiable against a public key: alter the payload and the signature fails.
  • Authority. A trace shows a tool call happened. It does not show the call was *permitted*. Receipts reference the grant that authorized the access, so "the agent read the customer table" and "the agent was allowed to read the customer table" are the same artifact.

We wrote about this split in more detail in signed receipts vs trace logs.

When you want both

Most teams should run both, because they answer different questions:

| Question | Reach for | |---|---| | Why did the agent loop three times on that tool? | tracing (LangSmith) | | Did my prompt change regress the eval set? | tracing + evals | | What did this agent touch on 14 August, and who authorized it? | signed receipts | | Show an auditor an unmodifiable record of agent actions | signed receipts | | Where do the agent's database and MCP server come from? | the runtime |

Instrumenting for tracing does not give you the runtime, and running on a runtime does not give you eval tooling. The overlap is smaller than the marketing on either side suggests.

The practical setup

On a2a cloud a LangGraph agent deploys as-is; nothing about your graph changes, and you can keep your existing tracing callbacks pointed wherever you already send them. See deploy a LangGraph agent in 60 seconds. What you additionally get is the boundary: a database the agent reaches through a scoped grant rather than a pasted connection string (why that matters), an MCP server generated for it (zero config), and a receipt per run.

That receipt is the artifact you hand to someone who does not trust you: a security reviewer, a customer's procurement team, or an auditor working through SOC 2 evidence for AI agents or EU AI Act Article 12 logging.

How to choose, honestly

  • Debugging agent behaviour and iterating on prompts is your bottleneck → tracing is the higher-value purchase, and LangSmith is a strong one.
  • Getting an agent into production with data, tools, and a defensible record is the bottleneck → that is a runtime problem, and tracing alone will not close it.
  • You are being asked "prove it" by someone outside your team → you need signatures, not screenshots.

If you want to see what a receipt looks like for a real, running agent, our own GTM agent runs on a2a cloud and publishes its own: our GTM is an agent — here's the signed receipt.

*Deploy an agent with a database, an MCP server, an API, and signed receipts at a2acloud.io.*

discussion

0 comments

Likes0Dislikes0
No comments yet.