Share your best AI workflow. We could show it to 2M+ people.

I built a meal tracker where my only job is to photograph a plate and send it to an agent. Identification, portion estimates, macros, storage, corrections, and the weekly review happen without me. The part worth stealing isn't the food. The agent has its own email address and iMessage thread, so anything I can send from my phone becomes an input. I send a photo through whichever channel takes fewer taps. I send corrections as plain English with `CORRECTION` in the subject, and answer questions in the same thread. There’s no app and no form. Adding a channel took an afternoon and changed what the agent could be pointed at—the tracker is just one use of an agent you can talk to. It polls on a schedule instead of using a webhook because my laptop sleeps and a local gateway would be unavailable half the time. Storage is append-only JSONL. Corrections append a new record with the same ID using last-write-wins, so the stats layer sees one meal while the original estimate stays on disk. Every number can be traced back to the model’s first guess and my override. The accuracy mechanism is a challenge step. Every photo is estimated twice: first by the main model, then by a blind subagent that receives only the photo and the rubric—not the first answer. If it identifies different food, the entry is downgraded to low confidence and becomes a question for me. Testing before making the system autonomous caught bugs that otherwise would have failed silently. The API returns attachments under a different field than I had assumed, and only on the detail endpoint. As a result, a photo email was read as having no attachments, and every meal photo would have been dropped while the daily task logged a tidy “no new meals” and appeared healthy. The send path was separately broken, which would have killed the weekly review on a Sunday even with everything upstream working. A silent no-op that produces a plausible clean run is what this category of build is prone to. The bug that actually cost me was token usage: each blind challenge read used about 44,000 tokens, so a five-photo dinner cost roughly 220,000 tokens for one meal and capped my usage. The fixes, in order of effect, were to run the challenger on a cheap model, skip it once a named product or my confirmation has settled the entry, downscale photos for viewing, and republish the dashboard only when the data changes. Measuring first mattered—I would have blamed photo size, but that was the smaller half. The honest limits are important: calorie estimates from a photo are 20–25% off at best, identification error is a bigger risk than arithmetic error, and alcohol, water, and caffeine are never estimated from photos. The sequence in which I asked for things mattered more than any single instruction: Step-by-step: 1. I gave the goal and the one ingestion mechanic I was sure about, then insisted on an agreed plan before any code. Arguing about storage and failure modes is cheap before code is attached. 2. Before scheduling anything, I processed one real input end to end in front of me, including every outbound path. Inbound gets tested because I use it; the reply and the weekly digest do not. 3. When the agent reported something about my own input that I knew was wrong, I said so and made it re-check. Confidently wrong answers about things I witnessed were the cheapest bugs to find. 4. I asked for an independent second assessment of anything estimated rather than read, and decided up front what level of agreement was enough to accept the result. 5. I asked for a visible audit surface showing every field the agent claims to track, with a correction control on it. 6. I asked the agent to look up anything knowable rather than estimate it. A named product is a lookup; only the unnameable needs a guess. 7. I treated approval friction and token cost as requirements rather than complaints, and measured before changing anything. Almost every rule exists because something went wrong in ordinary use, not because it was designed up front. An agent I can email or text, which keeps records and answers back, is general-purpose; I’ve pointed it at one narrow job. What else would you point it at?

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.