Bridget Overson Savannah, GA 2H AGO

Every Friday at 10 a.m. ET, a scheduled Claude agent refreshes a living "Hevy Workout Log" document with that week's strength-training data, body measurements, and a progress photo. The automation runs fully unattended, with no human in the loop after the owner sets it up. The agent pulls information from three independent systems: the Hevy fitness-tracking API, a Google Drive photo folder, and the living document. It reconciles those sources against a date range, determines what's new versus already recorded, and writes structured, formatted updates in the correct places. This requires more judgment than a simple script or webhook. The scheduled task starts a fresh agent session every Friday at 10 a.m. ET with the full task specification and API key included in the prompt. The Hevy API is the source of truth for workouts from `GET /v1/workouts` and body measurements from `GET /v1/body_measurements`; both endpoints are paginated. Google Drive holds the "Progress Pics" folder, which the agent searches by file timestamp. Claude Docs, through a Claude Artifact, is the living document: it has one tab for each weekday and a Weekly Summary tab, and the agent edits it in place with structured operations rather than full rewrites. To embed a photo, the agent downloads the Drive file locally, uploads it to the Claude Artifact asset store, converts it to a document-native blob, and references it as a Markdown image. There is no custom backend, database, or glue code. The agent calls each system's API directly and keeps the orchestration logic in its reasoning for that run. Step-by-step: 1. Read the document's current state and find the most recent week already recorded in the Weekly Summary tab. 2. Call the Hevy API and determine which Monday–Friday week has just ended, making sure today's date is past that week's Friday. 3. Check whether that week's row is already in the Weekly Summary table, fully populated, and contains the latest matching photo. If everything is already recorded, there may be nothing to update, but the agent still checks for a newer photo that may have appeared in Drive after the data was written. 4. Pull per-set details for every workout that week, including the exercise, weight, and reps. Compute total daily lifted volume by summing weight × reps for each set on each day. 5. Search the Google Drive photos folder for images timestamped within that Monday–Sunday window. Select the single most recent image, replacing any older photo already embedded for that week. 6. Pull body measurements from the same week and calculate weekly averages for weight and body fat, along with the week's waist reading. Convert units as needed from kilograms to pounds and centimeters to inches. 7. Update the Weekly Summary tab with one row per week, including daily volumes, weekly averages, and the progress photo. 8. Update each weekday tab with a dated section containing the workout name, a per-exercise set-by-set table, and a Total row for summed volume and reps. If no workout was logged, add a note instead. 9. Send the human a plain-language summary every time, describing what changed or confirming that nothing changed, because nobody is watching the scheduled run live. The workflow is idempotent without a database. There is no job-tracking table; on each run, the agent reads the live document, compares dates, and checks whether cells are filled before deciding what to write. Progress photos are not tagged by week, so the agent matches them only by whether their Drive timestamp falls within the Monday–Sunday window. It explicitly selects the most recent match, allowing a better photo taken later in the week to replace an earlier embedded photo. The workflow also handles the multi-hop process required to embed an image in a live document: Drive file to local download, artifact asset upload, document-native blob conversion, and Markdown image reference. If the Hevy API key is revoked, the task stops cleanly and tells the owner to generate a new key and provide it, rather than failing silently or looping. Because the workflow runs on a schedule without anyone watching, its specification requires a notification every time, including when nothing changed. This keeps the automation auditable even when it performs no updates.