I had a tracker in Excel. Simple enough. I needed AI to help keep it updated, so I brought it into Claude and started building.
It worked, for about a day. Then every time I opened the file and asked for a change, Claude rebuilt more than I asked for. New formatting. A slightly different layout. Numbers that used to live in one place migrated to another. I was not managing a tracker anymore. I was managing whatever Claude decided the tracker should look like that day.
I scrapped it. Started over in Copilot, inside Excel itself, and kept using Claude models for the parts that actually needed thinking. That combination held. I finally got the formatting and the data the way I wanted.
Which is the tool-follows-your-work rule from a few posts back, proving itself the hard way.
That is not a story about Claude being bad at spreadsheets. It is a story about building without a map.
Everyone gets excited about the automating part. Fewer people slow down on the building part. That is the gap this post is for: how to build an AI workflow that actually works, not just on day one.
How to Build an AI Workflow That Actually Works
Before you ask AI to build anything, ask it to describe what it is going to do first. Not the finished output. The plan for getting there.
What does it need access to. What is the sequence of steps. What does the output actually look like when it is done. Have it write that down in plain language, then read it before you approve anything.
The map is not just the technical plan either. If you already have reference files for this kind of work, an instructions file, a voice or tone file, an audit checklist, hand those over too. A written house rule like no em dashes lives in one of these, and it should shape the build from the first draft, not get caught after the fact. If you do not have files like this yet, that is fine. For now, just know the map pulls in whatever guardrails already exist, not only the steps.
This feels slower. It is not. Catching a wrong assumption in a two-paragraph plan takes thirty seconds. Catching the same wrong assumption after it has built the whole thing takes an afternoon, and by then you are also annoyed.
If you have access to more than one model, this is where the expensive one earns its keep, and it is not by doing the building. Hand it the map, not the task. Ask it to find what is missing and what is likely to break. That review is what the first build runs against. It is not the audit file yet. The audit file comes later, once there is an actual build to check.
Ask It What Happens When Things Change
Once you have the map, push on it. What happens if the data source moves. What happens if the account does not have the field it expects. What happens if two things it assumed would stay separate turn out to be the same thing.
AI does not always think through every scenario you already know could happen, because it has not lived through your particular flavor of chaos. You have. That is the part you bring to the build that it cannot.
The expensive model is better at exactly this: spotting the gap you did not think to ask about. The regular model is built for the opposite strength, following specific instructions well once it has them. Use each for what it is actually good at.
Ask it directly: what am I not thinking about. What are we missing here. If you see a gap or you are not sure, ask me, do not fill it in and keep going. This is the same instruction from setting up your first conversation, and it matters just as much here.
If you are in a tool that can search the web, use that too. Have it find real examples of people who have already run into this kind of problem, and bring back anything worth knowing before you commit to a plan.
This is still the foundation. The more you push here, before anything gets built, the fewer rounds of fixing you need once it does.
The Review Step Most People Skip
Now the regular model builds, against the map the stronger model already reviewed.
We do not need the Ferrari to build the car. We need it to tell the mechanic what to check for, once, in writing, and then get out of the way.
This is where the actual audit file gets created, not before. Once a real build exists, have the stronger model review the actual output, not just the plan, and write down what it finds. What is wrong, what is missing, what almost slipped through. That becomes the audit file. The next build, or the next run of this same build, gets checked against it. Every miss you catch turns into a line in that file, and the file gets sharper every time you use it.
If you are in Copilot, check before assuming you do not have this. Copilot Cowork now has a model picker with GPT-5.5, GPT-5.6, Claude Sonnet 5, and Claude Opus 4.8 sitting side by side. That means the same two-model split works there too: build with the faster default, then switch to Opus for the review pass. I have not run that combination in Copilot Cowork myself yet, so treat it as the plan, not a tested result.
If your version of Copilot does not give you a model picker, the fallback still holds: open a fresh conversation and ask it to review its own plan as if it were seeing it for the first time, specifically looking for what it would push back on. Do the same thing again against the actual output once the build exists, and write down what it finds. That is your audit file.
One more thing worth adding to that file, whatever tool you are in: if this is something that is going to run again and again, tell it to optimize for token usage on future builds. Claude, Copilot, Cowork, any AI billed by usage has a real cost lever there, and it pays off most on anything that runs more than once, not just a one-time build.
Take that further once something is not a one-time build but a recurring one, running on a schedule and touching real systems without you watching every time. Say it moves updated rows from an inbox or a spreadsheet into a project board automatically.
Each run should produce its own update record: what changed, where it came from, where it landed, and exactly when it ran. Post that update, or a summary of it, wherever you actually check things, Slack or email, so you know it ran and what it did. That is how you know the thing you built last month is still working, not just still scheduled.
The update record does more than confirm the run happened. It is what you check the board against when you need to validate every change actually landed. It is also what the next run should read first: tell AI to only look at what has changed since the last recorded update, not the whole board or the whole inbox again. That keeps every run scoped to what is actually new, the token-usage tip from a moment ago, working in practice instead of staying theoretical.
Betterish, Not Perfect
Here is the honest part. Even after all of that, things still get through.
I once had Fable, a model I use for outside perspective, build a reference file whose entire purpose was enforcing writing rules for this blog. One of the rules written into that file was simple: no em dashes. The finished file had an em dash in it. The document whose only job was catching that exact mistake made that exact mistake, inside its own text.
I did not find that annoying. I found it clarifying. That is exactly why you stay in the loop, even after you have built the map, done the review, and written the audit file. The process makes the output better. It does not make you unnecessary.
Confession: I collect board games. Over 350 of them, so please, no judgment. Getting AI to nail the output on the first try has become the same kind of game to me. Every audit file is a new rule I am testing against the machine. Every clean first pass is a win, and I am absolutely keeping score.
I still have to review it. That part never goes away. The game is not skipping the review, it is needing less of it: get the file good enough that I barely have to read every word, and chasing that is what makes this fun instead of tedious.
Case in point, mid-post: I asked my AI, point blank, whether we had actually added everything we found to the audit files, so the next first draft comes out better. It said no. Not “let me check.” It went and read the files instead of trusting its own memory, and found two real gaps that had never actually been written down, even though it had already told me twice, in that same conversation, that everything was covered.
Same discipline as Your AI Will Be a Yes-Man Unless You Stop It: question it before the build, not after. That one question is what caught it here.
When It Actually Breaks
Sometimes it is not a small miss. Sometimes the output is confidently wrong, a number is invented out of nowhere, or a task you scheduled quietly stops running and you do not notice for two weeks. This is the moment people quit on the whole idea, and it is the wrong moment to quit.
When it happens: stop, do not push forward on top of a broken foundation. Ask it to walk back through what it did and where the assumption went sideways. Fix that one thing. Then check the rest of the output, because a wrong assumption early usually shows up more than once.
It is not a sign you built it wrong. It is a sign you are auditing correctly.
How to build an AI workflow that actually works: not by skipping the boring parts, but by writing them down. You built it well. Now it needs to remember you, so you are not explaining yourself from scratch every time you open a new conversation.
Next up: your AI already has a foundation from your instructions. The next step, in Your AI Should Remember You, is deepening that into something that actually compounds over time.
Leave a Reply