Sharing traces you already have with AgentLasso

If your agent already sends traces to LangSmith, Langfuse, Datadog, or anywhere else, you don't need to migrate off it or hand AgentLasso any credentials for that platform. The pattern below — dual-export from your own pipeline — means AgentLasso never talks to your existing observability platform's API at all; it's just a second destination your own instrumentation writes to, alongside the one you already have.

This is deliberate, not just convenient. We looked at how other agent-eval platforms (Coval, notably) actually do this, and it's the same shape: the customer's own tracing pipeline exports to both places. We also specifically checked LangSmith's Terms of Service before recommending anything here — there's a real restriction (§2.4(c)) on using their platform to build a competing product, which is exactly why this guide is about exporting from your side, not AgentLasso pulling from theirs. No API calls to your existing platform, no stored third-party credential, nothing that could touch that clause.

Pick whichever of the three sections below matches your setup.

1. You run an OpenTelemetry Collector

Add a second exporter to your existing pipeline's config — same span stream, two destinations. This is the recommended approach if a Collector already sits between your app and your current platform, since it needs zero changes to your application code at all.

receivers:  otlp:    protocols:      http:      grpc:
exporters:  otlphttp/langsmith:    endpoint: https://api.smith.langchain.com/otel    headers:      x-api-key: ${LANGSMITH_API_KEY}  otlphttp/agentlasso:    # traces_endpoint (not endpoint) -- AgentLasso's route is the exact path,    # not a base URL the exporter should append /v1/traces to.    traces_endpoint: https://agentlasso.dev/api/v1/telemetry    headers:      x-api-key: ${AGENTLASSO_API_KEY}
service:  pipelines:    traces:      receivers: [otlp]      exporters: [otlphttp/langsmith, otlphttp/agentlasso]

Swap the otlphttp/langsmith block for whatever your current platform's own OTLP endpoint is (Langfuse, Datadog, etc. all publish one) — the AgentLasso side stays the same regardless.

2. You use a raw OpenTelemetry SDK directly (no Collector)

Register a second span processor on the same tracer provider. Node/TS shown; the same idea applies in any language's OTel SDK — one provider, multiple processors, each with its own exporter.

import { NodeTracerProvider } from "@opentelemetry/sdk-trace-node";import { BatchSpanProcessor } from "@opentelemetry/sdk-trace-base";import { OTLPTraceExporter } from "@opentelemetry/exporter-trace-otlp-http";
const provider = new NodeTracerProvider();
provider.addSpanProcessor(  new BatchSpanProcessor(    new OTLPTraceExporter({      url: "https://api.smith.langchain.com/otel/v1/traces",      headers: { "x-api-key": process.env.LANGSMITH_API_KEY! },    }),  ),);
provider.addSpanProcessor(  new BatchSpanProcessor(    new OTLPTraceExporter({      url: "https://agentlasso.dev/api/v1/telemetry",      headers: { "x-api-key": process.env.AGENTLASSO_API_KEY! },    }),  ),);
provider.register();

Every span your app already creates now goes to both places. No change to your actual instrumentation code, just the provider setup.

3. You have a hand-rolled tracer, not a real OTel SDK

Probably the most common case for an early-stage agent, honestly — a small fetch()-based helper wrapping whatever platform's REST API, not a real OTel pipeline. If that's your situation, don't build OTel infrastructure just for this: add one more POST call, using AgentLasso's flat JSON ingestion shape (no envelope, no span IDs to generate), right next to wherever you already send to your existing platform.

// Call this alongside your existing trace-send call, with the same data.// Fire-and-forget -- don't await this on your agent's actual response path.function postToAgentLasso(params: {  sessionId: string;  userInput: string;  agentOutput: string;  toolCalls: { name: string; args: Record<string, unknown> }[];}) {  fetch("https://agentlasso.dev/api/v1/telemetry", {    method: "POST",    headers: { "content-type": "application/json", "x-api-key": process.env.AGENTLASSO_API_KEY! },    body: JSON.stringify({      session_id: params.sessionId,      user_input: params.userInput,      agent_output: params.agentOutput,      tool_calls: params.toolCalls.map((t) => ({ name: t.name, arguments: t.args })),    }),  }).catch((err) => console.error("[agentlasso] trace send failed", err));}

All three paths get the same treatment once they land

PII redaction runs automatically regardless of which of the three you use (on by default, toggle in Settings). Your first ~10 traces get classified into intents immediately, inline — see the main README for that and for the OTLP/HTTP JSON path if your existing pipeline already speaks that format natively.