September 12, 2026
CASE STUDY: SWEEPSMONITOR'S CONTROLLED EDITORIAL SYSTEM

You now know both homes an agent can live in. This lesson shows a real system that chose the second one — and built it carefully. We study its mechanism, not its performance: how the parts connect, where the boundaries sit, and why it counts as agentic without being reckless.
What the system is
SweepsMonitor is an editorial monitoring workflow: it discovers candidate leads on a controlled schedule, takes in the promising ones privately, assembles an approved factual source packet for each, collects and analyzes evidence, generates a draft, validates that draft against factual checks, hands the result to human review as a pull request, and only then — after a human merge — marks the item published.
Note what is absent: no performance claims, no traffic figures, no private data. The teaching value is the shape of the machine, which you can reuse for any research-to-publication pipeline.
The bounded flow
discovery → intake → source packet → collect → draft → validate → PR → merge/publish
- Discovery (scheduled, controlled). Workers wake on a schedule — cron-style, not continuously — and check an approved list of sources. There is no open-ended roaming. The source list is configuration, reviewed like code.
- Intake (private). Candidate leads land in a private staging area. Nothing public happens here. Intake records what was found, where, and when, so later steps can cite their inputs.
- Source packet (approved factual base). Before any drafting begins, the system assembles a packet of approved factual material for the item. The draft may only draw on the packet. Anything outside the packet does not exist as far as the writer step is concerned. This is a source lock, and it is the single most important control in the system.
- Collect and analyze. Collector workers gather the packet's contents and run analysis steps against them. Collectors behave failed-closed: if a source is unreachable, malformed, or suspicious, the step fails rather than guessing. A missing fact stays missing; it is never invented.
- Draft and validate. A model step writes a draft from the packet, then a separate validation step checks the draft back against the packet — claims, figures, attributions. The writer and the checker are different steps with different instructions, so one step's optimism cannot certify itself.
- Review PR and merge/publish. The validated draft becomes a pull request in GitHub. A human reviews, requests changes or approves, and merges. Publication status is explicit state — draft, in review, published — stored in the system, not inferred from vibes. Only a merged PR flips the state to published.
Why it is agentic — and why it is not reckless
It is agentic because models and tools progress a bounded workflow across many steps: deciding which leads merit packets, collecting evidence, drafting, checking, and routing work forward. It observes intermediate results, updates run state, and decides what happens next — the loop from Class 30, running on real infrastructure.
It is not reckless autonomy because every consequential transition has a control:
- Source locks confine drafting to approved material.
- Validation re-checks output against inputs with a separate step.
- Private staging keeps unfinished work out of public view.
- Failed-closed collectors refuse to guess when evidence is absent.
- Review gates require a human merge before anything publishes.
- Explicit publication state means the system always knows what is draft, what is waiting, and what is live — and so does anyone reading the logs.
Autonomy moves work forward; gates decide what crosses each boundary. Both are designed, both are visible, both are tested.
Mapping it to what you already know
Every component traces back to an earlier part of this course:
| Component | Course roots |
|---|---|
| VPS workers, cron schedule | Part VII — Infrastructure: persistent machines, scheduled jobs |
| Queue, run state, logs | Parts VII–VIII: durable state, retries, inspectable runs |
| Search and content APIs | Part V — Tools: defined interfaces over scraping where possible |
| Database and knowledge base | Part VI — Data: operational records, editorial memory |
| GitHub review PR | Parts III, XI: branches, review, merge as the publishing gate |
| Markdown handoffs | Part II — Files: packets and drafts as readable files |
| Model calls | Part IV — Models: rented reasoning inside an owned system |
There is no mystery component. The system's power comes from how ordinary parts are arranged — and from the gates between them.
Practical exercise: draw the boundary map
On one page, redraw the flow as four lanes:
- Automatic: discovery checks, intake recording, collection, draft generation, validation checks.
- Private: lead staging, source packets, unreviewed drafts. Mark who can see each item.
- Requires human approval: the pull request merge and the publish-state flip. Name the approver role.
- Never delegated: inventing facts outside the packet, publishing without a merge, expanding the source list without review, widening collector permissions on its own.
Finish line: a one-page boundary map with at least two items in each lane, naming the approver and the never-delegated list explicitly.
Verify it: pick one "automatic" item and describe its failure path — what happens, what gets logged, and what state the item ends in. If you cannot answer, the lane is incomplete.
Common failure mode: putting "the agent decides what is true" in the automatic lane. Nothing in this system decides truth. Collectors gather approved sources, validators check drafts against packets, humans decide publication. Truth stays with sources and reviewers; the agent moves work between them.
Check your understanding
1. What is a source packet, and why does drafting from the packet — rather than from the open web — change the system's risk? 2. What does "failed-closed" mean for a collector, and what failure does it prevent? 3. Why is publication an explicit state flipped by a merge, rather than something the agent announces?
Where this course goes next: Class 33 asks when one good agent should become several — and when a crowd of agents is just expensive confusion. Bring this boundary map with you; it becomes the contract each future role must honor.
ARTICLE DISCUSSION
JOIN THE
CONVERSATION.
Got a question, a take, or a better way to do this? Log in and leave a comment.
