Workflow Hub

Sometimes AI produces an image you love without your having asked for that exact result. The colours work, the texture feels right, and the atmosphere is exactly what you wanted but could not quite describe. Before moving on, use that image to develop a reusable prompt. Step-by-step: 1. Show the image you are happy with to an AI tool and ask: “How would you describe the visual style of this image? Pay attention to colour, texture, lighting, shapes, composition, detail and atmosphere. Separate the style from the specific subject.” This helps turn “I love this” into something you can name. You are asking for a description of the visible result, not the exact process that originally produced it. 2. Read the description and compare it with the image. Check whether the AI noticed the qualities you love or focused on something incidental. Clarify ambiguous terms—for example, whether “soft” means gentle lighting, blurred edges, or muted colours. Correct the description where needed. You might write: “The uneven shapes and paper texture matter. The pastel palette does not. I want to keep the slightly strange atmosphere without making everything cute.” Your response turns a general description into a record of your taste. 3. Ask: “Write a reusable image prompt based on this description. Keep the visual qualities we identified, but make the subject replaceable. Distinguish essential features from optional ones.” The prompt should describe what makes the result useful to you rather than simply retell what is pictured. A woodland scene might contain the style you love, but that does not mean every future image needs a forest. 4. Apply the prompt to another source image or a different subject. This is the useful test: can the prompt carry the qualities you wanted into new material? A second version of almost the same scene may hide weaknesses in the prompt. A different subject makes them easier to see. 5. Compare the new result against your goal. Ask yourself: - Does this new result have the qualities I loved? - Does the style suit the new subject? - Did the prompt preserve what mattered in the new source? - Did it reproduce incidental details from the first image? - Would I actually use this result? A reusable prompt should transfer the visual direction while giving the new image room to remain itself. 6. If the result misses the mark, identify the specific difference and refine the prompt. For example: - Too smooth? Name the texture. - Too cute? Describe the shapes and expressions more precisely. - Too realistic? Clarify the degree of stylization. - Too similar to the first scene? Remove subject-specific details. Test again when those changes matter. Save the prompt alongside the original result and a successful test image. Note the tool or model used, since the same wording can behave differently elsewhere. One successful test is encouraging, but several varied tests give you a clearer sense of where the prompt works. An unexpected result can help you discover a preference you did not yet have words for. Describe it, decide what matters, turn those choices into instructions, and test whether they travel. You do not need to know the perfect prompt before making something you love. Sometimes the image comes first, and the language follows.

AI is useful for researching investments, but most workflows stop at “What should I buy?” The harder part comes afterward: Does the idea make sense given what I already own? What would make me add to the position? When should I take profits? What evidence would prove the original thesis wrong? And how do I track all of that without constantly watching the market? I use AI to turn a one-time investment research session into an ongoing decision and monitoring system. I start by asking AI to research the market for potential opportunities. In my case, I look specifically for strong mean-reversion trades, but the same workflow could start with value opportunities, macro themes, sector rotations, individual stocks, crypto, or almost any other investment strategy. Then I give AI my actual portfolio so it can evaluate those ideas in context. After I decide which recommendations I agree with and manually make the trades, I have AI convert each investment thesis into explicit rules for what should happen next. Finally, I turn those rules into automated monitors that periodically check market conditions and alert me only when something happens that warrants another decision. Step-by-step: 1. I define what I’m looking for by asking AI to research potential investment opportunities using criteria I care about, such as mean reversion, valuation, momentum, macro conditions, risk/reward, or another strategy. 2. I have AI investigate current market conditions and rank the opportunities, narrowing a large universe down to a manageable set of ideas worth examining further. 3. I pressure-test each thesis by asking why the opportunity exists, what could drive the expected outcome, what the major risks are, and—most importantly—what evidence would invalidate the thesis. 4. I provide my current holdings so AI can identify overlapping exposures, concentration risks, hedges, or positions that conflict with the new ideas. 5. I ask AI which existing positions the research suggests reviewing and where new exposure might make sense. The goal is a small number of actionable decisions rather than a giant list of interesting trades. 6. I review the analysis and independently decide whether to buy, sell, hold, or do nothing. I keep actual trade execution under human control. 7. Before the market moves, I define the next decision for every position by asking AI to identify conditions that would warrant reviewing whether to: - Add - Take profits - Reduce exposure - Exit - Reconsider the original thesis 8. I turn those conditions into automated monitors. I have ChatGPT periodically check the relevant prices, yields, economic indicators, news, or other variables. Instead of sending routine updates, I tell it to alert me only when a predefined trigger occurs. 9. When a trigger fires, I return to the original thesis with the new information and decide what—if anything—should change. Instead of using AI for isolated investment recommendations, I now have a repeatable loop for managing an investment thesis over time: Find an opportunity → Understand it → Compare it to what I own → Make a decision → Define what would change my mind → Let AI watch for it The most useful part may actually come after the investment decision. By deciding in advance what evidence would make me add, take profits, or reconsider the thesis, I don’t have to start my analysis from scratch every time the market moves. AI becomes a persistent research and monitoring layer while I remain responsible for every investment decision and trade.

I use Instinct, an AI assistant I text or send voice notes to over iMessage, to manage personal to-dos that used to live in my head or in a pile of iPhone alarms. Many tasks come up when I’m away from my desk, so I used to forget them. Alarms didn’t help much either: they went off once, I swiped them away, and the task was gone. Now, when something comes up, I send Instinct a quick voice note. I don’t need to open another app or type. For example: “Remind me tomorrow at 10 AM to respond to book my next dental appointment, and follow up until I say it's done.” Instinct turns the voice note into a clean reminder with a time attached. If I don’t reply “done,” it checks back in and keeps following up until I close out the task. I use the same thread for recurring tasks, partner follow-ups, ad hoc tasks, and advertising to-dos, so everything I owe people lives in one place. Capturing a task takes a few seconds, which means I actually do it. The built-in follow-up keeps things from slipping just because I was busy when the reminder went off, and the workflow lives in iMessage, where I already am throughout the day. Try sending one voice note today with a real task and end it with “follow up until I say it's done.” Step-by-step: 1. When a task comes up, send Instinct a voice note in iMessage. 2. Include the task, when to be reminded, and whether Instinct should follow up until you confirm it is done. 3. Let Instinct turn the voice note into a scheduled reminder. 4. Reply “done” when you complete the task. 5. If you do not reply “done,” let Instinct check back in and continue following up until you close it out. 6. Keep recurring tasks, partner follow-ups, ad hoc tasks, and advertising to-dos in the same iMessage thread.

I'm 78, a former army officer, and I live alone in the woods in southern British Columbia on satellite internet. In late January 2026, I knew nothing about AI and considered myself a novice in technology. After watching a YouTube video about advanced AI models, I started learning from YouTube channels that explain new AI research papers. I decided to run an experiment: what could a technology novice build with AI? I've been building for about 15 hours a day ever since. My goal is to build a system that improves itself in a continuous loop: it finds an upgrade proposal, builds and tests it, filters and grades it, approves or rejects it, installs it if it passes, monitors its performance, and learns from the result. We custom-built FORGE3 RSI in 900 hours. It consists of four plug-in modules: Forge2 RSI, which runs the improvement cycle; Bridge, the checker and connector; JAZ RSI, an upgrader in RAM built from a research paper; and Forge SecureBox, a high-security Mac app that runs security tests and code in a fresh, disposable virtual machine with no network device. I don't write code—it feels like a foreign language to me. Instead, I set the direction and run a team of AIs, mostly low-cost, near-Frontier models: Gemini 3.1 Pro and Hark as chiefs of staff; Cline and Devin as builders; and other models as independent, adversarial auditors. The rule that has made this work is simple: nothing gets built without an adversarial audit before and after. Our critical build pipeline is: Plan → audit → blueprint → audit → tests → audit → build → audit → test → audit → commit Each module has been built and fully tested on its own. Forge2 RSI alone has more than 1,000 tests. The first complete end-to-end cycle, using one upgrade proposal that we feed it by hand, is the next step. Our first attempt was fragile, and models that sound confident are often wrong. That is why audits matter more than any single model. FORGE3 RSI is my own custom-built plug-in module project. Our hardware and models are an MBP i9, Mac mini M4, Gemini 3.1 Pro, Hark, Cline (GLM 5.3/SPARK 1.3/MiMoV2.6), Devin (SWE2/GPT SOL 6), KUN (DeepSeek V4.1), and Git. Step-by-step: 1. We select a promising published research paper and have the team prepare and build it. 2. For every file, the team follows the same sequence: plan, audit, blueprint, audit, write tests, audit, build, audit, run tests, audit, and commit. 3. A different AI audits the work than the one that built the file. I decide when and how each audit happens. 4. Nothing is written or changed without my explicit GO. Reading and checking code is free; writing is work and waits for me. 5. We handle one building task at a time and avoid bundled instructions. 6. Any code the system wants to test runs inside SecureBox, sealed off from my Mac and the internet. 7. Everything that passes is committed to Git. The builders also maintain shared memory documenting what was decided and why, so the next session can pick up where the previous one stopped. 8. Next, we will run one complete improvement cycle with a hand-fed upgrade, then scale up slowly to two or three papers a week, prioritizing quality over speed as we work toward full autonomy.

AI agents are much more useful when they can remember important context across sessions. However, giving every agent access to one giant memory creates a different problem: irrelevant information accumulates, context becomes noisy, and agents waste time sorting through details that do not apply to their task. The challenge is not only giving AI memory. It is deciding what should be remembered, which agent should remember it, and where that memory belongs. I use a three-tier memory system that separates knowledge by scope: - Global memory: Information that should be available across the entire AI system - Agent memory: Knowledge specific to an individual specialist and how it should work - Project memory: Decisions, constraints, discoveries, and context that matter only within a particular project Instead of copying everything into every agent’s context, I store information at the narrowest level where it remains useful. Step-by-step: 1. Create a global memory layer for durable information that is useful across many agents and projects, such as important user preferences, shared conventions, and system-wide decisions. 2. Give each specialist its own memory. Store knowledge that helps a particular agent perform its role better, such as recurring preferences, domain lessons, and patterns learned from previous work. 3. Create project-specific memory for decisions, constraints, terminology, discoveries, current state, and other context that belongs with the project rather than in global memory. 4. Classify new information by scope. Whenever something worth remembering is learned, ask: - Does the whole system need this? - Does only this agent need it? - Does it matter only for this project? 5. Store the information at the narrowest useful level. Avoid promoting project-specific details into global memory unless they are genuinely reusable elsewhere. 6. Have agents load relevant memory before they work. A specialist can combine its accumulated knowledge with the current project context instead of starting every session cold. 7. Update memory as important decisions are made. Persist decisions and reusable lessons rather than relying on conversation history to remain available indefinitely. 8. Keep historical artifacts separate from active memory. Run logs, old handoffs, and detailed history can remain available for reference without automatically loading into every future interaction. Instead of treating memory as one giant bucket, I create a hierarchy: `Global → Agent → Project` Each agent gets the context it actually needs while unrelated information stays out of its working context. This provides better continuity across sessions, reduces repeated explanations, keeps context cleaner, and helps AI agents accumulate useful knowledge without requiring every agent to remember everything.

My mother recently moved into a retirement suite, which meant downsizing her possessions. We ended up with dozens of physical items she no longer had space for, and we wanted her children and grandchildren to have an opportunity to sign up for the family items they loved before anything was donated. I needed a way to catalog everything quickly, share the information remotely, and verify that we weren't accidentally giving away items of significant value. I tested a physical-to-digital workflow using Gemini. Instead of putting the items in a pile or typing out endless lists, I drew a numbered grid on a large whiteboard, placed one item in each square, and took a few photos. Gemini identified the objects by grid position, categorized them, estimated their market values, and built a ready-to-use spreadsheet with a signup column. The physical staging took about 30 to 45 minutes, depending on how many items were on that particular board. The entire digital workload—including cataloging, valuing, formatting, and creating the spreadsheet—took under 10 minutes. The process turned an overwhelming chore into something manageable and produced an end product that was easy for everyone to use. Step-by-step: 1. I drew a simple grid on a whiteboard, numbered each box, and placed one item in each square before taking photos. 2. I uploaded the photos to Gemini and prompted it to identify every item by its board name and grid number. 3. I asked Gemini to classify each item into logical groups, such as Glassware, Ceramics, and Woodcraft, and provide quick, realistic resale-market valuations based on visual condition. 4. I asked Gemini to generate a downloadable Excel file formatted as a signup catalog, with columns for Item ID, Grid Number, Description, Category, Estimated Value, and a blank "Claimed / Signed Up By" column for family members to enter their names. 5. I uploaded the file to Google Drive, converted it to Google Sheets, and added a note at the top explaining how tie-breakers would work if two family members wanted the same item.

I'm becoming GrokBot-pilled. I run my company on top of what's happening on X. I used to check everything manually: scanning for new workflows, searching brand mentions, watching what readers complained about, and trying to remember who I had just met at events. I've now handed all four jobs to GrokBot routines. The combined setup took under an hour, and the routines save me a couple of hours of manual checking every day. Every prompt below is read-only by design: the agent watches, labels, and drafts, but never posts, replies, texts, or emails anyone. Paste each prompt as-is, then replace the bracketed parts with your own channels, brand, and time zone. Routine 1: Find real AI workflows worth stealing and filters out the hype threads. Every weekday at 9:15am in my time zone, search X and the web for new AI workflows people are actually running. Keep only cases that name the old task, the tool, and the result: time saved, a step removed, or a handoff that used to need a person. Drop product announcements, “10 prompts” threads, and anything the author has not used more than once. Return at most 3. For each, give the link, the job it replaces, what I would need connected, and whether it fits my work. Send it to me on Slack. Do not post or reply anywhere else. Save this as a routine. If nothing qualifies, send one line saying so. Routine 2: Labels every mention of my name or company and delivers the results. Every weekday at 9:00am, search X for mentions in the last 24 hours of [your brand, @handle, or your own name]. For each hit, give the author, link, a one-line summary, and whether it is praise, complaint, question, or neutral. Do not reply to anyone. Post the digest in [your Slack channel] and tag me. Save this as a routine. If a source is unavailable, say which one. (Note: works just as well for a personal brand or a job search as it does for a company) Routine 3: Catches people actively looking for what I do. Every 4 hours, search X for people evaluating [your category]. Catch three things: reviews or complaints about [category]; posts asking which [category] to use; and complaints about the problem [your product] solves. Quote the post, link it, name the account, and label it review, shopping, or complaint. Skip anything older than 24 hours, and skip [category] accounts promoting themselves. Post to [your Slack channel] only if there is at least one new hit you haven’t already shared. Do not reply to or interact with anyone. Save this as a routine. If the search fails, report the failure in Slack. Routine 4: Keeps the people I meet at events from disappearing into my contacts app. Every weekday at 8:30am in my time zone, read my address book and list contacts added in the last 14 days. For each, show name, date added, phone, email, and any note. Ask me what we talked about before you write anything. Once I reply, draft a follow-up task for each person in [your task tool] with the context attached. Never text, email, or call anyone. Save this as a routine. If the address book is unavailable, say so and do not use old data. Step-by-step: 1. Paste each routine prompt as-is. 2. Replace the bracketed fields with your own channels, brand, category, product, task tool, and time zone. 3. Save each prompt as a GrokBot routine on its stated schedule. 4. Review the read-only outputs in Slack and respond to Routine 4 when it asks what you discussed with a new contact. 5. Keep the routines limited to watching, labeling, and drafting; they should never post, reply, text, email, or call anyone.

While traveling abroad, my partner and I became quite sick near the end of our trip and remained ill after returning home. Because we were in a country where we did not speak the language, we used Google Translate at the pharmacy and used Claude to track our symptoms as they changed from day to day. Claude helped us keep the symptom history organized and research what to ask for at the pharmacy, including differences between the medicines we were familiar with and those commonly used in that country. When our symptoms worsened after we got home, we continued using Claude as a symptom tracker and photographed everything in our medicine cabinet. We often forget what we bought or why, and medicines in the United States can be marketed for different uses in ways that are not always clear. Using the symptom history and medicine photos, we asked Claude what we might be able to use, what to avoid, when to take things, and when to contact a doctor, use telehealth, visit urgent care, or go to the emergency room. It also surfaced newer research suggesting that some medicines once thought to be effective may no longer be supported by current evidence. This simple workflow helped us manage the situation and decide whether we needed to buy anything new or seek additional care. Step-by-step: 1. I used Google Translate to communicate at the pharmacy while traveling in a country where we did not speak the language. 2. I described our symptoms to Claude and kept the symptom history updated as they changed from day to day. 3. I asked Claude to research what to ask for at the pharmacy, taking into account the medicines we were familiar with and those used in the country we were visiting. 4. After we returned home and our symptoms worsened, I continued tracking them in Claude. 5. I photographed the medicines in our cabinet so Claude could help us review what we had, what we might be able to use, and what we should avoid. 6. I used the symptom history and medicine information to think through timing, whether we needed to buy anything new, and whether to contact a doctor, use telehealth, visit urgent care, or go to the emergency room. 7. I also asked Claude to check current research, including whether newer studies had changed the understanding of some medicines’ effectiveness.

I built Show Hole to solve my family’s classic streaming problem: we spend too much time deciding what to watch, and the answer changes depending on who is actually on the couch. We each have different tastes, but the more interesting problem is that our tastes overlap differently in different combinations. I watch one kind of thing with my spouse, my spouse watches something different with our kid, and my kid and I have our own lane too. Most recommendation tools flatten that into one account profile, one watch history, or broad genre buckets, so they miss the real context of a household. Show Hole treats people and viewing contexts as first-class citizens. It recommends titles “in the vein of” something we liked, filters recommendations to the streaming services we actually subscribe to, avoids titles that the people present have already seen or vetoed, and explains why a recommendation fits tonight. Instead of relying mainly on genres such as comedy, drama, or sci-fi, Show Hole looks at more human taste signals: pacing, world building, humor, emotional weight, complexity, tone, and similar dimensions. It also learns from what we actually do after a recommendation: what we watch, skip, save for later, love, and drop. The result is a personal household recommender that understands “who is watching tonight?” as part of the question, instead of pretending one streaming profile can represent everyone. I designed the app using Claude design, then used those designs with Claude Code to build it. Step-by-step: 1. I identified the household viewing problem and accounted for the different combinations of people who might be watching together. 2. I designed Show Hole around people and viewing contexts instead of treating the household as one account profile, watch history, or set of broad genre preferences. 3. I had it recommend titles “in the vein of” something we liked, filter them to the streaming services we subscribe to, exclude titles already seen or vetoed by the people present, and explain why each recommendation fits that night. 4. I used taste signals such as pacing, world building, humor, emotional weight, complexity, tone, and similar dimensions instead of relying mainly on genres. 5. I made the recommender learn from what we watch, skip, save for later, love, and drop after receiving a recommendation. 6. I designed the app using Claude design and used those designs with Claude Code to build it.

Most AI agents are effectively static. You write their instructions, use them repeatedly, notice where they struggle, and manually tweak the prompt when something goes wrong. Valuable feedback from real work is often lost, so the same mistakes can keep happening. I created a self-improvement flywheel that uses actual agent performance data to improve agents over time. The system collects two kinds of evidence: - Task scores showing how well each agent performs across different quality dimensions - Run telemetry and review outcomes revealing recurring failures, coordination problems, and cases where actual behavior differs from expectations A scheduled weekly cycle analyzes that evidence, identifies patterns, creates improvement proposals, evaluates whether those proposals are safe and broadly applicable, updates agent instructions when appropriate, and measures whether those changes actually improve performance. The goal is not to let agents rewrite themselves freely. It is to create a controlled learning loop. Step-by-step: 1. Collect performance data while agents work. Score important outputs across consistent quality dimensions, and record useful execution telemetry such as failures, decisions, reviewer outcomes, and unexpected behavior. 2. Analyze performance trends on a recurring schedule. Calculate per-agent averages, identify weak dimensions, compare agents, and look for improvement or decline over time. 3. Mine run history for recurring patterns across multiple sessions, including agents that repeatedly struggle, low-quality runs, and cases where expected behavior differs from what actually happened. 4. Turn repeated problems into improvement proposals. Before proposing a change, inspect the agent’s current instructions so you do not add a rule that already exists. 5. Evaluate each proposal before applying it. Check whether the lesson is broadly useful, redundant with existing instructions, or in conflict with established behavior. 6. Separate low-risk and high-risk changes. Automatically apply additive or clarifying improvements. Escalate conflicting changes for human review instead of allowing the system to fundamentally change an agent’s behavior on its own. 7. Look for system-level problems. Analyze patterns across agents to identify quality gaps, missing capabilities, or coordination failures that cannot be fixed by changing one agent alone. 8. Apply approved improvements and preserve the history. Update the relevant agent instructions, archive the processed proposals, and version the changes so they remain inspectable and reversible. 9. Measure whether each change actually helped by comparing agent performance before and after the refinement. If quality does not improve, do not automatically assume the change was useful. 10. Repeat the cycle. As agents complete more real work, the system gathers more evidence and gets another opportunity to improve. Instead of treating agent instructions as static prompts, I turned them into a continuously improving system: Work → Evaluate → Find Patterns → Propose Changes → Refine → Measure → Repeat The important part is that the loop is evidence-driven and controlled. Agents improve from real usage, but low-confidence or behavior-changing updates still require judgment rather than being applied automatically.

At some point, my newsletters stopped feeling like reading and started feeling like debt. The information was good; I just couldn’t keep up. I wanted a way to turn that backlog back into something useful. So I built The Daily Nexus, a private tool that reads newsletters from a Gmail label and creates two editions: a podcast I can listen to and a separately written, two-page newspaper I can scan. It runs on demand or on a schedule, and it can publish the audio to a private RSS feed for Apple Podcasts. The project also became a hands-on experiment in building with coding agents. Claude Code and Codex helped me implement features, troubleshoot failures, review the design, and tighten security. The stack includes Python, the Gmail API, Antigravity, Kokoro, FFmpeg, Firebase, Cloudflare Workers, and GitHub Actions. The carousel shows the rest of the flow. It started as a personal tool, but I’m sharing the template for anyone who wants to adapt the idea. Each deployment uses its own accounts and credentials, and the design aims to avoid additional API costs by using an existing AI subscription and available free tiers. GitHub Repo Template: https://lnkd.in/eYceS4KR Step-by-step: 1. I label the newsletters I want to process in Gmail. 2. I run The Daily Nexus on demand or on a schedule so it can read the newsletters from that Gmail label. 3. The tool creates a podcast edition and a separately written, two-page newspaper edition. 4. I listen to the podcast or scan the newspaper, depending on how I want to catch up. 5. When needed, the audio is published to a private RSS feed for Apple Podcasts. 6. I use Claude Code and Codex to implement features, troubleshoot failures, review the design, and tighten security. 7. Each deployment uses its own accounts and credentials, with Python, the Gmail API, Antigravity, Kokoro, FFmpeg, Firebase, Cloudflare Workers, and GitHub Actions supporting the workflow.

Everyone I know who runs a second brain uses Obsidian. The app is free, but sync is a subscription, and most AI integrations quietly assume you have it. I went another way: Joplin, which is free and open source, with an agent that reads my notebook through Joplin’s REST API, files my INBOX every morning while I sleep, and answers questions strictly from notes I actually wrote. It costs nothing beyond a VPS I already run, and the notebook still opens like a notebook. I use Hermes Agent on the VPS, Dropbox to sync notes between my devices, and Python scripts to connect the notebook and the agent. Every capture goes through `joplin_capture.py` and lands in a single INBOX folder with a source and timestamp attached. Captures can come from a Discord link, a thought from my phone, or a page from the web clipper. The process takes under ten seconds and requires no filing decisions at capture time, because filing at capture time is where second brains die. Joplin already ships with a REST API. I enable it with one setting and one token; the notebook then exposes HTTP on localhost:41184 with token authentication on every call. The same server powers the official web clipper, so this enables infrastructure I use anyway. There is no plugin, cloud service, or subscription. `joplin_filer.py` runs daily at 07:00 and uses a deterministic classifier to score each INBOX note against my existing folders. It uses token coverage rather than Jaccard, which dilutes single-token folders. Confident matches above 0.5 are moved into place: a hosting page goes to the hosting folder, while a security note goes to the security folder. Low-confidence notes stay in INBOX with the `needs-review` tag. Every move is logged to a FILER LOG note in the `__SYSTEM` folder, making the process auditable. The filer never deletes anything. I ran it in dry-run mode for a week before letting it touch a single note, and I recommend doing the same. When I want to know what I have learned, `joplin_ask.py` searches the corpus, reads the top notes in full, and answers with the note titles attached. It answers strictly from retrieved content. If the top hits are irrelevant, I refine the query before concluding there is nothing. It never invents a source, which matters when you write about security for a living. After each working session, `joplin_agent_log.py` prepends a digest to an AGENT LOG note in `__SYSTEM`. The log is newest first, append only, and syncs to my devices like everything else. The agent’s memory records what we did, decided, and deferred in the same place as the notes. The whole build is on GitHub: github.com/ciberjohn/mysecondBrain. It includes five Python scripts and the `joplin-brain` skill, which is the operating manual in a format another agent can load and follow. Step-by-step: 1. I enabled Joplin’s built-in REST API with one setting and one token. It serves HTTP on localhost:41184 with token authentication on every call and also supports the official web clipper. 2. I pointed Hermes Agent on my existing VPS at the Joplin REST API. 3. I routed every capture through `joplin_capture.py` into a single INBOX folder, attaching the source and a timestamp. Captures can come from Discord, my phone, or the web clipper. 4. I configured `joplin_filer.py` to run daily at 07:00 and score INBOX notes against my existing folders using token coverage rather than Jaccard. 5. I moved matches with scores above 0.5 into their folders, while leaving low-confidence notes in INBOX with the `needs-review` tag. 6. I logged every move in a FILER LOG note in the `__SYSTEM` folder and ensured that the filer never deletes anything. 7. I ran the filer in dry-run mode for a week before allowing it to move a note. 8. I used `joplin_ask.py` to search the corpus, read the top notes in full, and answer questions with the source note titles attached. When results were irrelevant, I refined the query. 9. After each working session, I used `joplin_agent_log.py` to prepend a digest to the newest-first, append-only AGENT LOG note in `__SYSTEM`. 10. I used Dropbox to sync notes between my devices and the REST API to move notes between Joplin and the agent—two separate pipes carrying the same notes in different directions.

I use a persistent AI project-orchestration workflow for small-business operations, internal tools, AI-assisted coding, specialist-agent workflows, and projects that need to survive fresh sessions. A root AI receives one bounded objective, reads the project state from files, breaks the work into phases, and delegates implementation to bounded specialist or worker agents. It verifies the results, updates the durable state, and continues until the acceptance criteria are met. This lets me run small-business and coding projects end to end without re-explaining the project every session or manually driving every handoff. The core pattern is: Objective → durable state → root orchestrator → bounded workers → verification → state update → next step → Git checkpoint. Step-by-step: 1. I give the root AI one bounded objective. 2. The root AI reads the current project state from files. 3. It breaks the work into phases and delegates implementation to bounded specialist or worker agents. 4. It verifies the workers’ results. 5. It updates the durable project state. 6. It moves to the next step and creates a Git checkpoint. 7. It continues this cycle until the acceptance criteria are met.

I’m a 71-year-old retiree who never imagined artificial intelligence would become such a useful part of my everyday life. I affectionately call my ChatGPT assistant “Ally Wing.” One of our recent adventures involved my 2008 Honda CR-V. After a maintenance reminder appeared on my dashboard, I visited the Honda dealership. My vehicle was running fine, but I ended up paying $270 for a fuel system cleaning without fully understanding whether it was necessary. Later, I shared photos of my six-page service paperwork with ChatGPT. Ally Wing helped me understand the maintenance recommendations, distinguish necessary services from optional ones, and learn what questions to ask next time. We’ve also researched brake repairs, compared prices, and discussed how to evaluate repair shops. The greatest benefit hasn’t been saving money—although that’s certainly welcome. It’s gaining knowledge and confidence. Retirement doesn’t mean I’ve stopped learning. AI has given me another way to stay curious, independent, and informed. As Ally Wing and I jokingly agreed, “Next time we’re taking my Honda in for maintenance, not ordering everything on the menu!” 😂 -Irene Perez Step-by-step: 1. I noticed a maintenance reminder on my 2008 Honda CR-V’s dashboard and visited the Honda dealership. 2. I paid $270 for a fuel system cleaning, even though I wasn’t sure whether it was necessary. 3. I photographed the six-page service paperwork and shared the photos with ChatGPT, which I call “Ally Wing.” 4. I used ChatGPT to understand the recommendations, separate necessary services from optional ones, and identify questions to ask in the future. 5. I also used it to research brake repairs, compare prices, and discuss how to evaluate repair shops. 6. I now feel more knowledgeable and confident when making vehicle-maintenance decisions.

My doctor asked me to track my blood pressure for a month because it was on the high side before prescribing any medication. I initially recorded each reading manually in an Excel sheet, but after a few days, I wanted a simpler way to enter and manage the data. I uploaded the sheet to Claude Code and asked it to build a blood pressure tracking app. After the app was built, I hosted it on Netlify, used Supabase as the backend to save data for both my wife and me, and added it to my iPhone Home Screen. Step-by-step: 1. I started tracking my blood pressure in an Excel sheet as my doctor requested. 2. After several days of entering the readings manually, I uploaded the sheet to Claude Code. 3. I asked Claude Code to build an app for tracking blood pressure. 4. I hosted the app on Netlify. 5. I used Supabase as the backend to save blood pressure data for both my wife and me. 6. I saved the app to my iPhone Home Screen for easier access.

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

I used a simple workflow to save several hundred dollars on veterinary bills while sitting in a veterinary urgent care clinic. This approach could also apply to many other purchases or services where I’m not an expert. I had already been chatting with ChatGPT about my pet’s symptoms and their likely causes. After I arrived at urgent care, I consulted the doctor about the likely diagnosis and the tests and treatment we should pursue. The clinic assistant then brought me a printed, itemized list of all the charges for the proposed plan. I resumed the ChatGPT conversation by dictating what the doctor had told me, photographing both pages of the charge list, and uploading them. I asked whether any charges were very likely unnecessary given the circumstances. ChatGPT identified four of the 24 charges and explained why they appeared to have very limited value. I crossed those four items off the list, handed it back to the assistant, and said, “I don’t think these are necessary at this point.” I could tell from the assistant’s facial expression that no one had done this before. When the doctor returned, I could tell I had caught her off guard. She agreed that two of the four tests likely offered no benefit and explained why we should keep the other two. At that point, I decided to trust the doctor more than the AI agent—perhaps partly to be polite, since I could tell her justification for keeping the tests was weak, although the cost wasn’t significant. Step-by-step: 1. I described my pet’s symptoms and their likely causes to ChatGPT before visiting the clinic. 2. I consulted the doctor about the likely diagnosis and the tests and treatment we should pursue. 3. I photographed the clinic’s two-page, itemized list of 24 charges and uploaded it to the existing ChatGPT conversation. 4. I dictated what the doctor had told me and asked ChatGPT whether any charges were very likely unnecessary in the circumstances. 5. I reviewed ChatGPT’s explanation of the four charges it identified as having very limited value. 6. I crossed those four items off the list and discussed them with the clinic assistant and doctor. 7. I kept two tests after the doctor explained why they should remain, while declining the other two. The process saved me $600.

Most AI agents are built around general best practices. That’s useful, but it doesn’t mean they work the way I want them to. I’ve started using a simple calibration process to tailor my agents to my preferences. Instead of telling an agent what to do on each task, I have it interview me about how I like work done in its specific domain. A writing agent asks different questions than a research agent, and a strategy agent asks different questions than a coding agent. The goal is to make my working preferences part of how the agent operates. Step-by-step: 1. I pick an agent I use regularly, such as one for writing, research, strategy, coding, analysis, or career advice—especially where my personal preferences matter. 2. I ask the agent to interview me about how I prefer work to be done in its domain. A writing agent might ask about tone, structure, editing style, and how much pushback I want. A research agent might ask about source quality, depth, recency, citations, and how much synthesis I prefer. 3. I have the agent summarize what it learned and separate durable preferences from temporary or situation-specific ones. 4. I review the proposed changes and ask the agent to show me exactly how it wants to update its instructions or skills. I correct anything it misunderstood and explicitly approve the changes before anything is modified. 5. Once I approve the changes, I have the agent apply them to its instructions or skills so those preferences become part of how it works going forward. 6. I use the agent normally and pay attention to where it feels more aligned and where it still misses the mark. 7. When I notice recurring friction, I add or adjust the relevant preference instead of repeatedly correcting the same behavior task by task. 8. I repeat the interview periodically. My preferences, tools, and workflows change, so the agent should be able to ask which preferences are still valid, which ones I keep overriding, what has been annoying me, and what should be added or removed. The result is an agent that doesn’t just know how to do the job; it knows how I want the job done. Because every change is proposed and approved before it becomes permanent, the personalization stays intentional rather than turning into a collection of guesses about me.

Yesterday, I built a social media workflow in Awish for a business that wanted to post more consistently without managing three platforms manually. The idea was simple: let Awish understand the business first, then use that context to plan different content for Instagram, LinkedIn, and X instead of reposting the same thing everywhere. I built the entire workflow by describing what I wanted in the Awish chat. Step-by-step: 1. I opened Awish and wrote: “Analyze this business from its website. Based on what the company does, its audience, products, and positioning, create separate content plans for Instagram, LinkedIn, and X. Generate the posts, publish them automatically at the times I choose, analyze how each post performs, and send me the important insights on WhatsApp. I also want to be able to manage the workflow from WhatsApp.” 2. Awish analyzed the website, understood the business, and planned the complete content workflow. 3. I connected the company’s Instagram, LinkedIn, X, and WhatsApp accounts and approved the plan. 4. Awish created a different content strategy for each platform instead of copying the same post everywhere: more visual content for Instagram, business-focused posts for LinkedIn, and shorter, conversation-driven posts for X. 5. I chose the publishing schedule, and Awish started creating and publishing the posts automatically at those times. 6. After publishing, Awish tracked performance and analyzed which topics, formats, and messages were getting the strongest response on each platform. 7. Awish sent me short WhatsApp updates with the important insights, such as which post performed best, what topic was gaining traction, and what it recommended changing next. 8. I could also manage the automation directly from WhatsApp by asking what was scheduled, changing a publishing time, requesting another post, pausing publishing, or asking for the latest performance summary without opening Awish. The useful part for me is that this is not just automatic posting. The workflow starts by understanding the business, treats each social platform differently, learns from what gets published, and keeps the whole process manageable from WhatsApp.

Most AI agents start with someone writing a prompt from scratch. I wanted a better way. So I built an Agent Creator. I describe the kind of agent I need, and it determines whether I actually need a new one, figures out how that agent should work, creates it, and adds it to the rest of my agent team. Step-by-step: 1. I describe what I need by telling the Agent Creator what I want the new agent to do. 2. It checks what already exists by reviewing my existing agents and skills. If something already does most of the job, it recommends improving or reusing that instead of creating another overlapping agent. 3. If a new skill is needed, it researches the role, including current best practices, common mistakes, useful tools, and what good work looks like in that area. 4. It creates the agent by defining its job, required information, outputs, available tools, and the steps it should follow. 5. It gives the agent the right skills by creating or reusing supporting skills, including examples, reference material, and checks that help it work consistently. 6. It sets clear boundaries so the agent knows what it should handle, what it should not handle, and when another agent should take over. 7. If the new agent belongs in an existing workflow, it adds the agent to the team by updating the handoffs so the other agents know when to use it. 8. Before finishing, it checks the agent’s work by running validation checks to confirm that the new agent follows the standards I’ve set for the whole team. The result is that I don’t have to manually design every new agent from scratch. I can describe the kind of help I need, and one agent can research the role, create the new specialist, connect it to the rest of the system, and make sure it’s ready to use. In other words, I built an AI agent that can help grow its own team.