The People Photo Inventory: One Living Album per Person

A people photo inventory is one shared, auto-updating Google Photos album for every person in your network, indexed in a single Google Sheet, so any agent you run — Claude, ChatGPT, Kimi, Gemini, whatever you like — can pull real photos of a real person the moment a story, conference deck, blog post, or personal brand site needs them. I had my agent build mine this week: 123 people, 123 albums, 123 share links, one index sheet — built in my own Google Photos library while I did other things.

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.

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.