Odigos
Get a demo
Odigos
The production context platform

Production context.For every decision.

Odigos records what runs inside every service, live, with nothing in your code. Your engineers, AI agents and security teams get the evidence they need.

Get a demo
metrics
traces
logs
traces
profile
function values
code "BLACK50"
rule nil
returned 0.00
checkout revenue is down 12%following a checkout that completedwhatever that path already recordsnothing here backing out, trying elsewheretrying the promo pathfinding out which functions randynamically instrumenting applyDiscount()
cause foundthe rule lookup came back empty

Running in production at

t-mobile
csaa
merck
avodaq
avetta
hp enterprise
inpost
deephealth
omnissa
The platform, in one picture

Record production once. Debug it, defend it, and check what you shipped.

Logs and metrics record what someone predicted would matter. Incidents and attacks are the cases nobody predicted. Odigos keeps one record of what happened inside every running service, live, from outside your code, and every purpose reads from it. An engineer or an AI agent asks it after a page. A policy your team approved checks it on every call and refuses one. A coding agent checks what the change it just shipped did, before the next commit.

Why did checkout fail for these customers, and what changed?
Discount code missing from the rules table since the 14:02 deploy. 312 orders paid full price. Fix is one row.
01 / Observability

The cause from the code, not a guess from a graph.

Every trace from every service on day one. When the trace runs out, an engineer or an AI agent asks production what the code did on the failing request and has it in seconds. The cause is found in minutes, without a deploy.

Explore observability
Which of ten thousand permitted calls is the attack, and can we refuse just that one?
One reflective call in the ticket service, reached through a normal session. Policy refuses that call. Service still serving.
02 / Security

Block the attack call. Keep the service.

An AI-driven attack moves as permitted calls between services. WAF, EDR and SIEM each see a permitted call. Odigos records every call and enforces a policy your team approved: it refuses the call the policy names, and nothing else. The service keeps serving. Scoped to the callers you name, the policy ships and reverts without a redeploy and comes off when the fix lands.

Explore security
Did the retry change I shipped at 14:30 do what I meant?
No. Every failed payment now retries against the slow region. Latency on payments-api is 3x since the deploy. Revert one flag.
03 / Coding agents

Wrote it at 14:30. Checked it at 14:31.

Claude Code, Cursor, Copilot and the agents you build ship faster than anyone can watch. After each deploy they ask the record what their change did on real requests, so the fix is in the next commit, not the next incident. Same approvals, masking and audit as an engineer.

Explore coding agents
The wait

Same incident, two AI agents. One opens a pull request. One answers.

The one that can only read what someone logged in advance adds a log line and waits for the bug to happen again. The one on Odigos asks production what the code did. Hours to days against seconds, on every incident, on every team.

without Odigosit opens a pull request
>why is checkout revenue down 12%
Traces look clean. 200s across POST /orders, p99 flat. The only thing I cannot see into is the discount path.
Read(promo.go)Read 84 lines
applyDiscount returns early when the rule lookup misses, and nothing logs what it returned. I cannot confirm this from here.
Update(promo.go)Updated promo.go with 1 addition
41 rule := rules.For(code)
42 if rule == nil {
43+ log.Info("discount", "returned", 0.0)44 return 0
Opened PR #4471. Once it is reviewed and deployed I will know after the next occurrence.
hours to days before it can answer
with Odigosit queries production
>why is checkout revenue down 12%
Traces look clean. 200s across POST /orders, p99 flat. The only thing I cannot see into is the discount path.
odigos - find_functions("checkout", "discount")84 functions, applyDiscount at promo.go:41
odigos - capture("applyDiscount", args, returns)attached in 1.2s, nothing redeployed
odigos - read("applyDiscount")code "BLACK50", cart 49.00, returned 0.00
Found it. BLACK50 is missing from the rules table, so applyDiscount returns 0 and every order using it paid full price.
seconds and it can ask the next one
What production context means

Three things telemetry was never built to do.

They decide whether production answers, or someone guesses. For an engineer, a security policy, or the agent that wrote the code.

01 / 03

Every service on day one. Even the ones nobody owns.

One install covers the estate: the modern services, the fifteen-year-old Java, the stripped Go binaries most tools skip, the third-party code with no owner. No code changes, no rollout program, no team left to instrument by hand. Whoever asks sees all of production, not the parts someone got to.

every languagelegacy and modernno code changes
Complete
everyone else stops herethe syscall
POST /orders214ms · 200 OK
GET /cart31ms · 200 OK
that is the whole story they can tell
the edge of your service
odigos reads hereinside the code
applyDiscount("BLACK50", $49.00)
returned $0.00on every call
the value that explains the drop, out of a running service
02 / 03

It senses where the fire is, and looks there first.

The moment a service drifts, Odigos Autofocus starts capturing deeper evidence on that path: what the code did, with what inputs, on the requests that failed. By the time anyone asks, the answer is already there. Ask about anything else and it captures that too, in seconds, with no redeploy. Inside the limits your team approved, every capture audited.

Autofocusanswered in secondsno redeploys
Odigos Autofocus
AI agent
investigating
Production
342 services
asks ❯ capture goroutine stack for checkout
stack + 14 spans returnedlive
03 / 03

Out of process. Out of your blast radius.

Odigos never enters your process. A bad question, or a bad release of ours, reaches our sensor and stops there. Every capture names the workload and the code it may read, has a named approver under role-based access, masks sensitive values before anything leaves your cluster, and lands in your audit trail. AI agents work inside the same limits as your engineers, and every question they ask is logged. Policies are written and approved by people.

out of processnamed approveraudited, masked in-cluster
Safe
<1%
CPU overhead
out-of-processkernel-enforcedno in-process agent
How it works

One command. Nothing changes in your applications.

Odigos installs on the cluster, finds every service, and starts producing OpenTelemetry from all of them with no code change. One Fortune 500 swapped out the bytecode agent in its process on 1.04 million cores and measured the difference. The backends you already pay for keep getting fed.

1
Install

One command, any environment

Run one command on Kubernetes or Linux. Odigos finds every service, works out what language it runs and what it talks to, and starts there. You do not tell it anything.

❯odigos install
2
Capture

Inside the application, outside your code

Our own eBPF runtime reads what happens inside each service as it runs: the code paths taken, the queries made, the values carried. Nothing is wired into your applications.

eBPF probe attachedargumentsreturn valuesstacks
3
Ask

Autofocus on the drift

When a service drifts, Autofocus captures deeper on that path before anyone asks. Anything else is captured live on request. All of it exports as OpenTelemetry into whatever you already run, and into the AI agents that do the asking.

DatadogGrafanaSplunkyour AI
Governed by design

One question someone approved. One answer from production.

A capture names a workload and the code it may read. It is scoped, reversible, approved under role-based access, and masked for sensitive values before it leaves your cluster. Reading a value out of production is a decision your organisation made, with an audit trail, not a side effect of an AI agent.

The Odigos console: detected sources, in-flight actions and export destinations for a production cluster
Benchmarked by a customer

A Fortune 500 ran it across a million cores. Up to 27.6% less CPU than the bytecode agent it replaced.

Odigos runs outside your applications, so depth stops costing you throughput. One Fortune 500 customer benchmarked it against the bytecode agent already in their process, on the same traces, across 1.04 million cores. One of the largest retailers in the world built its own regression-finding AI agent on this data. Security runs on the same sensor and the same install, with no second agent to approve.

< 1%CPU overhead, out of process. Safe to leave on across all of production.
27.6%less CPU than the bytecode agent at the top of the range they measured, on identical traces, on their own hardware.
1.04Mcores under measurement when they ran it. New question. No new code.

// 11 enterprises in production, SOC 2 audited

One command. Kubernetes, VMs, bare metal.

Install today. First answer tomorrow. Security on the same install.

Get a demo

One record, every purpose. One service, fourteen days, success criteria written first.

From the team

Latest from the blog.

All posts