Workflow Hub

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.

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’ve been experimenting with agentic coding for quite some time, and I’ve noticed that the tasks I let the agent handle keep getting bigger. For larger tasks and projects, I gradually moved to a standard workflow, which I published at https://github.com/evermeer/CodingAgentOrchestration in part 2 of the tutorial. I use this workflow professionally and in my side projects. My most recent side project is Quadrim, a Four in a row game played in a 4×4×4 cube. I made it open source and included all the prompts for both the code and the artwork: https://github.com/evermeer/Quadrim It took me about eight working days to publish the first version to the app stores. Step-by-step: 1. I start by describing the idea. 2. I brainstorm the idea with the agent. 3. I use `to-spec` to create a specification document for the idea. 4. I use `to-ticket` to create independent, executable tasks. 5. I review the specifications and tickets from the perspectives of a senior software engineer, architect, security officer, and product manager. 6. I implement one ticket at a time. 7. I code-review the generated implementation for each ticket. During the pre-implementation steps, I always add this instruction to my prompt: “Ask clarifying questions until any ambiguities are resolved.” Extra fine-tuning of the idea, specifications, or plan pays off during implementation. When I let the agent build code, I ask it to use TDD, perform a code review at the end, and resolve the major and critical findings.

I built a workflow that turned a single plain-English idea into a live, 24/7 crypto trading bot without being a developer. Claude handled the engineering; I made the decisions. Step-by-step: 1. I gave Claude the goal rather than detailed instructions. My first message was roughly: "Create me a trading bot that runs 24/7, makes faster decisions than a human, takes calculated risks, picks the lowest-fee platform, and has a dashboard with profit graphs. Make it your own." Claude designed the whole system and named it Kestrel. 2. Claude explained the setup options, including exchanges versus on-chain trading, laptop versus cloud hosting, and minimum funds. I chose BNB Chain and PancakeSwap, using a brand-new MetaMask wallet dedicated to the bot so it can never touch my other funds. 3. I let Claude build and test the bot. It wrote the strategy—holding good coins in healthy markets and moving to stablecoins in bear markets—along with hard safety limits, including a daily loss cap, emergency brake, and trailing stops. It also built cheapest-route swap selection and automated tests. When the backtests did not clear the bar we had agreed on, Claude told me honestly instead of curve-fitting. 4. Claude walked me through deploying the bot by renting a cloud server, running it in Docker, and locking the server down with Tailscale and a firewall so nothing was exposed to the internet. I only copied commands and sent screenshots when I got stuck. 5. I went live with a small amount and used a private phone dashboard showing the balance, trades, the bot’s reasoning, and Pause and Sell-everything buttons. 6. I kept improving the system through conversation. I added a “strategy league,” where 10 strategies trade on paper and can be promoted only with my approval, along with self-healing, backups, and one-tap sharing of wins and losses to X. My biggest lesson was to talk to Claude like a capable coworker: give it the goal, make the key calls yourself, and ask it to be honest about the risks.

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.

I built Lumi, an HR assistant in French, with Claude Code in about two hours. It was an experiment: could Claude Code build a working product from a plain brief while being left completely alone? Employees ask questions, and Lumi answers using their company’s own HR documents. Each company has its own space, and HR can see which questions the documents couldn’t answer. Step-by-step: 1. I set up one window with Claude Code on one side and the files appearing on the other. I didn’t write code, but I could always see what was being built. 2. I described the product in plain language. I dictated my brief out loud, typos included: who pays, who uses it, the problem, a demo client, keeping clients separate, the admin view, the language, and the price. 3. I let Claude Code build the product and make every call. Thirty-four minutes later, the first version had 47 files and 3,949 lines. It even invented a fictional client company with a full HR handbook so I could demo it immediately. 4. I put the product online. Claude Code wrote a setup guide for Supabase and Vercel. I followed it one step at a time and sent a screenshot whenever something broke. 5. I improved it with feedback. I told Claude Code that the design looked like it had been created by a junior designer. Eighteen minutes later, it came back with a name, a design system, pricing plans, and everything in French. 6. I checked security, although I had skipped this during the build. When I asked for a full security review eleven weeks later, it took less than six minutes and found three serious problems, including a database function that allowed anyone to read a company’s documents. Claude Code fixed all three. Run `/security-review` before sharing the link and before each new change. The full write-up, including the unedited prompts: https://www.theaithinker.com/p/how-to-build-a-saas-product-with

I used Claude Code to build a 13-agent workforce for generating micro-courses. Each agent has its own job description and a defined role in the workflow, which begins with document analysis and ends with a course package agent delivering a complete, interactive HTML prototype as a local file. The agentic workforce creates knowledge-check quizzes with corrective feedback. Each micro-course also includes a downloadable handout highlighting the main points. In my case, a human course builder receives the final interactive HTML prototype and uses it to update our organization’s course catalogue. The HTML file is available for everyone to use as well. This reduced the production time from three months to two hours at most. I also included a security gate that redacts information from transcripts used to create course content. I’m happy to share more—we’re talking about folders and files here. Step-by-step: 1. I used Claude Code to build a 13-agent workforce for generating micro-courses. 2. I gave each agent its own job description and defined workflow. 3. I started the workflow with document analysis before the work begins. 4. I used a course package agent to deliver a complete, interactive HTML prototype as a local file. 5. I had the workforce create knowledge-check quizzes with corrective feedback. 6. I included a downloadable handout with highlights at the end of each micro-course. 7. I sent the final interactive HTML prototype to a human course builder, who updates our organization’s course catalogue from it. 8. I added a security gate to redact information from transcripts used for course content. 9. I made the HTML file available for everyone to use.

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.

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.

I build an office platform for small nonprofits, and every week users ask how to do something. I also keep changing features they have already learned, so written instructions go stale quickly. Screen recordings take an afternoon each and can be out of date by Friday. I use Claude Code in my project to turn each user question into both a software change and a how-to video. The video runs against a throwaway copy of the app filled with a made-up organization, so no real data appears on screen. It performs the task as a person would—clicking, typing, and waiting—while displaying captions one step at a time and moving a yellow pointer to each button before clicking it. There is no voice. I tried narration but dropped it because captions can be paused and read, and they never mispronounce anything. The important part is that the script also tests what it films. After each step, it confirms that the screen did what the caption says and prints PASS or FAIL. If anything fails, there is no video yet; I fix the bug first. In one day, the videos found four real defects that our automated tests had missed, so the video is also the test. `ffmpeg` turns the recording into an MP4 and a poster image. I watch and approve the result, then publish it on our videos page and inside the app’s Help box, next to the instructions for that screen. When the screen changes, I run the same script again and get a new video in minutes. The first videos were too fast. I am not as fast as Claude, and the person watching is trying to learn something new. Now each caption stays on screen long enough to read—about 1.5 seconds plus a third of a second per word—before the next click. The workflow produced 35 how-to videos in five days, most of them one to three minutes long. The checking in step 4 started on day four, after the videos kept finding problems. Every video since then has checked itself. Step-by-step: 1. I take a user’s email question or request and use Claude Code in my project to make the requested software change. 2. In the same session, I have Claude write a short script for a how-to video of the task. 3. The script starts a throwaway copy of the app, fills it with a made-up organization, and performs the task by clicking, typing, and waiting. 4. The script displays captions one step at a time and moves a yellow pointer to each button before clicking it. I use captions instead of narration so viewers can pause and read them without hearing mispronunciations. 5. After each step, the script confirms that the screen did what the caption says and prints PASS or FAIL. If anything fails, I fix the bug before producing the video. 6. I use `ffmpeg` to create an MP4 and a poster image from the recording. 7. I watch and approve the video, then publish it on our videos page and in the app’s Help box next to the relevant screen instructions. 8. When the screen changes, I run the same script again to create an updated video in minutes. 9. I keep each caption on screen for about 1.5 seconds plus a third of a second per word before the next click.

I built a system that reads my AI newsletters every morning and turns them into a searchable catalog of AI tools, plus a chat website where I can ask questions about the catalog in plain English. The system has two parts: a workflow that collects the information and a website that answers questions about it. I subscribe to several AI newsletters, and each issue mentions five or ten interesting tools. I would read about one and think, “I should remember that.” Months later, I would vaguely remember it but have no quick way to find it. I wanted a repository of these AI tools that I could search easily. The collector is a scheduled Claude Code Routine that runs once a day. It searches Gmail for newsletters from the last 24 hours and reads each email in full. It extracts every AI tool’s name, description, category, official link if present, and source newsletter. It skips non-AI items and pure ads but keeps sponsors that are genuine tools. Before adding anything, it checks for duplicates. New tools are added under the appropriate category in alphabetical order. If an existing tool has fresh details, its description and “last updated” date are refreshed. Tools mentioned by three or more sources receive a “Highly Mentioned” tag, which is a useful signal for what is catching on. The workflow also creates categories when new tools do not fit into an existing one. The workflow commits and pushes the catalog to a private GitHub repository, then posts a summary to Slack. The catalog is a single Markdown file—plain text, human-readable, and versioned in Git, with no database. The chat website displays the tool count, category count, and last-updated date, along with clickable example questions. If I ask, “Is there anything for voice AI?” it returns a written answer listing every match with descriptions and working links. The site is a React single-page app on Netlify with two small backend functions: one returns the statistics, and the other handles chat. When I ask a question, the backend fetches the Markdown file from the private repository, sends it to Claude along with my question, and returns the answer. To recreate it, you’ll need a GitHub account, Netlify (the free tier is fine), an Anthropic API key, and Claude Code. The routine prompt is the most important part. It names the exact newsletters, lists the fields to extract, and explicitly says: never invent a URL, never delete an entry, and only add or update. Vague instructions produce files that degrade over time. I learned a few things the hard way. Newsletters deleted before the workflow runs may cause it to report “nothing new,” so the logic should also check Trash or Deleted items. Tokens expire, and mine quietly expired, which caused the search site to stop working. Choose a long expiration period and record the date. Also, explicitly say “never invent a URL,” or the workflow may produce plausible links that go nowhere. It now runs every morning without me. When I need something, I ask a question and get an answer in seconds instead of trying to remember which newsletter, and which month, mentioned the tool I’m thinking of. Step-by-step: 1. I created a private GitHub repository with a starter Markdown file containing “Last updated” and “Total tools” fields, category headings, and consistent fields for each tool. 2. I wrote a Claude Code Routine prompt that names the newsletters, specifies the fields to extract, and instructs the workflow never to invent a URL, never to delete an entry, and only to add or update tools. 3. I scheduled the routine to run daily with Gmail access. 4. Each day, the routine searches Gmail for newsletters from the previous 24 hours, reads them, extracts AI tools, skips non-AI items and pure ads, preserves genuine tool sponsors, and checks Trash or Deleted items when necessary. 5. The routine checks for duplicates, adds new tools alphabetically under the right category, updates existing tools with fresh details, creates categories when needed, and applies the “Highly Mentioned” tag to tools found in at least three sources. 6. The routine commits and pushes the Markdown catalog to the private GitHub repository and posts a summary to Slack. 7. I built the frontend with Vite and React, including a statistics header, a scrollable message list, an input box, and example questions. 8. I added two backend functions: one for statistics and one for chat, with the GitHub fetch handled by a shared helper with a short cache. 9. I created a fine-grained, read-only GitHub token limited to the single repository. 10. I deployed the site to Netlify with the required keys stored as environment variables rather than in the code. 11. When I ask a question, the backend fetches the Markdown catalog, sends it to Claude with my question, and returns the matching tools, descriptions, and links.

I read the news every day, but it had become increasingly depressing and was making me miserable. What bothered me most was that it also felt inaccurate: although bad things are happening, there have been many positive developments over the past five years that rarely receive sustained coverage. Major news sites might publish an article or two about them, but those stories are quickly buried under negativity. I wanted a way to get only positive news stories in my feed each day. Keyword filters did not work: “record” and “breakthrough” also appear in stories about record wildfire seasons, while “war” can appear in “war ends.” Off-the-shelf sentiment analysis was not useful either. A happy press release about layoffs can be classified as positive, while a dry factual story about a disease being eliminated may be classified as neutral. So I trained a basic artificial version of my personality using a series of prompts about what I consider positive in the world. I connected it to Mistral through OpenRouter and gave it access to public RSS feeds from news sites I already trusted. This eventually became Rally News, which I published on Google Play. iOS has been more difficult. The app surfaces positive stories from more than 20 news sites in an endless scroll, giving me an alternative to my uncomfortable TikTok addiction. Because I made it public, I decided not to host article text: publishers keep their traffic and revenue, while the tool remains ethical. The system runs on a GitHub Actions cron job that pushes stories to a PHP and MySQL database. I built the app without coding experience for about $25 per month. Step-by-step: 1. I collected RSS feeds from established publishers I already trusted and stored the list as configuration. I started with about 10 feeds instead of a few hundred so I could realistically read the output. 2. I set up a scheduled GitHub Actions cron job to run a Python script that pulls new items from every feed. 3. I deduplicated incoming articles against the database using the URL and a normalized title. Syndicated stories frequently reappear under slightly different URLs, and I did not want to pay to evaluate the same article twice. 4. I wrote the filter prompt as a long persona document rather than a one-line instruction. It explains what I consider progress, what I consider a puff piece, and which cases should fail—for example, celebrity news is not good news, a company announcing an intention is not the same as taking action, and a local feel-good story without wider significance does not qualify. 5. I sent each new article to an LLM through OpenRouter and required JSON output containing a pass-or-fail decision and a short justification. 6. For the first few weeks, I read the justifications every day. Whenever I disagreed with the model, I added a new rule to the persona document. That review loop required nearly all of the actual work. 7. I wrote passing articles to MySQL with only the headline, source, link, and metadata, leaving the article body with the publisher. 8. I pointed the website and mobile app to the same database. 9. I added a second GitHub Actions job that assembles a daily newsletter from the same data through Brevo, allowing one evaluation pass to feed three surfaces.

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.

I’m 71 years old, retired from owning a large cattle-feeding operation, and fairly new to AI and software development. I’ve discovered that I really enjoy using AI to build practical tools in Replit. My latest project is an app for our church to help us oversee a $13.5 million renovation of a 65,000-square-foot former movie theater into our new church facility. I’m not a programmer or a construction expert, so I’m using AI to help bridge both gaps. I built the app almost entirely by describing in plain English what I wanted it to do, testing what it built, and working back and forth with AI to improve it. The app uses AI to read meeting notes, emails, texts, and general project updates and identify decisions, action items, important dates, budget changes, and project events. Nothing is accepted automatically. I review, edit, approve, or reject what AI finds before it becomes part of the project record. The app also keeps our budgets, documents, meetings, and project history together. My goal isn’t to replace our project manager or construction software. I want to see whether someone my age, with no programming or construction background, can use AI to build a useful tool for helping an owner understand and manage a complicated real-world project. Step-by-step: 1. I described in plain English what I wanted the app to do. 2. I used AI in Replit to build the app based on those descriptions. 3. I tested what AI built and worked back and forth with it to improve the app. 4. I designed the app to read meeting notes, emails, texts, and general project updates. 5. I use it to identify decisions, action items, important dates, budget changes, and project events. 6. I review, edit, approve, or reject every item before it becomes part of the project record. 7. I use the app to keep our budgets, documents, meetings, and project history together.

Content Repurposing System: one transcript into 4 platform-ready posts in 18 seconds. THE PROBLEM Every video cost me two hours turning it into posts for Twitter/X, LinkedIn, Skool and Instagram. The writing wasn't hard. The context switching was. Four platforms, four tones, the same idea rewritten four times. Built during the Skool x Hostinger n8n hackathon, Dec 2025. Still my daily workflow. STACK: n8n on a Hostinger VPS, OpenAI, Google Sheets. 13 nodes. HOW TO BUILD IT Manual Trigger. Swap for a Form or Drive trigger if you want it hands-off. Set node "Set Transcript", one string field: transcript. Leave a real sample transcript in the default value so anyone can hit execute and see output immediately. IF node "Check Transcript", two conditions with AND: transcript is not empty, and {{ $json.transcript.length }} > 50. False branch goes to a Stop and Error node. Four minutes of work. It's why I've never burned 5 API calls on a blank field. OpenAI node "Analyze Content", model gpt-5.4-mini, Simplify Output OFF: You are a content analyst. Analyze this video transcript and extract: Main topic/theme 3-5 key insights or takeaways Target audience Tone (educational, motivational, technical, etc.) Any specific examples, statistics, or stories mentioned Transcript: {{ $json.transcript }} Provide your analysis in a structured format. I don't send the transcript to four writers. I send it to one analyst first, and all four writers read that analysis. This lifted quality more than any prompt tweak: the posts share one reading of the material instead of each model guessing. The stronger model goes here for the same reason. Wrong analysis, four wrong posts. 5-8. Four generators, all gpt-4o-mini, Simplify Output OFF, all wired from Analyze Content's single output. Each pulls the same two inputs: Content Analysis: {{ $('Analyze Content').item.json.choices[0].message.content }} Original Transcript: {{ $('Set Transcript').item.json.transcript }} Then its own rules. Twitter (temp 0.8): hard hook, under 280 chars, one insight, no hashtags. LinkedIn (0.7): 150-250 words, 2-3 line paragraphs, ends on a question, no hashtags. Skool (0.8): 100-200 words, always a numbered list of actionable takeaways, ends by inviting replies. Instagram (0.8): 125-175 words, 5-8 hashtags, plus a detailed "Visual suggestion:" for a designer or image model. LinkedIn needed a tone block after v1 read like a press release: talk like you're with a colleague over coffee, use I and you, never "leverage", "in today's landscape", "fast-paced". Naming banned words works. "Write conversationally" does nothing. Merge node "Collect All Posts", 4 inputs, one generator per index. Aggregate node, mode All Item Data. Puts all four posts on one row instead of four. Code node "Format Output". Reads each generator by node name, each in its own try/catch, so one failure still writes a row. Builds a readable timestamp, a 100-character transcript_preview, and status: 'Generated'. Google Sheets, Append Row, Map Automatically. THE SHEET Seven columns, headers in row 1, named to match the Code node exactly: timestamp, transcript_preview, twitter_post, linkedin_post, skool_post, instagram_post, status. Status is a dropdown: Generated > Reviewed > Scheduled > Published. The system drafts, I decide. FOUR THINGS THAT COST ME HOURS Turn Simplify Output OFF on every OpenAI node. Every expression reads choices[0].message.content, which only exists in the raw response. Leave Simplify on and you get four empty columns with no error explaining why. No title row above your headers. I had a merged title in row 1, headers in row 2. Map Automatically stopped seeing my columns and silently built duplicates beside them. Extend data validation down the whole column (G2:G1000, not G2). I set the dropdown on one cell and every appended row arrived as plain text. Kill markdown in the prompt, not after. I wasted an evening regex-stripping ** in the Code node. The fix was upstream: tell Skool and Instagram plain text only, CAPITALS or "quotes" for emphasis. Zero artefacts since. Post-processing cleanup means your prompt is underspecified. RESULT Two hours per piece became 18 seconds of runtime plus 5-10 minutes of review. I tested 20 transcripts across five content types (tutorial, interview, news, explainer, motivational). Most were publishable with light edits. The failure mode never changed: rambling transcript, vague analysis, four vague posts. Which is exactly why the analyst node gets the better model. Budget 30 minutes to rebuild. The prompts are the product. Copy the structure, then rewrite the platform rules in your own voice. That's what decides whether it sounds like you or like everyone else.

I've been thinking about the value of handoff documents and explanatory documents as we continue exploring efficient ways to work alongside AI to build software and improve communication. Even though we use many different tools, Markdown still has an important place. This new version of an HTML handoff document can document what exists, describe what could exist, or serve as a mockup for a brainstorm. It lets us communicate with remarkable fidelity through visuals, hierarchy, and formatting. It's also an efficient format for AI to understand. We shouldn't underestimate the significance of AI communicating with us through a visual medium. A visual flowchart with thoughtful design, layout, animation, and progressive disclosure can help us understand the logic and flow of incredibly complex systems much faster. I tried all kinds of tools, including React Flow and Mermaid. They're fun to experiment with, but Archify is a game changer for this use case. I can point it at any technology, repository, or brainstorm and work with it to build flowcharts with animations and clean, distinctive design. It's also completely free. https://tt-a1i.github.io/archify/# Step-by-step: 1. I identify whether I need to document what exists, explore what could exist, or mock up a brainstorm. 2. I use Markdown and an HTML handoff document to communicate the ideas with visuals, hierarchy, and formatting. 3. I consider tools such as React Flow and Mermaid for creating visual representations. 4. I point Archify at the relevant technology, repository, or brainstorm. 5. I work with Archify to develop a flowchart with animations, clean design, and progressive disclosure so the system's logic and flow are easier to understand.

I created a media player for Android Automotive OS—not to be confused with Android Auto. I had been using an old, unmaintained app that lacked several features I wanted in a music player. I used Claude Code to build a new app from scratch, test it in an emulator, and eventually publish it for internal testing through the Google Play Store. After working through several bugs, I now have version 3 running reliably enough for day-to-day use in my car. I plan to add a few more features before ultimately releasing it publicly for free on the Play Store. Step-by-step: 1. I pointed Claude Code to the unmaintained package and gave it the option of using that as a starting point or starting from scratch. Claude chose to start from scratch. 2. I described the additional features I wanted. Claude suggested using Kotlin and Gradle, which I endorsed. 3. Claude created an initial build and installed an emulator to run alongside it. I did all of this on an Omarchy installation. 4. The initial build was buggy, so Claude and I worked together to identify and fix the problems. Claude often used the emulator autonomously to investigate what was going wrong. 5. Once I had a functional prototype, I needed to install it in my car. Claude guided me through creating a Google developer account and handling the administrative requirements beyond the app itself, including a privacy policy. 6. After the developer account was set up, Claude packaged the app for upload. I uploaded it and marked it for internal testing, which allowed me to access the app through the Play Store in my car. 7. Claude and I worked through a few more bugs. We are now on version 3, and the app is functional for day-to-day use. We plan to add more features, with the ultimate goal of releasing it publicly for free on the Play Store.

I ask Claude every month or so to be my Claude Code learning coach by simply typing the /insights command. It provides a hyper-personalized website report card with advice to help me use Claude Code better, with exact examples of where things go wrong, features, and prompts I should try. Step-by-step: 1. I ran the /insights command in Claude Code to analyze how I had been using the tool. 2. I reviewed the personalized website report card it generated, especially the examples of where my workflow was breaking down. 3. I pulled out the recommended features, prompts, and habits that were most relevant to the mistakes I was making. 4. I practiced those recommendations in my normal projects instead of treating the report as generic advice. 5. I repeat the exercise every month or so to see what changed and what I should learn next.

I built a custom news agent that skips the Google News and Apple News walled gardens. Eight prompts turn Claude into a personal news editor that reads my trusted RSS feeds, scores every story with a decision model, and delivers a clean daily page for about a dime a month. Each week, pulling two or three good stories for my newsletter digest meant searching multiple sites by hand—hours of clicking and scrolling for a handful of usable links. RSS feeds already deliver that content; the missing piece was a judgment layer that could separate worthwhile stories from noise without the cost or latency of running everything through a full LLM. I used Claude Cowork, Jev from TypeSafe AI, Vercel AI Gateway, RSS feeds, Python, and SQLite. Jev is a decision model rather than a chatbot: it returns a probability and confidence score instead of prose, does not hallucinate facts, and scores a story in a fraction of a second. That makes an automated daily judgment call inexpensive enough to run continuously. Step-by-step: 1. I set up a Claude project to hold the scripts, taste guide, database, and page. 2. I defined the goal and sections, then had Claude interview me to create a short “taste guide” describing what counts as a good story. 3. I found and live-tested the RSS feed for each trusted source instead of guessing feed URLs. 4. I fetched all working feeds into a deduplicated SQLite database and logged failures. 5. I used Jev through Vercel AI Gateway to score every story: first filtering ads and promotions, then ranking stories by section against my taste guide. 6. I selected the winners for each section, with Jev identifying near-duplicate stories so they would not appear twice. 7. I generated one-line summaries and fact-checked them against the source so nothing was invented. 8. I rendered a simple HTML page and scheduled the entire workflow to run every morning. A few details matter. I used Cowork rather than a plain chat because several steps require Claude to work with files, run code, and access the network. I also created a Vercel account and AI Gateway API key manually before the scoring step. Finally, I saved everything to the Claude project instead of a local folder, which allows the morning run to happen in the cloud on its own schedule. Scoring costs roughly $0.10 per month with Jev, compared with a few dollars for a full LLM doing the same job. The workflow turns a two-hour weekly slog into a page that is ready every morning, with each link going directly to the original publisher rather than a Google or Apple aggregator. Full build walkthrough: onabetternote.substack.com/p/build-your-own-news-agent-with-claude — the Substack post includes the exact eight prompts to copy and paste, plus more detail on why a model like Jev matters for cost containment as agents become routine.