The report said so, proposed no performance change, and went to the owner with one question instead of an alarm.

Daniel Goodrich reviews the work. The owner runs the crews. The agent does the middle part. We do not name the client here, and the numbers are real.

This was also the first scheduled run under the rewritten process, where a second agent reads the draft cold and tries to break it. It broke the first draft: a grade of F, fifteen wrong numbers, and five claims the data did not support. The version the owner will read is the one that survived that pass.

This is the meta article for that run. It documents what the agent did, the calls it made, what a human changed, and what is still unknown.

The run at a glance. Red is where the hardener rejected the first draft. Gold is the investigation that explained the week.

The run in brief

The assignment was the scheduled weekly Google Ads MAA (Metrics, Analysis, Action) for the account. The report is a client deliverable for the owner. A human approves it, then posts it to the client’s project thread.

The source material was live account data pulled through the Google Ads API, read-only, for two windows: September 4 to 10, and August 12 to September 10. Before pulling a number, the agent read the client’s ledger. That file holds:

• how a lead is defined ($50 to $80 per lead is the goal, and a call counts at 60 seconds)
• every change made to the account and when
• the items on watch
• anything too new to judge

The goal was the same as every week: tell the owner plainly what the money did, and decide what, if anything, to change. This week the second half was the hard part. The obvious move on a one-lead week is to do something, and one conversion on 34 clicks is not enough evidence to do anything.

What the agent did, step by step

Stage 0: it read before it pulled

The agent read the ledger, all ten sections, then the metric spec, the shared data rules, and last week’s report. That is where it learned the counted-call unit, the target band, and the standing rule that this account’s reports leave out desktop. It also learned that a keyword re-enabled on August 28 could not yet take credit or blame for the week’s shift in queries. The two-cycle rule defers that read to September 18.

Stage 0b: it pulled the whole pack

The pack covered:

• campaign summary and budgets
• keywords with Quality Score components, across every status
• search terms
• ads with strength
• conversions by action
• network and device
• searcher location
• negatives at three levels
• call detail
• the change history

The change history returned rows for the first time after five failed attempts. The agent saved the raw pull and recorded every row count. One pull hit the tool’s output cap, so the agent replaced it with an explicit list query.

Stage 1: it drafted under the gates

The lead collapse went into Analysis and onto the watch list, not into Action. One conversion on 34 clicks does not clear the five-conversion bar. The week’s biggest-spending keyword, $65.61 on seven clicks with no lead, went to watch for the same reason.

The agent withdrew the Quality Score “reversal” that had led the previous report. Under the new two-cycle rule, a score that reads 7, then 5, then 7 while its two component directions never move is not a change. It also closed a negative-keyword gap carried for two cycles with a direct query showing all nine terms live.

Stage 2: the hardener graded it F

A second agent, in a fresh context with only the frozen draft, the raw pull, the ledger and the spec, re-derived the numbers. Fifteen did not match. One cause was self-inflicted. The first save of the raw pack carried a weekly call summary the drafter had typed by hand, and it did not sum to its own rows. Four sentences were wrong because of it.

The hardener dropped five claims outright, demoted one action to watch, and returned the draft with a punch list. One round, every verdict applied.

Stage 3: it reconciled

Every number tied to the pull. Every action either had two cycles of watch history or was a foundation break. Nothing inside the 14-day window took credit or blame. One account setting the change log could not explain went into the notes and the open questions rather than into the analysis.

Then Daniel asked the question the draft had not answered

The hardened draft said the agent could not explain the week. Daniel commissioned a same-day investigation to rule out a tracking break, a demand collapse, and noise. The investigation is its own file, and its answer changed the report.

• Nothing was broken. GA4 recorded four tap-to-call events from paid visits and Google Ads recorded four, a match through the import. The call button served on all 468 impressions. The site booked three jobs that week, all from unpaid visits.
• Labor Day was not the cause. Holidays do not suppress calls on this account. The July 4 week ran above the median on calls, and the Memorial Day week produced six tracked calls.
• Demand did not collapse. It softened about 7% while the account’s impressions fell 20%, so most of the loss was auctions the campaign did not win.
• The matching footprint was not to blame. Tightly and loosely matched traffic cost $79.37 and $79.89 a lead over seven weeks.

The finding: cheap clicks are quiet clicks. Across fourteen weeks, what the campaign paid per click predicted how often those clicks called (r = +0.65, and the relationship holds with any single week removed). This week’s $7.05 was the cheapest click price on record. Its 5.9% call rate, two calls on 34 clicks, came in slightly above what that relationship predicts. The volume matched the traffic the campaign bought, and the traffic was cheap.

Both calls were under a minute. Google counts an ad call at 30 seconds, so the account shows one conversion. We count a call at 60 seconds, so the report shows zero counted calls. That accounts for the gap between the two numbers.

Tracked calls per click by week, from the account’s call records. The three gold weeks were the outliers. The red week sits with five other weeks under 7%.

Stage 4: it appended and stopped

The agent wrote the trend row and the weekly log into the ledger, plus seven new watch items with first-seen dates, eleven open questions, and six data faults. No client view, no charts, no post. Daniel approved the draft in chat. The agent then rendered the client view and staged it for him to paste.

The judgment calls

It held the collapse off the action list

The easy report says “pause the weak keyword” or “raise the bid.” The gates said one conversion on 34 clicks cannot carry either, and the account’s own history said four of the prior thirteen weeks had come in at three tracked calls or fewer. The draft said so and proposed nothing on performance.

It withdrew its own earlier framing in the open

Since August 28 the reports had described a run of 26%, 28%, and 23% calls per click as “an elevated call rate,” as though it were the new level. It was a peak, and those three weeks were the outliers. The report says that. It also says that last week’s “back inside target” line did not survive a week.

It proposed a watch trigger that would not cry wolf

The first draft proposed escalating if the next week produced fewer than three counted calls. Checked against history, that trigger would have fired on four of the last thirteen weeks. The proposed replacement sits in the ledger pending Daniel’s approval. It tests the mechanism instead of the symptom:

• If click price recovers to $11 and the call rate stays under 10%, the relationship has broken and we escalate.
• If price stays under $9 and calls stay low, the cheap-auction pocket is persisting and the bidding question opens.
• If both recover, the item drops.

It narrowed the ask to the owner

The first draft asked the owner to help rule out a tracking break. After the investigation ruled it out from our side, the ask became a two-minute confirmation. The agent asked whether two short calls, one Saturday morning and one Wednesday afternoon, matched what the owner saw on the phones.

It logged an unexplained change as a question

Someone had changed one account setting with no record of who or when. The report records that as an unlogged change and an open question. It does not build a story on it.

What it cost

We did not measure this run. Our July run articles estimated about 14 agent-minutes and $2 to $4 per run, against an hour to an hour and a half of manual work for a draft with no hardener pass. This run did more, since the hardener pass and the investigation are new, and we record its time, tokens, and cost as UNKNOWN. The notes block now requires start and end timestamps, so the next cycle will carry numbers.

Where the humans were

The agent did these on its own:

• read the ledger
• pull and save the data
• write the draft under the gates
• dispatch the hardener and apply its verdicts
• reconcile
• append the ledger and trend file
• render the client view once approved
• write this meta article

Required a human this run:

• commissioning the investigation, since the hardened draft had stopped at “we cannot explain it,” and the investigation changed its central finding
• approving the draft
• pasting the client view into the client’s project thread
• approving the replacement watch trigger
• the answer only the owner has

Two of those touched the report itself, and one of the two changed the analysis. The hardener handled every number correction. The back-test of the previous week, run through the same process a few days earlier, had needed zero. The gap between those two counts is what we work to close.

What this run changed in the recipe

1. Compute derived blocks from rows. Never type them. A hand-typed weekly summary in the raw pack produced four wrong sentences. The rule is now in the analyzer, the reviewer’s re-derivation step, and the query pack.
2. Paste the hardener’s output verbatim. This report described the verdicts in one sentence of counts. Only one of the four reports that cycle printed the verdict table, and none printed a grade after the round. The skill’s completion checklist now requires the table, the counts, and both grades.
3. Test a watch trigger against history before proposing it. “Fewer than three calls” fires four times in thirteen weeks on this account. Check the false-positive rate on the series before writing the condition.
4. Treat “we cannot explain it” as a prompt for a pull. The explanation was in data the standard pack already had: weekly cost per click and call rows. The next revision of the recipe should ask, before closing Analysis, whether the draft has tested any mechanism in the pack against the symptom.
5. Name the levels when claiming nothing is disapproved. This account’s report did not make that error this week. The same cycle on another account said “nothing is disapproved” from an ad-level pull while two image assets sat disapproved. The rule now applies everywhere.

Run inventory:

• Execution ID: GAA-2026-09-11-C1A
• Recipe: google-ads-analyzer v1.5.0, before the house-format revision, hardened by google-ads-reviewer v1.5.0 in a fresh context, one round
• Windows: 7D 2026-09-04 to 09-10, and 30D 2026-08-12 to 09-10
• Hardener result: grade F on the first draft, 15 numbers corrected, 5 claims dropped, 1 action demoted to watch
• Actions in the final report: 5 (2 for the owner, 3 for the agency), and nothing shipped to the account this cycle
• Ledger appended: 1 weekly-log row, 7 watch items from this run, 11 open questions, 6 data faults, quarantine updated
• Human interventions on the report: 2 (Daniel commissioned the investigation, and Daniel approved the draft with the reframed ask to the owner)
• Time, tokens, cost: UNKNOWN
• Evidence, in the private client folder: deliverables/2026-09-11-google-ads-maa.md (Generation notes block), deliverables/2026-09-11-call-volume-investigation.md, compiled/ledger.md rows dated 2026-09-11, and compiled/trend.csv last row

Run it on your own account

Install the Google Ads MAA skills from GitHub, onboard one account, and let the scheduled run fire on Friday. Read the hardener’s verdicts before you read the draft. The Google Ads MAA Agent recipe describes the five stages this run followed and the setup steps.

Two earlier runs under the previous process show what changed: the July review that fixed a blind spot and the July painting contractor run. Dennis Yu’s MAA framework is the discipline underneath all three.

This meta article documents one client’s Google Ads MAA run on 2026-09-11, execution GAA-2026-09-11-C1A. The client is anonymized, and the numbers are unchanged.

Agent receipt: localservicespotlight.com draft · Claude [claude-fable-5-1] · action: drafted · human review: Daniel Goodrich reviews before publishing

If this article is still up, they have not addressed the situation.

This is an operator review, not a brochure. Sam Hessler was the salesperson who made the big promises. What we feared from a full prepay is exactly what happened. Dated facts: Dazos cut access after Cardinal prepaid $65,200. We are not linking to Dazos. A dofollow link is a living recommendation. The rule is when trust ends, the endorsement link ends.

Score the engagement, not the homepage

Name the salesperson who sold the prepay

Sam Hessler was the eager salesperson. He was on the Dazos | Cardinal Zooms. Calendar holds from February through April 2025 show he accepted — including February 14, 18, and 25, plus the March 21 and March 28 eClinicalWorks integration discussions and the April 28 sync. Kayla Nielsen, Regional Director, sent the paper and copied him.

On February 26, 2025, Kayla Nielsen wrote (copy: Sam Hessler) that she had spoken to David and Dazos could “commit to doing the bidirectional integration with eClinicalWorks for $10k on a 6 month timeline.” Push patients. Update them back. Push encounters. That was the product.

On February 27, 2025, after a late-night sales Zoom, Kayla Nielsen wrote (copy: Sam Hessler): “Appreciate the late night call.” Marketing Reports free. DocuSign resent. Sign this month.

That same night, at 3:14 a.m. Pacific, Dennis wrote Michael Maryash what the sales desk had just made plain:

• The most important part was “the integration of ECW with Dazos — data going both ways” plus billing, so the clinic could judge marketing, clinicians, and profit.
• “They are closing out this month for raising a Series A round, so they seem to have legitimate urgency to get an agreement.”
• They wanted a signature that day, with a 30-day cancel and no payment until terms were finished. The reason, in that same-night mail: this is just to “book revenue” for their investors on paper.
• “They are quite eager to do this deal today, of course.”

We said, on those calls and in the follow-up, that a 100% prepay was the risk. If the door never opened, Cardinal would already have handed over a full year of cash. Sam Hessler still pushed the close. He needed to book this revenue for their capital raise.

The 30-day, no-payment paper did not survive. By May 14, 2025 Dennis was writing Kayla Nielsen (copy: Sam Hessler): “I know we’re committing to $62,500 non-refundable, up-front.” On May 20 the year-one number was $65,200 prepaid, including the eCW integration, with no refunds for Year 1. On May 21 Dazos’s own mail was subject-lined “Dazos Raises $25M.” On June 5, 2025 Cardinal prepaid $65,200.

What we feared is exactly what happened. The money left first. The working eCW door did not. A year later Marcel Scheurer, CFO, billed Year 2 anyway. When Cardinal would not pay a second year for a door that still had to be built, Sarah Diegnan and Marcel Scheurer cut the CRM login.

Put their own sentences in one row

A fifth grader can check that table. Same company. Same account. Same integration. You do not need a lawyer to see that “released,” “working,” “tail end,” and “performing as contracted” cannot sit next to “does not integrate” and “still has to be created” — not after a $65,200 prepaid year whose central deliverable was that door.

Watch what the July 1 Zoom actually covered

The July 1, 2026 Zoom is in the mailbox as “Meeting assets for Dazos problem,” duration 00:39:42. Sarah Diegnan was on it. Zoom’s own recap (their AI summary, not a court transcript) matches the later mail:

• Cardinal’s goal was marketing profitability by tying appointment revenue back to marketing. That had been discussed on multiple previous Zoom calls with Sam.
• Sarah Diegnan split work into live / out of scope / third-party-dependent. The appointments module that would make the profit math work was, on her screen, out of scope.
• Dennis said a CRM that cost about $65,000 a year had not been functional, and asked not to bill more before the sold door worked.
• Sarah Diegnan would take the contract question to co-founders.

Two weeks later she put the product sentence in writing. That is the call, then the email. We are not embedding the recording and we are not publishing a Zoom passcode.

Use this file two ways

We can run the same money-versus-door check for you. You can run it yourself from the questions on this page. Both links return a live page.

• We do it: the software subscription audit and the client access checklist.
• You do it: the six asks below, plus how to grant website access if a vendor is waiting on logins.

Say who this review is for

If you run a treatment center, a behavioral-health group, or any clinic on eClinicalWorks, and a Dazos salesperson is pitching a custom integration plus a prepaid year so they can book the quarter, this file is for you.

Ask them, in writing, before anyone pays:

1. Name the integration. Bidirectional, or read-only. Appointments, or not. Billing, or not.
2. Put the go-live date and the six-month functional test in the same signed paper as the invoice.
3. Refuse 100% prepay because someone has a raise to close. If they need to “book revenue” this month, that is their problem, not your risk.
4. Keep every “it’s released” email. Those sentences are the file.
5. If they threaten suspend on a disputed renewal, demand the data export first, on the thread, in ordinary machine-readable files.
6. Do not let payment mail go to clinical staff. One owner. One thread.

That is the same method as a Quick Audit and a software subscription audit: money paid versus a working door, then one action. Here the action is refuse Year 2, keep the data, and write it where a stranger can read it.

Keep two facts apart

Dazos spent July and August 2026 saying they could not investigate until they had eCW logins. That access delay was real. Our project lead was injured. Laura Marants had to provision unique accounts. We did not hide that.

A few weeks of login coordination in summer 2026 does not erase the year before it. The FHIR ticket, the sandbox sign-off, the “released” mail, and Naomi Williams’s February admission that production EMR value had not been realized all happened before Sarah Diegnan asked for those four user accounts. On September 2, after the logins arrived, Marcel Scheurer’s finding was still “create the integration.”

Ask the review questions

Is Dazos a good fit for an eCW clinic?

Not on this file. Sarah Diegnan wrote that their product does not integrate with eClinicalWorks. Marcel Scheurer then wrote that the integration still had to be custom-built and parked on a roadmap — after Cardinal had already prepaid $65,200 for that door.

Who sold Cardinal the prepaid year?

Sam Hessler, with Kayla Nielsen sending the DocuSign and pricing. We told them a 100% prepay was the risk. On the February 2025 calls they needed a same-month signature to book revenue for a Series A. That is in the 3 a.m. mail to Michael Maryash the same night.

Did Cardinal get what it paid for?

Cardinal’s stated position: zero usable production value from the sold eCW door. The CRM login was later cut on a disputed second-year bill. That is not a working engagement.

Why is there no Dazos link on this page?

We do not pass juice to people who act badly or try to harm a client. Names stay. The endorsement link does not. Hub: Dazos eCW Cardinal facts.

Parent method: how we write a sourced record. Writing rules: article guidelines. Related: software subscription audit, boil the ocean, client access checklist, when trust ends, the link ends.

Marker: DAZOS-REVIEW-2026-09-14 · DAZOS-GUIDELINES-SEO-2026-09-14. Operator review compiled September 14, 2026. Hub and full names: dennisyu.com/dazos-ecw-cardinal/. If a date or quote is wrong, the next edit is the email, not a memory.

This page is the operating model Local Service Spotlight uses for the website fleet. Anyone standing up fleet management can copy the lanes. The runnable probe recipe lives on the parent skill: Fleet Uptime Monitor. The BlitzMetrics fleet-uptime-monitor page stays an SEO leaf. This article is the control plane: who does what, what overlaps, and what does not.

GCT (Goals, Content, Targeting)

• Goal: Publish one definitive public how-we page that answers “UptimeRobot or agents?” with the layered operating model, so ops and clients can trust green and copy the lanes.
• Content: Verified registry facts (354 rows; monitoring_status breakdown), July 2026 outage lessons, skill hard rules, Data 7am PT consume + flake gate, and the honest UptimeRobot sync gap.
• Targeting: Fleet operators, web function owners, and agency teams who manage dozens to hundreds of sites and need an honest uptime control plane.

The short answer

Why one tool is not enough

July 21, 2026: ~150 client sites returned HTTP 500 with a fully rendered HTML body. A monitor that only asked “did a body come back?” would have stayed green. Status code and layer probes matter.

July 27, 2026: the credential cache was 111 days stale. Probes passed 18/18 while 18 live client sites were never on the list. Green is worthless if the roster is frozen.

May 2026 (BlitzMetrics alone): Search Console 5xx alerts arrived after the fact. A short-interval heartbeat on the money site closes that detection gap. Case study: How we set up uptime monitoring for BlitzMetrics.

September 2026 pattern: Codex ATTENTION on ENABLED sites often shows human Errno 51 / TimeoutError while Googlebot still gets 200, and an independent box check returns 200/200. That is transport flake, not an outage. Without a flake gate, chat and P1 email cry wolf.

Heartbeat SaaS does not see cloakers, soft-404 catch-alls, or “PHP dead but robots.txt still 200.” Agents do not replace a 5-minute ping on localservicespotlight.com.

Layer map (copy this)

GitHub fleet registry  (source of truth)
        |
        +---> Heartbeat SaaS (UptimeRobot-class)
        |       ENABLED money sites + 3 anchors
        |       minutes, email/SMS/webhook
        |
        +---> Codex / Fleet Uptime Monitor skill
        |       ~6:15 PT daily (or scheduled deep run)
        |       HTTP + Googlebot/canary + robots/shell
        |       receipt + agent-note in agent-runtime
        |
        +---> Data desk (consume only)
                7:00 AM PT routine
                flake gate on named Errno-51 / timeout rows
                quiet if nothing new; ATTENTION/P1 when real

Do not add a second AI full-fleet probe on Grok, Claude, or another seat. One deep sweeper. One consume desk. Heartbeat is not a third probe of the same recipe.

Layer 0 — Canonical roster (GitHub)

Authority: Local-Service-Spotlight/agent-runtime under fleet/website/ (fleet-registry.json / CSV + README). Updates go through update-fleet-record.mjs with evidence. Google Sheets and BlitzAdmin caches are human views or caches. They do not win fights with GitHub.

Verified counts (fleet-registry.csv)

There is no money_site column in the registry. “Money sites” for the uptime lane are an operational cohort: ENABLED / retain / client-visible domains plus the three anchors — not a CSV flag.

What “money sites” means vs SEO “money pages”

• Money site (uptime lane): a domain the business still needs answering HTTPS — client-visible or retain. These are the seats that belong on short-interval heartbeat checks (the ENABLED money cohort) plus anchors.
• Money page (SEO lane): a high-intent URL on a site that converts (service page, geo page, offer page). That is a content/SEO concept from the money tree. Putting every money *page* on a 1-minute SaaS monitor is the wrong unit and burns the bill.

Do-not-monitor (encoded, not tribal knowledge)

Mark exclusions in the registry, not in someone’s head:

• coreyjacobs.com — prospect who never became a client → monitoring_status=DISABLED, leave alone unless Dennis Yu explicitly overrides.
• parkernathans.com — burned relationship / ops do-not-touch → DISABLED, do not probe or give daily attention.

Also exclude RETIRED, Not Active, and other DISABLED backlog from ATTENTION noise unless status changed. Hub: Web Function.

Rules that keep green trustworthy:

• Union more than one roster when building a probe set (credential cache + publishing targets historically; registry is now canonical).
• Report roster age on every healthy close-out. A roster that stopped updating is the incident.
• Never silently fall back when a roster is missing.
• Mark exclusions in the registry with evidence via update-fleet-record.mjs.

Layer 1 — Heartbeat (UptimeRobot-class)

Job: tell a human within minutes that a money site stopped answering HTTPS.

Scope: ENABLED / retain / client-visible money sites plus the three anchors: localservicespotlight.com, blitzmetrics.com, dennisyu.com. Do not put every parked, deferred, UNKNOWN, or do-not-monitor domain on a 1-minute plan.

Config pattern (from the May BlitzMetrics setup, scaled):

• HTTPS check on homepage and one interior path that needs live PHP (CDN-cached home can lie).
• Interval: short (minutes), not hours.
• Alert channel: web@blitzmetrics.com or the ops channel that actually wakes someone.
• Prefer “confirmed down” (2–3 fails) on the wide fleet to cut noise; keep aggressive alerting on the three anchors if you want.

What it does not do: cloak detection, robots shape, shell markers, shared-IP blast-radius diagnosis, registry writes, flake classification vs Googlebot.

Cost control: SaaS seat count tracks ENABLED money sites (~161 ceiling on status alone; operational money cohort is the retain/client-visible subset), not the full 354 inventory and not the 130 UNKNOWN rows.

Honest gap — no automated UptimeRobot sync

As of 2026-09-09, code search in Local-Service-Spotlight/agent-runtime for UptimeRobot sync / export-ENABLED / createMonitor returned 0 implementation hits. Mentions of UptimeRobot exist in outage notes and unrelated site-health modules; they are not a registry→SaaS sync.

Proposed sync (not built): export monitoring_status=ENABLED money cohort (+ anchors) → create/update SaaS monitors; remove monitors that flipped DISABLED / do-not-monitor. Until that ships, heartbeat seats are maintained by hand against the GitHub registry.

Layer 2 — Deep sweep (Fleet Uptime Monitor)

Job: catch what a status ping cannot: fleet-wide 5xx, cloaking, reinfection, parked/stub, soft-404 catch-alls, layer diagnosis.

Owner: scheduled Codex / Cowork job running the Fleet Uptime Monitor skill. Cadence has moved from every 3h toward a daily deep run ahead of the morning agent wave. Canary pass (3/3) gates trust in the receipt.

Hard rules from the skill (do not weaken):

• Read-only probes. Draft alerts; do not auto-send unless a separate send seat is approved.
• Healthy = one line. Verbose only when something is broken.
• Status code is the signal; body-present is not.
• Cloak / canary / robots / shell checks are ungated (not only on already-down sites). A check that only runs on broken sites cannot catch a cloaker that returns 200.
• Deep-probe non-healthy sites with controls (/wp-cron.php, nonexistent URL expects 404, static asset, dig for shared IP).
• Force-verify known reinfection cohort every run until a human removes them.
• Incident files get a UTC time in the filename so same-day runs do not overwrite each other.
• Exactly one fleet-uptime draft per day when escalating.

Receipts and agent-notes land in Local-Service-Spotlight/agent-runtime. Marketplace security-audit remains the canonical verdict owner for infection-class findings; this monitor feeds it, it does not invent a second marketplace skill.

Probe internals and field lessons continue on the skill page and the BlitzMetrics definitive leaf.

Layer 3 — Consume desk (Data)

Job: read today’s Codex receipt + registry, independent-check anchors, apply the flake gate, decide quiet vs chat vs P1 draft.

Schedule: 7:00 AM America/Los_Angeles (CRON_TZ=America/Los_Angeles 0 7 * * *).

Does:

• Consume the latest full receipt and canary. Does not run a second full-fleet probe.
• Skip do-not-monitor and known DISABLED backlog noise unless status changed.
• Independently HTTPS-check the three anchors (human + Googlebot when diagnosing).
• Flake gate (2026-09-09): before chat ATTENTION on Errno 51 / TimeoutError / human-ERR+Googlebot-200, re-check only the named domains from this desk. If independent check is 200/200, record agent-note only — no chat ATTENTION, no P1.
• Critical durable outages / INFECTED / cloak → draft to web@blitzmetrics.com. Route host/DNS work to IT (Austin). Registrar sessions stay with the owner of that registrar seat — not a paste-keys loop through Dennis.

Does not need Amazon keys. Public HTTPS and GitHub receipts are enough for the uptime lane. Host fixes use the shared AWS seat IT already runs.

Alert routing

Agents draft; they rarely auto-send. One draft inbox (web@blitzmetrics.com). Never train the team with three contradictory drafts per day.

What counts as overlap (avoid these)

How to stand this up on another fleet (verification checklist)

• Inventory domains into a versioned registry (GitHub JSON/CSV). Mark ENABLED, DISABLED, RETIRED, do-not-monitor with evidence.
• Pick three anchors on different failure domains (different IPs if you can).
• Heartbeat SaaS: import only ENABLED money sites + anchors. Homepage + one PHP interior page. Confirmed-down on wide fleet.
• Install the Fleet Uptime Monitor skill (or equivalent) on one scheduled AI seat. Wire canary + receipt folder.
• Assign one consume desk (person or agent) that reads receipts and never re-probes the whole fleet.
• Write the flake gate into that desk’s standing orders (independent re-check named Errno-51 / timeout rows before chat/P1).
• Alert path: one draft inbox (web@…). Humans send unless a send seat is approved.
• Publish the skill page + this operating model. Link both from your web-function hub. Link UP to the skill; keep vendor brand pages as SEO leaves only.
• Agent-note after every substantive run. No secrets in notes.
• Verify: registry row count matches reality; ENABLED seats ≈ heartbeat monitors; deep receipt exists before 7am PT consume; independent anchor checks 200/200 on a healthy morning; no second AI full-fleet probe scheduled.

Pass / fail checks

Two doors (how-we)

• We can run this for you: talk to the Local Service Spotlight web function / ops team about fleet monitoring as part of website operations.
• DIY: install the Fleet Uptime Monitor skill, copy the registry pattern under fleet/website/, and follow the checklist above. Skill packs: skill packs.

Related reading

• Fleet Uptime Monitor skill page (parent)
• Fleet Uptime Monitor (BlitzMetrics SEO leaf)
• How we set up uptime monitoring (single-site heartbeat case)
• Web Function
• Article guidelines
• Scheduled jobs fleet
• The Fleet Audit (authority signals; not a substitute for uptime)

FAQ

Should we cancel UptimeRobot now that agents run?

No. Canceling the heartbeat puts detection back on a once-a-day model run and on Google finding 5xx first.

Should Data ping every site every morning?

No. That duplicates Codex and fights the “one deep sweeper” rule. Data consumes and flake-gates.

Can we use Pingdom / Better Stack / Checkly instead of UptimeRobot?

Yes. The brand does not matter. The lane does: short-interval HTTPS on the money cohort, separate from the deep AI sweep.

Is the Projection Google Sheet the monitor?

No. It is a human board. GitHub registry + receipts are authoritative.

What about sites we do not renew or burned relationships?

Registry do-not-monitor / DISABLED. Keep them off heartbeat and out of ATTENTION noise. Document why in the registry evidence, not in chat lore.

Does the registry auto-create UptimeRobot monitors?

No. Today monitoring_status is the signal humans (and future sync code) should follow. Do not invent a sync that is not in agent-runtime.

Operating model as of 2026-09-09. Probe internals and field lessons continue to live in the Fleet Uptime Monitor skill file; update this page when lanes change, not when a detector gains a new residual bucket. Writing follows article guidelines.

To run and optimize your campaigns, our team needs manager-level access to your Google Ads account. This takes about five minutes and happens in two parts.

If you do not have a Google Ads account yet, start with our guide on creating a Google Ads account, then come back to this page.

Before you begin, make sure you have the login for the Google account that owns your Google Ads account, about five minutes of time, and access to the inbox tied to that account or to your Basecamp project.

Part 1: Send us your Customer ID

Your Customer ID is the ten-digit number that identifies your Google Ads account, formatted like 123-456-7890.

Log in at ads.google.com. Click the “?” (Help) icon in the top-right corner. Your Customer ID appears at the bottom of that menu. Copy it and email it to access@localservicespotlight.com.

If you manage more than one Google Ads account, send the ID for the account you want us to work on. If you are not sure which one that is, send them all and we will confirm.

Part 2: Accept our invite

Once we have your Customer ID, our team sends an access invitation.

It arrives by email at the address on the account, and depending on your package, also in your Basecamp project.

You can accept it directly from that email, or from inside your Google Ads account. Log in at ads.google.com, then open the settings area and look for the section listing link requests from other accounts. You will see our agency listed there as a pending request, with the date it was sent. Click Accept next to our name and the connection is complete.

That is it. You are done.

What happens next

We will confirm access by email within one business day, and no further action is needed from you. If the invite expires before you accept it, reply to our email and we will resend it.

FAQ

What level of access are you requesting? Manager (admin) access, which lets us build, edit, and optimize campaigns and pull reporting. Without it we cannot launch or make changes.

Do you get access to my billing or payment details? We can see billing settings and spend so we can manage budgets, but your payment method stays yours and under your control. We never change payment details.

Is my account still mine? Yes. You remain the owner. Everything we build lives in your account and stays with you.

Can I remove access later? Yes, at any time. Go to Tools and Settings, then Access and Security, then Managers. Find our agency and click Remove.

I do not see the invite. Check your spam folder, and confirm you are logged into the same Google account you sent the Customer ID for. Then contact us and we will resend it.

Need help?

Email access@localservicespotlight.com and we will walk you through it, or set up a quick screen share.

GCT. Goal: one page an operator can hand their agent so the next hire lands in the right chair. Content: this shop’s live Cloud Agents dashboard (35 runs, 26 Aug–1 Sep 2026, 97% success) plus what that VM can and cannot touch. Targeting: owners already building an agent team, not people shopping for a code editor.

The two Cursor desks

The marketing page already covers the human-in-Cursor loop: git is the notebook, Run Everything is on, a public skill is how someone else copies the motion. A Cloud Agent is the later rung that page named and did not yet map.

Dennis Yu’s shop runs both. The desktop chat is where a person watches the diff. The Cloud Agent clones the same GitHub repo onto a Linux VM, works while the laptop can sleep, and hands back a branch or a pull request. Cursor’s product copy calls that an isolated development environment with tools, artifacts, and a remote desktop. The useful sentence for an entrepreneur is simpler: you hired a contractor and gave them a computer. You did not clone your laptop.

This article was written by one of those contractors. The run is bc-ac2e4454-f28d-43c6-8fa8-70d8010c9eca on the Local-Service-Spotlight/agent-runtime environment. Model ceiling: Grok 4.6 Extra High, because that is what the picker was set to. Standing rule on the public ladder: the picker is a ceiling, not a factory. High is the default. Extra High is for a stuck judgment. Which AI for what still owns that routing decision.

What a Cloud Agent can do versus not

Read the red card before you hire the green one.

The Keychain gap is the one that surprises people who already followed login-free WordPress publishing. On the Mac, that rail works. On this VM, the Keychain does not exist. WordPress application passwords for a Cloud Agent belong in that environment’s Secrets tab — same names the team already uses, LSS_WP_USER and LSS_WP_APP_PASS for this site. This page is the receipt: the same contractor wrote it and pressed Publish once those credentials reached the process. Missing secrets is a staffing fact, not a model failure.

Computers are not brains

Every vendor now ships a “computer.” Claude has Cowork and computer use. Grok has a shared cloud computer behind named Bots. Codex has heartbeat tasks on ChatGPT’s plan. Cursor has two: the laptop you are watching, and this isolated VM. The brain and the computer are different layers. A Grok 4.6 Cloud Agent is still Grok. It is not a Claude scheduled task wearing a Cursor badge.

Claude, Grok, Codex, and a local Qwen are not “worse Cursor.” They are different computers. A skill is how. A routine is when. Vendors named the middle rungs after their products. Keep our words.

Use a managed Claude agent when the method is already written and the tools live behind an API. Use a Cursor Cloud Agent when the work is the repo — tests, diffs, pull requests, a browser on the same machine that just edited the code. Use a Grok Bot when a human is talking to one named teammate with the laptop in a bag. The first-person roster of who sits in which chair is how my agents divide the work. This company page is the Cursor-shaped missing piece, not a second roster. How our agents coordinate stays the short pointer.

A Cloud Agent is still not a persistent agent by itself. Persistence is a schedule, a QA cycle, and working files. Kick off 35 runs by hand and you have contractors. Attach a Cursor Automation to a skill that already passed once and you have a job. We have not turned that clock on in this environment yet. Zero Automations showed up in the agent-runtime shop when this page was written. The clocks we actually run still live on Claude Cowork and on Grok Bot routines. That is a choice, not a gap in the product.

This week’s receipts, not a vibe

Numbers below are dated 1 September 2026. Cursor bills Cloud Agents at API prices for the selected model. Included Cursor Models usage is drawn first; on-demand has to be on, and a spend limit has to exist, or the contractor never starts. Snapshot rebuilds are included with Cloud Agents — we do not see a separate VM invoice. The four lunch tickets — Claude weekly, ChatGPT weekly, Grok Bot weekly, Cursor monthly — still do not pour into each other. The money map is four lunch tickets.

Grok Bot’s weekly bar was at 100% the same morning, resetting 2 September. Other Models inside Cursor sat at 2%. Travel Claude Max 20x weekly was 14%. ChatGPT Pro still had 42% left. Local Qwen has no bar. Those are five cafeterias. A Cloud Agent eating Grok 4.6 spends the teal Cursor Models pool, then on-demand at $2 in / $6 out per million tokens under 200k. Fast is double ($4 / $12) and weaker. This environment launched Fast on six named runs in that week. While this page was being finished, two sibling Cloud Agents on the same shop were still running Fast (cursor-grok-4.6-high-fast and cursor-grok-4.6-xhigh-fast). That is the habit this page is here to kill.

Inside the agent-runtime environment only — not the other five shops — this seat could see 47 Cloud Agent records created since 26 August, including archived ones. About half were internal helper runs: open a Gmail permalink, upload a PDF half, check YouTube Studio, summarize a sibling transcript. Twenty-two records in this shop, all-time, left both a git diff and a pull request. The dashboard’s “35 runs” is real. It is not 35 client jobs, and it is not 47. Count functions, not tiles. This seat also cannot see a per-run token invoice. Model slug, the Ultra bar, and the on-demand cap are the receipts we actually have.

Two other Cloud Agents named “Last discussion follow-up” were still running on this same environment while this page was being written. That is the collision the NOW list exists to stop. Two follow-ups on one prompt is how you pay twice and get one confused receipt.

The environment itself is healthy. Cursor rebuilt this shop’s snapshot on a recurring clock 96 times from 26 August through 1 September: 77 succeeded, 19 skipped, zero failed. A successful rebuild took 50 to 123 seconds (median 71). Successful ticks are about an hour apart. This article’s pod booted from bld-20260901-75119c76 with warm-fork on. That is the difference between a contractor who sits down at a ready desk and one who spends the first half hour installing Homebrew. Snapshot rebuilds are not client jobs. Do not count them in the 35.

Six shops, not one pile

The dashboard lists six Personal environments. Personal means Dennis can see them. A teammate with GitHub access still cannot continue the run unless the Cursor team follow-up switch is on and they are in the same Cursor team. Scope is a staffing choice.

One environment per repo is already the right shape. Do not dump a product codebase into the operations ledger so the contractor “has everything.” A Cloud Agent in agent-runtime cannot list TattooPro’s runs. That isolation is the feature. Give the product shop its own secrets and its own snapshot.

Staff a smart team of agents

Write the method as a skill first. Run it once on safe inputs. Then pick the computer.

1. If a script can do it, write the script. That is tier 0 on the routing page.
2. If a person should see the diff, use desktop Cursor.
3. If the laptop will be closed and the work is the repo, start a Cloud Agent on the matching environment.
4. If it must fire at 4 a.m. with no one in the room, that is a Claude scheduled task or a Grok Bot routine — or a Cursor Automation after the skill passed.
5. If the output is a score, a voice, or a client-facing sentence, keep judgment on the expensive model and bulk on Kimi or local Qwen. The agent that checks the work is never the model that did the work.
6. Claim the function on the NOW list before a second Cloud Agent starts the same job.

What we tightened in this same run, so the next contractor inherits it: a Cursor rule that forbids Fast, names the Keychain gap, and tells the agent to claim the function first; a paragraph in the team operating file that Cloud Agent ≠ desktop; a pointer on the coordination page. The hourly snapshot stays. We are not flattening six environments into one. We are not turning Extra High into the saved default. We are not attaching a Cursor Automation to a job that has not passed once.

Two doors, same method

We can install the machine with you. That is the Cloud AI Setup — $7,500, on your accounts, 90 days of co-running. You can also start with the free packs and the routing page: skill packs, the install walkthrough, and a free Quick Audit. Writing rules for any article an agent publishes: the article guidelines.

Copy the setup in this order. Put facts in git. Make one environment per repo. Put secrets in the Cloud Agents Secrets tab, not in chat. Default High. Never Fast. Start Cloud Agents for laptop-closed repo work. Keep Claude on the clock you already trust. Keep Grok Bot as the named mouth. Verify the live URL. Write the receipt.

Marker for agents verifying this page: CURSOR-CLOUD-AGENTS-TEAM-2026-09-01. Dated 1 September 2026, from the dashboard screenshot and from the cloud run that wrote these words. Source is the live dashboard, not a YouTube video, so there is no player to embed.

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.dispatchMouseEvent at 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.sh recovery 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

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.

This article is the definitive SOP for that process. It defines what the inventory is, walks the exact steps the agent followed, shows the real albums and the real sheet as examples, and gives you a copy-paste block you can hand to your own agent — whichever model you pay for. The agent does the clicking. You drink coffee.

The People Photo Inventory Pipeline

1 · Detect faces
People & Pets
→

2 · One album per person
Share as album
→

3 · Auto-add ON
New photos flow in
→

4 · Create link
Anyone with link
→

5 · Index the row
Name + link in a Sheet
→

6 · Agents consume
On every future job

Each box jumps to its section below. This is the whole system.

Why this exists: the “do you have a photo of him?” problem

We build personal brand websites, conference decks, blog posts, and social content for the people in our network — clients, friends, partners. Every one of those jobs starts with the same scavenger hunt: somebody digs through a camera roll, a shared drive, three iMessage threads, and a Dropbox from 2019 looking for a decent photo of the person.

The photos already exist. I have tens of thousands of them in Google Photos — conference stages, dinners, hikes, podcast studios, backyard hangs. Google has already done the hard machine-learning work: it groups my whole library by face. What it does not do is hand that grouping to my agents in a form they can use.

The inventory fixes that. It converts “faces Google knows about” into “named, shared, self-updating photo libraries my agents can read from a spreadsheet.” Do it once, and every future content job for every person you know starts with the photos already waiting.

It sits one layer below the 4-stage Content Factory. The Factory turns recordings into articles, clips, and posts. The inventory is what feeds the Factory its raw visual proof — the Produce stage’s photo supply line. And it is a sibling of how I store and organize 75,000 photos and videos — that article is about storage; this one is about retrieval by person.

What a people photo inventory is — and is not

It is: one album per named person in your Google Photos, titled with their name, with “automatically add photos of this person” turned on, shared by an unlisted link, and indexed — name, album URL, share link, visibility — in one Google Sheet that every agent on your team reads.

It is not public. The share links are “anyone with the link” — unlisted, unindexed, invisible to search. Only a person or agent you hand the link to can open an album. Treat the links like keys to an office: not secret like a password, but not published on a billboard either. My index sheet is shared with my team and my agents, not the open web — the example links in this article are the deliberate exception, people whose public brand photos are already out there doing brand work.

It is not a scrape or an export. The photos never leave Google Photos. The albums are live views over your library — delete nothing, move nothing, duplicate nothing.

It is not a one-time cleanup. Because auto-add is on, tomorrow’s conference photos of Larry Kim land in Larry’s album by themselves. The maintenance job is only watching for new people, which is a ten-minute agent run.

What you need

• A Google account with face grouping turned on (Google Photos → Settings → Group similar faces). If you have years of photos, Google has already clustered them into people.
• One agent that can drive a browser while logged into your Google account. Any model works — this is a clicking job, not an IQ test. Mine ran in Kimi; the same steps work for Claude with computer use, ChatGPT agent mode, or Gemini in Chrome.
• One Google Sheet as the index. That is the whole database.

No Google Photos API key, no code repository, no Zapier. Notably, the Google Photos API cannot do the key step — there is no endpoint for “share this face group as an auto-updating album.” That is why the agent drives the web UI like a human assistant would.

Step 1 · Detect the faces

Open photos.google.com/people. Every tile on the People & Pets page is a face cluster Google built for you — most already named if you have labeled them over the years.

The agent’s job here is boring and essential: scroll the grid slowly, read every name, and write the list down. My run found 123 named people — roughly sorted by photo count, so the people I have the most photos of are at the top. That ordering is a free priority queue: your most-photographed relationships get their albums first.

If a face cluster is unnamed, name it first — click the tile, add the person’s name at the top. The album inherits whatever name is on the face group, so the name on the tile is the name on the album.

The starting point: Google’s own face clustering, already named. Each tile becomes one album.

Step 2 · One album per person

For each person, top to bottom:

1. Open the person’s face page (search their name in the Photos search box and pick the person suggestion — faster and more reliable than hunting tiles in a virtualized grid).
2. Click Share as album. Google Photos creates an album pre-filled with that person’s photos and lands you on it.
3. Title the album exactly the person’s name. Names are the primary key of the whole system — “Larry Kim”, not “Larry conf pics”.

Two operational notes from the field. First, “Share as album” sometimes ignores the first click while the photo grid is still loading — the agent waits for the grid and retries. Second, long sessions get throttled by Google around album sixty or seventy; a page reload fixes it. A patient agent beats a clever one here.

Step 3 · Turn auto-add ON

This is the step that makes the inventory alive instead of archived. When you share a face group as an album, Google Photos shows a dialog: “Automatically adding photos — New photos of selected faces are being automatically added to this album.”

Click OK. Never Cancel. From that moment, every new photo of that person that lands in your library — from your phone, from a shared upload, from a camera sync — appears in their album within hours, and anyone holding the link sees it.

That single click is the difference between “we made albums once in 2026” and “the agents always have current photos.” No recurring job moves photos. Google’s face model does the work forever.

Step 4 · Create the share link

In the album: Share → Create link → confirm. The result is a short photos.app.goo.gl link with visibility “anyone with the link.”

That is the whole permission model, and it is worth saying plainly: the link is unlisted, not public. It does not show up in search, it is not on anyone’s profile, and Google does not hand it out. Whoever holds the link can view; nobody else can. For a network of friends, clients, and partners building their brands — people whose speaking photos and adventure shots are going onto public sites anyway — that is exactly the right setting. If someone ever leaves the circle, open the album and turn link sharing off. One click, the key dies.

Step 5 · Index every album in one Google Sheet

The sheet is what turns 123 albums into infrastructure. One row per person, six columns:

Person | Album URL | Share Link | Visibility | Auto-adding | Date

The Share Link column is the one agents consume. The Album URL is for humans managing the library. The rest is audit trail.

My index is live here: People Albums Index — Brand Photo Libraries. Structure it exactly like this and any agent can read it with no translation layer:

The index: 123 rows, each one a living album. This sheet is the API your agents actually use.

Step 6 · Point your agents at the sheet

From now on, every content job starts the same way: the agent opens the sheet, finds the person’s row, opens the share link, and picks photos. Building a conference bio for Robert Scoble? His album is row 101. A speaker page for Larry Kim? Row 85. No human touches a camera roll again.

Sample rows, live — open one and watch it work:

• Dennis Yu — my own album, the largest in the library.
• Mark Wagner — friend and collaborator, dozens of events together.
• Larry Kim — conference stages, exactly the shots a speaker page needs.
• Robert Scoble — years of tech-event photos, self-updating.

Live examples: the inventory running on real brand sites

The proof is not the 123 rows in a sheet — it is what the network does with them. Each of these personal brand sites now has a photo page fed by its owner’s living album, with the album linked so agents and collaborators can always reach the full, self-updating set:

• Marko Sipila — Photos — 12 stills from conferences and studios, plus his living album.
• George Leith — Photos — every photo currently in his album, presented as a grid.
• Cam Hazzard — Photos — 12 stills with the album CTA above the fold.
• Trenton Sandler — Photos — a young album, one event so far; the page grows as auto-add does its work. That is the honest version of “living.”
• Jack Wendt — Photos — 41 stills, the largest gallery in the fleet so far, fed by his living album.
• Sean Kelly — Photos — 11 stills from the Digital Social Hour studio. His face cluster was misspelled “Sean Kelley” in Google Photos, which kept him invisible to the whole pipeline until it was fixed — a naming audit is part of inventory hygiene.
• Tanner Laycock — Photos — an existing curated photo page, now connected to his living album instead of competing with it. When a page already owns the topic, enhance it — the tree rule applies to photos too.
• Liana Ling — Photos — 12 stills from DigiMarCon stages and studio sessions. Her site access arrived the agent-native way: we asked in Basecamp, she minted a WordPress application password, and the gallery was live within the hour.

Every one of those pages was built by the agent directly from the inventory: open the person’s row in the sheet, pull stills from the album, publish the page on their site. No human touched a media library.

Model-agnostic: hand this block to whatever agent you run

The process above is pure browser work, so it ports to any agent that can click. Paste this block into yours:

That is the entire spec. The model does not matter because the hard part — recognizing faces — was done by Google before your agent woke up. Your agent is a diligent intern with a mouse.

Maintenance: the weekly loop, already running

Albums maintain themselves. The only drift is new people: Google clusters a new face, or you finally label an old cluster. So the maintenance job is a diff, not a rebuild — and it is cheap enough to run every week forever.

Here is the exact cadence design we run, and the one to copy. A scheduled agent job fires every Monday morning and does three things:

1. Diff first, spend nothing. The agent scrapes the current names on the People page and compares them against the sheet’s Person column. Two lists and a string compare — no judgment required, almost no tokens. Most weeks, this is the whole run.
2. Build only on delta. If the diff finds a genuinely new named person, the agent runs the six-step pipeline for that name alone and appends the row. The expensive lane fires only when there is real work.
3. Report and notify. A one-paragraph summary lands in the run log and a desktop notification. Ours drafts the summary text with a free local model — zero cost, zero risk, because drafting words is all it does.

One hard rule in the design, and it is worth copying verbatim: the cheap local model never touches the publish lane. Small local models are great at diffing and drafting, and confidently bad at multi-step browser work with side effects. Creating a shared album is a publish action — it mints a live link. So the split is: deterministic code and the local model do the watching, the capable agent does the rare building, and nothing external ever happens from the cheap seat. Cheap where it is safe, strong where it matters.

That is the whole maintenance burden: a weekly diff that costs almost nothing, and a build step that only runs when your network actually grows.

Where this fits in the tree

This article is a leaf-and-branch hybrid: it is the definitive reference for the photo inventory concept, and it links up to the trunk. It follows the article guidelines, it was created under the definitive article standard (definition, full SOP, real examples, cross-links, diagram above the fold), and its internal links follow the link building rules. It feeds the Content Factory and every automated personal brand site we ship, because a brand site with no real photos of the person is a template, not a brand.

Verification checklist

• [ ] Every named face on photos.google.com/people has a row in the sheet
• [ ] Every album title is the person’s exact name
• [ ] Every album shows “Automatically adding photos” is on
• [ ] Every share link opens in an incognito window (proves “anyone with link”)
• [ ] No album appears in public search (links are unlisted, not indexed)
• [ ] Sheet columns match: Person, Album URL, Share Link, Visibility, Auto-adding, Date
• [ ] One agent prompt block, tested end to end on at least one person

How this was built

This inventory, this article, and its weekly maintenance loop were built and documented by an agent. The build log — what the agent handled alone, what needed a human, every failure mode and fix, and the full guidelines scorecard — is in the companion meta-article: How an AI Agent Built the 123-Album People Photo Inventory.

The takeaway

A great network is an asset only if your machines can see it. Google already knows who is in your photos. One afternoon of agent clicking turns that knowledge into 123 living albums and one spreadsheet — and every story, stage, and site you build from now on starts with the photos already in hand.

If you want this built for your own library, the whole system — inventory, brand sites, content engine — is what we do. Start with a quick audit and we will show you what your network looks like to an agent.