Agent Beacon: Open-Source Telemetry for AI Agents on Endpoints, CI, Browsers and Cloud

What Agent Beacon collects that a general observability stack does not

Most tracing tools answer questions about a service you wrote. Agent Beacon answers questions about an agent you installed. The README frames the problem as not knowing "what all of your agents are doing - across runtimes and environments, from endpoints and CI to browsers and the cloud", and the unit it produces is not a span for your HTTP handler but an event for a prompt, a tool call, a shell command, an approval, or a file edit.

The intended reader is a security or IT team, which the repository signals in three ways: the topics list includes endpoint-security, detection-engineering and security-information-and-event-management; the README links a dedicated "For Security & IT Teams" page; and the binary is described as shipping fleet-wide through MDM. A developer who wants to instrument their own Python agent will find the TypeScript SDK is one of several collection paths, not the centre of the product.

One event model over five collection paths

The architecture image in the README splits the system into sources, a Beacon layer, and destinations. Sources are not uniform, and the collection path differs per runtime: local agents arrive through hooks, plugins, or local OpenTelemetry; browser chat arrives through an optional extension; agents in code arrive through the TypeScript SDK; CI pipelines arrive through what the README calls a temporary collector; cloud agents arrive through sandbox hooks.

The Beacon layer then does the same five things for every source: collect, normalize, store, correlate, and detect. Normalization is the substantive part. The README says activity is normalized "into a single, unified schema", and the event model is OpenTelemetry-based, so the output is not a proprietary log format you have to parse yourself. Storage is a durable JSONL log plus a session timeline, and detection runs locally in what the README calls a local detection engine surfaced in the dashboard.

The default posture is local: "Collection, processing, and inspection stay local by default." Forwarding to a SIEM or object storage is a destination you opt into, not the path telemetry takes by default. That matters for teams with agents touching source code, because the first thing you can do is inspect events on the machine rather than ship them to a vendor.

Installing the endpoint binary and reading your first events

The README links installation to the docs site at docs.asymptotelabs.ai/cli/installation and says the project "installs with one command or fleet-wide through MDM". The repository also carries a Homebrew badge pointing at asymptote-labs/homebrew-tap, so the tap is the packaging channel named in the README. The exact install command is not reproduced in the README text, so check the installation page before running anything.

Once the binary is present, the command surface is the beacon endpoint command. The one path the README spells out in detail is the fx runtime, which is polled rather than hooked:

beacon endpoint fx sync

Running that pulls fx's own session records from `~/.fx/sessions/` and converts them into Beacon events. The README is explicit about the consequence: events land a turn late and cannot gate a tool call. If you are evaluating Beacon against the fx runtime, that single command tells you what the integration can and cannot do before you commit to a rollout.

For the other runtimes the shape is different. Claude Code and Codex CLI use local OTLP export, sometimes plus a hook for session identity; Cursor, Antigravity CLI and Devin CLI use native hooks; Cline uses managed plugin hooks. In practice this means installation is per-runtime configuration, not a single global switch, and the runtime-specific pages linked from the support table are the ones that matter.

Where the coverage table is honest and where it is thin

The support table is unusually candid for a project README. The fx row states plainly that approval and session-end records are missing "because fx persists neither", and that the integration cannot gate a tool call. That is a limitation stated by the project rather than discovered by a user.

The same table shows that coverage is not equal across runtimes. Claude Code lists prompt, command, tool, file, approval, API/model lifecycle, MCP connection, subagent and session. Cursor lists prompt, tool, shell command, MCP-like activity, approval and file edits. Factory Droid lists session, prompt, write/edit/create tool use, stop and session end. So a fleet running three runtimes will produce three different event densities in the same schema, and any detection rule that assumes an approval event exists will fire differently depending on which agent generated the row.

The README also does not document rollback. There is no uninstall path in the page text, no statement about what happens to the JSONL log when the binary is removed, and no retention policy for the local store. For a tool that records prompt and file content, those are questions to answer from the docs before an MDM push, not after.

Agent Beacon compared with OpenTelemetry-native tracing

The obvious alternative is to instrument agents yourself with the OpenTelemetry SDK and send spans to whatever backend you already run. The difference is where the work sits. With plain OpenTelemetry you control the schema and you write the instrumentation for each agent; you get exactly the attributes you chose, and nothing for runtimes you did not touch. Agent Beacon inverts that: it ships integrations for 21+ local runtimes and several hosted surfaces, and you accept its unified schema and its per-runtime coverage gaps in exchange for not writing hooks for Claude Code, Codex CLI, Cursor, Gemini CLI and the rest.

A second alternative is a managed AI observability platform. The README draws this line itself, offering a "system architecture overview" to "compare it with the managed path", and the distinction it draws is control: collection, processing and inspection stay local by default, and forwarding is to customer-owned destinations. If your constraint is that agent telemetry cannot leave your infrastructure until you decide it can, the local-first default is the reason to pick this over a hosted product. If your constraint is that nobody on the team wants to run a collector, the same default is the reason not to.

Licence, release cadence and what an upgrade actually costs

Agent Beacon is MIT licensed, and the README carries the MIT badge alongside the LICENSE file at the repository root. MIT is permissive: you can use, modify and redistribute the code, including commercially, provided the copyright notice and permission notice are retained. That is the extent of what the repository states. It says nothing about contributor licence agreements, trademark use of the Agent Beacon name, or whether any part of the managed path at docs.asymptotelabs.ai is covered by different terms, and none of that is legal advice. If you plan to redistribute a modified binary inside a product, read LICENSE and SECURITY.md yourself rather than relying on a badge.

The release history shows v1.3.7, v1.3.8 and v1.3.9 within three days of each other in early September 2026, and the last push to main was on 2026-09-10. That is a fast patch cadence on the 1.3 line, which is good for fixes and awkward for change control: an MDM-managed fleet pinned to a version will fall behind quickly, and a fleet tracking latest will absorb three releases a week. The repository includes a beacon-release-validation-runbook.md and a beacon-sandbox/ directory, which suggests the project has its own validation process, but the README does not describe a compatibility policy between minor versions or a deprecation window for the event schema. If your SIEM parsing depends on specific fields, pin the version and test the schema on each bump.

Editorial conclusion

Adopt Agent Beacon if you already run agents such as Claude Code, Codex CLI or Cursor on managed endpoints and need their prompt, tool and file activity in one schema you can forward to a SIEM or keep as local JSONL. Do not adopt it if you want distributed tracing inside your own agent code, or if your agents are the fx runtime and you need a pre-tool approval gate, because the documented fx path polls session records and lands a turn late. Before rollout, verify two things yourself: which of the 21+ runtime integrations match the agents you actually run, and which output destination your team already operates, since the README names SIEMs, log aggregators and object storage as targets but the truncated page does not list them.

Frequently asked questions

Official sources

1. Asymptote-Labs/agent-beacon on GitHub
2. License: MIT
3. Project website
4. README
5. Releases