AI agent observability in n8n with LangSmith: tracing via the REST API

An n8n AI Agent answering from a document base or triaging emails chains several model and tool calls whose order varies on every run. Our Langfuse guide already covered wiring that kind of agent into a dedicated observability tool — but if your team already uses LangChain, LangGraph, or LangSmith's Prompt Hub on the Python side, the question looks different: can n8n runs feed into that same trace system already in place elsewhere in the stack? The answer is yes, but with one structural difference from Langfuse worth knowing up front: there is no tracing community node for LangSmith. Everything goes through its REST API.

Why LangSmith over another tool

LangSmith is the observability and evaluation platform built by the LangChain team. It makes particular sense if part of your AI agents already live in that ecosystem (Python agents in LangGraph — the split we describe in LangChain vs n8n — prompts managed through the Prompt Hub): wiring n8n into it surfaces your workflows in the same dashboard as the rest of your AI stack, instead of adding a tool that's isolated to n8n alone. If that's not your situation, Langfuse — with its ready-to-use tracing community node — needs noticeably less manual plumbing for a comparable result; the comparison section further down details that choice.

No tracing community node: straight to the REST API

Only one community node exists on the LangSmith side for n8n: n8n-nodes-langsmith-prompt, which exposes a "Fill Prompt Template" operation — it fetches a versioned prompt by name from the Prompt Hub and fills in your variables. That's useful for prompt management, but it traces nothing: no run data is sent to LangSmith with this node. To trace an AI Agent — cost, latency, inputs/outputs of each run — the path available today is to call LangSmith's REST /runs endpoints directly (https://api.smith.langchain.com) with two HTTP Request nodes: one to start the run, one to close it.

Creating a project and grabbing an API key

On smith.langchain.com, a free account (with a monthly trace quota generous enough to test) gives access to Settings → API Keys, where you generate a key. Unlike Langfuse, which splits a Public Key and a Secret Key, LangSmith uses a single key, sent in the x-api-key header of every request. Store it in an n8n HTTP Header Auth credential rather than a static field on the node — the same principle detailed in our guide on securing API credentials.

Starting a run: POST /runs

At the input of your AI Agent (or right before its trigger), a first HTTP Request node sends a POST https://api.smith.langchain.com/runs request with a JSON body like:

{
  "id": "{{ $json.runId }}",
  "name": "email-triage-agent",
  "run_type": "chain",
  "inputs": { "email": "{{ $json.emailBody }}" },
  "start_time": "{{ $now.toUTC().toISO() }}",
  "session_name": "flowkit-inbox-ai",
  "tags": ["n8n", "inbox-ai-pack"]
}

The id field must be a UUID generated on the n8n side — a Code node placed right before, with crypto.randomUUID(), does the job and lets you reuse the same value for the closing PATCH. run_type takes the values chain, llm, or tool depending on what the run represents; for tracing the agent as a whole, chain is the natural choice. session_name determines the LangSmith project the trace lands in: if it doesn't exist yet, LangSmith creates it automatically — no need to pre-configure it from the interface.

Closing the run: PATCH /runs/{run_id}

At the agent's output, a second HTTP Request node sends PATCH https://api.smith.langchain.com/runs/{{ $json.runId }} with the output and end timestamp:

{
  "outputs": { "category": "{{ $json.category }}", "urgency": "{{ $json.urgency }}" },
  "end_time": "{{ $now.toUTC().toISO() }}"
}

That PATCH, and only that PATCH, is what visually closes the run in the LangSmith interface. A common mistake (covered below) is wiring it only on the success path: on an error branch, that same PATCH must also be called, with an error field set instead of outputs — otherwise the run stays shown as "in progress" indefinitely, exactly the kind of silent failure our Error Workflow guide recommends routing explicitly instead of letting slip.

Nesting tool calls: a practical limit worth knowing

The REST API accepts a parent_run_id field to attach a child run (one specific tool call) to a parent run (the agent as a whole), rebuilding a trace hierarchy. In practice, doing that by hand for every tool call of an n8n AI Agent (a RAG lookup, an HTTP call, a Supabase write) means wrapping each one in its own POST/PATCH pair with the right parent_run_id — something LangSmith's Python/JS SDKs automate natively, but nothing automates on the n8n side today. For most workflows, tracing only the top-level run (the full chain, with its final inputs and outputs) already covers the essentials: the internal tool-by-tool detail stays available in n8n's native log or in intermediateSteps, as described in our guide on logging an AI agent's decisions. Reserving full nesting for agents whose multi-tool behavior is genuinely what needs watching avoids a setup disproportionate to the benefit.

This parent/child tree trace model isn't unique to LangSmith: it directly follows the one popularized by Dapper, Google's internal distributed tracing system, described by Sigelman and coauthors in Dapper, a Large-Scale Distributed Systems Tracing Infrastructure (Google, 2010), which laid the groundwork for the parent-span/child-span pairing now used by nearly every modern observability tool, AI agents included.

Bonus: pulling your versioned prompts with the dedicated community node

If your prompts already live in LangSmith's Prompt Hub — a common practice for a team that versions prompts like code — the n8n-nodes-langsmith-prompt community node (installable via Settings → Community Nodes on a self-hosted instance) lets you fetch them directly in an n8n workflow with the "Fill Prompt Template" operation, instead of duplicating the prompt text between your Python code and your n8n workflows.

LangSmith or Langfuse?

• Already in the LangChain/LangGraph ecosystem, prompts managed via the Prompt Hub → LangSmith, to centralize every trace in one place.
• Pure n8n stack, want a ready-to-use setup without manual HTTP plumbing → Langfuse, whose tracing community node automatically captures generations and tool calls.
• Need to keep traces on your own infrastructure → self-hosted Langfuse rather than LangSmith, which remains a cloud service (a separate self-hosted Enterprise offering aside).

The two aren't mutually exclusive either: nothing stops you from tracing an n8n agent into LangSmith to sit alongside existing Python agents, while keeping Langfuse for other, purely n8n-based workflows.

Common pitfalls

• Forgetting the PATCH on the error branch: a run that's never closed stays "in progress" forever and skews any aggregated duration reading.
• Generating a new UUID instead of reusing the one from the POST: without the same id, the PATCH creates a second, orphaned run instead of closing the first one.
• Forgetting the UTC timezone: start_time and end_time must be in ISO UTC format; an unconverted local timestamp skews the computed durations.
• Hardcoding the API key in the HTTP Request node instead of a dedicated credential — the same risk as with any n8n API key.

Going further

The RAG Assistant Pack (119 €) and the Compliance & Audit Pack (149 €) both rely on a conversational agent whose answer quality deserves tracking over time, not just testing once — a natural complement to our guide on n8n Evaluations for turning that into objective scores, an approach that echoes the LLM-as-judge method documented by Zheng and coauthors in Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS, 2023 — see the study). If observability across your whole AI automation stack is a cross-cutting concern, the Complete FlowKit Bundle (269 €) brings all three packs together on that same baseline.