If your AI tool vanished on Monday, what could your team still do on Tuesday? For most firms I’d guess the honest answer is not much, because the steps live inside the tool, in saved prompts and settings nobody wrote down anywhere else. That’s where I’d start with portable AI workflows. Write the workflow into a file your firm owns, and the picture changes. The file is yours. The model is the part you rent.
For an Alberta firm with a lean team this file matters more than the tool choice, because the person who set up the tool is often the only one who knows how it works. Among Canadian businesses using AI, 44.4% changed their training or staffing because of it, so the know-how moving on with one person is a real risk.
Models and tools change places constantly. The one that leads in spring gets caught by summer. Prices move. A feature your team leans on gets changed or retired, and a rival adds the thing yours was missing. None of that should force a firm to relearn how it works. It only ends up stored inside a tool when nobody bothers to keep it anywhere else.
What does owning a workflow actually mean?
It means the job is written down in a file your firm controls, in plain words. The steps in order. What goes in at the start. What good output looks like, with a real example kept beside it.
And the checks a person runs before the work counts as done. A new hire could pick the file up and run the job from it. So could a different tool.
Most firms keep none of that. The knowledge sits in the tool itself, spread across chat history, saved settings and half-remembered prompts. That feels harmless while the tool stays put. It stops feeling harmless the week the tool changes its price, its terms, or its plans for a feature you built on.
Why does the tool side keep moving under you?
Because no vendor holds the lead for long, and no contract freezes a product in place. This spring, one firm that builds with AI all day moved its whole working life from one of the two leading building tools to the other, inside a single season.
The first tool had not failed them. The move was possible for a plainer reason. Their workflows were files they owned, written in plain words, stored in their own folders. The new tool read the same steps and worked to the same standard. What could have been a rebuild took days, because the know-how was never the tool’s property. The same split decides which half of an AI purchase is worth owning.
A firm that can leave never has to plead with a vendor to stay good, and never stays with a tool that stopped earning its place out of fear of the move.
What goes in the file?
Five things, in plain language. The steps, in the order they run. The starting material the job needs, the brief, the records, the numbers. One or two examples of output that passed, kept whole, so good has a shape.
The checks, written as questions a person answers before the work ships. And the stop line, the point where the agent hands the job back to a person instead of pressing on, the handover a tired reviewer tends to wave through.
This is also where the coaching lives. Corrections stop being things you said once in a chat and start being lines in the file, where the next run can find them. I set out that rhythm for an agent working a cold lead backlog, where the standing instruction is to coach it like a team member, with a scorecard and a line it may not cross. Whichever tool runs that file next inherits the lessons the last one learned.
If a new hire could not run the job from the file alone, the file is not finished.
How do you run the exit test?
On paper, before you ever need it in real life. Take a workflow and pretend the tool is gone on Friday. On Monday, hand the file to the person who would run the job, or to the tool you would move to, and watch what happens.
Where they stall is where the file is thin. Where they ask a question the file should have answered, write the answer in. Run the test twice a year and it stays honest. I’d put both dates in the calendar today.
Portability moves the steps and the standards. It does not move the responsibility. The output still goes out under your firm’s name, and the promises it makes still land on your desk. That was the point of the store an agent built in an afternoon. The building was the easy part, and the risk stays yours no matter which tool does the building. Owning the file and owning the risk are the same habit, seen from two sides.
Which workflow should you write down this week?
Pick one weekly workflow, the kind that runs often enough to hurt if it broke. Write it down as a file your firm owns: the steps, the starting material, one example of good output, the checks, the stop line.
Store it in your firm’s own folders, outside the tool that runs it today. Then run the exit test on paper and fix the thin spots you find. One workflow done this week gives you the pattern for the rest. Turning how a firm works into files it owns is a core part of AI Agent Architecture and Orchestration work.
Portable AI workflows, quick answers
What is a portable AI workflow?
A job written down in a file your firm controls, in plain words. The steps in order, the starting material, an example of good output, the checks a person runs and the point where the agent hands back to a person. Any capable tool, or a new hire, can run the job from it.
How do you avoid AI vendor lock-in?
Keep the know-how outside the tool. Store each workflow as a plain file in your own folders, then run an exit test on paper twice a year. Pretend the tool is gone and hand the file to whoever would run the job. Where they stall, the file is thin.
Write one weekly workflow into a file you own. The AI Newsletter with ZAK covers tests like that every Friday.
3 Comments