Tracing Basics

What we're building

Three @traceable functions, where one (analyze) calls the other two (clean, count_words). Lesson 1 traced a single, isolated function call. Real programs are never that flat, so this lesson shows what LangSmith does when traced calls happen inside other traced calls.

What this reveals

LangSmith doesn't need to be told about the relationship between analyze, clean, and count_words. It detects that clean and count_words were called while analyze's run was still active, and records them as child runs of analyze. The result, in the UI, is a run tree: analyze at the top, clean and count_words nested underneath it, each with its own inputs, outputs, and timing.

This matters because real applications are call stacks many levels deep. Without nesting, you'd see a flat list of runs with no way to tell which calls belonged to which request. With it, you can open one top-level run and see everything that happened underneath it, in order.

The code, piece by piece

@traceable
def clean(text: str) -> str:
    return text.strip().lower()

@traceable
def count_words(text: str) -> int:
    return len(text.split())

Two small, independently traceable functions, nothing new here from Lesson 1.

@traceable
def analyze(text: str) -> dict:
    cleaned = clean(text)
    word_count = count_words(cleaned)
    return {"cleaned": cleaned, "word_count": word_count}

analyze is also @traceable, and it calls the other two functions during its own execution. That's the entire mechanism: nesting comes for free from ordinary function calls, there's no special API for "parent" and "child" runs to configure.