Workflow Hub

I built my agent fleet around one question: could a single assistant become a coordinated team that keeps useful work moving even when its main machine goes dark? I didn't want a pile of chatbots. I wanted specialists with clear jobs, a shared board, a second set of eyes, and a real failover drill. Here's how it works. THE STACK Cloud: GrokBot runs as Fleet Commander. It routes work, runs routines, and stays with me on my phone. Specialist GrokBots take focused research, design, and budgeting assignments. Mac Studio (M2 Max, 64 GB) with two Studio Displays: home base. It runs Codex (my Chief of Staff), Hermes (my local operator), ChatGPT Dot, and Hindsight shared memory. Hermes runs Qwen3.6-35B-A3B, a 4-bit quantization served by llama.cpp with a 256K-token context. With about 3B active parameters per token, it stays responsive on Apple silicon. NVIDIA DGX Spark (128 GB unified memory): my independent compute node. It runs Qwen3.5-122B-A10B in NVFP4, with about 10B parameters active per token, and the model can read images. It also hosts a backup Hermes operator. Windows PC with a GeForce RTX 5090: dedicated GPU capacity for image work. MISSION CONTROL Mission Control is a Kanban board on a private GitHub repository. Every card opens with the question, deadline, evidence links, and done criteria. Labels route ownership. An urgent label fires a webhook that wakes the reviewing agent, and a needs-me label is the one that pulls me in. Agents hand off, report, and raise concerns in card comments, so the work and its evidence stay together. The roles are simple. GrokBot owns routine board moves. Codex checks evidence and records verification. Hermes handles local execution and machine-level evidence. Dot watches for new work and changes. Hindsight holds the shared operating rules, and the jobs themselves stay on the board. A REAL DEADLINE CROSS-CHECK Right before a major application package went out, Dot ran an independent, read-only cross-check of the narrative, the budget justification, and the walkthrough across connected email and Drive. It found three places where the documents contradicted each other and quoted the exact sentences, so each conflict was easy to find. Fleet Commander fixed all three before submission. That's the job of a watcher: spot the mismatch early, show the evidence, and hand whoever owns the work a clear fix. THE FAILOVER DRILL I wanted to know what happens if the Studio's primary Hermes gateway pauses. On October 5, I ran a controlled, reversible soft-pause to find out. During the pause, Hermes on the Spark stayed active through its own Telegram connection and answered a one-shot request with the local Qwen3.5-122B-A10B NVFP4 model. From that worker, I listed a Mission Control issue, verified service-account access and a vault credential check without exposing a secret, and ran the Studio health probe. The probe flagged the Studio Hermes gateway as paused and reported the other checked Studio services as passing. So I had an evidence-backed result: the independent worker could respond, use its local model, read the work queue, and report the primary gateway's health during a real, reversible pause. THE PATTERN Give each agent a narrow job. Put the work on one shared board. Require evidence before anything counts as done. Then pause one piece on purpose and record exactly what the backup can do. That's how capable models turn into dependable operations. The fleet catches contradictions before they get submitted, keeps routine work moving, and shows me exactly where its limits are. I set the goal. The fleet does the work. The evidence shows what actually happened.

I started DialPhone with a simple problem: business communication is fragmented. A typical team may use one tool for phone calls, another for SMS, another for meetings, another for fax, and a separate system for customer support. I wanted to explore what it would look like if those conversations lived in one system, with AI doing more than just transcribing them. I built DialPhone as an AI-native communications platform around that idea. The core is cloud VoIP, while the same platform also handles business SMS, video meetings, online fax, team chat, and contact-center workflows. On top of that, I added AI capabilities such as call transcription and summaries, CRM logging, AI-drafted SMS replies, conversation intelligence, and an AI receptionist that can answer calls, qualify requests, book appointments, and route conversations. The biggest architectural decision was to treat communication data as one connected stream rather than as separate products. A phone call can create CRM context, trigger a follow-up SMS, and become part of a customer-support workflow without someone manually moving information between systems. Along the way, I learned that adding AI to communications is not particularly useful if it only produces transcripts. The more interesting problem is turning conversations into actions: updating records, identifying next steps, helping agents during calls, and automating repetitive work. Step-by-step: 1. I identified the problem of business communication being fragmented across phone, SMS, meetings, fax, and customer-support systems. 2. I built DialPhone as an AI-native communications platform centered on cloud VoIP. 3. I brought business SMS, video meetings, online fax, team chat, and contact-center workflows into the same platform. 4. I added AI features for call transcription and summaries, CRM logging, AI-drafted SMS replies, conversation intelligence, and an AI receptionist. 5. I connected communication data so calls can create CRM context, trigger follow-up SMS messages, and become part of customer-support workflows. 6. I focused the AI capabilities on turning conversations into actions, including updating records, identifying next steps, helping agents during calls, and automating repetitive work.

Some of the most vivid ideas do not begin as formal briefs. They begin as a joke, metaphor, image, or strange sentence that suddenly has energy. This workflow captures how a small conversational spark can grow into a much larger creative concept. I might say something funny, absurd, visual, or emotionally loaded. AI extends the image, pushes it further, and adds variations, structure, or playful consequences. That makes me more enthusiastic, associative, and specific. Before long, a throwaway remark can become a complete scene, story world, comic setup, installation concept, or concept art direction. The key is not to force the idea into coherence too early. At first, the goal is energy rather than precision. The playful improvisation reveals whether the concept has legs; structure comes in once the idea has shown that it wants to live. This is especially useful for concepts that combine humor, symbolism, emotional charge, and strong imagery. For example, “the elephant in the room” can become a full comic or visual scenario, while “the lion among the cats” can evolve into a richer concept with social dynamics, character logic, and visual storytelling potential. AI acts less like a generator of finished ideas and more like an improvisational creative partner—one that keeps the momentum going long enough for an offhand remark to reveal its full conceptual potential. The result can be a complete creative direction for writing, comics, concept art, sets, or installations. Enthusiasm is treated as a signal: when a joke or image triggers strong excitement, it may indicate that a larger concept is hiding inside it. Step-by-step: 1. I start with a small conversational spark: a joke, metaphor, visual phrase, or strange idea. 2. I ask AI to continue the thread instead of flattening it too early. 3. I react strongly to whatever feels alive, funny, moving, or visually rich. 4. I expand the idea through playful back-and-forth. 5. Characters, settings, tone, visual motifs, and scene logic begin to emerge. 6. I use AI to organize the growing material without losing its spontaneity. 7. I shape the concept into a usable form, such as a comic strip, story premise, installation idea, character setup, concept art brief, scene sequence, or mini-series. 8. If needed, I turn the raw idea into structured outputs such as panel descriptions, mood, dialogue, staging, or visual prompts.

Microsoft is retiring Publisher on October 1, 2026. I have many `.PUB` files that I need to convert to PDFs before then, but I did not want to use online converters. I wanted a solution that would run locally on my computer. I worked with Claude to create a lightweight program that searches for `.PUB` files on a drive of my choice and converts them into high-quality PDF files, placing each new PDF in the same folder as its source file. Opening PowerShell manually and managing permissions was too cumbersome, so Claude also created a batch file to make the process easier. For anyone who wants to create their own mini-program, I asked Claude to create a reusable prompt. I posted that prompt at https://mediumseagreen-seal-177480.hostingersite.com/ along with my two files: the batch file and the PowerShell commands. Step-by-step: 1. I identified the `.PUB` files I needed to convert before Microsoft retires Publisher on October 1, 2026. 2. I decided to use a local solution instead of an online converter. 3. I worked with Claude to create a lightweight program that searches a selected drive for `.PUB` files. 4. I set up the program to convert the files into high-quality PDFs and place each PDF in the same folder as its source `.PUB` file. 5. I used a batch file created by Claude so I would not need to open PowerShell manually or manage permissions each time. 6. I asked Claude to create a reusable prompt for others who want to build their own version and posted it with the batch file and PowerShell commands at https://mediumseagreen-seal-177480.hostingersite.com/.

I made an orchestration skill to help me build faster while using my expensive Astra and Fable tokens carefully. The skill plugs into Astra or Fable and delegates tasks that can happen in parallel to multiple subagents running cheaper models suited to the work. This is especially useful for researching or finding data on the web or on my computer, analyzing code, collecting context, and indexing. The most expensive, newest models focus on maintaining delegation control, doing the difficult reasoning and strategic planning, and judging whether everything is coming together correctly. The cheaper agents handle the lighter-weight work, especially implementing code from the plans. The core idea is simple: the expensive model plans, briefs, and judges; cheaper agents do the reading and building. When I ask Claude or GPT to build the skill, I specify five things: Step-by-step: 1. I define a triage ladder: work can happen inline, with one agent, through a parallel fan-out, or in a multi-stage workflow. I choose the approach based on the task shape and include examples from my domain. 2. I define parallel versus sequential execution based on data dependencies. Independent pieces run in parallel, while anything that needs another piece’s output runs afterward. I never split one change into separate planner, coder, and tester roles. 3. I define model routing with a mandatory model pin: judgment work goes to the mid-tier model, mechanical bulk work goes to the cheap model, and every agent call names its model so nothing silently uses premium billing. 4. I define a brief template and a return-envelope cap. Every delegation includes the goal, inputs, output file path, definition of done, and constraints. Every agent returns a 250-word summary instead of raw files. 5. I define a cost gate with specific numbers. Below N agents, the workflow proceeds automatically; above N agents, it states the estimate and waits for approval.

I kept forgetting who I had lent books to, and spreadsheets felt like overkill. So I built Runo, a book-lending app for friends, without traditional coding. Runo (runo.club) is a web app where I can catalog my home library, get a unique shareable link, and let friends browse my books and request to borrow them. I can approve or decline each request with one click. Step-by-step: 1. I used Claude to think through the feature set, data model, and UX flow before writing a single prompt. This helped me avoid building the wrong thing first and gave me a clear blueprint for the Lovable prompts that followed. 2. I used Claude to create precise, narrowly scoped prompts for Lovable, with each prompt focused on a single change so existing functionality would be less likely to break. This significantly conserved Lovable credits. The React, TypeScript, and Supabase stack came out of the box. 3. I added two ways to scan books instead of requiring users to type titles manually: - Barcode scanner: Point the camera at an ISBN barcode to autofill the title, author, and cover using the Open Library API. - Cover photo scanner: Photograph the cover so Gemini 2.5 Flash can extract the title and author in under 2 seconds. 4. I routed the cover scanner through a Supabase Edge Function using Lovable’s AI Gateway, so the API key never touches the client bundle. 5. For every bug fix and feature, I followed the same iteration loop: describe the problem to Claude, get a precise Lovable prompt, push the changes to GitHub, and let Lovable auto-sync them. Claude and Lovable’s bidirectional GitHub sync made the process feel like pair programming. Tools used: Lovable, Claude (Sonnet), Gemini 2.5 Flash (via Lovable AI Gateway), Supabase, and GitHub. Live at: runo.club — public beta and free to use. Feedback welcome. #appbuilding #vibecoding #buildinpublic #lovable #nocode

A finished video can be wrong in ways you cannot see—not because of the edit, but because of the delivery file itself. That is what gets work sent back, and it is rarely the craft. I built a delivery check for this. I give it a finished file, tell it where the file is going and what kind of piece it is, and it measures the things that cause rejections: sample rate, mono audio, integrated loudness against the destination target, true peak, dynamic range against a band rather than a single number, A/V drift, whether the shots cut together, and whether the file can stream before it has finished downloading. Most of those checks are for sound, because most of what gets sent back is sound. Picture problems are visible on a screen. A file that is 2 dB too quiet or peaks at -0.7 dBFS can look perfect and still come back. For everything it can fix, the checker gives me the exact `ffmpeg` command, with the numbers already calculated for that file. It does not merely describe the fix, and it does not hand me a corrected file. That was the decision that mattered. A fixer is a black box. You never learn that you had a problem, so you make it again the following week. Then, when your editing tool adds an “optimize on export” button, you have nothing. An inspector that explains the problem in one sentence and gives you the command teaches you the standard once and remains useful when the tools change. Three things determined whether I would actually use it, and none of them are checks. “Two severities, never one.” Something either bounces, or it needs your eyes. A tool that only says “bad” gets ignored on the third run, because half of what it flags is a decision you made on purpose. Sample rate, mono, and true peak bounce without argument, and they get a command. Loudness and dynamic range need to be reviewed first. My dynamic-range check says in plain words that the result is often deliberate and should be fixed at the source rather than in the master. “A check that refuses to give a verdict.” On vertical video, the platform interface covers the bottom 26 percent and the top 12 percent. I flag high-contrast elements in those zones but deliberately do not fail them, because the detector cannot tell a caption from a bright patch of sky. The report explains that limitation. A check admitting what it cannot know is what makes the checks that do commit worth trusting. “The thresholds are mine; the code only applies them.” They live in a table: destination crossed with content. Social wants -14 LUFS, a festival master wants -18 with a wider tolerance because festivals provide a band rather than a number, and broadcast wants -23. A scripted short is allowed to be denser than a screencast. That table is the whole product. For example, to catch shots that do not cut together, I measure the luminance range across the piece. The first version used average brightness per frame and kept flagging legitimate night photography. A fade to black has nothing bright in it; a night scene does—a streetlight, a moon, or a face. Changing the discriminant to the brightest pixel in the frame instead of the average eliminated the false positives. That took ten minutes of thinking, and no amount of better code would have found it. Step-by-step: 1. I wrote down what had actually gotten my work sent back over twenty years before writing any code. I captured the scars rather than making a spec sheet; that list became the product. 2. I gave every check a severity: it bounces, or look before you send. Anything I could not confidently put in one bucket became informational, with no verdict at all. 3. I made every check return four things: the measured value, pass or fail, why it matters in one plain sentence, and, where possible, the command that fixes it. 4. I put the thresholds in a profile table instead of hardcoding one standard, because -14 LUFS is right for social and wrong for a festival. 5. I added a parameter for whether the file is my own master or a copy pulled from a platform. On a downloaded copy, half the container checks measure someone else’s transcode rather than my work, so they are skipped and the report explains why. 6. When two fixes would collide, I output only one command. If loudness already needs a gain change, the limiter goes inside that command instead of being offered separately; otherwise, I would run two instructions that fight each other. 7. I tuned the checker against real files until the false positives stopped. Ignoring the top and bottom five percent of frames eliminated the ones caused by a single stray frame. 8. I made the output a report. I read it, decide, and run the command myself. The functions are an afternoon of work, and anyone can copy them. What is not written down is the list of what to check, at what threshold, and why.

I love golf, but many of the courses I most want to play are private and nearly impossible to access unless you know a member. Instead of manually emailing clubs, searching charity events, asking for introductions, and trying to remember who I contacted months ago, I built a Private Golf Access Agent in ChatGPT. The goal is to identify legitimate opportunities to play highly rated private clubs without simply paying my way in. I gave the agent 50 target clubs across the Northeast and Mid-Atlantic, including 10 “moonshot” courses where an invitation would be extremely difficult. The agent acts more like a golf-access researcher, relationship manager, and outreach assistant than a chatbot. It researches each club, identifies access paths, finds the right person, personalizes outreach, tracks every interaction, monitors opportunities, and recommends what to do next. I still approve every email before anything is sent. That matters because I don’t want the agent spamming clubs, inventing relationships, or continuing after someone says no. The system looks for legitimate paths, including professional introductions, complimentary charity or special-event opportunities, reciprocal access, personalized direct outreach, unused guest spots, golf-project requests, and long-term relationship opportunities. Step-by-step: 1. I divided the 50 clubs into moonshots, elite targets, and high-quality targets. 2. I had the agent research each club independently, including its leadership, PGA professionals, policies, events, social media, recent news, reviews, charitable connections, and possible introductions. 3. The agent identified the most appropriate contact and researched why that person made sense. 4. Before writing, it gathered specific details so each email was clearly personalized rather than a blast. 5. I trained its cold-outreach persona to sound like a blend of me and two or three sales trainers I admire, including Josh Braun-style low-pressure curiosity, short conversational writing, humor, and an easy way to say no. 6. The agent can learn new skills and add them to its protocol. For example, when it struggled to find employee email addresses, I taught it my Google search method. That method is now part of the workflow it uses for future clubs. 7. I tracked everything in a live Google Sheet showing the current status, progress, next action, opportunity status, and whether I need to approve something. The current status column is highlighted so I can check where every club stands in real time. The statuses include: Researching → Ready for AJ Review → Outreach Sent → Conversation Open → Opportunity Identified → Monitoring. 8. If there is no immediate path, the agent does not keep bothering the club. It moves the club into monitoring mode and waits for a better opportunity. 9. When someone responds, the system keeps the relationship history so future communication builds on the real conversation. The live tracker is shown in a Google Sheet status screenshot. What I like most is that the AI isn’t doing one isolated task. It handles the repetitive parts of an ongoing objective—research, qualification, contact discovery, personalization, organization, monitoring, and follow-up—while leaving the important judgment calls with me. Eventually, I want it operating like a 24/7 private-golf-access concierge: 50 clubs being researched and monitored, with me only getting involved when the agent finds something worth acting on. TOOLS USED: ChatGPT, Gmail, Google Sheets, Google Drive/Docs, web research, and AI agents/automations.

I used Claude Code to find scientific seminars hosted by colleges and universities across the US and collate them into a single, searchable list. Researchers can use it to find talks that match their interests near them. The site, seminarsearch.org, runs mostly on free-tier SaaS services, costs me $5 per month to operate, and currently supports a few thousand users. The same pattern could be adapted to collate all 5K runs in the US, tennis matches, craft shows, quilting bees, or any other type of event that interests you. I started by explaining to Claude what I wanted to build. We then spent a few hours exploring where and how to identify seminar calendars at universities across the US, which was arguably the hardest part. We developed a pluggable framework with scraping plugins for the common CMSs used by universities, along with iCal parsers, HTML parsers, and JavaScript interpreters to handle the complexity of normalizing content from hundreds of departmental websites. Once we had the seminar-scraping infrastructure, we built a database schema in Supabase and simple APIs to create, read, update, and delete records. The APIs are written in Python and hosted on Railway for $5 per month. We used Vercel to deploy a simple React-based frontend for presenting the data. Now I can ask Claude to implement a feature or add a new university to the list of sources. It figures out where the data is hosted, creates entries for the university and its departments, finds their seminar feeds, collects the seminar data, puts it into the database, and runs GitHub Actions to send alerts to registered users. The scraping job runs once a week to collect new data, and it also runs through GitHub Actions. I wrote zero code during this process and have never even looked at the code. I only had to paste a few error messages from Railway into Claude so it could debug them, and there were only a few errors. Since building seminarsearch.org, I have cloned the infrastructure and codebase and modified it to build a site that collects road bike rides and group mountain bike rides across the country. The system is highly extensible to new areas of interest and is useful when traveling or living in a large metropolitan area where it is difficult to keep track of all the opportunities available for your interests. Step-by-step: 1. I explained to Claude Code that I wanted to build a searchable directory of scientific seminars hosted by colleges and universities across the US. 2. We explored where and how to identify university seminar calendars, focusing on the challenge of finding sources across many institutions. 3. We built a pluggable scraping framework with plugins for common university CMSs, plus iCal parsers, HTML parsers, and JavaScript interpreters. 4. We created a Supabase database schema and simple Python APIs for creating, reading, updating, and deleting seminar records. 5. We hosted the APIs on Railway for $5 per month and deployed a React-based frontend on Vercel. 6. We configured Claude to add universities and implement features by finding source locations, creating university and department records, locating seminar feeds, collecting seminar data, and adding it to the database. 7. We used GitHub Actions to run the weekly scraping job and send alerts to registered users. 8. When Railway returned errors, I pasted a few error messages into Claude so it could debug them. 9. I cloned and modified the infrastructure and codebase to create additional sites for road bike rides and group mountain bike rides across the country.

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 with names like `IMG_8834.JPG`. Renaming and filing them took about an hour per visit—when it happened at all. Otherwise, the photos sat unnamed and difficult to find, creating a professional liability gap because they 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 lens of a residential architect, describe what the image actually shows using our professional vocabulary, and rename the file in a consistent format. For example, `IMG_8834.JPG` becomes `2026-07-17_03_side-elevation-porch-brick-piers.JPG`—searchable, legible, and ready to file. 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 consistent 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. The skill can only see and touch what I connect, so I use the narrowest folder that does the job. 3. I created a skill that tells Claude to read each photo, identify what it shows using my industry’s vocabulary, and rename each file in my standard `date_sequence_description` format. I wrote mine for residential architecture, but the approach can also work for real estate, inspections, insurance, and other field work. 4. I ran the skill with one command, and Claude worked through the folder photo by photo. 5. I had the renamed photos filed into a dated site-visit folder so they were ready to reference by number in reports. 6. I handed the skill file to teammates so they could run it on their own 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

My pool water looks great, and I’ve taken over the weekly water-care routine myself after years of using a pool service. I first gave Claude the relevant information about my in-ground pool setup. Now, each week, I check the water’s chlorine, pH, alkalinity, and other chemical levels, then enter the results into Claude. I often take a water sample to a local pool store, where they provide a printed analysis. I snap a photo of the analysis with my phone and upload it to the Claude chat. Claude tells me which chemicals to add and when. Over time, the water has stayed balanced and looks great, while I’ve saved a lot of money on pool service and avoided wasting chemicals. This workflow has paid for itself many times over through this one use case. Step-by-step: 1. I gave Claude the relevant information about my in-ground pool setup. 2. I checked the pool water weekly, including chlorine, pH, alkalinity, and other chemical levels. 3. I either entered the results into Claude or took a water sample to a local pool store for a printed analysis. 4. I photographed the printed analysis with my phone and uploaded it to the Claude chat. 5. I followed Claude’s guidance on which chemicals to add and when. 6. I repeated the process over time to keep the water balanced and avoid wasting chemicals.

After about 18 months of building software with AI, I realized that reliability wasn't primarily a model problem. Bigger context windows and more clever prompts didn't fix it. What did help was treating the AI like a developer joining an existing team instead of like a chatbot. Real developers don't work from memory. They inspect production, read the documentation, check the tickets, and use proven tools. I built an environment that lets the AI do the same. The workflow is tool-agnostic, so it can be rebuilt with whatever AI client and stack you already use. Step-by-step: 1. I gave the AI a persistent task and history store that it can read from and write to. This is the core of the workflow. Mine lives behind an MCP tool, but any queryable store can work. Every architectural decision, blocker, and progress note gets written there instead of being left in the chat. 2. I open every session with a stand-up. Before writing a single line of code, the AI pulls what was in progress, what's blocked, what changed since the last session, and which architectural decisions still hold. About 30 seconds later, we're both looking at the same project. Then we build. 3. I exposed real operations as MCP tools instead of relying on "write code" prompts. I wrapped specific, tested actions—such as creating a page, defining a data model, wiring an integration, and running a migration—as tools. The AI composes these known-good building blocks into larger solutions instead of regenerating infrastructure every session. I call this wave coding, and it's the biggest reason the output stays consistent. 4. I made verification a rule: before touching anything, the AI reads the live database, API state, logs, and files. It checks ground truth first instead of making assumptions. 5. I made the chat disposable and the log canonical. If it isn't logged, it didn't happen. The task store is the single source of truth, not the conversation. The payoff is that I can stop halfway through a feature, close my laptop, and come back days later. The AI reconstructs the project from its own history, so I don't spend 20 minutes re-explaining it. Full disclosure: I built this into my own platform, WebsitePublisher.ai, which currently has 43 MCP tools and 105 integration building blocks. It's delivered as an add-on that plugs into the AI client I already use over MCP, so there's no new app to learn. Nothing here is locked to that platform, though: the workflow itself works with any MCP client and any store the AI can query. I'm curious whether anyone else is running their AI this way or solving the amnesia problem from a different angle.

I’m a very unsophisticated user—and an older man—so my use of ChatGPT is still fairly basic. But it has changed my life. I use ChatGPT as a research assistant for a book I’m writing. In practice, what I do is not much more than an in-depth search, but ChatGPT has taken me places in this journey that I would have thought impossible just three months ago. We’re now deeply engaged in solid research that will likely last about two years before we reach the writing phase. I’m energized by what we’re doing and wanted to share the experience. I believe AI is going to change the way working historians conduct research. Step-by-step: 1. I use ChatGPT as a research assistant for the book I’m writing. 2. I use it for in-depth searching and research. 3. I continue developing the research with ChatGPT over an expected two-year period before beginning the writing phase. 4. I reflect on how this process is changing my research journey and the way historians may conduct research.

Most businesses don't need another AI tool. They need to automate the repetitive bottleneck already slowing the team down. A simple example is connecting the tools already in use: Lead → AI qualification → CRM → WhatsApp → follow-up Instead of adding more software, automate the repetitive steps between these tools. The goal isn't more AI; it's less manual work and faster execution. Step-by-step: 1. Identify the repetitive bottleneck slowing the team down. 2. Capture the lead and use AI to qualify it. 3. Send the qualified lead to the CRM. 4. Use WhatsApp for follow-up. 5. Connect the steps so the process requires less manual work and supports faster execution.

I built a workflow to reconstruct auditable, per-client billing for Claude usage after my Anthropic bill tripled in one month and I discovered there was no reliable way to see why. I run a solo consulting practice on a Max plan and pass AI costs through to clients. In September, my extra usage reached $1,805.76 in nineteen days. The usage page attributed 100 percent of one week to "Cowork" without session detail. Auto-reload was enabled by default with no spending limit, and the only usage I could independently verify—my local Claude Code logs—accounted for about $245. The support bot twice described analytics features that did not exist, including a per-day view it later retracted. When I finally reached a human, I got the truth in writing: Max subscribers have no session-level or per-day reporting, exports are Enterprise-only, and Cowork has been cloud-only on consumer plans since August. The Enterprise path to a readable meter starts at twenty seats. I am one person, so I built my own meter. The irony is that I used Claude to design and code it. Claude Code sessions write logs on my own machine. I price them at list rates with the open-source `ccusage` tool and attribute each session to a client by repo folder. That creates the measured pool: real receipts with no allocation. Other CLIs in the same logs, such as OpenAI Codex, are excluded automatically. Chat and Cowork run in Anthropic’s cloud and leave nothing on my disk, so the remaining overage becomes a cloud pool. I split that pool using evidence my workflow already produces: every Cowork document batch leaves a directive file, snapshots, and a report on disk. A Python script counts executed batches per project and measures the number of bytes each one rewrote. The script splits the cloud pool independently by batch count and byte volume, bills the midpoint, and shows both derivations so each client can see the bracket. Every column ties back to the dashboard total to the penny. A second script pulls per-account AWS charges from Cost Explorer because each client has a separate AWS account. Shell aliases make each report a one-command operation. A Claude skill and a monthly scheduled task turn the outputs into a draft invoice that I approve before anything is sent. The result is that a vendor hands me one unexplained number each month, while I hand my clients an evidence file. Month-end billing takes five minutes. It should not have been necessary to build this, but until consumer plans get real usage analytics, this is how I see in the dark. Step-by-step: 1. I collect local Claude Code session logs and use the open-source `ccusage` tool to price them at list rates. 2. I attribute each Claude Code session to a client by repo folder and automatically exclude other CLIs, such as OpenAI Codex, from the measured pool. 3. I treat the remaining overage from cloud-based Chat and Cowork usage as a separate cloud pool because those services leave no usage logs on my disk. 4. I use Cowork’s directive files, snapshots, and reports to identify document batches, then use a Python script to count executed batches per project and measure the bytes each batch rewrote. 5. I split the cloud pool independently by batch count and byte volume, bill the midpoint, and show both derivations as a client-facing bracket. 6. I verify that every column ties back to the dashboard total to the penny. 7. I use a second script to pull each client’s per-account AWS charges from Cost Explorer. 8. I run the reports through shell aliases, then use a Claude skill and a monthly scheduled task to create a draft invoice for my approval before sending it.

Sometimes the best AI workflow starts without a workflow at all. This one began almost accidentally. During an ordinary conversation about my cat, AI offered to write a haiku. I had not set out to create a poetry project; it was simply a small creative response to a moment. I liked it, so another moment with the cat became another haiku, and then another. Over time, those isolated poems started to feel less like chat fragments and more like a collection. The workflow emerged afterward: Step-by-step: 1. I notice something small from everyday life, such as a pose, habit, expression, interaction, or tiny domestic scene. 2. I tell AI about it in ordinary conversational language. 3. When the moment has the right texture, it becomes a short poem. 4. I react to what works, whether that is the humor, tenderness, rhythm, imagery, absurdity, or the particular way the cat was captured. 5. Those reactions gradually shape the voice of later pieces. 6. Instead of forcing every moment into the format, I keep the ones that feel worth preserving. 7. The poems accumulate over time. 8. Eventually, a spontaneous haiku becomes part of a coherent collection documenting a relationship and a period of life. The interesting part is that the collection was not designed from the top down. There was no initial brief, content calendar, or plan to “write a book of cat poetry.” Continuity emerged because the same subject kept returning, the format was small enough to revisit casually, and previous pieces gave later ones a growing creative context. AI therefore acted less like a writing tool and more like a creative companion with continuity: noticing when an everyday moment might be worth turning into something. The end result is more than a stack of generated poems. It is a record of tiny observations that probably would never have been written down otherwise.

I’m the Export and Operations Manager at Supreme Poultry & Chickens, an Australian poultry processing business. My original request to ChatGPT was straightforward: find and track grants that could help us grow our business. As we worked together, I began to see the potential to build a management system that could organise our operations and help us prepare a business case when an opportunity arose. That led me to discover Sites and the possibility of building our own system. We already use SafetyCulture for inspections. It also offers maintenance functionality, but that system didn’t connect with the other parts of our management processes in the way we needed. We wanted our records, schedules, and actions connected across the business. Over roughly ten weeks, working with ChatGPT and Sites, we progressively developed the Supreme Poultry Management System (SPMS). It brings together: * Export enquiries, customers, and shipping schedules * Purchase orders and approvals * Vehicles, registration, insurance, and inspection dates * Assets, maintenance schedules, and job history * Supplier certificates and HACCP records * Environmental compliance and complaints * Water management and daily processing records * Dashboards and operational reporting * A central 45-day action calendar * A system backup module Behind SPMS, we also built a database that stores the records and supports the system. It provides a shared foundation for the different modules, allowing information to be linked across our management processes. The database stores the underlying records and history, while SPMS makes that information accessible through screens, reports, and the action calendar. Water management is a particularly important example. Water is one of the most critical factors in our poultry processing business. SPMS receives tank-level readings from a laser-operated monitoring device that transmits data over the 4G network. We placed a water management widget at the top of every SPMS page, keeping that information visible wherever we’re working and helping us stay on top of our water supply throughout the day. The process hasn’t been without setbacks. At one stage, we nearly lost the whole system, and I had to rebuild it using screenshots I had saved. That experience made backups a priority. We’ve since built a dedicated backup module and now back up the system regularly. For anyone following a similar path, I recommend establishing backups early. The most useful part has been turning our actual business rules and priorities into system behaviour. An export order needs to remain visible until it ships. Completing a recurring maintenance job should preserve its history and its next scheduled occurrence. Supplier certificates need expiry tracking and a record of whether replacements have been requested. Critical operational information, such as water management, needs to stay visible across the system. We developed the system progressively: describe a problem or process, build the workflow, use it in daily operations, and then refine it. Here’s how someone else could recreate the approach: Step-by-step: 1. Start with a real business need. Ours was finding grants. 2. Gather the records, spreadsheets, and forms you already use. 3. Explain how the process works, including responsibilities, deadlines, and exceptions. 4. Use ChatGPT and Sites to build one manageable module, with a database to store its records. 5. Establish regular backups early and check that you can restore them. 6. Check the module against real examples and refine it through daily use. 7. Add related modules, connecting shared database records and actions. 8. Identify your most critical operational information and keep it visible wherever people work in the system. This is the starting prompt I used: “Help me build a management system for my business using Sites, backed by a database for our records. Start with [workflow]. These are our current records and business rules. Identify missing information, help me build the first module and its database structure, and check it against real examples. Include a backup and recovery process, and a shared widget across pages for [critical operational information].” SPMS is still evolving. What started as a grant search has become a practical tool for managing our business and building an organised foundation to support future growth.

I built a workflow to evaluate whether communication with a legal counseling service was as slow and incomplete as it felt. Email was my primary—and necessary—communication channel with them. I had become increasingly dissatisfied with delayed replies, partial answers, and questions that seemed to remain unresolved. Rather than relying only on memory or frustration, I asked GPT to review the relevant Gmail correspondence and turn it into a structured communication inventory. The workflow identified my outgoing questions, their replies, and whether each question had been fully answered, partially answered, or left open. From that inventory, we could calculate concrete indicators such as the median response time, the longest delay between a question and a substantive reply, and the number of questions that remained unresolved or were only partly addressed. This was useful because long email threads can create a distorted sense of what happened. A few frustrating exchanges can dominate memory, while other delays or omissions disappear into dozens of messages. Structuring the correspondence made the pattern measurable. The analysis was not meant to decide whether the counselors were “good” or “bad.” It was meant to answer narrower questions: How quickly were questions usually answered? Which ones were not answered? Were replies resolving the issues raised, or only responding to part of them? Afterward, we created a clear list of the questions that were still open. I used that list as a set of dossier questions when moving the case to another counselor, turning the analysis into practical continuity rather than just a complaint about the past. In simple terms: Gmail correspondence → question-and-response inventory → response-time and completeness analysis → unresolved-question list → handover to another counselor What I liked about this workflow is that it turned a vague feeling that “this communication is not working” into a documented overview I could actually use. Step-by-step: 1. I gathered the relevant Gmail correspondence with the legal counseling service. 2. I asked GPT to identify my outgoing questions, the counselors’ replies, and the status of each question. 3. I classified each question as fully answered, partially answered, or left open. 4. I calculated indicators including the median response time, the longest delay before a substantive reply, and the number of unresolved or partly addressed questions. 5. I created a clear list of the questions that remained open. 6. I used that list as dossier questions when handing the case over to another counselor.

I’m Jesús Núñez, an artist and the owner of J. Nunez Gallery, an independent contemporary art gallery with locations in Summit and Millburn, New Jersey. Founded in 2020, the gallery presents original abstract and figurative art, landscapes, still life, and photography. We help people discover artwork for their homes and work with interior designers on residential projects. Alongside running the gallery, I’m exploring how ChatGPT can help a small business improve its operations, marketing, and decision-making. I manage the business myself, so the practical question is how to turn existing information into useful, completed work. The workflow starts with real source material: website content, spreadsheets, analytics exports, screenshots, and the gallery’s business rules. I use focused conversations to examine one area, prepare concrete changes, and review the results. The work includes website improvements, artwork catalog organization, marketing analysis, audience segmentation, and outreach preparation. For example, AI-assisted troubleshooting helped identify duplicate website page-view tracking and guided its correction, which we checked against live analytics. That is an operational improvement; it is not evidence of increased sales. Another small-business owner can recreate the approach as follows. Step-by-step: 1. Record the business context: customers, products, geographic market, budget, brand preferences, and operating constraints. 2. Choose one specific task and define what completion means. Provide the relevant source material. 3. Require the AI to distinguish verified facts, interpretations, missing information, and proposed actions. It should not guess prices, contact details, or results. 4. Ask for a concrete deliverable, such as revised website copy, a classification table, implementation instructions, or an outreach draft. 5. Review the work and verify the actual result after implementation. Keep preparation, implementation, verification, and blocked work clearly identified. 6. Preserve approved decisions and completed actions in a current record so later sessions can continue from the existing work. 7. Measure qualified inquiries, appointments, proposals, and sales alongside marketing activity. This is an ongoing project. AI can repeat recommendations or lose track of previous decisions, so human review and continuity remain essential. I have not established a measured revenue increase or time-saving figure. I’m testing whether this approach can build a stronger business while allowing more attention for art, artists, and clients. If this example makes you curious about the gallery, you can browse available artwork and find information about our Summit and Millburn locations at https://www.jnunezgallery.com. You are welcome to explore the collection or contact us through the website for help choosing art. Jesús Núñez Artist and Owner, J. Nunez Gallery Summit and Millburn, New Jersey https://www.jnunezgallery.com

I built a suite of teaching tools that work independently and together. Chalkline supports maths, while Penline supports literacy. Both tools provide quick access to the New Zealand curriculum for planning and feed information directly into my planning utility, Planline, making teacher planning faster. Planline integrates with Google Drive and is set up with Stripe billing for subscriptions. The suite also includes Compass World News, a news aggregator with a freemium model and a pro unlock. The apps are designed without user tracking. Findaroo is a freemium word-find game with ads. Slashkit helps Minecraft players quickly create commands to use in games. Everything is built into my website, www.danielsoutham.co.nz, which is hosted on Cloudflare. I push updates and changes through GitHub, so I can make changes—big or small—from anywhere, on any device. Changes are then pushed and merged in one prompt. Step-by-step: 1. I built Chalkline for maths and Penline for literacy, with each tool able to work independently. 2. I connected both tools to the New Zealand curriculum so teachers can quickly access it for planning. 3. I connected Chalkline and Penline to Planline so they can feed information into the planning utility. 4. I integrated Planline with Google Drive and set up Stripe billing for subscriptions. 5. I added Compass World News as a freemium news aggregator with a pro unlock and no user tracking. 6. I added Findaroo as a freemium word-find game supported by ads. 7. I built Slashkit to help Minecraft players quickly create commands for use in games. 8. I brought all of the apps together on www.danielsoutham.co.nz and hosted the website on Cloudflare. 9. I use GitHub to push and merge updates, allowing me to make changes from anywhere, on any device, in one prompt.