The calibration drift problem: accountability when the agent's physical-world inputs silently degrade

A sensor that fails stops producing readings, or produces readings so obviously wrong that they trigger alerts. A sensor that drifts continues producing readings. They are off by a small and slowly growing margin. At any given moment, the value looks plausible. In isolation, no single reading is suspicious enough to act on. It is only in retrospect — after the decision informed by months of drifted inputs turns out to be harmful — that the pattern becomes visible.

This is the calibration drift problem. It sits at the junction of hardware and accountability, and it is sharpest in the domains where AI agents are being deployed fastest: physical-world care and critical infrastructure. The accountability frameworks developing around AI agents have not adequately addressed it, in part because the legal and philosophical categories for agent accountability were built around discrete events rather than gradual degradation.

Why drift is harder than failure

Sensor failure has a clear accountability structure. An agent makes a decision based on a sensor reading; the sensor is subsequently found to have failed; the agent's action can be traced to a defective input with a known failure time. Liability can be apportioned between the agent developer, the hardware supplier, and the operator responsible for maintenance.

Drift dissolves this structure. There is no failure time. The sensor was producing acceptable readings when it was last calibrated, and it is still producing readings that fall within a plausible range. The agent was not acting on a broken input; it was acting on an input that had gradually become less accurate. The agent cannot know the difference without an external reference. The operator, in many cases, cannot either.

The accountability question then becomes: who bears responsibility for harm caused by an agent that acted correctly given the inputs it had, when those inputs had silently degraded? The answer is not obvious, and current frameworks do not provide one.

The hardware crossing: when trust roots drift

At the hardware crossing, calibration drift touches the foundations of agent identity and cryptographic correctness. Hardware security modules depend on internal oscillators whose frequency drift affects the timing of cryptographic operations. Timing drift in protocols that assume synchronized clocks — including many of the post-quantum key exchange schemes entering deployment — can cause operations to silently fall outside specification. The operation succeeds in the sense that it completes without error. It fails in the sense that the timing guarantees the protocol relied on no longer hold.

This matters for AI agents that manage cryptographic state. An agent responsible for key rotation, session management, or certificate lifecycle in a hardware-anchored system is making decisions based on timing and state information that depends on calibrated hardware. If the hardware has drifted, the agent's view of the cryptographic state is subtly wrong. It will continue acting on that view confidently, because nothing in its observable environment signals a problem.

The accountability challenge here is that the agent is not the point of failure, and the hardware is not broken in any detectable sense. The failure mode lives in the gap between calibration events — and that gap is often not defined, tracked, or treated as an accountability-relevant artifact.

The care crossing: when readings look right but aren't

In physical-world care settings, calibration drift creates risk that is more immediate and harder to defend against. AI care agents make decisions — about medication schedules, activity levels, care escalation thresholds — based on readings from sensors embedded in the care environment. A pulse oximeter that reads two percentage points high does not look broken; it reports values in a plausible range. A weight scale that has drifted five kilograms low does not trigger any alarm; the trend line it produces looks smooth. A motion sensor whose detection radius has shrunk does not report errors; it simply fails to register activity that is actually occurring.

In each case the agent is acting correctly given its inputs. It is escalating when the readings cross the thresholds it was configured with; it is maintaining the care plan the readings support. The failure is invisible until a harm occurs that, retrospectively, the drifted readings explain.

The people most exposed to this failure mode are care recipients who cannot self-report that the sensor readings are wrong. An elderly resident experiencing genuine physiological changes may not be able to distinguish between the agent's decision being incorrect and the situation being what the agent describes. The agent's confidence in its readings — which is often communicated to care staff as confidence in the decision — is not calibrated to the physical state of the hardware providing the evidence.

What accountability architecture demands

Treating calibration drift as an accountability problem rather than a maintenance problem changes what the architecture must do. Several properties become necessary.

First, calibration events must be treated as first-class audit artifacts. The current calibration state of every sensor an agent acts on should be a logged, timestamped, and queryable fact — as much a part of the agent's accountability record as the decisions it made. An audit trail that records what an agent decided without recording the calibration state of the inputs at the time of decision is incomplete in an accountability-relevant sense.

Second, agents must propagate sensor uncertainty into their outputs. An agent acting on inputs from hardware whose last calibration is outside a defined tolerance window should flag that uncertainty explicitly — in its decision record and, where possible, to the humans relying on its outputs. The confidence an agent expresses in a decision should not be independent of the physical state of the hardware providing its evidence.

Third, calibration schedules must be treated as obligations that can be audited, not as maintenance recommendations that can be deferred. In care settings this means tying agent operating authority to the calibration status of the sensors it depends on. An agent whose sensor inputs have lapsed beyond a calibration threshold should operate in a degraded mode — with reduced autonomy and explicit uncertainty flags — until calibration is restored.

The calibration drift problem is not exotic. Every AI agent deployed in a physical environment faces it. The accountability architecture being built for those agents will need to address it directly — not as an edge case, but as a structural property of the operating domain.