ML//agent//agent harness//observation design

Observation design is the deliberate construction of the representation an agent receives from external state, the part of an agent harness that decides what the model actually sees (the concrete engineering behind the epistemic interface lens). The environment may contain files, processes, logs and network services; the model sees only the output of a harness-defined mapping.

Observation design is the deliberate construction of the representation an agent receives from external state, the part of an agent harness that decides what the model actually sees (the concrete engineering behind the epistemic interface lens). The environment may contain files, processes, logs and network services; the model sees only the output of a harness-defined mapping.

ot=OH(st)o_t=O_H(s_t)ot​=OH​(st​)

The model does not receive the repository; it receives an argument about the repository assembled by software. That argument is designed along five axes:

SelectionWhich files, matches, records or events are included at all.

ResolutionA whole file, a 100-line window, one symbol, an aggregate or a summary.

EncodingSemantic names versus opaque IDs, ordering, JSON versus prose, and whether relationships are made explicit.

Failure semanticsEmpty output, truncation and errors must distinguish successful silence from missing evidence or failed execution.

TrustProvenance and prompt-injection screening matter because observations become instruction-shaped tokens inside the same context as legitimate evidence.

The aim of observation design is to preserve the distinctions needed for the next decision while respecting token, latency and security budgets: an observation is worth what its representation improves that decision, against what it costs (value of information). Minimizing output unconditionally is a different goal.