> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Why zero-code
> The problem zero-code instrumentation actually solves, when it is the wrong tool, and how to combine it with the OpenTelemetry SDK instead of choosing.
Instrumenting an estate with an SDK is not technically hard. It is hard to
*coordinate*, and that is a different problem with a different solution.
**Availability.** The zero-code agent is an early-access distribution. It is
installable, upgradable and tested, and it is **not yet an integrated part of
the product**: there is no dashboard page for it, no in-product installer and
no self-service download. Ask your account contact for access.
Its telemetry, once flowing, is ordinary OTLP and needs nothing special —
it appears in Services, Traces and Metrics exactly like SDK telemetry does.
That is the design rather than a shortcut.
## The problem it solves
Adding the OpenTelemetry SDK to one service is an afternoon. Adding it to
eighty is a programme, because each one needs a team with capacity, a
dependency bump, a code review, a test cycle and a deployment window. Some of
those services will not get one:
* **Nobody owns it.** It runs, it is important, and the team that wrote it has
moved on.
* **You cannot rebuild it.** A vendor binary, a legacy container image, a
language nobody left uses.
* **Change is expensive.** A regulated deployment path where a dependency bump
means a re-certification.
* **It is not worth an afternoon each.** Forty small services, individually
unremarkable, collectively the whole of your dependency graph.
The result is familiar: excellent telemetry from the services that were easy,
nothing from the rest, and a service map with holes exactly where incidents
turn out to live.
**The agent's value is coverage, not depth.** One install per host, and every
process on it becomes visible at once. It is the fastest way to answer "what
is actually running and what talks to what" — and it does not need anyone's
roadmap.
## When it is the wrong tool
**Do not choose zero-code when the question you need answered is inside your
code.** eBPF observes the boundary. If your open questions are "which
customer tier is affected", "which feature flag was on", "what did the
exception say" or "how long did the internal cache lookup take", the agent
cannot answer any of them, at any privilege level, ever. That is not a
limitation to be lifted in a later version — it is where the technique sits.
It is also the wrong tool when:
* **You do not control the kernel.** Serverless platforms, gVisor, Firecracker
and managed runtimes with no node access are out. See
[Compatibility](/zero-code/compatibility).
* **Your teams are already instrumenting.** If SDK adoption is happening
anyway, the agent adds cost and overlap rather than coverage.
* **Granting kernel capabilities is not approvable.** Some security teams will
not, and that is a legitimate answer. [Capability profiles](/zero-code/profiles)
exists to make that decision on evidence.
## Use both
Zero-code and the SDK are not competing choices, and treating them as one is
the most common mistake in evaluating this.
You get a complete service inventory, a real dependency graph, and RED
metrics on every service — including the ones that were never going to be
instrumented. This is your floor, and it arrives in an afternoon.
The five or ten services where incidents actually get diagnosed. Custom
spans, business attributes, exception detail.
The agent reads an incoming W3C `traceparent` and joins that trace. So a
request entering an SDK-instrumented service and passing through an
agent-only one produces **one** trace, not two.
**The join works because both speak OpenTelemetry.** There is no correlation
feature to enable and no vendor glue in the middle — it is the standard
context-propagation header doing what it was designed to do.
## What it replaces, honestly
| Instead of | You get | You still need |
| :------------------------------------------------- | :------------------------------------ | :--------------------------------------------- |
| An SDK rollout across dozens of low-value services | Coverage of all of them today | The SDK in the services you debug |
| A service inventory maintained by hand | One discovered from observed traffic | Ownership metadata, which no agent can infer |
| Guessing at your dependency graph | The edges that actually carry traffic | Nothing — this is where the agent is strongest |
| A network-level view from a service mesh | The same edges without a mesh | The mesh, if you use it for traffic control |
## The claim worth checking
Vendors describe agents like this as "100% OpenTelemetry". For most, the agent
is a proprietary binary that *emits* OpenTelemetry.
Here the agent **is** upstream OpenTelemetry eBPF Instrumentation, unmodified
and version-pinned. The practical test is portability: point it at a different
OpenTelemetry backend and it works, because there is nothing aiAxonIQ-specific
inside it. If you are comparing products, that is the question to ask each of
them. See [OpenTelemetry OBI](/zero-code/obi).
## Next
Enough kernel detail to answer a security question, and no more.
Three privilege levels and how to choose between them.
Whether your hosts can run it, stated per kernel and platform.