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

GeneTrust AI — Asistente Genético Virtual (AGV) es una plataforma tecnológica concebida bajo una arquitectura basada en evidencia (Evidence-First), asistida por IA y gobernada por humanos. Está diseñada para facilitar el acceso, la estructuración, la exploración, la clasificación, la priorización y la síntesis trazable de evidencia genética y biomédica. Su diseño busca prevenir riesgos críticos de la IA en biomedicina, como las alucinaciones, las referencias no resolubles, la pérdida de procedencia, el ocultamiento de contradicciones y la atribución indebida de autoridad clínica. Aplica operaciones aditivas y no destructivas: filtrar, clasificar o priorizar los datos nunca modifica ni reescribe la evidencia fuente original. Además, preserva la ambigüedad y los elementos no clasificables en lugar de forzar conclusiones artificiales. El stack tecnológico incluye React, TypeScript, Node.js y servicios en la nube. La plataforma integra un enfoque de múltiples proveedores y agentes de IA, con modelos generativos desacoplados, junto con una clasificación multidimensional de la evidencia mediante la abstracción de un Structured Decision Provider (SDP, Proveedor de Decisión Estructurada). Utiliza específicamente TypeSafe AI, con su modelo Jev, como proveedor de decisiones estructuradas bajo estrictas políticas de activación y gobernanza por dimensión. La IA y sus agentes asisten en la organización, exploración y síntesis de información compleja, pero no actúan como una autoridad diagnóstica ni determinan por sí mismos la verdad clínica. Sus salidas se manejan como inferencias computacionales controladas, separadas estrictamente de la evidencia fuente y sujetas a validación humana explícita. Step-by-step: 1. Accedo y estructuro la evidencia genética y biomédica dentro de una arquitectura basada en evidencia. 2. Exploro, clasifico y priorizo la información mediante operaciones aditivas y no destructivas, sin modificar ni reescribir la evidencia fuente original. 3. Mantengo la procedencia, las contradicciones, la ambigüedad y los elementos no clasificables, evitando forzar conclusiones artificiales. 4. Utilizo múltiples proveedores y agentes de IA, con modelos generativos desacoplados, para organizar, explorar y sintetizar la información compleja. 5. Aplico una clasificación multidimensional mediante la abstracción de un Structured Decision Provider (SDP), utilizando TypeSafe AI y su modelo Jev bajo políticas estrictas de activación y gobernanza por dimensión. 6. Trato las salidas de la IA como inferencias computacionales controladas, las separo de la evidencia fuente y requiero una validación humana explícita antes de utilizarlas.

I built three interconnected websites for the Solomon for Jesus ministry. The first, solomonforjesus.com, houses the shining jewel: an AI chatbot named Solomon. The second, solomonforjesus.net, is a ministry academy with four levels of instruction and 16 lessons per level. The third, solomonforjesus.net, is home to my book *Fingerprint of Reality* and other articles and essays. All three websites are still in development, but they are operating and publicly available. I use GitHub repositories for coding, Vercel for hosting, Cloudflare for domains, and Supabase for back-end security. Step-by-step: 1. I built three interconnected websites for the Solomon for Jesus ministry. 2. I used solomonforjesus.com for the Solomon AI chatbot. 3. I used solomonforjesus.net for the ministry academy, which contains four instructional levels with 16 lessons per level. 4. I used solomonforjesus.net for my book *Fingerprint of Reality* and other articles and essays. 5. I use GitHub repositories to code, Vercel to host, Cloudflare for domains, and Supabase for back-end security. 6. I keep all three websites operating and publicly available while they remain in development.

I built a workflow that prepares late invoice reminder emails for me. Our industry has tight margins, and our back end is rudimentary with limited capabilities, so sending these reminders was annoying, repetitive manual labor. I had Claude Cowork walk me through creating an agent that logs in every Monday night, checks our late AR, and compares the customer names against a Google Sheet list I created. It uses an email template I provided, adds the contact name from the Sheet, and includes each late invoice’s identifying number, amount, and due date. The agent puts the emails in my Drafts folder and emails me a report showing which customers were included, how much each one owes, and the totals. All I have to do is review the drafts, confirm everything looks good, and hit Send. This has saved me about an hour every Monday night of tedious, repetitive manual labor. Step-by-step: 1. I created a Google Sheet with the customer names and contact names. 2. I had Claude Cowork walk me through creating an agent that logs in every Monday night. 3. The agent checks our late AR and compares the customer names against the Google Sheet. 4. It uses my email template and adds the contact name, invoice identifying number, amount, and due date. 5. It places the completed emails in my Drafts folder. 6. It emails me a report listing the included customers, the amount for each, and the totals. 7. I review the drafts, confirm that everything looks good, and send them.

AI image prompting often starts online: search for a style, collect references, describe them, and generate. But your visual vocabulary can also begin in the physical world—a plant, a tile, a book cover, a strange facade, a piece of furniture, or a detail in a church. This workflow turns everyday discoveries into a personal prompt library. AI helps investigate and translate what catches my attention, while I decide what matters. Step-by-step: 1. When something catches my eye, I photograph it and record where I found it and why it interested me. I do not need to understand my attraction immediately. It might be, “This plant has fascinating leaves,” “Who is the writer quoted on this tile?” or “Is it the copper, its patina, or the reflected light that I like?” Attention comes before classification. 2. I ask AI to help identify unfamiliar materials, objects, plants, techniques, or historical connections. A tile might lead to a writer, a literary movement, typography, or metalworking techniques. I preserve the original context—including the location, date, material, maker if known, and my observations—and mark uncertain identifications as uncertain. 3. I separate each object from what makes it visually interesting. For example: - Source: Plant with folded leaves. Principle: Layered fan-like forms with radial repetition. - Source: Weathered copper plaque. Principle: Warm metallic surface, uneven oxidation, and shallow relief. - Source: Facade with irregular windows. Principle: Repeated vertical rhythm interrupted by asymmetry. - Source: Green and coral book cover. Principle: Muted green with a single warm coral accent. This lets me reuse the visual logic without copying the object. 4. I translate each visual principle into concise, reusable prompt fragments, such as: - “Fan-like folded forms with radial repetition” - “Aged copper with dark patina and shallow embossed texture” - “Regular architectural rhythm interrupted by one off-grid element” - “Muted green field with one warm coral accent” These descriptions give me more control than generic words such as “beautiful,” “organic,” or “vintage.” One object can produce multiple fragments related to typography, surface, colour, proportion, lighting, or composition. 5. I store the entries in a document, database, or tagged visual archive. Useful fields include the reference, photo, location, date, what caught my attention, identification and research notes, visual principle, prompt-ready fragment, tags, related references, and confidence. I tag entries by visual function, such as colour, material, texture, rhythm, lighting, or composition, and always preserve links to the original reference. 6. I connect discoveries that may share underlying principles. Folded leaves, pleated fabric, ribbed metal, and fan-shaped architecture might express similar structural rhythms. I ask AI which relationships are visually meaningful, which are superficial, and which could combine well. The library becomes a connected visual vocabulary rather than a collection of isolated images. 7. When creating an image, I select references according to what they contribute. For example, a plant can provide shape language, copper can provide surface and lighting, a facade can provide compositional rhythm, and a book cover can provide colour balance. I ask AI to explain each contribution and remove references without a clear purpose. The goal is not to place all four objects into one image, but to combine their visual principles into something new. 8. I keep collecting and refining. A walk, museum, garden, or café can introduce new references. I update entries when I discover better information and preserve personal reactions, even when the only explanation is, “I just really like this.” Repeated attraction can reveal a personal visual vocabulary I had not consciously recognised. The workflow is: Notice → Capture → Investigate → Extract visual principles → Translate → Store → Connect → Reuse → Refine. AI does not have to be where inspiration begins. The world can stay upstream. A plant can start a prompt. A tile can start a research trail. A material can become a lighting instruction. A facade can become a composition rule. A book cover can become a colour recipe. I notice. AI helps unpack, translate, and connect. The prompt library becomes the bridge between seeing something in the world and being able to use what I saw later.

I’m a nerd for deals, so I built a Personal Credit Card Optimizer in ChatGPT. I wanted a simpler way to figure out which store and card would save me the most money on any item I want to purchase. The workflow maintains a database of my credit and debit cards—recording their series, but not their exact numbers—along with their rewards, fees, and benefits. Whenever I want to buy something, I add a product link. It scans retailers for better prices, checks current bank offers against my specific cards, and compares instant discounts, cashback, reward points, and other benefits to determine where I should buy and which card will provide the most value. It’s now an ongoing skill in my ChatGPT project. No more manually checking a dozen bank offers or discovering at checkout that my card isn’t eligible. Step-by-step: 1. I add my credit and debit cards to a database by recording their series, rewards, fees, and benefits without entering their exact numbers. 2. When I want to purchase something, I provide a product link. 3. The workflow scans retailers for better prices on the product. 4. It checks current bank offers against my specific cards. 5. It compares instant discounts, cashback, reward points, and other benefits to determine the best retailer and card combination.

Today's Rundown reported that Anthropic spent the past year consulting religious scholars from different faiths to help shape Claude's morals. I use a different approach for Bible study, research, and writing Bible study books with Claude. I wrote a set of Bible study principles that Claude reads before any work begins and follows throughout the process. The main tenets are: - The Bible is the sole authority. No commentary, tradition, or scholar outranks the text. - Scripture interprets Scripture. When a passage is unclear, the answer comes from another passage, not from a theological system. - First ask what the text actually says before asking what it means. - Ask who is speaking, to whom, and under what circumstances. - Quote every verse word for word. Never paraphrase it. - Separate what the text states from what we infer, and say "I don't know" where the Bible is silent. The difference shows in the outcome. The books contain no man-made doctrines, denominational vocabulary, or creeds—only what the Bible says, with the passage shown for every claim. When a draft goes beyond the text, these principles catch it. My experience is that the moral standard an AI needs is already written down, and an AI can be held to it. The principles, along with 23 free books and studies, are available at noblemind.study. Step-by-step: 1. I wrote a set of Bible study principles for my own Bible study, research, and Bible study books. 2. I have Claude read the principles before any work begins. 3. I require Claude to follow the principles throughout the work. 4. I use the principles to keep claims grounded in the biblical text, quote verses word for word, and distinguish statements from inferences. 5. I review drafts for man-made doctrines, denominational vocabulary, creeds, and claims that go beyond the text.

Turn a collection of documents, reports, spreadsheets, and notes into an evidence-backed decision brief with ChatGPT. Instead of asking AI to simply summarize the information, this workflow makes it identify what matters, connect the evidence, compare it with historical context, explore scenarios, and highlight what should be considered before making a decision. Step-by-step: 1. I gather the information relevant to one decision, including reports, PDFs, spreadsheets, research, historical data, meeting notes, and existing analysis. I upload everything into ChatGPT. 2. I ask ChatGPT to understand the situation using this prompt: > “Analyze the information I provided and build a structured understanding of the situation. Identify the key entities, important facts, relationships, metrics, trends, assumptions, and constraints. Do not make recommendations yet.” This creates the context before jumping to conclusions. 3. I build an evidence brief by asking: > “Create an evidence brief. Separate verified facts, derived insights, assumptions, conflicting information, and missing information. For every important conclusion, identify the supporting source or evidence.” This gives me a clearer picture of what is known versus what is inferred. 4. I add historical context when it is available by asking: > “Compare the current situation with the historical information provided. Identify meaningful patterns, similarities, differences, and changes. Highlight which historical observations could be relevant to the current decision.” This turns historical data into context rather than simply another report. 5. I explore three scenarios by asking ChatGPT: > “Based on the evidence and historical context, evaluate three scenarios: upside, base case, and downside. For each scenario, identify the assumptions, key drivers, risks, likely impact, and evidence supporting the assessment.” The objective isn't to pretend the future can be predicted perfectly. It is to understand how the decision changes when assumptions change. 6. I generate the decision brief by asking: > “Create a concise decision brief containing: > > 1. Current situation > 2. Most important evidence > 3. Key insights > 4. Historical context > 5. Critical assumptions > 6. Key risks > 7. Scenario analysis > 8. Evidence gaps and uncertainties > 9. Questions that should be investigated > 10. Possible actions and their implications. > Do not make the final decision on my behalf.” This produces a structured decision brief instead of another AI-generated summary. 7. I review the brief and challenge its conclusions before making the decision. I ask follow-up questions such as: > “Which assumption has the greatest impact on this decision?” > “Show me the strongest evidence against the current conclusion.” > “What information would most likely change the recommendation?” The AI helps structure the decision, but I make the decision. The important shift is: Summarize the information → Understand the situation → Establish the evidence → Add historical context → Explore scenarios → Evaluate the decision This approach can be applied to almost any domain where decisions depend on complex and interconnected information. A property investment is one example. A business strategy, product decision, operational problem, financial analysis, research question, or engineering decision can follow the same pattern.

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.

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.

I'm not a professional developer, but I built Sujido, a live word puzzle, with multiple AI agents. For months, they gave me bloat, lost context, and slop, and neither I nor the models could untangle what had been decided or why. I eventually settled on two agents: one Claude instance that plans and reviews, and another that builds. I imposed rules on both, one failure at a time. None of these rules would surprise a professional engineering team, but nobody handed them to me. That's the key lesson I learned: agents won't bring the discipline for you. You have to impose it. When I showed the first game revision to strangers, their verdict was that the first half was "boring" and the second half was novel. It was hard news to hear about my baby, but I took the feedback to heart and cut the game in half. That required surgery on code tangled across both halves, followed by a rebuild under the rules below. Before the rebuild, a separate AI audit graded the codebase B−. Afterward, it graded it A−. The deployed site shrank by 97.5%, and every serious finding was fixed and locked in by an automated test. The models didn't change drastically, but my operating rules did. Step-by-step: 1. I wrote a constitution before the first prompt. The repo holds what every agent must read before working: `CLAUDE.md` files for the project as a whole and for each major part of the code, a collaboration protocol for how the agents and I work together, a spec for the core data format, and a decision log. The data format is changed there first and then in code. Nothing is remembered unless it is written down. That's my life as well. :) 2. I split the work by role, not by task. One Claude instance is the strategist: it writes briefs, reviews reports, and never commits code. Claude Code in VS Code is the builder: it executes the brief, writes the tests, reports back, and never releases. Neither agent can approve its own work. 3. I made every job start from a written brief, and I never edit briefs. Each brief is committed to the repo with an exact scope, such as "do X only, do not begin Y." If plans change, a dated amendment states what it supersedes. The builder may skip a risky item with a written reason; skipping is better than forcing it. 4. I used mock-ups with real data instead of descriptions. Anything I will look at gets a mock-up, and I approve it before any code is written. I learned this when a status report described only in words arrived on my phone formatted as a wall of text. The approved mock became the spec, and the tests pin the output to it. 5. I proved that every test could fail. No test is trusted until it has been run against deliberately broken code and caught the bug. A test suite that has never failed hasn't proven anything. 6. I verified reports against the real repo. Agent reports drift. One summary said players rated a puzzle "just right" when the log said "too easy." An audit said there were about 25 unused functions; a recount found 29. The strategist spot-checks load-bearing claims against the actual files and data before anything ships. 7. I built gates the agents can't talk their way past. All work lands on a branch that auto-deploys to a test site. GitHub Actions lints and runs the Python and headless-browser tests on every push. A git hook refuses direct pushes to production. Releases are fast-forward merges that only I perform, after CI is green and I've tested the build personally. The live site shows the release's commit ID, and I check it before calling it shipped. Nothing merges automatically. An agent's "looks good" is just another report, and reports drift. 8. I gave the system a memory. Every session ends by updating the decision log and a "resume here" document, so the next session—a fresh model with no recollection—picks up exactly where the last one stopped. Without this, every session starts by relitigating old decisions. 9. I let the data and end users overrule me. A scheduled GitHub Action turns player telemetry into a daily report. It showed that the difficulty dials I assumed mattered did not predict what players found hard; what mattered was how misleading the starting arrangement was. When testers were confused by the tutorial, I rebuilt it even though I had already approved it. Player feedback about their own experience outranks my earlier rulings. AI agents are velocity multipliers, but they multiply bad structure as quickly as good code. The rules came from me, not the models: the AI writes the code, while the rules, gates, and written record keep the process honest. See the result at Sujido.com. Finding the anagram is the easy part; sliding it into place is the hard part. One board took me 902 moves. My S.O. solved it in 242, and I haven't heard the end of it. Try to break it!

The Rundown recently held our first in-person retreat in Portugal, which was also my first time traveling to Europe. Claude and ChatGPT were amazing resources throughout the trip, from helping me navigate a chaotic international airport to providing personalized advice on cultural differences, tipping, translating menus, and using public transportation. My wife accompanied me and had plenty of time for solo exploration during the day. She is already a big planner, but a ChatGPT project containing our trip information helped her create a detailed plan, including a packing list, pre-trip checklist, and well-structured day-by-day itinerary for seeing as much of Lisbon as possible. As someone who gets stressed by travel, having an expert with context about my life available in my pocket to answer questions whenever I needed it is something I can’t imagine taking trips without. Step-by-step: 1. I used Claude and ChatGPT for personalized travel guidance during my first trip to Europe. 2. I asked for help navigating a chaotic international airport and handling cultural differences, including tipping, translating menus, and using public transportation. 3. My wife created a ChatGPT project with our trip information to support her planning. 4. She used it to create a packing list, pre-trip checklist, and day-by-day plan for exploring Lisbon during her solo time. 5. I used the tools throughout the trip to answer questions with context about my life and reduce the stress of traveling.

I’m building an automated content engine for a client using n8n and the Claude API. Every week it produces blog articles and social posts for eight brands. The client already has a blog with [number] articles, and we want the output to match that voice. What I’ve tried: [e.g. a tone-of-voice description in the system prompt / a few example articles in the prompt]. What I get is text that’s fine but sounds AI-written and slightly translated. It doesn’t read like a native Swedish copywriter wrote it. What I’m weighing: Is it better to extract a tone-of-voice guide from the blog (rules, word choices, sentence length, do’s and don’ts) or to pass example texts as few-shot? How many examples do I need, and should they be full articles or excerpts? Is a separate editor step that only reviews and adjusts tone worth it? How do you handle one shared base voice across eight brands that each have their own variant?

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

My AI digest looked perfect and was quietly wrong. What actually fixed it. Every run succeeded. Every dashboard was green. And the content was still wrong. My digest invented "AI Moat Brief", a newsletter that does not exist. It reported scan counts nobody measured. It resurfaced week-old stories as fresh headlines. Here is what broke, and what fixed it. The sorting used to happen in my head: skimmed subject lines, unopened tabs, quiet guilt. The Signal is one email at 08:00: a single Make scenario calling Claude Sonnet through OpenRouter. It reads the last 24 hours of my RSS feeds and newsletters, keeps what touches what I am actively building plus the domains I need to stay current in, and arrives in the language I actually think in. Core items end with what it means for my work. Five to ten minutes, and I know where to go deep today. Structurally it looks like this, minus the content, rendered in English for this post (Image 1). No real edition is shown; section names and sample lines are illustrative. The dangerous failures were never pipeline failures. They were content failures, and the cause is structural: an LLM summarizing newsletters that already summarize primary sources is third hand by construction. Every hop strips attribution and adds confidence, and when data goes missing the model fills the gap the way LLMs do: fluently. Valid HTML, confident tone, green pipeline, wrong content. Image 2 is that whole failure class in one frame. Three rules closed the gaps I caught, all live in production: Step-by-step: 1. Verbatim or nothing. A source name is copied character for character, and a link exists only if that exact URL is in the input. The model copies; it never composes. 2. The model never generates metrics. Every count the report shows is injected by the pipeline after the model returns. 3. Recycled news gets demoted. A recap of recaps gets one line at most, and is dropped when the underlying story falls outside the collection window. Rules 1 and 3 lean on the prompt, and that is why the counters exist. The pipeline writes a hidden HTML comment into every email it sends: items, links, urls, cost, finish status. That line caught what I could not see. In one run, the published-links counter and the leftover-urls counter read 45 and 435: the only sign a new cleanup step was a silent no-op. Another morning the model stopped at 15,999 tokens against a 16,000 cap, one token from an email cut off mid-sentence. On the morning I wrote this they agreed, 21 links and 21 urls, and boring is the goal. Image 3 is that morning's actual comment, with the same two counters from the no-op run. The run itself has a dead man's switch on Healthchecks.io, so a missing 08:00 email reaches me before I notice. Honest limits: the $0.31 per report is a fresh measurement I am still validating, and I have not proven these rules hold as the source set scales. There is more behind every part of this; I would rather share it where it is wanted. Ask and I will put it in the comments: the three rules in full, the exact cost and what drives it, what this replaced in my day, how it compares to what is on the market, or the ugliest of the 15 documented bugs. I am sharing this because I doubt I am the only one building fragile things behind the scenes, and monitoring text is harder than monitoring uptime. What content-level checks do you run on LLM output, the kind pipeline monitoring cannot see? Real thresholds and embarrassing failures especially welcome.

Sometimes I remember something perfectly badly: not its title, creator, or where I found it, but a sound, a color, a vague cover, a sentence, or a period in my life. I know it exists because I loved it, but I cannot name it. I use AI and my digital traces to recover songs, books, videos, articles, and quotes. Memory is not a catalog; it stores traces. AI can turn those traces into searchable hypotheses. Step-by-step: 1. I dump every surviving clue without waiting for a proper search query. The clues can be as rough as “The title sounded like nu nau tau,” “It was ambient or humming,” “The cover was maybe a green desert?” or “I knew it around 2019.” Another example is: “A book about makers and Disney. White 3D-printed figures, tiny people, and bears on a blue cover.” This is raw memory evidence. 2. I separate certainty from guessing by labeling each clue as certain, fairly sure, possible, or probably distorted. I keep uncertain clues, but do not treat them as facts. A wrong attribution or outdated cover does not invalidate everything else. 3. I reconstruct the original encounter. I ask where I was and whether I Shazamed it, saved it, sent it to someone, screenshotted it, or bought it at a book fair. In one case, I remembered hearing a song in someone’s car and Shazaming it because I could not parse the pronunciation. Remembering that capture action pointed to a retrieval source. 4. I search my own collections first: playlists, liked songs, Shazam history, saved videos, old posts, messages, bookmarks, notes, photos, receipts, and reading lists. The object may already be there under metadata I no longer remember. I start with the smallest reliable fragment. 5. I search for “nu” inside my playlists after remembering “nu nau tau.” That recovered Man O To — Nu. The artist and title had blended into one phrase, and the song was sitting in several playlists, including my Shazam collection. A clue does not need to be complete; it only needs to be distinctive enough inside the right collection. 6. I allow memory to scramble metadata. An artist and title may merge, album art may become song art, and a quotation may survive with the wrong poet attached. I split remembered phrases, swap artist and title, try different word boundaries, consider older releases, and search phonetically using similar syllables, vowel sounds, homophones, alternate spellings, or other languages. I also ask what the cover looked like when I knew it, because artwork changes. 7. I use context and cross-reference traces. A year, trip, relationship, or platform can narrow the search more than a half-correct title. Spotify might preserve the song, Shazam the discovery moment, and an old message the recommendation. Old posts are accidental archives, and dead links may still leave names, dates, or descriptions. If memory fails completely, I inspect behavior from the relevant period, such as repeated listening, watch history, purchases, or library loans. 8. I let AI propose candidates and compare them against several independent clues, including sound, subject, period, cover, and personal context. One matching detail is not confirmation. I show titles, covers, creator names, and short descriptions because recognition may succeed where recall fails. Rejections also help: “No, but the cover was more minimal,” “The title was shorter,” or “It was fiction, not nonfiction.” Each correction sharpens the search. 9. I pay attention to the strangest clue. The blue cover with white figures, bears, and a makers-and-Disney theme led to *Makers* by Cory Doctorow. 10. Once I confirm the object, I save the title, creator, link, why it mattered, and how I recovered it. For example: - Clue: “nu nau tau” - Encounter: heard in someone’s car and Shazamed - Search: Spotify/Shazam collection → “nu” - Result: Man O To — Nu - Distortion: artist and title blended together This becomes a retrieval playbook: which clues survive, where traces live, and how my memory distorts them. The overall workflow is: collect fragments → mark uncertainty → reconstruct the encounter → search personal traces → try phonetic, visual, and contextual clues → compare candidates → recognize and confirm → save the result and retrieval path. I do not need to remember the database fields. I need enough fragments to rebuild the trail. Sometimes the best clue is what I did when I first encountered something. Sometimes it has been sitting in five of my own playlists while I spend years wondering what it was called. 😑😭🎧

I built a workflow in which AI agents build a product under the kind of governance I’d expect from a senior engineering team. After 20 years in software engineering, including 10 years running my own businesses, I learned that writing code isn’t the hard part. Keeping control of it is. So I set up a build loop on GitHub. One thing I’ve kept for myself is decision-making: approving plans, answering product questions, and signing off on what the system has learned. The product it’s building is Cordexa, a tool for document-heavy expert work, such as quantity take-offs from engineering drawings or assessing a tender against a company’s own CVs and case studies. It’s designed to run inside the customer’s own cloud, so their documents never leave it. Every figure is cited to the document it came from or flagged for a person. It never guesses. The problem it solves is complex, but the build loop lets the system work in the background and notify my phone when it needs a decision. That allows me to stay focused on my day job. Step-by-step: 1. I start every module with a plain-English plan and approve it before any code exists. 2. One agent writes the tests from the plan. A different agent writes the code, and it cannot modify the tests. 3. An independent reviewer agent checks every change against its plan. Safe changes merge automatically; anything that changes the product waits for my approval. 4. A watchdog checks every 15 minutes for anything that is stuck, fixes it when possible, or tells me why it cannot. 5. Real test jobs run after every merge and are scored against known answers, so progress is measured rather than guessed. 6. I handle the decisions, answer product questions, and sign off on what the system has learned.

Spotify can tell me what I played, but it rarely explains what music does in my life. I use exported listening data, playlists, and personal context to explore taste, memory, regulation, identity, and continuity. I look at both observable listening behavior and the meanings I attach to it, without forcing every track into a biography. Step-by-step: 1. Start with the data. I export streaming history, tracks, artists, timestamps, listening duration, saved songs, and playlists where available. I check the period covered and remember that missing history does not mean a song never mattered. I start with behavior: a supposed favorite may barely appear, while another track may have played hundreds of times quietly. 2. Separate tracks from artists. I count unique tracks, unique artists, and tracks per artist. One artist with dozens of songs and hundreds of artists represented by one track suggest different listening styles: exploring discographies versus collecting exceptional songs. 3. Find lasting favorites. I distinguish temporary high-volume artists from favorites that return across years, playlists, and life phases. I look for persistent songs: tracks spanning years, returning after long gaps, or appearing in several playlists. Persistence can matter more than total plays. Some songs never win a monthly ranking yet refuse to disappear. 4. Connect music to life. I add relevant personal context, such as teenage years, university, a move, a relationship, or rebuilding. I ask which songs became landmarks and which were described as “my song.” Dates show when music appeared; I explain what that timing means instead of forcing every track into a biography. 5. Discover playlist functions. Repeated songs are not always favorites. Sometimes music has a job: providing strength, calm, concentration, singing, emotional release, or a way to reconnect with myself. I read playlist names alongside their tracks and listening patterns. “Power” might mean, “I do not feel strong, so I need external strength.” “Gold” might mean, “I want to feel my own golden heart again.” These meanings matter more than a generic genre label. 6. Treat corrections as evidence. AI suggests interpretations, but I decide whether they fit. For example: “This song is not nostalgic. It reminds me that I remain myself regardless of what another person does.” Corrections like this can change the meaning of an entire playlist, so I keep them alongside the data. 7. Look for regulation patterns. I find songs played daily for weeks, tracks repeated within one day, and playlists used at consistent times. I ask whether they accompany difficult tasks, low energy, singing, or calming down. Repetition is a clue, not proof of an emotional function. 8. Look beyond genre. Pop, rock, electronic music, mantra, and soundtracks can share dramatic builds, layered vocals, melodic hooks, powerful voices, intimate production, or mantra-like repetition. These qualities can explain why apparently unrelated songs belong together. I let myself name the patterns; “Post-Classical Electroacoustic Intimate Futurism” may be more useful for discovery than a standard genre. 9. Separate nostalgia from continuity. An old song returning is not necessarily nostalgia. I ask whether it is remembered or still actively used. Some music belongs to the past, while some music simply has a very long present. I keep different musical worlds separate: anthemic pop and meditative mantra may serve different parts of the same person. 10. Build a traceable profile. I include core artists, persistent songs, personal anthems, life-phase associations, functional playlists, regulation patterns, musical qualities, and unexpected findings. I link interpretations to dates, play counts, playlist appearances, and my explanations. I separate observed behavior, AI hypotheses, and confirmed meanings, and keep the profile easy to correct. 11. Recommend for the person. Instead of asking for “songs similar to Coldplay,” I ask: “Find the emotional build I like in Coldplay, the vocal force I like in Sia, and the intimate electronic texture in my meditation playlists.” I can also ask: “Find tracks for Power that could survive repeated listening without copying its existing artists.” 12. Update over time. I add new data and look for new favorites, returning anchors, changing playlist functions, and stable patterns. The ongoing cycle is: export → analyse → find persistent songs → map functions → add personal context and corrections → build the profile → recommend → update. Listening history records what I played. AI helps me explore why something kept returning. I remain the only person who can finally say: “Yes. That is what this song means to me.”

I built a model dispatcher to avoid paying premium usage for simple tasks. In Claude, every task runs on the model used by the current session, so a two-line formatting fix can consume the same level of model capacity as a difficult strategic problem. I had Claude build a scoring system that evaluates each task across six dimensions: required reasoning, the amount of context, the importance of craft or nuance, whether speed is the priority, the number of agentic parts involved, and the potential consequences if something goes wrong. Based on the score, it recommends a model—from a light, fast option for rote work to the most capable option for genuinely difficult tasks—and suggests how much effort that model should apply. The key design choice is that the dispatcher never spends anything automatically. Scoring is free and instant, while sending the task to a model through the API costs real money. Dispatching therefore requires an explicit confirmation flag every time. Nothing runs without me saying go. The payoff is not dramatic from day to day. It comes from many small savings that add up, along with a habit shift: I check the router before sending a task instead of wondering afterward why a simple request cost more than it should have. Step-by-step: 1. I identified the problem: every task in a Claude session uses the current model, even when the task is simple. 2. I had Claude build a scoring system that evaluates each task across six dimensions: reasoning, context, craft or nuance, speed, agentic complexity, and the potential consequences of failure. 3. I used the score to recommend an appropriate model, from a light and fast model for rote work to the heaviest model for genuinely difficult tasks. 4. I included a recommendation for how much effort the selected model should apply. 5. I kept scoring free and separate from dispatching, since sending a task through the API costs money. 6. I required an explicit confirmation flag before dispatching any task, so nothing runs automatically. 7. I check the router before sending tasks and benefit from small savings that accumulate over time.

I built Atlas to turn AI-assisted creative findings into readable project cards with source links, relationships, comments, and a calm HTML interface. Extracting creative findings is only half the job. Once fragments, metaphors, visual ideas, and research trails accumulate, I need somewhere to return to them and keep working. Atlas is that project layer over my old conversations. AI helps me revisit source material and suggests findings worth keeping. I decide what they mean, how to name them, where they belong, and which relationships matter. The results become readable cards. My harvesting system points to conversations that seem rich, and then I revisit them with AI. We identify existing projects, standalone findings, recurring material, and connections. Sometimes the review sparks new ideas. After just two rich conversations, we had 28 cards, including four collection cards and three new ideas. The harvest is the radar. The review is where interpretation happens. Atlas keeps the results usable. Step-by-step: 1. I let the harvest flag chats containing project ideas, unusual language, visual concepts, or unfinished thoughts. It suggests where to look without deciding what matters. 2. I review promising conversations with AI and ask, “What here deserves a place in the creative system?” AI suggests findings and connections, while I correct interpretations, separate unrelated material, and decide what belongs together. The card structure grows out of that dialogue. 3. I create readable cards with information such as a name, category, description, findings, sources, relationships, questions, and comments. The contents depend on the material: a story needs different information from an essay. The goal is to recognise and understand the work when I return. 4. I group recurring fragments into collection cards for language finds, story material, or visual motifs. Individual items stay visible without turning Atlas into hundreds of tiny, barely distinct cards. 5. I link each card back to the original conversations so I can access exact wording, context, and how an idea developed. Several conversations can feed one card, giving me a stable starting point while its source history grows. 6. I record meaningful relationships that I recognise, such as shared themes, predecessors, spin-offs, fictional worlds, or research overlaps. Similar words alone do not establish a meaningful relationship. Categories provide visual orientation, while relationships let me move across them. 7. When I remember a source but cannot find it yet, I leave a comment: “Find and link the old conversation about XYZ.” When it turns up, I attach it and update the comment: “Found it, now linked.” This turns imperfect memory into a useful breadcrumb, so missing sources do not have to stop the work. 8. I use a small green indicator to mark cards with updates I have not viewed yet, such as a new source, finding, relationship, or resolved comment. This shows me where something changed without requiring me to check every card. 9. I let cards stay unfinished. One paragraph, one source, and an open question can already make a useful card, and more context can accumulate later. Reviewing old material can also spark new work, making the archive generative through fresh interpretation. 10. I keep the HTML environment calm and make it feel like a reading room: Browse → recognise → open → read → follow a source or relationship. Code handles IDs, CSV rows, statuses, and consistency checks underneath while I work with readable cards. Each layer answers a different question: the harvest tells me where to look, the collaborative review tells me what is there and what it means, and Atlas keeps the result usable. AI helps me notice and organise, while I assign meaning. Atlas preserves the results with the original conversations available underneath. I can navigate backwards to the source and sideways to related work, starting wherever I am. The harvest tells me where to look, the review tells me what I found, and Atlas makes sure I can use it again.

I built a website that turns property photos, architectural renderings, or even just an address into cinematic property videos. I’m a civil engineer and photographer/videographer, not a software developer, so I used ChatGPT, Gemini, and Claude Code to help build the site and work through problems as they came up. Much of the process involved translating the way I would personally edit a real estate video into usable software. For example, kitchen and living room shots should usually stay together and have longer durations, bedrooms should stay near their bathrooms, an opening shot should feel different from a detail shot, and every clip should include some movement so the result does not feel like a generic slideshow. I used AI to turn those editing principles into actual logic for the site. The system analyzes and organizes the images, builds a storyboard, ranks scenes to decide which ones to use, creates prompts for video models, generates the clips, and assembles everything into a finished video. Most of the development has been iterative. I test the site with real properties I’ve shot, watch the results, identify what feels off, and then improve the prompts, scene planning, timing, or video assembly process. AI has been useful for much more than generating the final video. I’ve also used it to write code, troubleshoot errors, plan features, improve the user experience, and think through how the product should work from the perspective of its primary user. Step-by-step: 1. I defined the video-editing principles I use for real estate footage, including grouping related rooms, varying shot durations, distinguishing opening shots from detail shots, and adding movement to every clip. 2. I used ChatGPT, Gemini, and Claude Code to translate those principles into software logic. 3. I built the site to accept property photos, architectural renderings, or an address as input. 4. I had the system analyze and organize the images, build a storyboard, rank scenes, and select the footage to use. 5. I used AI to create prompts for video models and generate the clips. 6. I assembled the generated clips into a finished property video. 7. I tested the site with real properties I had shot, reviewed the results, and iteratively improved the prompts, scene planning, timing, and video assembly. 8. I used AI throughout development to write code, troubleshoot errors, plan features, improve the user experience, and think through the product from the primary user’s perspective.