You Do Not Need to Own the Mind to Observe the Runtime

Observability used to mean understanding software we owned. We instrumented our services, inspected their logs, traced their calls, and measured their infrastructure.

Large language models changed that assumption.

Many production AI applications call models operated by another company. The application owner cannot inspect the model weights, training data, internal activations, or complete reasoning process. Yet an increasingly mature observability layer has formed around these opaque systems.

It works by observing the boundary.

The system records what went into a model call, what came back, how long it took, which model and provider handled it, how many tokens were used, which tools were called, which documents were retrieved, how agents handed work to one another, and whether the result satisfied an evaluator or produced a useful outcome.

That does not reveal everything happening inside the model. It reveals enough of the surrounding runtime to operate, compare, evaluate, and improve the larger system.

Human cognition presents a similar problem. We do not own the human processor. We cannot inspect private thought as source code. Most useful human-performance signals are partial, contextual, and sometimes derived through proprietary analytics. But we can observe the authorized boundary around human participation: what information was available, what was sampled, how the person interacted, which state estimates were produced, what action followed, and whether it helped.

This is the opening for Human Runtime, or HRT.

Observability does not require full access to an internal process. It requires a trustworthy account of the signals, context, actions, and outcomes around it.

LLM observability already monitors systems their users do not own

A company using OpenAI, Anthropic, Google, Amazon Bedrock, or another managed model generally interacts through an API. The model remains a black box. Instrumentation can still wrap the client library, proxy the request, or create spans around the call.

OpenTelemetry’s emerging generative-AI conventions provide standard fields for model providers, requested and returned models, token usage, operations, tools, and other runtime attributes. The specification explicitly accounts for cases in which the apparent API provider may differ from the underlying model host. OpenTelemetry GenAI attributes

OpenInference builds an AI-specific semantic layer on top of OpenTelemetry. It defines trace structures for LLM calls, agents, tools, retrieval, reranking, guardrails, prompts, and evaluators. Its LLM spans can describe calls to external providers using the request parameters and responses visible at the application boundary. OpenInference specification, OpenInference LLM spans

OpenLLMetry similarly instruments supported frameworks and foundation-model APIs on top of OpenTelemetry, then exports traces either to its own service or another observability backend. OpenLLMetry introduction

Langfuse uses traces to connect prompts, responses, tools, retrieval steps, latency, token use, metadata, and evaluations across an LLM application. Its SDKs are built on OpenTelemetry, allowing AI-specific observations to participate in a wider trace ecosystem. Langfuse observability, Langfuse SDKs

These projects do not need the model’s internal implementation. They need stable instrumentation around the interaction.

What the trace can know

An LLM or agent trace can commonly record four different kinds of information.

1. Direct observations

These are facts available at the boundary:

• request and response timestamps;
• provider and model identifiers;
• prompts and returned messages, when policy permits recording them;
• token counts reported by the provider;
• errors and finish reasons;
• tool requests and tool results;
• retrieval queries and returned documents;
• agent handoffs, retries, and control-flow steps;
• latency and resource usage.

2. Configuration and context

The trace may include:

• prompt-template and application versions;
• model parameters;
• session and trace identifiers;
• the user task;
• application state;
• available tools and permissions;
• infrastructure and service context;
• the production environment in which the call occurred.

3. Derived interpretations

Observability systems increasingly add processed or classified information:

• estimated cost;
• topic or behavior clusters;
• anomaly classifications;
• detected prompt injection or sensitive content;
• LLM-as-a-judge scores;
• inferred user satisfaction;
• likely failure modes;
• root-cause hypotheses.

4. Outcomes and evaluations

A trace can later be linked to:

• explicit human feedback;
• task success or failure;
• business outcomes;
• functional tests;
• human review;
• code-based evaluation;
• another model’s evaluation;
• results from repeated experiments.

The presence of processed information does not make the trace invalid. It makes provenance essential. A token count returned by a provider, a cost calculated from a price table, a topic assigned by a clustering model, and a correctness score supplied by an LLM judge are different kinds of claims. HRT keeps those claims distinguishable in the trace.

That is directly relevant to cognitive observability. Much of the human-runtime “log tail” may consist of classified or derived data rather than raw signals. HRT must keep observed, derived, interpreted, and outcome data visibly separate.

Which LLM runtime numbers are actually available?

LLM observability can provide surprisingly concrete runtime measurements even when the application owner does not own the model. The exact coverage depends on whether the model runs locally, through an instrumented inference engine, or behind a third-party API.

OpenTelemetry currently defines fields for input tokens, output tokens, cached-token categories, model and provider identity, operation duration, and the request’s maximum output-token setting. That gen_ai.request.max_tokens field is the maximum generation requested for a call; it is not the model’s total context-window size. OpenTelemetry GenAI attributes, OpenTelemetry GenAI attribute registry

Datadog exposes span and trace duration plus distributions for input, output, reasoning, prompt, completion, total, cache-read, cache-write, and non-cached tokens. It keeps those operational values distinct from qualitative evaluation scores. Datadog Agent Observability metrics

For locally controlled or deeply instrumented inference, the numbers can become more detailed. Datadog’s vLLM integration captures input and output tokens along with time to first token, queue time, prefill time, decode time, and total inference time. Hosted model APIs may expose only a subset, although streaming clients can still measure time to first token at the boundary. Datadog automatic instrumentation

Context utilization needs special care. Input-token count is an observation. Context-window capacity is model metadata. The ratio between them is a derived measure whose formula must be declared. For example:

input utilization = input tokens / model context capacity

reserved utilization = (input tokens + requested maximum output tokens)
                       / model context capacity

estimated headroom = model context capacity
                     - input tokens
                     - reserved output tokens

These answer different questions. A request can have modest input utilization but little reserved headroom if it allows a very large response. A multi-agent session can also accumulate far more total tokens than any single model call contains, so per-call context utilization is distinct from session token consumption.

Datadog’s local Lapdog product displays context-window usage and cache-hit rate across coding-agent sessions, demonstrating that context utilization can be made operationally visible even though it is not yet a universal OpenTelemetry field. Datadog Lapdog

OpenTelemetry’s GenAI conventions are still evolving in this area. End-to-end operation duration and input/output token usage exist, while standardized time-to-first-token, cost, retry, rate-limit, and agent-budget utilization measures remain subjects of active proposals rather than one fully stable cross-vendor metric set. OpenTelemetry GenAI metrics proposal, agent budget-utilization proposal

This mix of observed, provider-reported, configured, and derived numbers is another close parallel with human-runtime measurement. HRT supports all four, and every field states which kind it is.

Datadog’s agent-observability stack

Datadog is moving beyond traditional LLM-call monitoring toward an integrated agent-development and operations stack.

Its Agent Observability product represents an LLM-powered request as a trace. Individual spans can cover model inference, tools, retrieval, workflows, and agent operations. It combines operational measures such as latency, errors, tokens, and cost with quality, privacy, and safety evaluation. Datadog Agent Observability

Datadog now accepts OpenTelemetry GenAI semantic conventions and supported OpenInference traces. Teams can instrument an application with compatible libraries and route the resulting spans through OTLP without using a Datadog-specific observability SDK. Datadog maps the common attributes into its own Agent Observability model. Datadog OpenTelemetry instrumentation

The Collector is important here. Before telemetry leaves an organization’s environment, processors can redact, sample, enrich, or route it. Datadog presents this as a way to keep governance in the OpenTelemetry pipeline while still using Datadog for analysis. Datadog support for OpenTelemetry GenAI conventions

This is a useful pattern for HRT. A provider-controlled or customer-controlled HRT gateway could decide which raw signals, derived states, or summaries may leave the local boundary. It could apply purpose, consent, precision, retention, and access policies before another agent sees the data.

From tracing to an improvement loop

The most important development in LLM observability is not the trace viewer. It is the feedback loop being built around traces.

Datadog Experiments can turn production traces into versioned datasets, run alternative prompts, models, and agent configurations, attach evaluators, and compare quality with latency, token use, and cost. Production failures can become future test cases. Offline improvement can then be checked against live behavior. Datadog Agent Observability Experiments, Datadog LLM Experiments

Its Patterns preview clusters production interactions to reveal emerging behavior, capability gaps, regressions, and areas with weak evaluation coverage. Representative traces can then become targeted datasets. Datadog Patterns

Datadog also supports continuous evaluations on sampled production traffic and can associate evaluator scores with the exact trace, prompt, response, and operational context that produced them. Datadog evaluation-framework integrations

The resulting cycle is:

Observe → identify a pattern → form a hypothesis → build an evaluation set → test a change → deploy carefully → observe the outcome.

This is remarkably close to the value HRT creates around human performance:

Observe → identify a human-runtime pattern → add context → design an intervention → test it → observe whether performance, safety, or learning improved.

The human case demands greater ethical restraint, but the systems pattern is similar.

Datadog’s agents use the observability layer

Datadog is also showing what happens when the consumers of telemetry are themselves agents.

Bits Investigation is an autonomous SRE agent that queries live telemetry, forms root-cause hypotheses, tests them, classifies them as supported or unsupported, and produces an auditable investigation. Datadog evaluates it against labeled real incidents and aligns automated scoring with human judgments. How Datadog built Bits Investigation

Bits Agent Builder allows customers to create hosted agents that use Datadog and third-party signals, call tools, and take actions through workflows. Multiple agents can be chained or triggered conditionally. Datadog Bits Agent Builder

Datadog also exposes observability data to external AI agents through integrations and its MCP server. Coding and operational agents can query metrics, logs, traces, experiment results, and related context without forcing a human to manually reconstruct it. Datadog AI-agent integrations

This suggests three distinct roles for an observability system:

1. Observe the agent — record how models, tools, retrieval, and handoffs produced an outcome.
2. Improve the agent — convert traces into evaluations, experiments, and regression tests.
3. Inform the agent — make current and historical telemetry available as context for future action.

HRT can use the same three-part model:

1. Observe the human runtime — record authorized observations, derived states, interactions, and actions.
2. Improve the human–agent system — evaluate interfaces, handovers, training, routing, and interventions.
3. Inform authorized agents — provide the minimum relevant human-runtime context needed for coordination.

Opaque models clarify what cognitive observability means

LLM observability is useful precisely because it does not claim to reveal everything inside the model.

When a managed model returns a response, an operator may know the prompt, model name, latency, token use, tool activity, and output. The operator does not know the complete causal path through billions of parameters. Even a provider-generated reasoning summary is not equivalent to direct access to the underlying computation.

The trace remains valuable because it connects visible evidence across time.

Human Runtime uses the same epistemic discipline.

An eye-tracking system may observe fixations, saccades, pupil changes, or head movement. A specialist analytics provider may transform those signals into estimates of processing, focus, automaticity, flow, or residual capacity. A task system records what occurred. A coach or agent interprets the episode. A later outcome supports or challenges that interpretation.

None of those layers is the person’s mind itself.

HRT therefore defines cognitive observability as:

A time-aligned, provenance-aware account of authorized signals, derived human-performance states, task context, actions, interventions, and outcomes—not direct access to private thought.

This is more scientifically credible and more technically useful than a claim to make cognition transparent.

The processed log is still a log—if its provenance survives

Traditional logs often appear factual because they record discrete software events. Modern AI observability already complicates that picture. A trace can contain raw API responses beside classifications, safety scores, anomaly detections, clusters, and evaluations produced by other models.

Cognitive observability will be even more dependent on processed data.

A useful HRT record therefore identifies at least:

• subject — the person or role to which the record relates;
• episode — the task span or situation in which it was produced;
• class — observed, derived, interpreted, evaluated, or outcome;
• provider — the device, processor, person, or agent that created it;
• method version — the algorithm, model, rubric, or protocol version;
• source signals — direct references where permitted, or a description of their type;
• confidence and quality — including calibration and missing-data conditions;
• validity — how long and under which circumstances it can be used;
• authorization — who may access it and for what purpose;
• retention — when it expires or is deleted;
• relation — which agent event, intervention, action, or outcome it connects to.

An agent consuming the record can distinguish:

Observed: gaze moved from instrument A to warning B
Derived: provider estimates reduced residual capacity
Interpreted: instructor believes the procedure is not yet automatic
Action: training agent reduces information density and requests confirmation
Outcome: next attempt completes with fewer missed cues

The value comes from the chain, not from declaring any one derived value to be the truth about the person.

A possible HRT observability architecture

The LLM ecosystem suggests a modular HRT stack.

Instrumentation boundary

Devices, interfaces, applications, simulators, and interaction systems expose authorized events. Raw data can remain local.

Human Runtime Processor

A specialist provider transforms inputs into measurements or estimates. Its algorithms can remain private. It emits only the permitted output contract.

HRT gateway or collector

A policy-aware component receives observations and provider outputs. It applies consent, redaction, precision limits, sampling, purpose restrictions, retention, and routing. It connects the data to hrt.node, hrt.span, hrt.event, and hrt.trace identifiers.

Semantic and provider profiles

The stable HRT core defines the shared structure. Provider profiles define specialized fields, validity requirements, and provider-owned extensions without exposing the implementation.

Observability and evaluation layer

The system relates human-runtime records to agents, tools, environmental events, decisions, interventions, and outcomes. It supports pattern discovery, evaluation datasets, comparisons, and experiments.

Authorized agent interface

Agents query the minimum context required for a task. They do not receive a permanent unrestricted feed of human-performance data. Their permitted responses are constrained by governance outside the measurement itself.

This architecture can work even when no participant has complete knowledge of the whole system.

Where HRT must go beyond LLM observability

The analogy is powerful but incomplete.

An LLM does not have employment rights, bodily autonomy, dignity, or a private life. A person does. Human-performance telemetry can affect opportunity, reputation, authority, compensation, or safety. Errors may be difficult for the observed person to detect or contest.

HRT therefore needs protections that ordinary LLM observability may not require:

• meaningful consent and lawful purpose;
• strict separation between capability and authority;
• access and correction rights where appropriate;
• visibility into who used a state estimate and why;
• prohibitions on covert productivity scoring or unsupported psychological inference;
• limits on cross-context reuse;
• protection against permanent profiling from temporary states;
• human review of consequential automated actions;
• explicit scientific validity and uncertainty requirements;
• the ability to stop collection and expire historical state.

HRT is not “Datadog for people.” It can borrow the architecture of observability while rejecting the assumption that a person is simply another service to monitor.

A practical implication for specialist providers

LLM observability shows that a provider can participate in a trace ecosystem without revealing its internal model.

When an application calls a third-party LLM, the trace records the interaction contract and surrounding workflow. It does not download the provider’s weights. In the same way, a specialist processor can emit an attributed human-performance state without giving HRT its algorithm, feature engineering, or raw biometric history.

That protected interface can still support legitimate competition and composition. Several processors can accept the same authorized evaluation episode, return attributed outputs, and be compared against an independent outcome without making their implementations public.

The provider’s role is comparable to a specialized model endpoint:

• receive authorized inputs;
• apply private expertise;
• return a documented output;
• attach version, quality, confidence, and validity information;
• permit only defined uses;
• remain accountable for the semantics of the result.

HRT supplies the trace and coordination layer around that result. Other providers can participate through their own profiles. Competition moves toward measurement quality, evidence, domain performance, support, and useful applications—not toward who can create the most isolated data format.

The larger opportunity

LLM observability emerged because intelligent systems became too important and too opaque to operate through outputs alone.

Human–agent systems are approaching the same threshold. A human approval, correction, or intervention is an output. It does not explain whether the person had the right context, whether the handover was viable, whether performance was stable, or whether the intervention improved the next attempt.

HRT can extend the trace across that boundary.

It does not need to own or decode the human mind. It needs to preserve the relationship between evidence, context, measurement, interpretation, action, and outcome.

That is what modern LLM observability already does for systems whose most important processor is often owned by someone else.

We do not need transparent minds. We need accountable boundaries, interoperable traces, and evidence about what happened next.

The companion proposal Human Runtime Cognitive Metrics translates this argument into candidate counters, durations, ratios, rates, saturation measures, metric classes, and measurement contracts for the HRT protocol.