Compare
AgentSight complements LLM observability by profiling the system effects around the agent.
SDK traces, gateways, and local transcripts are useful. They are also incomplete for local and closed-source agents that spawn commands, touch files, and make network calls outside the framework boundary.
Capability
SDK tracing
LLM gateway
Transcript tools
AgentSight
Integration model
SDK, callback, wrapper, or auto-instrumentation
Route provider traffic through a proxy
Read agent logs after the fact
Attach from the OS boundary with eBPF
Closed-source CLIs
Limited to exposed hooks
Only sees routed LLM traffic
Depends on saved local format
Traces the process and child processes directly
Commands and subprocesses
Only when the app reports them
Not visible
Often summarized or incomplete
Process tree, argv, status, and timing
File and network effects
Framework-specific and often missing
Provider traffic only
Only what the agent logs
Reads, writes, deletes, endpoints, and attribution
Best fit
Your own LLM app
Provider routing and cost controls
Cheap historical usage reports
Observer-agent profiling across semantic intent and OS effects
Use Langfuse, LangSmith, Phoenix, or Datadog for app-level spans, evals, and traces.
Use Helicone or provider gateways for routing, model controls, and provider traffic analytics.
Use AgentSight when the run depends on processes, files, network, resources, and opaque local CLIs.
Use the right layer for the question.
AgentSight is the system profiling layer for agent runs. It is not a replacement for app traces, gateways, or eval platforms.