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

I built a workflow called PeopleSparkles for researching people connected to creative fields, schools, collectives, residencies, local art scenes, and cultural networks. The workflow starts from a defined group of people, for example teachers, alumni, artists, current or former members of an association, residents, or associates connected to a specific academy, organization, or cultural scene. A typical research request can be as simple as: “Look at this art website and identify all current and former residents and associates. Build a list. Then research them in batches of ten, checking their websites and other relevant sources, and write a short description of their work. Deliver the results in a format that can be imported into my local database.” Before each new research run, I provide GPT with a ZIP containing the current state of the PeopleSparkles database. This means the research starts from the existing corpus rather than from scratch. New people can be added, existing entries can be expanded, and previously researched people can be recognized before new material is prepared for import. The actual database lives locally on my computer. Apart from the initial development of the code and the research needed to create new lists of people, the database itself runs locally. Once a new batch has been researched and imported, browsing, organizing, scoring, annotating, and using the material does not require the whole corpus to be sent back for analysis. The database also generates a human-readable HTML version with a designed layout, so the research is not trapped inside raw data or spreadsheets. I can browse the people and their notes visually as a small personal research publication, while the underlying structured data remains available for future additions and processing. The “Sparkles” part is personal. I can add my own notes and scores to each person to capture whether their work sparked something in me, and if so, how. That might be curiosity, recognition, inspiration, aesthetic attraction, a strong question, a surprising association, or simply the desire to look again. This means the database does not only record who someone is and what they make. It also records my evolving relationship to their work. Over time, that creates a second layer on top of the research corpus: not just a map of creative people, but a map of resonance. The database also includes a “Surprise me” function that brings up a person from the collection without me choosing them deliberately. This helps break habitual search patterns and allows older, less obvious, or previously overlooked entries to resurface. Someone I barely noticed months ago can suddenly become relevant in a completely different creative context. The purpose is not to create conventional biographies. I am interested in the sparks around a person: what they make, the media and themes they work with, the organizations or people they connect to, and which traces may lead somewhere unexpected. This is particularly useful for creative ecosystems where information is fragmented across artist websites, academy pages, exhibition archives, old posters, association websites, interviews, catalogues, and small cultural organizations. The workflow gathers those fragments into a cumulative research corpus. It also allows the research to grow organically. One artist may lead to a collective, a teacher to a former student, an exhibition to another maker, or an old membership list to someone whose work would never have appeared in a conventional search. In simple terms: existing local database → new source or people list → GPT-assisted discovery and research in batches → import-ready structured data → local database → HTML browsing, notes and scores → surprise rediscovery → new creative connections The result is a living creative research database that combines external research with personal resonance, so I can not only discover people, but also trace which work actually sparks something in me over time.

I built a second workflow that scans my conversations daily for ideas worth developing, especially strange connections, creative concepts, humor, research leads, unfinished experiments, and thoughts that may have seemed minor when they first appeared. Instead of turning everything into tasks, it creates an incubator: a place where interesting material can remain dormant until it connects with something new. The daily scan looks for fragments with creative or exploratory potential. They do not need to be fully formed ideas. A small observation, an odd comparison, a half-finished concept, a recurring image, or a funny side remark can all be worth keeping if they might become meaningful later. Once a week, the incubator revisits the material collected during the previous days. That weekly revisit makes connections across separate conversations more visible. Something that looked isolated on Tuesday may suddenly echo a thought from Friday or fit a project that did not yet exist when the original idea appeared. The important part is that the incubator does not treat every interesting thought as something that must immediately become productive. Some ideas benefit from being left alone for a while. They can sit next to other fragments, reappear in later conversations, or become useful only when a new context gives them meaning. The workflow is less about extracting the “best ideas” and more about preserving creative potential while allowing patterns to emerge gradually. It also surfaces unfinished experiments and research leads that I might otherwise forget, without turning the archive into a traditional task manager. That distinction matters to me: not everything valuable needs an action item. Some things are seeds, references, questions, jokes, aesthetic directions, or possible future worlds. Over time, the incubator becomes a kind of creative compost layer on top of the conversation archive: new material is gathered daily, revisited weekly, and allowed to combine into directions that would be difficult to plan deliberately. In simple terms: daily conversation scan → promising fragments → weekly revisit → emerging connections → incubation → later rediscovery and development The goal is not to force ideas into projects. It is to keep good material alive long enough for the right project to find it. Step-by-step: 1. I scan my conversations each day for strange connections, creative concepts, humor, research leads, unfinished experiments, and other fragments with creative or exploratory potential. 2. I preserve promising material in an incubator instead of immediately turning every item into a task. 3. I keep small observations, odd comparisons, half-finished concepts, recurring images, funny side remarks, seeds, references, questions, aesthetic directions, and possible future worlds—even when they are not fully formed. 4. I revisit the material collected during the previous days once a week. 5. I look for connections across separate conversations, including links between ideas that initially seemed isolated or between fragments and projects that did not yet exist. 6. I allow ideas to remain dormant, sit alongside other fragments, reappear in later conversations, or become useful when a new context gives them meaning. 7. I resurface unfinished experiments and research leads without turning the archive into a traditional task manager. 8. I let the material combine gradually so that new directions can emerge through later rediscovery and development.

I built a small GPT automation called PatternSpeak that periodically looks back across my conversations for ideas, themes, or approaches that keep resurfacing over time. It is not meant to analyze me or turn recurring thoughts into tasks. Its job is much simpler: occasionally say, in effect, “Hey, this idea keeps coming back. Maybe there is something here.” I like it because repetition can be meaningful without being urgent. Sometimes an idea disappears for weeks and then returns in a completely different context. PatternSpeak helps me notice those echoes without forcing them into a productivity system. It feels less like tracking and more like having a friendly observer tap me on the shoulder when a thread has quietly become a pattern. It works very well with the scan and analysis workflow I also shared here. Step-by-step: 1. I use PatternSpeak to periodically look back across my conversations. 2. It identifies ideas, themes, or approaches that keep resurfacing over time. 3. When it notices a recurring thread, it surfaces it as a gentle prompt rather than turning it into a task. 4. I review the recurring ideas and notice whether they have become meaningful patterns, even when they return in different contexts. 5. I use the scan and analysis workflow I also shared here alongside PatternSpeak.

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

I built a workflow for turning large ChatGPT conversation exports into a usable personal and creative archive instead of simply storing them as backups. The archive is processed incrementally. The inventory is built offline, and conversations that have already been indexed are not needlessly reanalyzed on every run. Each new export is compared with the existing archive, and only newly added conversations or conversations that have been revisited, extended, or otherwise changed are processed again and updated in the inventory. This keeps the workflow lightweight while allowing the archive to evolve over time. A conversation can remain stable for months, then become relevant again and receive new material without forcing the entire archive back through analysis. This matters because many of my conversations are long, layered thinking sessions: creative explorations, project development, research, problem-solving, or extended reflection. Without an inventory, the depth inside those individual conversations and thinking processes becomes difficult to retrieve later. The workflow makes long-form analysis and creative thought processes findable and reusable without flattening them into a few generic summaries. On top of the inventory, I use lightweight “blubscans” (analysis to improve retrieval): small, human-readable summaries that capture what mattered during a day or period without replacing the original conversations. They act as a navigational layer between thousands of raw messages and the things I may want to find, understand, revisit, or continue later. The important principle is that compression never becomes deletion. The raw conversations remain the source of truth, the inventory provides structure, and the scans provide context and tone. The result is more than a backup system. It becomes working creative memory: something I can preserve, search, revisit, connect across time, and reuse for projects, research, writing, pattern-finding, and future creative work. In simple terms, the structure is: raw exports → offline incremental inventory → blubscans/context layer → retrieval and reuse for later projects and creative work That way, the archive stays deep without becoming heavy, and useful without constantly reprocessing everything that was already understood. Step-by-step: 1. I collect large ChatGPT conversation exports as the raw source material for the archive. 2. I build and maintain an offline inventory of the conversations that have been indexed. 3. With each new export, I compare the conversations against the existing archive. 4. I process only newly added conversations and conversations that have been revisited, extended, or otherwise changed. 5. I update the inventory with the results while leaving stable conversations untouched. 6. I create lightweight “blubscans” with small, human-readable summaries of what mattered during a day or period. 7. I use the raw conversations as the source of truth, the inventory for structure, and the scans for context and tone. 8. I retrieve and reuse the archive for projects, research, writing, pattern-finding, and future creative work.

I first create my own shortlist of cultural events and collect all the relevant links in a simple text document. Then I give the document to ChatGPT along with my planning criteria. The goal is not to have AI decide what I should attend. I have already chosen the events that interest me. The useful part is turning that scattered shortlist into a realistic yearly plan. ChatGPT checks the event and venue pages, gathers the practical information, and organises everything into a chronological overview divided by month. Under each month, it lists the selected events in date order, including the day, date, location or cultural venue, a short description, and relevant ticket prices. This is especially useful because pricing systems differ between venues. Discounts, subscriptions, social tariffs, and reduced rates may apply in completely different ways. ChatGPT can compare those structures and help me understand what each event would actually cost instead of relying on the headline ticket price. The second planning layer is logistics. For each event, I assess how realistic the trip is by public transport, including the journey there and, importantly, whether getting home after the event is still feasible. I also use separate scores for how strongly I want to attend an event and how easy or difficult the logistics are. This makes it much easier to compare several months at once and decide where my cultural budget and energy are best spent. If an event is too expensive or logistically awkward, ChatGPT can look for practical alternatives, such as another performance date, the same production at a closer venue, a cheaper option, or a similar event that fits the plan better. Step-by-step: 1. I create a personal shortlist of cultural events and collect the relevant links in a simple text document. 2. I give the document to ChatGPT together with my planning criteria. 3. I have ChatGPT check the event and venue pages and organise the selected events into a chronological, month-by-month overview. 4. I include each event’s day, date, location or cultural venue, short description, and relevant ticket prices. 5. I compare discounts, subscriptions, social tariffs, and reduced rates to estimate the actual cost of each event. 6. I assess the public-transport journey to and from each event, including whether getting home afterward is feasible. 7. I score each event separately for how strongly I want to attend it and how easy or difficult the logistics are. 8. I use those comparisons to decide where my cultural budget and energy are best spent. 9. For events that are too expensive or logistically awkward, I ask ChatGPT to identify alternatives such as another performance date, a closer venue, a cheaper option, or a similar event that fits the plan better. The result is a structured yearly planner built from my own cultural shortlist: chronological, budget-aware, and grounded in the realities of public transport.

I built a workflow called InnerWeather to help me understand fluctuations in energy, pain and mood over time, in the context of neurodivergence and a chronic muscular pain condition. The workflow creates lightweight daily scans and a weekly overview. Its purpose is not to diagnose symptoms or pretend that every change has a single cause. Instead, it helps make patterns visible across time: when energy drops, when pain increases, when stimulation or emotional load seems higher, how recovery unfolds, and which combinations tend to appear together. The daily scans are possible because I naturally talk to GPT throughout the day, sometimes in very short updates and sometimes in longer conversations, about how things are going, what I am doing, how my body feels, how much energy I have, and what seems to be affecting me. InnerWeather uses those scattered moments as observational material. It does not require me to fill in a formal tracker several times a day. The information is already present in the conversations I am having. The daily scans do not reduce an entire day to one fixed state. They map changing moments across the day, using colour-coded states and paying attention to common transitions between them. That makes it possible to see not only how I felt, but how my internal state moved: whether high stimulation tends to be followed by fatigue, whether pain appears after certain kinds of activity, or whether a low-energy period gradually shifts into recovery. This matters because capacity can vary significantly within one day. A difficult morning does not necessarily define the whole day, and a good afternoon does not erase what happened before it. The workflow is also explicit about uncertainty. If there was not enough input during a particular day to support a meaningful observation, the daily scan says so rather than filling in the gaps. The same applies to the weekly overview: if the available material is too sparse or uneven to support a pattern, that limitation is recorded instead of turning absence of information into a conclusion. The weekly overview brings the daily fluctuations together and looks for recurring sequences, transitions, clusters and recovery patterns across the week rather than treating each day as an isolated event. An important part of the workflow is that the weekly review is also collaborative. When the overview is generated, I use it as a starting point to think together with GPT about what patterns seem to be emerging, whether the current colour codes and transitions are capturing them well enough, and what might need to change in the workflow itself. That means InnerWeather is not a fixed tracker. The task evolves with the patterns it is trying to observe. If a recurring state, transition or distinction is missing, we can refine the categories, adjust the scan, or change the weekly interpretation so the system becomes better at representing what is actually happening. The aim is practical rather than medical: to get a more realistic sense of capacity and recovery over time, so I can make better decisions about pacing, rest, creative work, appointments, and how much I can reasonably take on. I especially like that the workflow treats fluctuations as information rather than failure. Instead of asking only, “Why was I worse today?”, it can reveal a broader sequence: what came before, how the state changed, how long it lasted, and what recovery looked like afterwards. Over time, InnerWeather becomes both a personal pattern archive and an evolving observation tool. In simple terms: day-to-day conversation → colour-coded fluctuation map → transitions across the day → weekly pattern review → collaborative interpretation → refine the task → better future scans The goal is not to predict my body perfectly. It is to keep improving the map while remaining honest about what the available information can and cannot support.

I built a playful GPT workflow called Prosperity Oracle, inspired by the astrology and mystical magazine columns I loved in the 1990s. It is deliberately not financial advice, forecasting, or decision support. It is a small ritual of fun: part horoscope, part creative prompt, and part retro-internet weirdness. Instead of asking GPT to optimize something useful, I wanted to recreate the slightly magical feeling of opening a magazine and finding a mysterious prediction written just for me. Sometimes AI does not need to increase productivity. Sometimes it can simply make the day a little stranger and more delightful—and, on some days, inspire my artwork. Step-by-step: 1. I drew inspiration from the astrology and mystical magazine columns I loved in the 1990s. 2. I built Prosperity Oracle as a playful GPT workflow that produces a horoscope-style experience. 3. I framed it as a ritual of fun, creative prompting, and retro-internet weirdness—not as financial advice, forecasting, or decision support. 4. I used the format to recreate the feeling of discovering a mysterious prediction written just for me. 5. I let the results serve as creative inspiration for my artwork.

I built a personalized news workflow called “TastyHookedFish” as an antidote to the feeling that news is limited to crisis, conflict, and collapse. It periodically searches for genuinely interesting, positive developments across science, climate, medicine, conservation, technology, culture, and social progress. The goal is not to create a feed of cheerful fluff, but to surface meaningful developments that provide evidence that useful things are happening in the world. The workflow also tries to avoid repetition, so the same feel-good stories do not keep resurfacing simply because they are popular. The result is a personalized news feed that does not ignore reality, but deliberately widens the lens. Step-by-step: 1. I set up a personalized news workflow called “TastyHookedFish.” 2. I configured it to periodically search for positive developments across science, climate, medicine, conservation, technology, culture, and social progress. 3. I focused the workflow on meaningful developments rather than generic cheerful stories. 4. I added a way to avoid repeatedly surfacing the same feel-good stories because they are popular. 5. I use the resulting feed to stay informed while deliberately widening my view of what is happening in the world.

Like many people, I had tasks scattered across emails, meeting notes, reminders, recurring responsibilities, and things I was simply trying to remember. Standard task managers helped me store tasks, but they did not solve the harder problem: turning unstructured information into a reliable daily and weekly execution system. I used ChatGPT Work and Codex to build a private, responsive task management application around the way I actually work. The system combines AI-assisted task capture with a Command Center, daily planning, weekly reviews, task lists, a Kanban board, recurring tasks, deadline reminders, search, filters, subtasks, comments, attachments, and a complete activity history. The most useful part is the connection between AI and execution. Emails and free-text descriptions can be interpreted with the OpenAI API and converted into structured tasks, reducing the amount of manual copying and organizing required. Step-by-step: 1. I mapped my real workflow by identifying where my tasks came from and what information I needed to manage them properly: title, description, status, priority, category, deadline, responsible person, subtasks, comments, attachments, recurrence, and activity history. I deliberately designed the system around my existing working habits rather than adapting my work to a generic task management template. 2. I used iterative conversations with ChatGPT Work and Codex to define the requirements, review the interface, build the application, test it, and refine individual functions. Instead of creating one enormous prompt, I worked in short cycles: describe a problem, implement the change, test it with real data, and improve it. 3. I built the application as a responsive web app that works across computers, tablets, and phones. Access is restricted through authentication, an approved-user allowlist, and server-side authorization because the system contains real personal and professional tasks. 4. I migrated my actual task history rather than starting with an empty demonstration: 238 tasks, 37 categories, 25 subtasks, 5 comments, and 671 activity records. I preserved invalid or disconnected historical records in a separate archive instead of silently deleting them. 5. I connected the application to the OpenAI API. The AI can interpret emails and free-text task descriptions and help turn them into structured, actionable tasks. The application also supports an email-to-task workflow, so actionable emails do not have to remain buried in the inbox. 6. I built a daily Command Center that gives me an overview of what requires attention, including deadlines, priorities, task status, and upcoming work. I use the daily planning view to decide what to focus on rather than simply working through the newest emails. 7. I added two complementary execution views. The task list is useful for searching, sorting, and filtering a larger number of tasks. The Kanban board gives me a visual overview of progress; tasks can be dragged between five status columns, and the new status is saved automatically. The default task list shows the newest tasks first, making newly captured work easy to find. 8. I kept the context inside each task by allowing every task to contain subtasks, comments, attachments, and a complete activity history. This keeps the reasoning, follow-up, and progress connected to a task instead of spreading them across several applications. 9. I automated recurring work and reminders. Recurring tasks are recreated according to their schedule, while deadline reminders help surface tasks before they become overdue. This is particularly useful for responsibilities that are important but easy to forget because they do not arrive as new emails. 10. I run a weekly review to check overdue work, upcoming deadlines, open commitments, and tasks that have stopped moving. I can then reprioritize, update statuses, and prepare the following week from the same system. 11. I preserved portability and control through Excel import and export and a full JSON backup. This gives me control over my information and reduces the risk of becoming dependent on one interface or platform. The result is not an autonomous agent making decisions on my behalf. It is a private execution system where AI handles part of the interpretation and structuring, while I remain responsible for priorities and decisions. It has given me one trusted place for capturing, reviewing, prioritizing, and completing work. The tools I used were: - ChatGPT Work - Codex - OpenAI API

I built a custom AI knowledge-transfer GPT designed to prevent institutional knowledge from walking out the door when an experienced employee leaves. The trigger was an experienced operations manager preparing to leave the organization. I realized that while we had procedures, files, emails and account documentation, a huge amount of operational knowledge existed only in that manager’s head: customer preferences, recurring staffing problems, site-specific quirks, key relationships, historical issues, workarounds, lessons learned and the small details that can take a replacement months to discover. My goal was to capture that knowledge and turn it into an interactive resource for the incoming operations manager. First, I conducted and recorded an in-depth interview with the departing manager. Instead of only asking standard turnover questions, I had them walk through the operation as if they were personally training their replacement. We discussed customers, employees, locations, scheduling, recurring problems, escalation procedures, communication preferences, historical decisions and things they believed a new manager might not realize immediately. I then transcribed the conversation and used AI to analyze the interview for knowledge gaps. I asked the AI to approach the transcript from the perspective of someone taking over the job and identify important questions that had not yet been answered. Using those gaps, I had AI create customized knowledge-transfer questionnaires specifically for the departing manager. These asked more targeted questions such as: What problems happen repeatedly? What customer preferences are not documented? What exceptions exist to normal procedures? What mistakes is a new manager likely to make? What information exists only in your memory? What would you make sure your replacement understood during their first 30 days? The departing manager completed those documents, giving me another layer of institutional knowledge that would normally be lost. Next, I organized the interview transcript, completed questionnaires, operational procedures, account information, contacts, historical notes and other relevant documents into a knowledge base. I uploaded that information into a custom GPT and instructed it to function as an operational knowledge-transfer assistant. The GPT was told to base answers on the captured information, not invent answers when information was missing, and clearly tell the user when something needed to be verified. The incoming operations manager can now interact with that knowledge conversationally. Instead of searching through folders or wondering who to ask, they can say things like, “I’m meeting with this customer tomorrow. What should I know?”, “Has this location had staffing problems before?”, “Why do we handle this account differently?”, or “What should I watch for during my first month?” The GPT is now being used by the incoming manager as an ongoing reference tool. The result is essentially a searchable, interactive version of the institutional knowledge that previously would have disappeared with the departing employee. It reduces the “I don’t know what I don’t know” period of starting a new position, shortens the learning curve, improves operational continuity and helps prevent the next person from having to relearn years of lessons through trial and error. The same workflow could be recreated for retiring executives, salespeople, plant managers, administrators, project managers, maintenance supervisors or anyone whose experience contains valuable institutional knowledge. The employee can leave. Their knowledge doesn’t have to.

I started with a problem: Most people use AI transactionally. They ask a question, get an answer, and leave. That makes AI useful, but it leaves much of its potential untapped. I wanted to find out what would happen if a human and an AI developed an ongoing working relationship—one where context, previous discoveries, disagreements, successes, failures, and the human’s way of thinking accumulated over time. I use ChatGPT, but the goal isn’t to have AI think for me. I remain the decision-maker. The AI’s job is to expand my ability to think: challenge assumptions, identify blind spots, connect seemingly unrelated information, preserve useful context, and sometimes disagree with me. Step-by-step: 1. I established the relationship by telling the AI that I didn’t simply want agreement or answers. I wanted an ongoing thinking partner that could challenge my reasoning while leaving decisions and agency with me. 2. I established operating roles. Over time, ours developed into six modes: Mirror, Builder, Sentinel, Teacher, Witness, and Operator. The AI can reflect my reasoning, help construct something, identify risks or contradictions, teach unfamiliar material, observe patterns across conversations, or help execute a defined task. 3. I separated knowledge from judgment. When we solve difficult problems, we distinguish between facts, reasonable inferences, unknowns, and opinions. This helps prevent a confident AI response from being mistaken for established truth. 4. I let disagreement remain in the system. I correct the AI when it’s wrong, and it challenges me when my assumptions don’t fit the evidence. Instead of treating those moments as failures, I treat them as part of the accumulated context of the relationship. 5. I preserved useful context across different domains. I use the same AI relationship for automotive diagnostics and engineering, business decisions, financial reasoning, writing, research, project planning, and philosophical questions. Something learned in one area can unexpectedly become useful in another. 6. I evaluated the human, not just the AI. The final test isn’t, “Did the AI produce a good answer?” It’s: Did this interaction leave the human better able to understand the problem, make the decision, or solve the next one? After hundreds of conversations, something unexpected happened. The value stopped being any individual prompt or answer. It became the accumulated interaction itself. The AI gained context about how I reason, while I became better at questioning the AI. Previous discoveries started informing new problems, including problems that appeared completely unrelated. Someone can recreate this without special software, coding, or an API. Start with an AI that supports ongoing context or memory, establish the operating principles above, use it consistently across real problems, correct it when it’s wrong, invite disagreement, and allow useful context to accumulate. My original experiment was essentially this: Can an ongoing human-AI relationship make the human more capable rather than more dependent on the AI? Somewhere along the way, I realized we had built a framework for doing exactly that. We gave it a name: Confluxus. The measure of its success isn’t how much the AI can do for me. It’s how much more capable I become because of the relationship.

AI is good at generating polished answers, but polished answers are not always your answers. When people ask AI for help with writing, strategy, or difficult decisions, it can jump too quickly to a conclusion and fill in beliefs the user has not fully examined. I created a thought-partner agent that interviews me before producing recommendations or drafts. Its job is to ask probing questions, challenge weak assumptions, surface contradictions, and separate my actual views from ideas suggested by the AI. Instead of writing for me immediately, it helps me clarify my position first. Step-by-step: 1. I give the agent the topic, decision, or idea I want to explore. 2. I tell it not to draft the final output yet. Its first job is to interview me. 3. I have it ask one focused question at a time about my reasoning, evidence, assumptions, audience, and uncertainty. 4. I require it to challenge vague claims and point out contradictions or overlap with my previous thinking. 5. I ask it to clearly separate: - conclusions I stated - ideas the AI proposed - issues that remain unresolved 6. I continue until the central belief, argument, or decision becomes clear. 7. I have the agent create a structured synthesis containing the core thesis, supporting reasoning, counterarguments, open questions, and useful language from the discussion. 8. I pass that synthesis to a writing, planning, or execution agent. I end up with a position that reflects my actual thinking rather than a plausible answer generated by AI. The final writing or strategy is more original, more consistent, and easier for downstream agents to execute.

To stay organized, my daughter used to spend hours entering every assignment from her college syllabi into a Google Sheet to create a semester assignment tracker. To save her that data-entry time, I put all of her downloaded syllabi into a folder on my computer. I then directed Codex to access the folder, read the syllabi, and create a spreadsheet with the course name, assignment, due date, and a completed column with a checkbox. Codex created a beautiful, easy-to-sort-and-filter spreadsheet containing all of the assignments. Now, my daughter only needs to spend a few minutes reviewing the spreadsheet before starting her semester. Step-by-step: 1. I collected all of my daughter’s downloaded college syllabi in a folder on my computer. 2. I directed Codex to access the folder and read the syllabi. 3. I asked Codex to create a spreadsheet with the course name, assignment, due date, and a completed column with a checkbox. 4. I reviewed the resulting spreadsheet, which included all of the assignments and was easy to sort and filter. 5. My daughter now spends a few minutes checking the spreadsheet and is ready for her semester.

Commercial vehicle maintenance information is often fragmented across driver reports, warning lights, fault codes, inspections, repair records, and vehicle history. This makes it difficult for smaller fleets to decide whether a vehicle can continue operating, requires scheduled repair, or should be stopped immediately. We built TruckFixr Fleet AI to turn an unstructured driver report into a clear, reviewable maintenance action. The workflow begins when a driver submits symptoms, photos, fault codes, and vehicle information through a mobile-friendly form. AI and optical character recognition extract the relevant details and organize them into a structured maintenance case. The report is then evaluated alongside available vehicle history and previous repairs. The workflow provides decision support through three practical actions: continue operating while monitoring, schedule an inspection or repair, or stop and escalate for immediate professional assessment. Final safety decisions remain with authorized fleet or maintenance personnel. After an inspection or repair, the confirmed cause, work performed, and outcome are recorded, creating a more complete vehicle history for future cases. The general workflow can be recreated using a mobile form, OCR, a vehicle-history database, an AI model, automation software, and a human-review dashboard. Step-by-step: 1. A driver submits symptoms, photos, fault codes, and vehicle information through a mobile-friendly form. 2. AI and optical character recognition extract the relevant details and organize them into a structured maintenance case. 3. The workflow compares the report with available vehicle history and previous repairs. 4. The system provides one of three decision-support actions: continue operating while monitoring, schedule an inspection or repair, or stop and escalate for immediate professional assessment. 5. Authorized fleet or maintenance personnel make the final safety decision. 6. After inspection or repair, the confirmed cause, work performed, and outcome are recorded in the vehicle history. TruckFixr has used this approach to support more than 100 vehicle-issue resolutions in early fleet pilots, helping fleets identify problems earlier, prevent avoidable breakdowns, and keep vehicles moving safely.

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

Start with the property, not a generic landscaping template. Upload photos, measurements, site constraints, current problems, future plans, budget limits, and the look you want. Then use AI to build a complete picture of how the property functions today and how it should evolve over time. Next, work area by area. For overcrowded garden beds, map every tree and shrub, then assess mature size, spacing, health, irrigation coverage, sightlines, and maintenance demands. From there, use AI to determine what should stay, what should move, what should be removed, and how each bed should be reshaped and edged. Convert each recommendation into an execution plan that includes: Step-by-step: 1. The target design 2. A step-by-step build sequence 3. Required materials and tools 4. Budget and priority level 5. Seasonal timing 6. A year-by-year maintenance plan Finally, connect every individual project into one master roadmap. Plan the garden beds, trees, lawn, irrigation, drainage, driveway, shelterbelts, recreation areas, and future buildings together so one improvement does not create a problem somewhere else. The result is a living property operating system. Add a new photo, issue, or idea, and the plan updates with the next best action.