@Catherine Eadie Quick update on this thread because the whole workflow ended up being more interesting than I expected. What started as a GPT migration turned into a three-part process: 1. Recover the accumulated knowledge first. Before migrating the older GPTs, I used my OpenAI data export to mine the conversation history and recover useful specialist knowledge that had never made it into the visible instructions. That turned out to matter a lot, because otherwise I would have migrated the shell of the GPT and left a lot of the real institutional knowledge behind. 2. Turn that recovered knowledge into structured Skills/Plugin packages. I used the recovered material to build cleaner specialist Skills with references, boundaries, workflows, and personality preserved, then migrated those GPTs into the newer Plugin/Skill model instead of just recreating prompts. 3. Use one of those migrated Skills inside a persistent Codex workflow. My AI Mechanic Skill now runs as the operating layer for a persistent VS Code/Codex project workflow with durable project state, root-agent planning, bounded subagents, acceptance criteria, verification, fresh-session recovery, and Git checkpoints. So, the pipeline ended up looking more like: OpenAI data export → knowledge recovery → Skill creation → GPT-to-Plugin migration → persistent agentic project workflow The biggest change for me is that I’m no longer doing longer builds as a sequence of disconnected prompt/test/re-prompt loops. The project itself now carries the state, decisions, open risks, and next step. I tested the persistence pattern in a throwaway repo, then moved it onto my real BHP Ops Dashboard and ran an actual change through the full loop. Looking back, this would have made a huge difference during my Brandstamp build, especially around continuity, regression testing, task isolation, and not having to reconstruct context across sessions.

@Catherine Eadie Yes — I’ve started moving the checking into the workflow too. My current setup has AI Mechanic as the root/orchestrator. It owns the architecture, plan, acceptance criteria, sequencing, and final decision on whether a task passes. Implementation gets delegated to bounded workers, but the root has to review the result before anything moves forward. I also have it independently run tests, inspect the Git diff, and verify that the worker stayed inside scope. We actually caught a failure this way yesterday: one worker completed the code correctly but didn’t return the required handoff report, so AI Mechanic marked the step as failed even though the code itself worked. Today it caught another one where the durable project-state files had been updated by overwriting prior history instead of preserving it. The root rejected that, corrected the state files, and only then continued. So I’m doing less of the checking manually now, although I still do the final human sanity check on anything that matters — especially if it changes business behavior or production data. I haven’t yet added a completely separate “verification agent” as a permanent role the way you have, but I can definitely see the value in that. Right now the pattern is more: worker does the task → AI Mechanic root independently verifies → Git/tests confirm → I spot-check the result Your point about “the one that did the work always thinks it went fine” is exactly why I wanted the root to stay out of the implementation role. I think we’ve converged on the file-based persistence part. Mine has gone one step further into a persistent orchestration loop, where AI Mechanic stays as the root, delegates bounded tasks, verifies each result, updates durable state, and then decides the next step without me re-prompting every phase.

Welcome back @Ryan Doser

@Shelly Paige I’ve thought about that, but I really built it specifically for Better Home Photos. The concept could absolutely work for another photographer, but the actual system is too tightly tied to how my business operates to be a simple wrapper that someone else could just install and use. My Business Desk contains my pricing logic, policies, SOW language, travel rules, workflow decisions, client communication patterns, Calendar conventions, access rules, and all the little operational lessons that came from running my own jobs. The Dashboard is then built around those exact rules and states. Another photographer might have completely different pricing, different contracts, different scheduling authority, different delivery rules, different service types, and different ideas about what should require human approval. So I think the reusable part is really the architecture and method: build the business knowledge first, document the real workflows, decide what belongs in prose versus code, then put a UI over the repetitive paths so the operator doesn’t have to reconstruct the process every time. But I wouldn’t want to pretend my Dashboard itself is a universal photography-business system. It’s really a custom operating system for BHP. If another photographer wanted something similar, I think the better approach would be to build from their business rules rather than trying to force mine onto them. Have you found the same thing with your e-commerce workflows — that the method is reusable, but the actual playbook becomes very specific to the way you run your business?

@Shelly Paige Exactly. That shift from “what can AI automate?” to “where does the business repeatedly lose time, create friction, or make mistakes?” has probably been the biggest lesson for me. My original thought actually wasn’t to use AI to make money. It was to use AI to stop me from losing money and time. Missed details, unclear scope, unnecessary return trips, things not documented, workflow steps falling through the cracks — those are all small leaks that add up. That’s really why the Dashboard evolved the way it did. Now I’m experimenting with adding more of an AI interface on top of that system. What interests me is not just chatting with the Dashboard, but having that interface able to reach the other information and tools the business already uses when they’re relevant — calendar, documents, email, research, and so on — while keeping the actual business rules underneath. I’ve already gotten a glimpse of how useful that can be with tools like NotebookLM. For example, I can load a body of published material, look for recurring ideas and patterns, and then ask what might actually apply to my own business. The same idea could eventually be used to study public competitor sites and material — what they emphasize, where they differentiate, what seems common across the market — and feed those observations back into the business system rather than leaving the research in a separate silo. I’m still learning what half of these things are technically called after I build them. 😄 But I’m starting to think the next interesting step is making all of these separate AI capabilities feel like one simple interface for the business owner.