Skip to main content

Overview

Beacon supports multiple runtime surfaces because each agent harness exposes telemetry differently. Beacon collects and normalizes supported local, CI, and cloud-agent telemetry, while Beacon Cloud adds hosted ingest, visibility, and governance on top of the same surfaces. These integrations are grouped by where the agent runs and how telemetry is collected:
  • Local: Agent harnesses running on an endpoint write telemetry to Beacon’s local collector, hook adapter, plugin, or gateway path.
  • Browser chat: An optional MV3 extension for Chromium browsers and beta Firefox reads the chat streams of supported sites and posts them to the same local collector.
  • CI: Ephemeral CI jobs use a temporary collector and write normalized runtime JSONL as a build artifact or upload target instead of installing a persistent endpoint service.
  • Cloud: Provider-managed cloud agents can write session telemetry from the cloud sandbox to customer-managed storage, while SDK integrations instrument agent applications that run in servers, serverless functions, workers, and hosted agent platforms.

Support matrix

Local coding agent harnesses

Poll collection reads records a runtime has already committed to disk, so every event from those paths is marked harness.collection_method=poll. It is useful for backfill and scheduled catch-up, but it cannot hold, approve, deny, or delay a tool call. fx is the pure poll case because it exposes no hook, plugin, or OpenTelemetry surface at all; the other poll paths complement live hooks, plugins, or OTLP export.

Local knowledge worker agent harnesses

Browser chat surfaces

Both sites are collected by one optional extension, with one build for Chromium browsers and a separate beta Firefox build. Browser chat resolves to the claude_web and chatgpt_web harness names, so it stays distinguishable from CLI agents. The extension retains full prompt and response text by default. See Browser Extension to install it and to change the retention mode.

CI harnesses

Cloud agent harnesses and SDKs

Deployment notes

Local agent harnesses need the endpoint agent installed on the machine they run on. Use the native package for that platform, which installs and starts everything in one step:

macOS

Signed, notarized .pkg for Jamf Pro, Fleet, Rippling, or manual install.

Linux

.deb and .rpm for amd64 and arm64.

Windows

.msi for x64, installed as a Windows service.
Each package installs the endpoint agent, starts the local collector as a service, and configures the installing user’s supported agent runtimes to export to it. Paths differ per platform: MDM assets, meaning Jamf Pro Extension Attributes, Fleet osquery queries, and Rippling deployment, are macOS only. On Linux and Windows, deploy the package with whatever configuration management you already run.

Enterprise runtime configuration

The default user-mode install discovers and configures supported user-level hooks, plugins, and extensions. Use beacon endpoint hooks install for an explicit target or project-level setup. OpenHands CLI/GUI coverage specifically requires project scope, and goose remains the exception: its adapter can map manually configured hooks, but Beacon does not yet install or discover it. System packages and MDM scripts keep their explicit fleet harness lists because runtime hook configuration belongs to the logged-in user’s profile. Poll sync commands are also run or scheduled in the account that owns the runtime’s local session store. If a system collector is running while the CLI is reading the default per-user log, beacon endpoint status and the local dashboard surface a runtime-log source warning so you can tell where OTLP events are being written.

Core concepts

Runtime surfaces, agent harnesses, and endpoint events.

Agent harness integration model

See how Beacon discovers and configures each runtime.

Hooks

Install, inspect, and uninstall runtime hook integrations.

MDM deployment

Deploy Beacon through Jamf Pro, Fleet, or another macOS MDM.