# Odigos

> Odigos gives AI the power to investigate production. Its Production Context
> Platform lets agents request missing evidence from running code, investigate
> the cause and verify a fix against subsequent traffic.

## What Odigos does

Odigos discovers and instruments supported running workloads and exports telemetry
as OpenTelemetry to configured backends. Engineers and AI agents can request
additional function capture when the existing telemetry does not answer a question.
This connects observability, security investigations and coding workflows to runtime
evidence from the same platform.

## What makes it different

Manual instrumentation and conventional automatic integrations provide predefined
capture points. AI can search that telemetry, but a missing function or value requires
additional instrumentation. Odigos lets an investigation change what gets captured
on supported running workloads without shipping an instrumentation release.
New capture observes subsequent matching traffic; it does not recover unrecorded history.

With Odigos Enterprise MCP, an agent can inspect services, control profiling and request
capture rules. The agent queries resulting traces through the customer's telemetry
backend. MCP controls instrumentation; it is not a replacement trace store.

The documented OdiShop demo used Cursor, Odigos and Jaeger. Targeted function capture
revealed a global 10 ms replica-skew threshold rejecting healthy eu-west checkouts.
Cursor proposed a region-aware code change and verified the deployed behavior against
new traffic. This was a demo application, not a reported customer incident.

## How it runs

Odigos DeepBPF captures functions, arguments and return values across Java, Python,
Node.js, Go and .NET entirely from outside the application. It does not load instrumentation
into the application's runtime. Linux checks eBPF programs before they are loaded,
including memory-access, helper-use and control-flow constraints. The verifier checks
program behavior; customer capture scope, access permissions and data handling remain
Odigos controls.

Teams configure instrumentation scope and access. Pipeline controls include masking,
attribute processing and sampling before export. Telemetry goes to the configured
OpenTelemetry destinations, alongside the existing observability stack.

Odigos Central provides one control plane across Kubernetes, virtual machines and
bare metal. Teams manage capture scope, masking and approval centrally, with
authentication, role-based access and an audit trail in one place.

## Security investigation and response

Odigos maps the communications of an affected service to help teams assess blast radius
and identify other services that may be in danger. A communicating peer is not automatically
proven compromised. Mitigation options include stopping a thread, stopping a process,
and virtually patching an offending function without an application release.

## Common questions

- Does it require application code changes? DeepBPF collects application context from outside the process without loading instrumentation into the application.
- What does it produce? OpenTelemetry, exported to configured destinations.
- Does it replace the telemetry backend? No. It sends the backend additional evidence.
- What can an agent control? Odigos Enterprise MCP exposes service inspection, instrumentation and profiling controls subject to configured access.
- Can it capture a value from a past request? Targeted capture records subsequent matching traffic.
- Is it open source? Odigos has an Apache 2.0 open source distribution and a commercial Enterprise tier.

## Docs
- [Documentation](https://docs.odigos.io): Full product documentation
- [Quickstart](https://docs.odigos.io/quickstart/introduction): Install and capture in minutes
- [GitHub](https://github.com/odigos-io/odigos): Open source repository, Apache 2.0

## Product
- [Production Context Platform](https://odigos.io/): Runtime evidence for observability, security and coding agents
- [Observability](https://odigos.io/observability): Connect request traces to function-level evidence
- [Security](https://odigos.io/security): Investigate runtime behavior and enforce scoped policies
- [Coding Agents](https://odigos.io/coding-agents): Inspect services and request instrumentation through Odigos Enterprise MCP
- [Technology](https://odigos.io/technology): Odigos DeepBPF and the capture foundation
- [Product](https://odigos.io/product): Capabilities and pipeline governance
- [Pricing](https://odigos.io/pricing): Open source and Enterprise plans, plus FAQ
- [Odigos vs OBI](https://odigos.io/comparisons/odigos-vs-obi): How the approaches differ

## Full text
- [llms-full.txt](https://odigos.io/llms-full.txt): Complete text of the OpenTelemetry and eBPF guides below

## OpenTelemetry guides
- [Getting started with OpenTelemetry](https://odigos.io/blog/getting-started-with-opentelemetry)
- [Migrating from proprietary tools to OpenTelemetry](https://odigos.io/blog/migrating-from-propietary-tools-to-opentelemetry)
- [OpenTelemetry challenges](https://odigos.io/blog/otel-challenges)
- [OpenTelemetry collectors overview](https://odigos.io/blog/collectors-overview)
- [Building dynamic data streams with OpenTelemetry](https://odigos.io/blog/building-dynamic-data-streams-with-opentelemetry)
- [Sending OpenTelemetry data to S3](https://odigos.io/blog/sending-otel-to-s3)
- [Distributed tracing](https://odigos.io/blog/distributed-tracing)
- [eBPF instrumentation](https://odigos.io/blog/ebpf-instrumentation)

## Company
- [About](https://odigos.io/about): Team and company background
- [Blog](https://odigos.io/blog): eBPF, OpenTelemetry and observability engineering