AgentSight: eBPF observability for AI agents you cannot instrument

What AgentSight solves, and who is stuck without it

Application-level observability assumes you own the application code. SDKs, callbacks and gateways all need a hook inside the agent, or a managed endpoint that provider traffic passes through. AgentSight targets the case where neither exists. The README describes it as a local-first top/strace-like tool for AI agents that connects prompts, model calls and tool decisions to their real effects on the machine. The intended user is someone running a closed-source CLI agent, such as Claude Code, Codex, Gemini CLI, OpenCode or OpenClaw, and needing to know which files changed, which processes spawned and which services received requests. The README names the gap explicitly: logs controlled by the agent can be incomplete, disabled or modified, while kernel-level events are independent of application logging. That is the whole argument for this project. If you can edit the agent's code, a framework tracer is cheaper. If you cannot, you are the audience.

How eBPF and TLS call tracing produce a session view

The mechanism has two halves. On Linux, eBPF programs attached to kernel hooks emit events for process execution, file access and resource use. Separately, AgentSight captures plaintext at SSL/TLS call boundaries, which the README says happens without a proxy. Those two streams are correlated: LLM traffic is joined with the process and file events that surround it. The repository layout reflects that split. There is a bpf/ directory for the kernel-side programs, a collector/ crate for the user-space binary, and separate crates named agentsight-capture and agentsight-protocol. The Makefile builds them in stages: build-frontend, build-vis, build-bpf, then build-rust, and the Rust stage compiles both ext/vis and collector. So the shipped binary is the consumer of a library, agentsight-capture, which the README says exposes the same eBPF runners, agent-native sources, analyzers, event model, materialized view and sinks. Sessions are also readable from agent-native session files, which is why top, bind, vis and report work on Windows and macOS without eBPF at all. Only record and the eBPF-backed debug commands need the kernel side.

Install AgentSight and watch your first agent session

The quickest path is Cargo. The README gives this as the primary install command, with a release binary as the alternative.

cargo install agentsight

On Linux, there is also a Homebrew tap, which the README says currently supports Linux x86-64.

brew tap eunomia-bpf/tap
brew install eunomia-bpf/tap/agentsight
agentsight --version

Once installed, the live view is a single subcommand. According to the README, sessions are ranked by model, session tokens, health, process family, tool calls, file activity and network activity.

agentsight top

For a visual replay of file activity, the README shows a second subcommand that renders how a coding agent read, wrote, created, renamed and deleted files across a repository.

agentsight vis

On Linux, sudo is optional for top, and the README says eBPF is enabled automatically when sudo is already available. For a source build, the Makefile's install target pulls libelf1, libelf-dev, zlib1g-dev, make, clang and llvm via apt, then installs Node.js and Rust if they are missing. The README points to docs/build.md for the full source-build path.

Where AgentSight stops being the right tool

The kernel requirement is the first boundary. The README specifies Linux kernel 4.1 or newer with eBPF support, and recommends 5.0 or newer for record and the eBPF-backed debug commands. On Windows and macOS, top, bind, vis and report fall back to agent-native session files; the kernel-level view is not available there. The README also notes that native Windows builds are exercised by a Windows CI workflow, and the truncated text stops short of confirming a shipped Windows binary, so treat Windows as unproven. The second boundary is scope. AgentSight observes the system boundary, not the agent's reasoning. It will not tell you whether a prompt was well designed or whether a model's answer was correct; that is what eval-oriented tools do. A third limitation is more structural: TLS interception at the call boundary depends on the traffic being visible there. The README frames this as capturing plaintext at SSL/TLS calls, and does not document what happens with pinned certificates or custom TLS stacks. Anyone whose agent uses a non-standard transport should check that before assuming coverage.

AgentSight against application-level tracing tools

The README names LangSmith, Langfuse and Phoenix as application-level tools that are strong for traces, prompts, tokens, evals and latency when you own the application code, and Helicone as a gateway tool useful when provider traffic can be routed through a managed endpoint. The difference is where the observation point sits. Those tools see what the application chooses to report, which is enough for prompt-level debugging and evaluation. AgentSight sees what the kernel and the TLS layer record, which is enough for subprocess execution, file operations and cross-boundary correlation, but it does not produce the eval and prompt-management features the other category is built around. The honest framing is that these are complements. If your agent is your own code and you want to compare prompt versions, an application-level tool answers that question and AgentSight does not. If your agent is a binary you downloaded, AgentSight is the only one of the two that can see inside the run at all.

Licence, maintenance and what an upgrade costs

AgentSight is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive arrangement with no copyleft obligation on your own code, but the repository also vendors or links external components: the top-level entries include libbpf and bpftool, and the Makefile has a SYNC_VENDOR variable that defaults to 0 and is forced to 1 for the build target. Anyone redistributing a built artifact should check the licences of those vendored pieces separately, since MIT on the project itself does not automatically cover them. This is a description of the repository contents, not legal advice. On maintenance, the last push was on 2026-09-07, and the most recent release listed is v1.0.31 from 2026-09-05, following v1.0.30 and v1.0.29 in late August. The release cadence is frequent enough that pinning a version matters more than usual: the Makefile's build path compiles both BPF objects and Rust crates, so an upgrade can change the kernel-side programs and the user-space binary together. There is no documented rollback procedure in the README, so keep the previous release binary until a new one has been exercised against your own agents.

Editorial conclusion

Adopt AgentSight if you run closed-source coding agents on Linux and need to see subprocesses, file writes and TLS payloads that application-level tracing cannot reach. Do not adopt it if your team is on Windows or macOS and needs kernel-level capture: the README limits eBPF-backed record to Linux 4.1+, and the Homebrew formula covers Linux x86-64 only. Before committing, verify two things on your own machine: that your kernel version and sudo policy let the eBPF programs load, and that the agent you care about actually exposes its model calls through SSL/TLS calls the tracer can read.

Frequently asked questions

Official sources

1. eunomia-bpf/agentsight on GitHub
2. License: MIT
3. Project website
4. README
5. Releases