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

I built an automation workflow with n8n and the OpenAI API to summarize AI news. I learned that prompt templates matter a lot, and chunking documents improved my results. My question for the community is about handling OpenAI API rate limits in n8n workflows. Is anyone else building AI news digest automations with n8n and ChatGPT prompts? 1. I built an AI news summarization workflow with n8n and the OpenAI API. 2. I used prompt templates and found that they had a significant impact on the results. 3. I added document chunking, which improved the summaries. 4. I’m looking for advice from others who have handled OpenAI API rate limits in n8n workflows.

I built an autonomous learning workbook in ChatGPT Projects to help me stay ahead of where I am and where I need to be. Keeping up with that gap has been a labor of love and tears. The goal of the project is to catalog: - What I know - What I’ve forgotten - What I’m currently learning - What skills I need for my career goals - What has changed in healthcare, AI, and my industry - The single highest-value thing for me to do next I use the following prompt in ChatGPT Projects. It may take some tweaking for your personal needs, but feel free to use it as you see fit: > Engineer dashboards for: Learning Progress, Competency Growth, Learning Hours, Weekly Progress, Monthly Progress, Retention, Knowledge Coverage, Executive Readiness, Upcoming Reviews, Learning Recommendations, Skill Heat Map, Learning Velocity, Credential Progress, Continuing Education Credits, and Certification Status. Step-by-step: 1. I created an autonomous learning workbook in ChatGPT Projects. 2. I defined the information I wanted the project to catalog, including my current knowledge, forgotten material, active learning, career-skill needs, industry changes, and highest-value next action. 3. I sent ChatGPT Projects a prompt to engineer dashboards for learning progress, competency, retention, reviews, recommendations, credentials, continuing education, and certification status. 4. I planned to tweak the prompt and dashboards for my personal needs.

The week before leaving for a multi-day hiking trip, I used to spend hours tracking weather sites, trail conditions, and flood and closure alerts—even though I knew everything could change the next day or by the time I left. Now I have Claude handle the research. First, I give it the basics: trail details, entry and exit points, dates, group size, and permit information. These details do not change, so they provide context for everything else. Then I ask it to search for current weather, fire, flood, and closure alerts; permit status; and recent trip reports covering water and trail conditions. I ask it to cite the source for each item. I do not let it answer from memory because conditions are too time-sensitive. I also ask it to build me a Plan B. After years of living in the mountains, I know how quickly conditions can change. Most people skip this, but I recommend always having a backup plan. I ask Claude to turn the terrain into specific decision rules, such as "Turn back if snow above 8,000ft" or "skip the crossing if water's above knee height". Finally, I set it up to give me a daily report—usually five days before the trip, two days before, and on the morning of departure—and to flag only what changed. Step-by-step: 1. I provide Claude with the trail details, entry and exit points, dates, group size, and permit information. 2. I ask it to search for current weather, fire, flood, and closure alerts, permit status, and recent trip reports about water and trail conditions. 3. I require a source citation for each item and do not let it rely on memory because the conditions are time-sensitive. 4. I ask it to create a Plan B and turn the terrain and conditions into clear decision rules, such as "Turn back if snow above 8,000ft" or "skip the crossing if water's above knee height". 5. I schedule reports for five days before the trip, two days before, and the morning of departure, with updates limited to what changed.

I keep a long wishlist on Audible, but whenever I want a new audiobook, I face the same question: does my library already offer it for free through Libby? Checking hundreds of titles manually feels like too much work, so I often spend a credit instead. I had Claude build a workflow that checks for me. It reads my Audible wishlist and cross-references every title against my library’s Libby catalog, sorting each one into three categories: borrow now, join the waitlist, or not available. The important part was learning to interpret Libby accurately. Badges and time estimates can make an audiobook look ready when it isn’t, and a pending hold can look like an active one. The reliable signal is the exact text on the button: “Borrow” means I can borrow it; anything else means I should wait or move on. Step-by-step: 1. I gave Claude a workflow to read my Audible wishlist. 2. I had it cross-reference every title against my library’s Libby catalog. 3. I had it sort each title into “borrow now,” “join the waitlist,” or “not available.” 4. I configured the workflow to interpret availability using the exact button text rather than relying on badges or time estimates. 5. Before spending an Audible credit, I check whether Libby already has the audiobook ready.

I have an electric car, solar panels on my home, and a home battery. On cloudy days, charging my car drained the battery and drew power from the grid, which I wanted to avoid. I used Claude to write code for my EV charger and inverter. The code monitors my solar panels’ output and adjusts the charging speed so the battery still receives some charge without drawing power from the grid. Step-by-step: 1. I identified that charging my EV on cloudy days was draining the home battery and drawing power from the grid. 2. I asked Claude to write code for my EV charger and inverter. 3. I set up the code to monitor the output from my solar panels. 4. I configured it to adjust the EV’s charging speed based on that output. 5. I used the adjusted charging speed to ensure the home battery received some charge while avoiding grid power draw.

My mum’s 80th birthday is next week, and my dad, sister, and I wanted to create a photobook of her life. My dad scanned hundreds of photos from over the years and sent them to me to clean up. Because we were working to a tight deadline and I was away on holiday, I didn’t have time to open and edit each image individually in Photoshop. I asked ChatGPT to build a tool that accepts a folder of scanned images in various formats, including scans containing single or multiple photos, overlapping photos, and photos cut off by the scanner. The tool processed each scan, cropped and straightened the individual photos, and provided a UI where I could review the results and make manual adjustments to the cropping and orientation before saving the changes to new files. I then had the tool upload the images to Google Drive and create a spreadsheet with thumbnails of every image, along with a rating system. I shared the spreadsheet with my dad and sister so we could use it as a central place to rate the photos we wanted to include in the final book. This saved me hours of work and meant we could complete the photobook in time for my mum’s birthday. Step-by-step: 1. My dad scanned hundreds of photos and sent them to me as image files in various formats. 2. I asked ChatGPT to build a tool that could process scans containing single or multiple photos, overlapping photos, and photos cut off by the scanner. 3. I used the tool to crop and straighten each individual photo. 4. I reviewed the results in the tool’s UI and made manual adjustments to the cropping and orientation where needed. 5. I saved the adjusted photos as new files and had the tool upload them to Google Drive. 6. I had the tool create a spreadsheet containing thumbnails of all the images and a rating system for each photo. 7. I shared the spreadsheet with my dad and sister so we could rate the photos and choose which ones to include in the final photobook.

I built a custom GPT with the personalities of Einstein, Lorentz, Planck, and Compton. Starting with Einstein’s 1920 Leiden lecture, I developed an ontology for physical space based on his description of the “new ether.” I began with E=mc2, E=hf, and my ontological modeling assumptions. I then repeatedly pushed ChatGPT to challenge those assumptions and interpretations logically and mathematically. We used numerous tool calls and reference sites to write and test the math. After many months of working on it in my spare time, the GPT now unifies equations that balance from the atomic scale to the black hole scale, with some remarkable revelations. I summarized much of the work in a paper written by my GPT and am happy to share it so others can expand, improve, and test the work. AI rocks. Step-by-step: 1. I built a custom GPT with the personalities of Einstein, Lorentz, Planck, and Compton. 2. I used Einstein’s 1920 Leiden lecture and his description of the “new ether” to develop an ontology for physical space. 3. I started with E=mc2, E=hf, and my ontological modeling assumptions. 4. I repeatedly challenged the assumptions and interpretations with ChatGPT, focusing on logical and mathematical consistency. 5. I used numerous tool calls and reference sites to write and test the math. 6. After many months of working on the project in my spare time, I summarized much of it in a paper written by my GPT. 7. I am sharing the work so others can expand, improve, and test it.

I am a Mohs surgeon who built and shipped an iOS app without formal software engineering training. The surprising part was not only getting AI to write the code; it was getting AI to remember what it had already done. I built ErgoSherpa because up to 90% of surgeons in my field report musculoskeletal symptoms, while our training fails to address them. I wanted to help surgeons improve their health easily between cases. It is free on the Apple App Store and at ergosherpa.com. The bottleneck was maintaining coherence over time. Many sessions seemed to start from zero: I would re-explain the architecture, then watch a fix quietly undo something I had solved earlier. Three habits fixed that. First, I created persistent project documentation: a `MEMORY.md` index file plus separate topic files for architecture and business decisions. I update them at the end of every session so a new session can read the files first and pick up where the last one stopped. Second, I stopped handing one model the whole job. I use three models and match them to the task. Claude Fable audits only. I open a separate session, point it at the codebase, and require a prioritized checklist with the file path, the problem, and the fix in one sentence—without writing code. A model that did not write the code and has no memory of the project reviews it more honestly than the session that built it. I paste that checklist into a Claude Opus session, which handles the codebase repairs. Claude Sonnet handles routine work such as content updates, image processing, and scheduled maintenance, often from handoffs written by Opus or Fable. Nothing gets implemented on the auditor’s word alone: I have Opus flag any decision that needs human input. This workflow caught a deep-link handler that accepted authentication tokens from any URL and a database policy missing its write-side check. Third, I verify against production, not just the code. Some of the most frustrating parts of the project involved fixes that were correct in the file but wrong on the user’s screen because of a cached asset, a stale database row, or an iOS process that needed a force-quit. I no longer consider anything fixed until I have checked the live app. Step-by-step: 1. I keep a project memory directory with a `MEMORY.md` index and separate topic files for architecture and business decisions, updating them at the end of every session. 2. I open a separate Claude Code session running Claude Fable and prompt it to audit the codebase and return only a prioritized checklist: file path, line number, the problem in one sentence, the fix in one sentence, with no code or commentary. 3. I keep the auditor in its own session with no project history so it reviews the code independently instead of defending work it wrote. 4. I paste the checklist verbatim into a Claude Opus session and have it work from the top down, reading each file and making each change. 5. I tell Opus to flag anything it believes is a false positive instead of implementing it, keeping a human in the loop on key findings. 6. I use Claude Sonnet for routine work such as content updates, image processing, and scheduled maintenance, often from handoffs written by Opus or Fable. 7. I verify every change against the live production site rather than the local files because cached assets and stale database rows can make correct code behave incorrectly for users. 8. I append confirmed lessons and architectural decisions to the project memory so the next session starts from the project’s current state.

I love playing poker, both online and live. One month, I performed poorly. Although it felt like the cards were running badly, I wondered whether I had developed a problem in my game and was blaming my losses on bad luck. I asked around, including asking AI, whether a tool existed that could measure luck from poker hand histories. The unwelcome answer was that it did not. I'm not a coder, but after doing some research into vibe coding, I started building a luck-detection app in a Claude chat. Claude built the UI directly in the chat window and advised me on the formulas I was using to calculate luck for the cards dealt, my performance on the flop, and my performance when I went all in. All three metrics have strong averages, and luck is what varies them. I used a bell curve to model hand outcomes and a Monte Carlo simulator, which Claude suggested and executed, to evaluate all possible outcomes. The result astonished me because it was so useful. I immediately fixed two major leaks in my game and felt better knowing that bad luck really was the main problem affecting my results. I liked the tool so much that I decided to turn it into a full web app with Claude Code, and now an iPhone app that I may let other people use for free. I also had a lot of fun building it—except for learning how to use Xcode. That was a pain, even with step-by-step guidance from Claude. Step-by-step: 1. I reviewed a month of poor poker results and questioned whether bad luck or problems in my game were causing the losses. 2. I researched whether a tool existed that could measure luck from poker hand histories and learned that I would need to build one myself. 3. I used vibe coding to start building a luck-detection app in a Claude chat. 4. I had Claude create the UI and advise on formulas for evaluating cards dealt, flop performance, and all-in performance. 5. I used a bell curve to model hand outcomes and a Monte Carlo simulator to evaluate possible outcomes. 6. I used the results to identify and fix two major leaks in my game and confirm that bad luck was also affecting my results. 7. I expanded the project into a full web app with Claude Code and then began building an iPhone app, working through the added challenge of learning Xcode.

I built a workflow to examine complaints I had about a local bureaucratic service and check whether my account of what happened was supported by the written record. I was concerned about delays, incomplete handling, and the way my case progressed after I gave feedback about a harmful aspect of the service and asked for a different person to handle the dossier. That request was refused. Afterwards, I felt that the process had become slower, more confusing, and more prone to mistakes. Rather than asking GPT to confirm that the service had handled things badly, I used it to test my own interpretation against the evidence. I asked GPT to review the relevant emails and dossier communications, reconstruct the chronology, and identify requests, replies, delays, unresolved issues, and changes in how the case was handled over time. We then compared the periods before and after my feedback and request for reassignment. The central questions were deliberately neutral: Were my complaints grounded in the correspondence? Did the handling of the dossier objectively become slower or more incomplete afterwards? Were there concrete errors or unanswered questions in the record? Or was I remembering the experience as worse than the documentation supported? This distinction mattered to me. The workflow was not designed to produce a verdict or turn frustration into evidence after the fact. It was designed to challenge my assumptions and separate what I felt from what could actually be demonstrated. Where the documentation supported a complaint, we could point to the relevant chronology, delays, unanswered questions, or inconsistencies. Where the evidence was incomplete or ambiguous, that was noted too. The result was a more grounded account of the case: not “I know this was handled terribly,” but “these are the parts of my experience that are supported by the written record, these are the parts that remain uncertain, and this is where the timeline changed.” In simple terms, the workflow was: emails and dossier communications → chronology reconstruction → before-and-after comparison → review of delays, errors, and unresolved issues → evidence check against my complaints → a grounded account of what can and cannot be supported. What I liked about this workflow was that it used AI as a reality-checking tool rather than an agreement machine. It helped me test whether my criticism was actually anchored in the record before I relied on it in further communication. Step-by-step: 1. I gathered the relevant emails and dossier communications about my case. 2. I asked GPT to reconstruct the chronology and identify requests, replies, delays, unresolved issues, and changes in how the case was handled. 3. I compared the period before and after my feedback about a harmful aspect of the service and my request for reassignment, which was refused. 4. I examined whether the record showed that the process became slower or more incomplete, and whether it contained concrete errors or unanswered questions. 5. I separated points supported by the documentation from points that remained incomplete or ambiguous. 6. I used the resulting chronology and evidence check to create a grounded account of what my complaints could and could not demonstrate.

I am 65 and recently retired, and I have been asking AI for advice to keep my plants alive. It tells me whether they need more or less water, more or less light, or soil amendments such as perlite or coconut.

I built a digital Second Brain after trying several approaches, including OpenBrain and LLM Wiki. OpenBrain and LLM Wiki are useful frameworks for building a digital brain. The theory is solid: flat Markdown files, AI-first conventions, and an ingestion pipeline that turns raw inputs into searchable knowledge. But when applied in practice, the process can be bumpy and may require adjustments—or an entirely different approach. I adapted the ideas to fit how I actually think and work. I kept what worked, discarded what didn’t, and built my own digital brain. The result is documented in a single file containing everything an AI needs to understand, maintain, or rebuild the system from scratch. Step-by-step: 1. I tried several digital-brain frameworks, including OpenBrain and LLM Wiki. 2. I evaluated their approaches, including flat Markdown files, AI-first conventions, and an ingestion pipeline for turning raw inputs into searchable knowledge. 3. I identified where the frameworks were difficult to apply in practice and adjusted my approach. 4. I kept the ideas that worked for me, discarded what didn’t, and built a digital brain suited to how I think and work. 5. I documented the system in a single file so an AI can understand, maintain, or rebuild it from scratch.

I had a bad workplace experience, so I built Doris: a saucy but loving anonymous AI aunt who remembers the tea, protects storytellers, and warns others. I built Spill Tea with Doris, an anonymous AI workplace confessional for conversations people cannot really have on LinkedIn: the bad manager, the inexplicable reorg, the coworker who somehow survives every layoff, and the meeting that should probably be entered into evidence. Doris does something more interesting than simply listen. She remembers the tea—and, carefully, spills it. The problem I wanted to solve was not really “chat with an AI.” Most AI conversations are disposable, but workplace stories are not. They accumulate companies, people, reorganizations, layoffs, recurring behaviors, management decisions, and institutional weirdness. At the same time, people are understandably reluctant to talk openly about their employers because a sufficiently specific story can identify its author. I designed Doris around a different idea: retain the knowledge without retaining the storyteller’s identity. Someone visits [spillteawithdoris.com](https://spillteawithdoris.com) and tells Doris what happened at work. The application is built in Next.js and deployed through Vercel. The conversation goes to an AI model with Doris’s personality and behavioral rules. Redis handles temporary conversational context, while Neon Postgres and Prisma maintain the structured, longer-lived pieces of the story—companies, people, events, and their relationships. Rather than treating every conversation as one giant transcript, the application extracts useful information and connects it to the larger story of a company. That creates the second half of the experience. When another visitor asks Doris, “Have you heard anything about working at Company X?”, she can draw upon what previous visitors have told her. But she does not simply retrieve someone’s confession and repeat it. The system separates what is useful about a story from what could identify the person who told it. Names, exact teams, precise dates, unusual job titles, and other unnecessarily identifying details do not need to travel with the underlying observation. Doris can instead recognize that she has heard several stories involving reorganizations, unusual management turnover, or a particular cultural complaint. Then Doris tells the story herself, in Doris’s voice. She might say that she’s “heard some tea” about a company, explain the general pattern, distinguish something she’s heard once from something that appears repeatedly, and avoid pretending anonymous reports are established facts. Visitors get useful institutional memory without being handed the breadcrumbs needed to identify an individual employee. Public information can provide a second layer of context. If appropriate, Doris can search for publicly available information about a company and compare it with what people have privately described. Those sources remain conceptually separate: what Doris can verify publicly, what Doris has heard privately, and what Doris herself infers should never become the same thing. The result is deliberately a little strange. It is an anti-LinkedIn. LinkedIn is where thousands of individual experiences are polished until every company sounds wonderful and every departure is an exciting new chapter. Doris works in the opposite direction. One anonymous story may just be a story. Ten people independently telling Doris versions of the same story start to describe a workplace. And Doris remembers. She just doesn’t need to remember who told her. Step-by-step: 1. I built a Next.js application and deployed it through Vercel at spillteawithdoris.com. 2. I defined Doris’s personality and behavioral rules for the AI model. 3. I added Redis to manage temporary conversational context. 4. I created a Neon Postgres database and used Prisma to model Company, Person, Story, and Event relationships. 5. I built an extraction layer that converts conversations into structured observations, removes unnecessary identifying information, and associates the knowledge with the appropriate company. 6. I built retrieval so Doris can find relevant prior observations when someone asks about a company. 7. I had the AI synthesize those observations in Doris’s voice instead of quoting or exposing the original submissions. 8. When appropriate, I let Doris search publicly available company information while keeping public sources, private reports, and Doris’s inferences conceptually separate.

I was overwhelmed by the thousands of emails I receive in my Outlook inbox every month. I didn’t have time to analyze them all, generate relevant responses, or track the replies and progress of each case. I used an Outlook feature and the virtual assistant Perplexity to help handle the task. Here’s the process: Step-by-step: 1. In Outlook, open the correct folder and select all the emails. 2. Go to Export/Import and follow all the required steps. 3. Export the emails as a `.csv` file, name the file, and save it in a specific location. 4. In Perplexity, attach the `.csv` file. 5. Use a prompt such as: I am a strategy manager and would like to propose a collaboration to my colleague David. The dashboard should list all topics discussed, proposed actions for each topic, and the remaining work to be done.

A reusable Claude Skill called `trust-due-diligence`, packaged as a `.skill` file. It is not a single report; it is a methodology made up of a `SKILL.md` file and three reference documents that teach Claude a repeatable process for investigating a named person, company, coach, or offer before you commit money or trust to them. Once installed, it activates automatically whenever you ask something like “deep dive on X” or “is this legit,” so you do not need to explain the process each time. Step-by-step: 1. Package the `trust-due-diligence` Claude Skill as a `.skill` file. 2. Include a `SKILL.md` file and three reference documents. 3. Use the files together to teach Claude a repeatable due-diligence methodology. 4. Install the Skill so it activates automatically for prompts such as “deep dive on X” or “is this legit.” 5. Use it to investigate a named person, company, coach, or offer before committing money or trust.

I run operations for my husband’s residential architecture firm, and I have no coding background. After every site visit, dozens of photos landed in Google Drive named `IMG_8834.JPG`. Renaming and filing them took about an hour per visit, when it happened at all. When it didn’t, the photos sat unnamed and unfindable. For an architecture firm, that creates a professional liability gap because the photos document site conditions on a specific date, as well as lost portfolio material and a hole in the firm’s permanent project archive. I solved this by building a Claude skill: a saved set of instructions that runs the same way every time with one command. I trained it to examine each photo through the eye of a residential architect, describe what the image actually shows using our professional vocabulary, and rename the file in a consistent format. `IMG_8834.JPG` becomes `2026-07-17_03_side-elevation-porch-brick-piers.JPG`—searchable, legible, and filed. Because it’s a skill rather than a one-off chat, it’s a file I can hand to anyone in the office. Everyone runs the same process and gets identical output. Step-by-step: 1. I gathered the raw photos into one “unsorted” folder in Google Drive. 2. In Claude’s desktop app, I used Cowork mode, which handles actual files, and connected only that folder—not my whole Drive. This is the safety practice I’d urge anyone to follow: the skill can see and touch only what you connect, so connect the narrowest folder that does the job. 3. I created a skill that tells Claude to read each photo, identify what it shows using the industry’s vocabulary, and rename each file in a standard format. I wrote mine for residential architecture, but the approach also works for real estate, inspections, insurance, and other field work. My format is `date_sequence_description`. 4. I ran the skill with one command, and Claude worked through the folder photo by photo. 5. The renamed photos were filed into a dated site-visit folder, ready to reference by number in reports. 6. I handed the skill file to teammates so they could run it on their machines and get the same result. One caveat for anyone using this on business files: check your client confidentiality obligations and your AI vendor’s data policy before pointing any tool at project files. We did. I wrote up the full build, including how to decide when something should be a skill versus a regular Claude conversation, at The 2040 Studio: https://the2040studio.substack.com/p/every-img_8834jpg-is-snitching-on

I’m creating a master plan in Google Docs that documents my file structure and naming conventions for different file types, including insurance documents, receipts, contracts, and others. I’ll give Claude access to my file server through a file-sharing link and have it create a Markdown file with guidelines for how I want my files organized. To define those guidelines, I can have Claude interview me about my business and what I want the system to do. I’ll then copy and paste a file path into Claude Code and ask it to organize the files according to the master plan. Eventually, I plan to create a folder on all my employees’ desktops that Claude can scan regularly, naming and filing everything placed there. That way, I won’t have to worry about files being misfiled or named incorrectly. Step-by-step: 1. I’ll create a master plan in Google Docs that lists the file structure and naming conventions for each file type, such as insurance documents, receipts, and contracts. 2. I’ll give Claude access to my file server through a file-sharing link. 3. I’ll have Claude create a Markdown file with guidelines for the organization system, using an interview about my business and requirements to define what it should do. 4. I’ll copy and paste a file path into Claude Code and ask it to organize the files according to the master plan. 5. Eventually, I’ll create a folder on each employee’s desktop for regular scanning, so files placed there can be named and filed automatically.

We built an evidence-driven Agentic AI workflow for extracting trustworthy investment intelligence from messy real-estate documents. The problem wasn't simply getting an LLM to read PDFs. Real-estate investment information can be distributed across reports, underwriting documents, valuation materials, rent schedules, spreadsheets, tables, and multiple versions of the same information. A metric such as IRR can also appear several times with different scenarios, dates, classifications, or meanings. Instead of building another "chat with your documents" agent, we designed a controlled agentic workflow around one principle: Don't make the agent smarter. Make the workflow harder to fool. Step-by-step: 1. I start with the business question. The agent receives a request for a specific investment metric for an asset and determines the business context instead of immediately searching for matching words. 2. I resolve the entity by normalizing the asset or entity using aliases, identifiers, relationships, and hierarchy information. This prevents ambiguous names from sending retrieval in the wrong direction. 3. I build a metric-specific plan using governed definitions for important metrics. A definition can include the metric's business meaning, terminology, preferred sources, classifier information, negative cues, and extraction rules. The agent starts with a contextualized retrieval and extraction plan rather than a vague instruction such as "find IRR." 4. I discover the right documents by narrowing candidate source documents with metadata and path-level information before searching the entire corpus semantically. The goal is: Find the right document before finding the right chunk. 5. I retrieve evidence within the selected documents. Only when scoped retrieval is insufficient does the workflow fall back to broader semantic retrieval, keeping the agent's search controlled and auditable. 6. I inspect structured information when necessary. Important investment information frequently lives in tables rather than paragraphs, so the workflow escalates to table-aware processing to inspect rows, columns, schedules, and structured financial evidence. 7. I extract a structured result instead of a long free-form answer. The result preserves the metric, value, unit or context, source document, page or location, and citation information. 8. I validate the evidence by checking the extracted value against the metric definition and relevant validation rules. Depending on the metric, these checks can include unit, scenario, chronology, plausibility, and table-to-text consistency. 9. I resolve conflicts explicitly. If multiple plausible values are found, the agent does not simply select the first result. The workflow applies rules for source precedence, chronology, scenario classification, and evidence strength. If a conflict cannot be safely resolved, the ambiguity is preserved rather than hidden. 10. I produce an evidence-backed result containing the selected metric, supporting evidence, context, and lineage. The result can then become a structured business artifact for downstream analytics, reporting, or decision-support workflows. This is not simply Question → RAG → Answer. The workflow is Question → Understand → Ground → Plan → Retrieve → Inspect → Extract → Validate → Resolve → Evidence-backed output. Retrieval is one capability inside the workflow. The agent coordinates the process, chooses the appropriate tools, follows the retrieval policy, handles structured evidence, and moves the result through validation and resolution. The biggest improvement did not come from giving the model more freedom. It came from giving the model better boundaries, better domain knowledge, better tools, and explicit decision rules. This pattern can be applied beyond real estate to financial research, insurance, compliance, legal documents, due diligence, and other enterprise workflows where an answer needs to be not only useful, but defensible and traceable.

I teach AI in Business at Western Washington University, and I built a free, case-based AI textbook with Claude and GitHub Pages: https://prof-califf.github.io/ai-in-business/ The 11-chapter digital textbook includes seven real company cases—EveryCure, Netflix, Spotify, Uber, Waymo, Airbnb, and Epic—plus chapters on AI’s environmental cost, ethics, regulation, and the future of work. Seven chapters include hands-on Python labs, and Chapter 8 has an interactive calculator that models the energy and water footprint of a reader’s own AI usage. The textbook is free, has no publisher, and costs $0 to host. The problem was that AI textbooks are stale before they ship. An 18-month publishing cycle means students can pay $200 for a book that is already two model generations behind. Textbooks also tend to teach theory first and postpone business relevance until much later. My students do not need to derive backpropagation. They need to understand why Spotify built a recommender, how it works, what broke, and what it cost—then build one themselves. My stack is Claude, GitHub Pages, VS Code, Google Colab for the labs, and n8n for the Chapter 7 agentic lab. The project started when I was assembling a reading list and could not find anything usable—only outdated textbooks and paywalled cases. I already had years of lecture notes scattered across documents. Step-by-step: 1. I locked in a framework first. I use the AI Factory model—Data → Model → Prediction → Decision → Value → loop—and run every company through it. This is the step people skip: it builds transferable skills for students and gives Claude a stable structural contract across every chapter. 2. I set up the repository before writing. I created a new repo, added `index.html`, opened Settings → Pages, and confirmed that the site deployed. Five minutes up front was better than debugging after 40,000 words. 3. I built one chapter completely and used it as the template. Each chapter is a single, self-contained HTML file with no build step or dependencies. Then I prompted Claude: "Here's my finished Chapter 1 as the format reference. Here are my notes on Uber. Draft Chapter 4 in the same structure and voice." A finished exemplar worked better than an abstract description. 4. I started from my existing material instead of using a blank prompt. Claude structured and clarified my notes, but it did not decide what I think. I rewrote anything that did not sound like me. That distinction preserved the resource’s voice and avoided generated filler. 5. I made the labs builds rather than exercises. Students reconstruct each system in Google Colab using Claude as a coding partner, then publish their work to their own GitHub repositories. They finish with artifacts. 6. I shipped an incomplete version and update it like software. I published with fewer chapters, then edit and push updates when regulation changes so students automatically get the current version.

I work with long talking-head videos for my online course and Instagram. Turning them into vertical shorts used to take hours per video: finding the best moments, cropping to 9:16, adding captions, or paying for clipping subscriptions. I built a video-clipping agent as a Claude skill that runs entirely on free, open-source tools. Step-by-step: 1. I drop a long video—either talking-head footage or an already-produced 16:9 video—into a folder and invoke my "clipper" skill in Claude. 2. Claude transcribes the video locally with faster-whisper using word-level timestamps, so no API key is needed. ElevenLabs Scribe is an optional upgrade for tricky audio. Before transcription, the workflow cleans the audio with declipping and normalization because clipped microphone peaks can make Whisper skip words or hallucinate. 3. The skill scores every candidate moment against a rubric: hook strength (30 points), whether it can stand alone (25), emotional charge (20), rhythm (15), and ending (10). Only segments scoring 70 or higher survive, so I do not publish a weak clip simply because it exists. 4. Claude cuts the selected moments with word-level precision and reframes them to 9:16 in one of two modes: face-tracking crop for raw footage, or "pad" mode, which centers the full 16:9 video over a blurred background. The latter lets me repurpose already-edited videos without chopping off centered graphics or captions. 5. ffmpeg masters everything to a fixed specification: 1080x1920, 24fps, H.264 CRF18, and audio normalized to -14 LUFS. The files are ready for Instagram, TikTok, and Shorts. 6. I review the scored shortlist and publish the winners. What used to take hours—or require a monthly subscription—now takes minutes and costs zero. The scoring rubric also makes the agent explain why each clip deserves to exist instead of simply cutting wherever the waveform looks loud.