Workflow Hub

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’m building an AI travel assistant called SundayAtlas, and I wanted a systematic way to keep learning from what travelers are talking about between individual user conversations. Reddit is useful for this because people are unusually candid about trip-planning frustrations, destinations, bad experiences, and what they wish travel products did better. The problem is volume: I didn’t want to manually read hundreds of posts every week, so I built a Reddit Signal Agent that does the first pass and sends me a weekly travel-insights newsletter. Each week, the workflow collects posts from selected travel subreddits and passes them through an LLM-based classification and analysis pipeline. The report is organized around: - New or intensifying signals - Steady baseline themes - Fading signals - Rising destinations - Competitor mentions - Anomalies unusual enough to warrant attention This week, for example, the agent analyzed 77 posts. It surfaced a spike in discussion around short-term rental restrictions in Tokyo, growing payment friction for travelers in Japan, increased interest in quieter alternatives to heavily touristed Asian destinations, and recurring trust issues involving travel platforms. I use the newsletter as one input into product discovery for SundayAtlas. It gives me a weekly pulse on problems and behaviors that may be worth investigating further, rather than relying purely on my own assumptions about what travelers need. Step-by-step: 1. I collect recent posts from a defined set of travel subreddits. 2. I clean and structure the Reddit data for analysis. 3. I run the posts through an LLM using a defined signal taxonomy. 4. I aggregate the classifications across the weekly sample to identify patterns, changes, and anomalies. 5. I generate the report in a consistent newsletter format. 6. I run the full pipeline automatically with GitHub Actions so a new report is produced each week. I built the agent in Node.js and used Claude Code extensively during development. Evaluation ended up being the most important part. Early outputs looked convincing, but I had no objective way to know whether the classifications were actually good. I manually labeled 91 Reddit posts and created a blind golden dataset, then built a deterministic scorer to compare the agent’s classifications with my labels. The first held-out evaluation scored only 0.23, which gave me something concrete to improve against. I iterated on the classification approach and inspected individual failures. Along the way, I found three separate defects in the data collection pipeline. The held-out score eventually improved to 0.61, while the score across the full dataset increased from 0.33 to 0.67. The finished loop is: Reddit conversations → signal classification → trend analysis → weekly insights newsletter → product discovery for SundayAtlas The golden dataset remains underneath the workflow as a regression test, so when I change the agent, I can measure whether I’ve actually improved it.

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.

AI can make a child’s drawing look more polished, but it can also erase exactly what made it interesting. A yellow tree, a rabbit larger than a person, a horse with impossible legs, or a tiny floating object may look like mistakes to a model—but they may be the whole point. I use the child’s drawing as art direction: preserve its visual logic, then build outward. The child supplies the invention; AI helps develop the surroundings. Step-by-step: 1. I read the drawing before transforming it by making a neutral description of what is visible: placement, relative sizes, colours, expressions, unusual shapes, and small details. For example: “A large yellow tree stands on the left. Two tiny figures sit near its trunk. A blue shape fills the lower right.” 2. I avoid deciding what an unclear shape represents. “An oval object with three legs” is more faithful than “a rocket” unless the child confirms it. If possible, I ask the child what is happening, since a strange proportion or colour may have a specific story behind it. 3. I separate essentials from flexible details in two short lists. Essentials might include the yellow tree, oversized rabbit, horse’s pose, characters’ arrangement, and red object in the corner. Flexible details might include lighting, textures, materials, environmental detail, and depth. 4. I make clear that the original is the structural source, not just a mood reference. This gives the model room to work while defining the boundaries. 5. I choose a target style, such as a storybook illustration, watercolour, digital painting, comic panel, or 3D scene. 6. I explicitly ask the model to preserve unusual proportions, unexpected colours, expressions, and relationships between characters. I identify details that must remain, even if they appear anatomically impossible or visually awkward. I avoid vague instructions such as “make it better,” because they leave the model to decide what counts as improvement. 7. I use a starting prompt such as: “Use this drawing as the structural blueprint for a storybook illustration. Preserve the composition, relative sizes, poses, expressions and original colour choices. Keep the yellow tree and the rabbit larger than the person. Do not normalize unusual anatomy or remove unexplained objects. Add texture, lighting and environmental depth around the existing scene.” 8. I treat comparison as part of the workflow because specific instructions do not guarantee a faithful result. I expand the world around the invention: a blank background can become a forest, a blue patch can become a pond if that interpretation fits, and two skiing figures can gain a mountain landscape. 9. I keep the original spatial relationships: who stands beside whom, what dominates the scene, which way characters face, and where empty space matters. I give colour the same care, so a yellow tree does not quietly become green because the model expects green trees. 10. I place the source and result side by side and check whether a character disappeared, the rabbit shrank, the palette changed, or the model invented a focal point, “fixed” an unusual shape, or altered the story. I also watch for generic cuteness—big eyes, pastel colours, and perfect symmetry—which can make very different drawings converge into the same image. I ask whether the result still feels like an expansion of this exact drawing. 11. If most of the result works, I request a targeted edit, such as: “Keep this version, but restore the original hair shape.” “Make the rabbit larger again.” “Return the tree to yellow.” 12. I check the whole image after each local edit because changes can affect other areas. I keep useful versions instead of repeatedly starting over. 13. I treat handwritten text separately. I do not guess unclear wording, correct spelling, or invent labels. If the tool cannot reproduce the text faithfully, I retain the original lettering through a separate editing step. 14. I save the original photo or scan alongside the result, instructions, and useful intermediate versions. I also keep a brief note about protected details to make future transformations easier. 15. Once I have a faithful version, I explore alternatives such as a space setting, surreal painting, or cinematic scene, keeping them as branches from the original. Across several drawings, I preserve recurring colours, shapes, and characters without forcing every image into one rigid style. The child has already decided who exists, what matters, how large things are, and what belongs together. Those decisions are creative direction. A drawing does not need to become less itself to become more finished. The impossible colour may be the atmosphere, and the awkward shape may be the character. The question I return to is: “How can I help this drawing become more fully what it already is?”

I built an Awish workflow that handles a support ticket before anyone on the team opens it. I realized support tickets were not just taking time to answer. Someone still had to understand the problem, decide how urgent it was, search the documentation, route it to the right person, and prepare a response. I wanted that first layer of support work to happen automatically. I opened Awish and wrote: “Whenever a new support ticket comes in, understand the issue, determine its urgency, check our documentation, prepare a response, create a Jira issue if it looks like a product bug, and escalate anything important to the team before taking customer-facing action.” Awish understood the request, planned the workflow, and showed me which applications it needed. Step-by-step: 1. I described the complete support process I wanted in the Awish chat. 2. Awish planned the workflow and selected Zendesk, Notion, Jira, and Slack for the required steps. 3. I connected my accounts and approved the automation plan. 4. When a new Zendesk ticket arrives, the workflow identifies the issue type, urgency, and customer intent. 5. It checks the relevant Notion documentation and prepares a response based on the available information. 6. If the issue looks like a product bug, it creates a Jira ticket with the customer context already attached. 7. Urgent or sensitive cases are escalated to the team instead of being handled automatically. 8. I connected WhatsApp from the Awish chat. I now receive workflow updates there and can manage the automation without opening Awish. Customer-facing actions still stay under my control when approval is needed.

We needed legal help with a small-claims case. A company owed us $3,500, and the cost of hiring a lawyer would have far exceeded that amount. I used Grok to explain what to do and how to file the paperwork. Last week, I served three writs of garnishment on banks that might hold the company’s money. Whichever bank has its account will now have to freeze the account and turn that amount over to us. Before AI, I would have had no idea how to do this on my own. Grok scans my completed documents for errors and directed me to the correct county sheriff’s office to have the papers served. It can explain things more simply when I don’t understand them. Need legal help in your state? AI can guide you step by step. Step-by-step: 1. I explained the small-claims situation to Grok, including that the company owed us $3,500 and that hiring a lawyer would cost more than the amount owed. 2. I asked Grok what to do and how to file the paperwork. 3. I used Grok to scan my completed documents for errors. 4. I followed Grok’s direction to the correct county sheriff’s office for serving the papers. 5. I served three writs of garnishment on banks that might hold the company’s money. 6. The bank holding the company’s account will have to freeze the account and turn the amount owed over to us.

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 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.

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 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 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’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

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.

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.

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 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.

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’ve been using the Awish app I built less as an automation builder and more as a way to solve specific business problems people bring me. One hotel client, Aurelia Bay Hotel, had an interesting marketing problem. They could see travel trends across search, Instagram, YouTube, website traffic, and ads, but connecting those signals early enough to spot a real campaign or guest-experience opportunity was difficult. I built an automation for them with Awish and gave it to them to test. Step-by-step: 1. I opened the Awish chat and wrote: “For Aurelia Bay Hotel, monitor Google Trends, YouTube, Instagram, Google Analytics, and Google Ads every day. Find rising interests around Dubai travel, staycations, family trips, wellness, dining, events, and hotel experiences. Cross-check those trends with social engagement, website behavior, and campaign performance. Rank the strongest opportunities, send them to the marketing team in Microsoft Teams for approval, and create a campaign or guest-experience opportunity brief in SharePoint for anything they approve.” 2. Awish understood what I wanted, planned the complete workflow, and selected the apps required for each step. 3. I reviewed the plan, connected the client’s accounts, and approved it. 4. Awish added Microsoft Teams as the human approval step and SharePoint for the final opportunity briefs. 5. Once everything was connected, Awish built the workflow and started running it daily. 6. It now cross-checks trend growth, social engagement, website behavior, and ad performance. When it finds a strong opportunity, the marketing team gets the evidence in Teams. If they approve it, Awish creates the full campaign or guest-experience brief in SharePoint. The useful part is that a trend isn’t treated as an opportunity just because it is growing on one platform. Awish checks whether the same signal is appearing across the business before recommending action. Do you have any time-consuming, repetitive tasks or problematic aspects in your job? I would be happy to develop an automation solution for you as well.

I built an AI-assisted vertical grain supply-chain resilience workflow after discovering that the rye flour we normally use for homemade bread had been discontinued. I started by asking ChatGPT to locate alternative retail and bulk suppliers for rye and spelt flour. We compared package sizes and prices, contacted local mills and bulk-food suppliers directly, and expanded the search from finished flour to locally available whole grain. The workflow then moved offline. ChatGPT helped us identify the resources we already had: agricultural land, grain bins, a cultivator, a seeder, an old but functional industrial grain crusher, and even a combine. We also realized that a friend owns a seed-cleaning plant and that our farming neighbors can connect us with local rye and spelt growers. Our next steps are to test whether a household coffee grinder can produce sufficiently fine flour from grain, source fresh food-grade rye and spelt locally, and investigate growing a small crop ourselves. The biggest lesson was that AI was most useful not because it gave us one answer, but because the conversation kept changing the question. We began with “Where can I buy rye flour?” and ended with “Why are we buying rye flour when we already have most of the infrastructure required to produce it ourselves?” Step-by-step: 1. I asked ChatGPT to find alternative retail and bulk suppliers for rye and spelt flour after our usual rye flour was discontinued. 2. We compared package sizes and prices, contacted local mills and bulk-food suppliers directly, and expanded the search from finished flour to locally available whole grain. 3. We reviewed the resources already available to us, including agricultural land, grain bins, a cultivator, a seeder, an old but functional industrial grain crusher, and a combine. 4. We identified additional local resources: a friend’s seed-cleaning plant and farming neighbors who can connect us with local rye and spelt growers. 5. We plan to test whether a household coffee grinder can produce sufficiently fine flour from grain, source fresh food-grade rye and spelt locally, and investigate growing a small crop ourselves. 6. We reframed the question from where to buy rye flour to whether we could produce it ourselves using the infrastructure already available to us.

When medical care, psychosocial support, and administrative follow-up are spread across services, emails, documents, and people over many years, there can be plenty of information but very little overview. A new provider sees snapshots, old decisions hide in email threads, and referrals resurface months later. Reconstructing the full story from memory every time requires almost a second brain. So I built a living chronological timeline. I did not want a summary of what my situation was “more or less.” I wanted: `date → event → action taken` For example: `14 March 2026 — Symptoms discussed with service X — Service refers me to Y; appointment requested.` This shows not only what happened, but what followed. My timeline runs from 2009 to the present and is divided into five documents covering meaningful periods. A new document begins when a new phase in life or support begins. Older periods stay stable, while almost all active maintenance happens in the latest document. I reopen historical files mainly when a missing record resurfaces. Step-by-step: 1. I collect existing traces, including emails, appointments, referrals, medical or administrative documents, formal decisions, and earlier notes. A sent email is often only half an event, so I also search for replies and follow-up. 2. I search by trajectory rather than by one name. I use names, spelling variants, organisations, domains, senders, recipients, subject words, and attachment terms. 3. I read the full conversation. A search result is not yet a timeline item, so I establish what happened, when it happened, who was involved, and what action or response followed. 4. I separate evidence levels. I distinguish between my own report at the time, a response or confirmation, an official decision or document, and an event that seems real but still lacks confirming evidence. I do not replace a missing document with an assumption; the absence itself becomes part of the record. 5. I track people and organisations separately. “Contact with organisation X” can hide that different people suggested, revisited, or formally communicated different things. 6. Before adding a new event, I compare it with the existing timeline. It may add information by filling a gap, replace an incomplete entry, clarify an existing event, or mark a missing record while preserving uncertainty. This prevents duplicate versions of the same event. 7. For substantial historical work, I first create a temporary review document using `date — event — action taken`. It can contain open issues, missing documents, and uncertainties. Only after review do I update the main timeline. For ordinary new events, I skip this step when the source and date are clear. 8. I make uncertainty visible by grouping research notes into “Clearly found,” “Possible identity confusion,” and “Not found or insufficiently documented.” 9. I maintain the living timeline using the structure `year → month → chronological events`. Older information is preserved, duplicates are merged, uncertainties stay visible, and open trajectories remain open. In practice, the five documents behave like version control: the first four are mostly archive, while the fifth is alive. 10. I reuse the timeline for thematic analysis. Chronology is the factual foundation, but events can also be regrouped to reveal patterns in functioning, work capacity, transport, medical developments, administrative burden, communication needs, and realistic conditions for participation. Two workflows emerged: - Historical reconstruction: collect sources → reconstruct trajectory → determine evidence status → review → update the correct historical period - Ongoing follow-up: new event → verify source → record date and action → add to the active document Most records are organised around institutions. A GP sees one part, a psychologist another, and an agency only its own procedure. Emails are chronological within a mailbox, but not across a life. A personal timeline turns that model around. The person becomes the organising axis, not the institution. That lets administratively separate events appear next to each other in time, revealing patterns such as repeated referrals, waiting times, administrative burden, or support disappearing when the need for it increases. The workflow in one line is: `Collect sources → reconstruct trajectories → connect events to actions → distinguish evidence status → compare → review → integrate → maintain → analyse thematically.` The result is not a perfect record, but a steadily improving map of what actually happened, with mainly the newest edge continuing to grow while the past stays calmly in place.