Adopt before you build

The roadmap was clear: Phase 1 of my agent project is one strong research agent — read forwarded links, verify them live, land structured notes in my vault, every claim sourced or cut. Build it as a single focused thing, use it daily for two weeks, then decide whether anything else is worth building.

Before writing a line of it, I did the boring check: what already exists that does this job? The answer was embarrassing — I’d been running one since July. Months ago I’d set up a research inbox pipeline: forward anything interesting to a dedicated email address, and every day at 5pm an agent checks the mail, researches each item properly — fetches the repo, reads the article live, verifies claims against independent sources — and writes a structured note into my vault with every factual claim carrying a real source URL. It handles funnels, duplicates, unreachable sources, all of it. It had processed hundreds of items by the time I sat down to ‘build’ it.

The honest options were: build a fresh agent that matches the plan, or admit the plan’s Phase 1 already exists. Adopting wasn’t free, but it was hours, not weeks. Making the schedule real turned ‘usually works’ into ‘runs at 5pm’ — the daily run had depended on a desktop app happening to be open, so it got registered as an actual scheduled task. Backfilling the test set from history meant a frozen set of ten tasks, built from two months of real run logs instead of written from scratch — and its held-back tasks catch overfitting later. And documenting the differences mattered most: the pipeline behaves differently in one place than the plan specified (how Gmail threads get labelled and archived afterwards), and that went into the constitution as a named exception, versioned — not silently ignored, not rebuilt to match the doc, just written down as an accepted difference.

That last step is the one people skip, and skipping it is how drift starts. A plan that pretends reality matched it stops being usable the first time someone relies on it. An exception, named and versioned, keeps both the plan and the system honest.

The general rule: check for an existing solution before building — not because your build would be bad, but because a component that has survived months of real traffic carries evidence no new build has: known failure modes, handled edge cases, habits formed around it. The corollary matters just as much — when you adopt something that differs from the plan, write the difference into the plan. Governance that documents exceptions stays trustworthy; governance that pretends the exception doesn’t exist gets quietly ignored the next time reality disagrees. The best code is often the code you didn’t have to write. The second best is the code you honestly described.