AgentSight: eBPF Observability for AI Agents You Cannot Instrument
lightweight system-level observability for AI Agents
At a glance
- What is it?
- AgentSight is a local-first tracer that watches AI agent CLIs from outside the process, correlating TLS model traffic with file, process and network effects. It is the right tool when you do not control the agent binary, and the wrong one when you need per-prompt evaluation scoring.
- Who is it for?
- Adopt AgentSight if you run closed-source agent CLIs such as Claude Code or Codex on Linux and need to know which files changed and which endpoints received traffic. Do not adopt it if you need prompt-level eval scoring or you are on a platform without eBPF support, since record and the eBPF-backed debug commands need Linux 4.1+ and 5.0+ is recommended.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Gap AgentSight Targets: Agents That Log Their Own Story
An agent that runs shell commands, rewrites files and calls remote APIs produces logs written by the same process being observed. Those logs can be incomplete, disabled, or shaped by the agent's own choices, and the README makes this the central argument: when a run fails or stalls, agent logs rarely tell the whole story. AgentSight's answer is to move the observation point out of the application and into the kernel, using eBPF plus TLS traffic tracing.
The intended user is someone operating an agent they did not write. The README lists Claude Code, Codex, Gemini CLI, OpenCode and OpenClaw as targets, and states the tool works without an SDK, proxy or vendor integration. That constraint is the whole product: if you own the agent's source, you have cheaper options. If you are handed a compiled CLI and asked why it deleted a file, you do not.
This is a Linux-first tool despite the cross-platform claim. The README is explicit that `top`, `bind`, `vis` and `report` can use agent-native session files on Windows, macOS or Linux without eBPF, while `record` and the eBPF-backed debug commands need Linux kernel 4.1+ with eBPF support, 5.0+ recommended. The macOS and Windows paths are therefore a reduced version of the product, not an equivalent one.
How the Observation Works: Kernel Events Plus TLS Plaintext
The architecture visible in the README is a two-source correlation. On one side, eBPF programs attached in the kernel produce process execution, file access and resource-use events. On the other, AgentSight captures plaintext at SSL/TLS call boundaries, which is how it reads model traffic without routing the agent through a proxy. The README describes this as capturing plaintext at SSL/TLS calls rather than intercepting a network hop.
The value is in the join. Application-level tracing stops at the framework or process boundary, so a subprocess spawned by the agent disappears from the trace. AgentSight's event model keeps LLM traffic and process and file events in the same stream, which is what makes questions like which files changed during this session answerable.
A Rust library, `agentsight-capture`, exposes the same eBPF runners, agent-native sources, analyzers, event model, materialized view and sinks that the binary uses. The CLI is published separately as the `agentsight` package and the README calls it the library's primary consumer. If you want to build your own sink or analyzer rather than use the terminal UI, that crate is the entry point, and it is a real API surface rather than a thin wrapper.
One caveat on the TLS claim: the README does not describe how key material is obtained for a given process. Whether this works against a statically linked or otherwise unusual TLS stack is not something the supplied material answers.
Installing and Running AgentSight
The quick start is two lines. Install with `cargo install agentsight`, or download the release binary with `wget https://github.com/eunomia-bpf/agentsight/releases/latest/download/agentsight && chmod +x agentsight`. On Linux there is also a Homebrew path: `brew tap eunomia-bpf/tap`, then `brew install eunomia-bpf/tap/agentsight`, then `agentsight --version` to confirm. The README notes the current formula supports Linux x86-64 only.
Release assets are `agentsight-x86_64` and `agentsight-aarch64` for Linux; the unsuffixed `agentsight` asset is kept as an x86_64 compatibility alias. Native Windows builds are exercised by a Windows CI workflow, though the README text is truncated at that point, so treat Windows support as present in CI rather than fully described.
The commands shown in the README are `agentsight top` for a live session view, `agentsight vis` for the Agent Nebula replay of file reads, writes, creates, renames and deletes across a repository, and `record` plus `report` for capturing and inspecting saved sessions. Privileges are conditional: sudo is optional for `top` on Linux, and the README states eBPF is enabled automatically when sudo is already available. There is also an `agentpprof` guide referenced for semantic flamegraphs where width is system-effect weight and stack height reflects prompt, tool-call, process and effect paths ending at different depths. That last detail is the most interesting design choice in the README: the profile is not a CPU profile, so the usual intuition about what a wide frame means does not carry over.
Where AgentSight Is the Wrong Tool
AgentSight observes effects, not intent. If your question is whether a prompt produced a correct answer, or how a model scored against an eval set, this tool has nothing to say. The README is candid about the division of labour, positioning LangSmith, Langfuse and Phoenix as strong for traces, prompts, tokens, evals and latency when you own the application code. That is not a marketing concession; it is a real boundary. Kernel events tell you a file was written, not whether the write was the right one.
The second limitation is platform. On macOS and Windows the eBPF path is unavailable, so you lose `record` and the eBPF-backed debug commands and fall back to agent-native session files. If the agent you care about does not write usable session files, the non-Linux experience is thin.
The third is the nature of kernel-level capture itself. A tracer that reads process, file and TLS activity at the system boundary sees everything in those categories, including activity unrelated to the agent under study. The README does not describe filtering or scoping mechanisms in the material provided, so how cleanly sessions are separated on a busy machine is something to establish empirically before relying on it.
Finally, this is a fast-moving project. Three releases landed between 24 August and 5 September 2026, with v1.0.31 on 5 September. That cadence suggests active development, and it also means the CLI surface and the `agentsight-capture` API may shift between minor versions.
How It Differs From LangSmith, Langfuse and Helicone
The comparison the README draws is between two observation points. LangSmith, Langfuse and Phoenix instrument the application: you add an SDK or callback, and in exchange you get structured traces with prompt text, token counts, latency and eval hooks. Helicone takes the gateway route, where provider traffic flows through a managed endpoint and observability comes from that position. Both approaches assume you can change something about how the agent is built or how its traffic is routed.
AgentSight assumes you can change neither. It observes existing binaries from outside, which is why the README frames closed-source CLIs and agent-controlled logs as the problems application-level tools cannot reach. The trade is depth for reach: you get process execution, file access and plaintext model traffic correlated in one stream, but you do not get the semantic richness of a framework-native trace, and you do not get eval scoring at all.
A practical consequence: these are complements more than substitutes. An agent you wrote can be traced with an SDK and simultaneously watched by AgentSight to catch subprocess executions that bypass instrumentation, which the README lists as a specific class of missed interaction. The overlap is small and the failure modes are different.
Maintenance, Licensing and Upgrade Surface
The licence is MIT, which permits commercial use, modification and redistribution with the copyright notice preserved. That is permissive and low-friction for internal tooling. It says nothing about the arXiv paper (2508.02736) or the ACM DOI (10.1145/3766882.3767169) referenced in the README badges, which are separate publications with their own terms. Nothing here is legal advice; if you redistribute a modified binary, read the MIT text yourself.
Upgrade cost depends on how you consume the project. If you use the `agentsight` binary as a CLI, upgrades are a `cargo install` or a fresh release download, and the risk is command and output format churn given the release cadence. If you depend on `agentsight-capture` from Rust, you inherit the library's API stability, which the README does not characterise. Pin a version and read the release notes before moving.
The kernel requirement is the maintenance item people underestimate. Linux 4.1+ with eBPF is the floor, 5.0+ is recommended, and the eBPF-backed commands are the ones that need it. A fleet with mixed kernel versions will have mixed capability, and the README gives no compatibility matrix beyond that sentence. Verify the kernel on the machines you actually care about before standardising on the `record` workflow.
Who Should Adopt AgentSight
Adopt it if you run agent CLIs you did not write, on Linux, and your questions are about effects: which files changed, which processes spawned, which services received requests, where a session spent its time. The README's framing of auditing data movement and security-sensitive effects maps directly onto that use case, and the absence of an SDK requirement means you can point it at a binary the day you receive it.
Do not adopt it as a replacement for prompt-level observability. If your team's core question is model quality, AgentSight will not answer it, and the README says so by pointing at LangSmith, Langfuse, Phoenix and Helicone for that layer. Do not adopt it on macOS or Windows expecting parity with the Linux experience, because the eBPF path is not there.
Before committing, verify three things: that your kernel version supports the eBPF features the `record` path uses, that the Homebrew formula's Linux x86-64 constraint or the release asset naming matches your architecture, and that the TLS capture works against the specific agent binary you care about. The first two are documented constraints. The third is the one the README does not settle, and it is the one your deployment depends on.
Editorial conclusion
Adopt AgentSight if you run closed-source agent CLIs such as Claude Code or Codex on Linux and need to know which files changed and which endpoints received traffic. Do not adopt it if you need prompt-level eval scoring or you are on a platform without eBPF support, since record and the eBPF-backed debug commands need Linux 4.1+ and 5.0+ is recommended. Verify first that the Homebrew formula's Linux x86-64 only constraint matches your hardware, and check whether your kernel exposes the tracepoints the record path expects before you build a workflow around it.
Community notes