From @anvia/lens to Anvia Lens

An agent trace and an evaluation result describe the same system from different angles. The trace explains what happened during one run. The evaluation explains whether that behavior met an expectation. They become far more useful when they can point to each other.

@anvia/lens is the native connection between the Anvia runtime and Anvia Lens. It exports traces and correlated evaluation results over OTLP HTTP with project-scoped credentials.

An observer with an explicit lifecycle

The smallest integration attaches a Lens observer to an agent:

import { AgentBuilder } from "@anvia/core"
import { lens } from "@anvia/lens"

const tracing = lens.create()

const agent = new AgentBuilder("support", model)
  .name("Support Agent")
  .observe(tracing)
  .build()

await agent
  .prompt("Summarize this ticket.")
  .send()

await tracing.flush()

The adapter creates isolated OpenTelemetry trace and log providers. It does not register global providers or export unrelated application telemetry. Several Lens instances can exist without silently rewriting the host application's OpenTelemetry setup.

Long-running processes call shutdown() during application cleanup. Short-lived jobs call flush() after their final run. Delivery is part of the lifecycle rather than a background side effect the process may exit before completing.

Safe capture is the default

Operational metadata is often enough to answer the first question: which agent, model, tool, release, environment, latency, and usage were involved? Lens records that data in safe capture mode without exporting input and output bodies.

Full payload capture is opt-in:

const tracing = lens.create({
  captureMode: "full",
  captureMaxBytes: 128 * 1024,
  redactInputs: true,
  redactOutputs: true,
})

The built-in redactor masks common email, credential, bearer-token, and payment-card patterns. Applications can add domain-specific patterns. Capture-size limits still apply after the decision to include payloads.

This is intentionally not an all-or-nothing observability switch. A production service can keep operational traces while reserving full capture for environments and data classes where it is approved.

Evaluation is correlated, not attached later

Lens evaluation reporters carry run identity, suite lifecycle, cases, metrics, outcomes, usage, and trace references through the same telemetry connection.

import { AgentBuilder } from "@anvia/core"
import {
  agentEvalTarget,
  runEvalSuite,
} from "@anvia/core/evals"
import { lens } from "@anvia/lens"

const evals = lens.evals({
  serviceName: "support-evals",
  includePayloads: true,
  optional: true,
})

const agent = new AgentBuilder("support", model)
  .observe(evals.observer)
  .build()

await runEvalSuite({
  ...suite,
  target: agentEvalTarget(agent),
  reporters: [evals.reporter],
})

Lens receives run start and finish events along with each metric outcome. A failed faithfulness case can link back to the agent trace that produced its output. A completed suite can be grouped as one evaluation run, compared across releases, and checked against a quality gate.

Case payloads and arbitrary metadata are omitted by default. When enabled, they pass through the tracing instance's redaction transforms and capture limit.

Managed datasets make a run reproducible

The Lens dataset client fetches immutable published dataset versions and returns cases ready for @anvia/core/evals. Pagination is handled by the client, while the evaluation run records the dataset name and version it consumed.

That gives a comparison a stable input boundary. The latest development dataset can keep changing, but the run that evaluated release 2026.08.09 can still point to the exact published version used at the time.

The same project public and secret keys authenticate telemetry writes and dataset reads. Dataset publication remains a product workflow in Lens; evaluation execution remains application code.

Why the adapter is native

Anvia also supports general observability backends. Lens is different because its adapter can evolve with Anvia-specific concepts: agent and generation identity, prompt references, release and environment context, evaluation lifecycle, managed datasets, and direct run links.

The package stays narrow despite that integration. It observes runs, reports evaluations, and reads approved datasets. The application still defines the agent, chooses what may be captured, owns its release policy, and decides when telemetry is flushed.

Read the Lens package documentation, the Lens product guide, and the Lens adapter changelog.