Agent Beacon: A Local-First Telemetry Layer for AI Agent Runtimes
Agent Beacon is the world's first open-source telemetry layer for AI agents wherever they run: locally, in CI, in the browser, or in the cloud.
At a glance
- What is it?
- Agent Beacon is an MIT-licensed Go binary that collects activity from more than 21 local agent runtimes, a browser extension, CI pipelines, and a TypeScript SDK, then normalizes everything into one OpenTelemetry-based event model. The judgement: it is a serious fit for security and IT teams that need an audit trail across heterogeneous agent tooling, and a poor fit for anyone who wants a hosted service with no local operational burden.
- Who is it for?
- Adopt Agent Beacon if you run several different agent runtimes across endpoints and CI and need one normalized event stream you own, and if you have someone who can operate a local collector and its forwarding destinations. Do not adopt it if you need to gate tool calls in real time: the fx collection path, by the project's own documentation, lands events a turn late and cannot block a tool call.
- 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 received new commits within the last day.
- What is it written in?
- Mainly Go, 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 problem Agent Beacon targets: agent activity scattered across runtimes
An engineering organization rarely standardizes on one coding agent. One team runs Claude Code, another uses Cursor, a third has Codex CLI in CI, and someone is experimenting with Gemini CLI or Factory Droid. Each of those tools emits its own telemetry, or none at all, in its own format, on its own schedule. The result is that nobody can answer a basic question: what did agents do across this fleet last week, and did any of it touch a sensitive file or run a destructive command?
Agent Beacon is aimed at that gap. Its README describes it as an open-source telemetry layer that captures activity where each agent actually runs and normalizes it into a single, unified schema. The audience is explicit in the documentation navigation: there is a page titled For Security & IT Teams, and the repository topics include endpoint-security, detection-engineering, and security-information-and-event-management. This is a security and compliance tool that happens to be built by people who understand developer tooling, not a developer productivity dashboard.
The scope claim is broad. The README states support for 21+ local agent runtimes and every major surface agents run on, with collection paths that differ per runtime: native hooks for some, local OTLP export for others, a managed plugin for Cline, polling session records for Vercel Labs' fx, and an optional browser extension for chat surfaces. Whether that breadth holds up in your environment depends entirely on which runtimes you actually use and whether they expose a hook surface Beacon can attach to.
One event model, four collection surfaces, and a durable JSONL log
The architecture diagram in the README divides the system into three layers: sources, Beacon itself, and destinations. Sources are local agents (via hooks, plugins, or local OpenTelemetry), the browser (via an optional extension), agents embedded in code (via the TypeScript SDK), CI pipelines (via a temporary collector), and cloud agents (via sandbox hooks). Beacon then collects, normalizes, stores, correlates, and detects. Every surface is meant to land in one event model, one durable JSONL log, one session timeline, and one local detection engine.
The normalization target is OpenTelemetry. That choice matters more than it first appears. Because the event model is OTel-based, the forwarding step is not a bespoke integration problem: the same stream can go to SIEMs, log aggregators, and object storage that already speak OTel or accept OTLP. The README lists output destinations as major SIEM, observability, and data platforms, with a dedicated section on output destinations in the docs.
The default posture is local. Collection, processing, and inspection stay on the machine unless you configure forwarding. That is a deliberate contrast with hosted agent-observability products, where the vendor sees your prompts and tool calls. The README is careful to note that the same normalized event model extends to CI, cloud-agent, and SDK paths under customer control, which is the honest way of saying the remote paths exist but you operate them.
Coverage depth varies by runtime, and the README table is worth reading closely rather than skimming. Claude Code gets the widest list: prompt, command, tool, file, approval, API/model lifecycle, MCP connection, subagent, and session. Cursor covers prompt, tool, shell command, MCP-like activity, approval, and file edits. Gemini CLI is opt-in local OTLP covering prompts, tool calls, MCP activity, file operations, and approval-related events. The variation is a property of the runtimes, not a defect in Beacon, but it means two agents on the same machine can produce different levels of detail.
Installing the endpoint binary and pointing it at a destination
The project ships as a lightweight endpoint binary and installs with one command, per the README, with a Homebrew tap referenced in the badge row and an installation page under the CLI docs path. Fleet-wide deployment is documented through MDM, which is the path that matters if you are rolling this out to more than a handful of machines.
The command surface is organized around the endpoint. The README references `beacon endpoint fx sync` as the collection mechanism for Vercel Labs' fx runtime, which polls fx's own session records under `~/.fx/sessions/`. That naming pattern implies a subcommand structure of `beacon endpoint <runtime> <action>`, and the docs include a command reference page for the full set. I have not run the binary, so treat the exact flags as something to confirm against the command reference rather than this description.
Configuration keys are not enumerated in the supplied README. What is confirmed is that there is a unified event schema documented at a dedicated page, a dashboard for local inspection, and an output-destinations section covering SIEM, observability, and data platforms. The practical setup sequence the material supports is: install the binary, enable the collection path for each runtime you care about (native hooks, local OTLP export, or a managed plugin, depending on the runtime), confirm events appear in the local dashboard, then configure forwarding to your destination.
The MDM path deserves separate attention because it changes the failure modes. Pushing a binary fleet-wide means you also own version drift, signing, and the update channel. The release cadence visible in the repository suggests this is a moving target: three releases (v1.3.7, v1.3.8, v1.3.9) landed within roughly four days in early September 2026. A fast cadence is normal for young tooling, but it means an MDM deployment without an update policy will leave you running stale collectors within weeks.
Where the fx collection path shows the design's honest limits
The fx (Vercel Labs) row in the supported-runtimes table is the most informative entry in the README, because it states its own constraints without hedging. Collection works by polling fx's session records under `~/.fx/sessions/` through `beacon endpoint fx sync`. Two consequences follow directly from that mechanism, and the table names both: events land a turn late, and they cannot gate a tool call. There is also no approval or session-end record, because fx persists neither.
That is a real limitation, not a documentation footnote. If your use case is blocking a dangerous tool call before it executes, a poll-based collector is the wrong architecture for that runtime, no matter how good the normalization is. Beacon's detection engine runs on the collected stream; detection on a stream that arrives after the action is forensic, not preventive. For fx specifically, you get an audit trail, not a control plane.
The same reasoning applies more broadly. Native-hook runtimes can surface pre-tool events, which is what makes gating conceivable at all. Runtimes collected through OTLP export or session polling are inherently after-the-fact. If you are evaluating Beacon for enforcement rather than visibility, the first thing to check is which of your runtimes expose a pre-tool hook and which do not. The README's per-runtime coverage column answers that question directly, and the answer differs per row.
There is a second limitation worth naming: the breadth of the supported-runtimes list is also its maintenance burden. Twenty-one runtimes, each with its own hook format, plugin API, or session file layout, means the project carries a long tail of integrations that can break when a vendor changes its internals. The four-day, three-release window is consistent with that pressure.
Agent Beacon against raw OpenTelemetry collection
The obvious alternative for a team that already has observability infrastructure is to skip Beacon and collect from each agent directly with OpenTelemetry. Several of the supported runtimes already export OTLP natively: Claude Code supports local OTLP export, Codex CLI uses local OTLP plus a session identity hook, Gemini CLI has opt-in local OTLP, and Factory Droid uses OTLP HTTP. If your agents speak OTLP, you can point them at your existing collector and be done.
The difference is in what happens after collection. Raw OTLP gives you spans and metrics in whatever shape each runtime emits. Beacon's contribution is the normalization step: mapping prompt, tool, file, approval, MCP, and token-usage events from different runtimes into one schema, so that a query for file edits does not need a per-runtime branch. It also adds a local detection engine and a session timeline on top of the collected stream, which a generic collector does not provide out of the box.
The trade-off is a component you now run and update. A generic OTel collector is a well-understood piece of infrastructure with a large operational community; Beacon is a younger, narrower tool with a fast release cadence. If your fleet is small and homogeneous, or if you only care about runtimes that already export clean OTLP, the normalization layer buys you less than it costs. If your fleet is heterogeneous and your security team needs one query surface, the normalization is the whole point.
Maintenance cost, version drift, and what the MIT licence does and does not settle
The licence is MIT, which is permissive and imposes essentially no obligations on how you deploy or modify the code. That is the right licence for an endpoint agent that security teams need to audit and potentially fork. It does not, however, answer any of the questions that actually matter for an endpoint deployment: who signs the binary, how updates reach managed devices, and what happens when a runtime vendor changes its hook format and the corresponding collector silently stops emitting.
The release history in the supplied material covers only a few days, so it cannot support a claim about long-term cadence. What it does show is that the project is actively changing, and that patches arrive quickly. For a security tool, quick patches are good. For a fleet deployment, they are an operational commitment: every release is a candidate for your MDM pipeline, and skipping them accumulates risk in a component that sits on developer endpoints.
The upgrade cost is therefore dominated by your own deployment mechanics rather than by the software. If you already push binaries through MDM with staged rollout and a rollback path, incremental cost is low. If your developers install it themselves via Homebrew, you have no version inventory at all, which is a poor position for a tool whose purpose is audit. The licence permits either approach; only one of them produces a defensible record.
Editorial conclusion
Adopt Agent Beacon if you run several different agent runtimes across endpoints and CI and need one normalized event stream you own, and if you have someone who can operate a local collector and its forwarding destinations. Do not adopt it if you need to gate tool calls in real time: the fx collection path, by the project's own documentation, lands events a turn late and cannot block a tool call. Before committing, verify three things against your own environment: which of your runtimes appear in the supported table and through which collection path, whether your MDM can deploy and update a signed endpoint binary, and whether the JSONL retention and SIEM forwarding you configure satisfy your own audit requirements. Start with the endpoint binary on one machine and one runtime, confirm the events in the local dashboard, and only then roll out through MDM.
Community notes