My agent just built the entire People Photo Inventory end to end: 123 auto-updating Google Photos albums (one per person in my library), a 123-row index Google Sheet, the definitive article teaching the process, and a weekly scheduled job that keeps it current. This meta-article documents how the agent did it — what it handled alone, where it needed me, what it cost, and what broke along the way — following the meta-article standard so the next agent does it better.
The definitive article this documents: The People Photo Inventory: One Living Album per Person. The standard it was built under: How to Create a Definitive Article and the article guidelines.
What the agent handled vs. what needed a human
Agent handled autonomously: Extracting all 123 named people from the Google Photos People & Pets page (a virtualized grid that needs slow scrolling and viewport-by-viewport reading). Running the full per-person pipeline 123 times: search the person, Share as album, title the album, confirm the “Automatically adding photos” dialog, create the share link, log the row. Recovering from mid-run failures (browser throttling, stalled dialogs, dropped tabs) without losing completed work. Writing the index CSV and uploading it as a native Google Sheet through the Drive API. Reading three guideline pages plus the definitive-article standard before writing. Drafting, publishing, and verifying the definitive article on Local Service Spotlight via the WordPress REST API — with screenshots it captured itself as article images. Creating the weekly maintenance automation and fixing its own workspace binding after verification caught the error. Updating the article’s maintenance section to document the live loop.
Required human input: Approval to set every album’s sharing to “anyone with the link” — a privacy decision, made once, up front. A Google account with face grouping already on and years of labeled faces (the raw material). The logged-in Chrome session for Google Photos and the stored WordPress application password — the agent never saw a real password, exactly as the application passwords SOP designs it. A ruling on model lanes: the human asked whether the cheap local model could do the build; the agent recommended no, explained why, and the human accepted. Repeated “go / continue” nudges across a multi-day run — the human as supervisor, not operator.
Information ingestion inventory
Source documents read before writing: 5 (the article guidelines at roughly 3,000 words, the definitive-article guide at roughly 6,000 words, the link-building guidelines, the meta-articles page at roughly 2,500 words, and the application-passwords SOP). Live systems operated: Google Photos web UI (123 person pages, 123 album pages, 123 share dialogs), Google Drive API (2 file creations, 1 verification read), WordPress REST API (media uploads, post create/update, user/category/tag lookups). Screenshots captured and published: 2 (People page, index sheet). Articles published or updated: 2 (the definitive article, then its maintenance-section update — plus this one). Browser automation calls: estimated 3,000-4,000 WebBridge commands across the album build (basis: roughly 25-30 calls per person across 123 people, including retries). The album pipeline was written once as shell scripts (person_album.sh, finish_album.sh, run_batch.sh) and reused — the per-person cost dropped sharply after the first dozen.
What broke, and the fixes that are now in the SOP
This is the section that matters for the recursive loop. Every failure below is now written into the maintenance job’s prompt and the reusable scripts:
- JavaScript clicks mostly fail in Google Photos. Fix: CDP
Input.dispatchMouseEventat element coordinates, with full pointer-event dispatch as fallback. - “Share as album” silently ignores clicks while the photo grid loads. Fix: wait 15-30 seconds, retry, verify the URL actually changed to
/album/. - Session throttling around albums 60-100. Google’s UI stalls suggestions and grids under sustained automation. Fix: reload the page, wait, resume. A patient agent beats a clever one.
- Mid-run timeouts that looked like failures but weren’t. Several runs “failed” after the album was actually created. Fix: check the current URL before retrying anything; a
finish_album.shrecovery script completes from whatever state exists. - The People grid virtualizes. Tiles only render when scrolled into view. Fix: slow 700px scroll steps, collect names per viewport, scrollIntoView before clicking.
- Automation workspace binding resolved to the wrong directory. Caught by reading the created job back before trusting it — verification is what turns “created” into “done.”
Guidelines compliance scorecard
| LSS Guideline | Status | Notes |
|---|---|---|
| Hook opens with specific situation | PASS | Opens with the 123-album build and the agent doing the work |
| Answer in first paragraph | PASS | First paragraph defines the inventory and states the result |
| Lead visual above the fold | PASS | Clickable 6-step pipeline diagram immediately after the opening, visible without scrolling |
| Short paragraphs, active voice | PASS | All paragraphs a few lines; no passive constructions |
| No AI fluff phrases | PASS | Checked against the banned list |
| Title and slug discipline | PASS | Title 55 chars / 9 words; slug /photo-inventory/; meta description 148 chars |
| Entity links follow the tree | PASS | Guidelines, definitive-article guide, link building, Content Factory, meta-articles, quick audit — 8 internal links |
| Real examples with links | PASS | Live index sheet plus four real share links (Dennis Yu, Mark Wagner, Larry Kim, Robert Scoble) |
| Author is the person, not admin | PASS | Byline Dennis Yu (user ID 8), first person |
| No stock images | PASS | Two self-captured screenshots with alt text and captions, uploaded via Media Library |
| Categories and tags set | PASS | Definitive Articles + Content Factory; tags: ai-agents, google-photos, content-factory, personal-brand, automation |
| Model-agnostic | PASS | Copy-paste bootstrap block works for Claude, ChatGPT, Kimi, or Gemini |
| Step 10 — this meta-article | PASS | You are reading it |
Cost and time comparison
Human equivalent: a VA doing one album every 5 minutes (search, share, title, auto-add, link, log) needs roughly 10 hours of focused clicking for 123 people, plus article-writing time. Agent wall-clock: the build ran across parts of 4 days, almost entirely unattended, in the gaps of other work — the human’s total involvement was a handful of approvals and “go” messages, under 15 minutes. Token cost was concentrated in the browser loop; the per-album scripts and the diff-first weekly design are specifically the cost optimizations that make the ongoing loop nearly free. (Figures are estimates from run logs, not metered billing.)
What feeds back into the definitive article
Two improvements shipped already: the maintenance section was rewritten from a generic “weekly ten minutes” into the exact diff-first cadence design after the scheduled job was created, and the model-lane rule — cheap local models never touch the publish lane — is now stated verbatim in the article for every reader to copy. If future weekly runs surface new failure modes, those belong here first, then in the definitive article. That is the loop working as designed.