Designer & builder
TLDR Research Ops
Newsletter triage as a gated agent pipeline
Project brief
Design studyProblem
Research gets expensive when every new question starts with the same source collection, triage, and citation work.
Outcome
A six-stage agent pipeline design that triages a daily tech newsletter, verifies claims against evidence, and produces separate learning and implementation plans behind two independent codegen approval gates. Ten architecture decisions and a working plan orchestrator exist; the core pipeline stages are specified but not yet implemented.
Evidence
- Ten accepted architecture decisions fix the invariants before any pipeline code exists, every stage emits a versioned, schema-validated artifact so no state passes implicitly between stages; a learning plan stays structurally separate from an implementation plan so studying a topic never quietly turns into shipping code; and codegen sits behind two independent gates (a configuration flag defaulted off, plus an interactive approval) with the write-scoped credential withheld until both pass.
- A 225-line orchestrator runs ten dependency-ordered plans in isolated agent contexts, and a roughly 1,776-line shell CI harness enforces branch, size, secret, and revertability checks on every change.
Key decisions
- Design layer: Ten accepted architecture decisions and a requirements doc fix the invariants before any pipeline code is written.
- Orchestration: A single script runs ten dependency-ordered plans, each in an isolated agent context.
- Governance & CI: A guard hook blocks protected-branch and force-push operations; a separate CI harness gates changes with deterministic checks and LLM judges.
- Specified runtime: The scheduled ingestion job and the core pipeline package are specified but not yet implemented.
Editor’s note
The design starts from a bet: the bottleneck in daily newsletter triage is not reading, it is deciding which items deserve deep study and turning the worthwhile ones into grounded, repo-specific plans, with enough audit trail that the whole thing could run unattended. I fixed the invariants in ten accepted architecture decisions before any pipeline code exists.
By the numbers
Architecture — the stack
Two diagrams describe the system as designed: a layered architecture connecting design, orchestration, and governance to a not-yet-built runtime.
The design layer commits to its invariants before orchestration or runtime code exists, and a separate governance layer gates every run.
Architecture — the specified pipeline
The specified pipeline from ingestion through gated codegen.
Margin note gates every stage downstream
Each stage emits a versioned artifact, and codegen only fires if a default-off flag and an interactive approval both pass.
Every stage is meant to emit a versioned, schema-validated artifact so no state passes implicitly between stages. A learning plan stays structurally separate from an implementation plan. Codegen sits behind two independent gates (a flag defaulted off, plus interactive approval).
In brief
Ten accepted architecture decisions and a requirements doc fix the invariants before any pipeline code is written.
A single script runs ten dependency-ordered plans, each in an isolated agent context.
A guard hook blocks protected-branch and force-push operations; a separate CI harness gates changes with deterministic checks and LLM judges.
The scheduled ingestion job and the core pipeline package are specified but not yet implemented.
Researching my way to an orchestration system is the habit behind it. Dual channels keeps research residue out of the next session's window.
Further reading
Where this fits
Portfolio graph
Maps how the work here connects. Open the Portfolio graph →
- Professional
- Personal
- Skill
- Writing