Process study · Agent orchestration
An agent-monitored
data pipeline.
Keep the data work deterministic. Use an agent to investigate what breaks—and require independent checks before a repair can take effect.
- 01ObserveRun & quality evidence
- 02DiagnoseAgent proposes a repair
- 03ValidateIsolated tests & checks
- 04ActivateOnly if checks pass
01 / The task
Make failures actionable
A recurring collection pipeline needs more than a scheduled run. Source changes can break parsing or quietly reduce data quality. The useful question is whether an agent can help diagnose those failures without being free to rewrite the system that checks its work.
My design brief
Connect the pipeline’s run and quality evidence to an agent, constrain the proposed changes, and make activation conditional on checks outside the agent’s control.
Owner account · Implementation inspected
02 / Decisions
A small control plane
The agent proposes; the supervisor decides
The agent receives bounded evidence and a source snapshot. It returns a structured diagnosis and repair proposal. It does not run tools or decide whether its own change has passed.
Repair scope is explicit
Only two parser and normalization modules may be changed. Tests, transport, budgets and the supervisor itself stay outside the repair boundary. A malformed, empty or out-of-scope proposal is rejected.
Check the candidate in isolation
A candidate copy runs regression tests with network access disabled. A separate, bounded smoke check verifies data quality. Activation requires both gates to pass, with the previous source retained for rollback.
03 / Agent contribution
Diagnosis inside boundaries
- Collect bounded run results, errors and quality evidence.
- Ask the agent for a diagnosis, sampled checks and a structured proposal.
- Validate the proposal and prepare an isolated candidate.
- Run regression and data-quality gates; reject failures.
- Activate only a passing candidate and retain the previous version.
Source text and model responses are treated as untrusted inputs. Time, output and retry budgets are enforced by the supervisor.
04 / Selected evidence
What the tests check
A failed candidate must not become active
Implementation inspected · Paraphrased test assertions
Given a repair proposal that fails regression checks: The proposal is rejected. The existing source stays unchanged. The candidate evidence remains available for inspection.
A proposal cannot change its own checks
Implementation inspected · Paraphrased test assertions
Given a proposal that edits the supervisor: Reject the forbidden path before activating a candidate. Keep the current implementation unchanged.
These are plain-language summaries of inspected tests, not a reproduced run log or a claim that new tests were executed for this study.
05 / Result & limits
A verifiable mechanism
The inspected code implements a bounded supervision and repair mechanism, with tests covering rejection and activation paths. That supports the architecture shown here.
It does not establish how often a real incident was repaired, sustained operating reliability, or a production success rate. The source system and its data are deliberately anonymized; this study focuses on the orchestration design.