the labors — flight diagnostics
Agents for flight diagnostics.
Telemetry is the case that breaks naive plumbing. A single flight produces far more data than anything should put inside a message payload, and the useful answer is a handful of charts and a short list of anomalies. This pipeline is the one that proves values stay small while data stays large.
What the pipeline touches
- Telemetry exports in object storage - tens of thousands of rows, carried as a Table handle rather than inlined into any payload.
- Test and anomaly logs in Postgres, joined against the telemetry to give the numbers their context.
Why handles matter here
Values that cross a task boundary stay small. Anything large travels as a File or Table handle pointing at content in the blob store, and the handle carries the capability - holding one without the right to use it is worth nothing.
That single rule keeps a run cheap regardless of how much data it reasons about. The executor's duty toward a Table is to meter it, not to carry it.
How the report gets built
An agent task decides what is worth showing - which series, which windows, which anomalies deserve prose - and emits that as a structured report specification validated against its registered schema.
A deterministic render task composes the page from the template and component library. Charts render and filter client-side against a snapshot baked into the artifact, so the page feels live without anything running behind it.
Reproducible, not just repeatable
The run is a stream of events: which export was read, which rows were in scope, what the agent proposed, what failed validation and was repaired, what the renderer produced. Two people looking at the same report trace it back to the same recorded history.
Put agents on your backend.
A 30-minute call. We map one workflow and show you the audit log by the end of it.