From data to decision: a complete AI foresight workflow

This is the workflow we recommend to operators picking up an AI foresight engine for the first time. It's the same shape we've watched experienced users converge on after a few months. If you treat the engine as a question-and-answer box, you'll get value. If you treat it as a workflow, you'll get a lot more.

The example we'll walk through is a budget reallocation decision in a 50-person company. Same workflow applies to almost anything.

The decision

You have $400k of marketing budget left for the year. You can either double down on the paid channel that's been working (Google Ads, generating most of your inbound), or fund a content + SEO push that would only show returns in nine to twelve months. The team is split. You have a board meeting in nine days.

Step 1: write the rough situation, not a question

Most people, on first contact with a foresight engine, type a question — "should I do paid or content?" That's the wrong unit. The engine does better with a situation. Write three or four paragraphs in plain English: where the company is, what's been working, what hasn't, what you'd consider a win, what would scare you. Don't optimize the prose. Just dump.

For our example, that's: ARR, growth rate, current paid spend efficiency, what the content team currently looks like, what your competitive set is doing, what your hypothesis is about why content might work, what your hypothesis is about why it might not. About 400 words.

Step 2: load in the actual numbers

Before you run anything, paste the supporting numbers as a table or CSV snippet directly into the chat. CAC by channel for the last 12 months. Conversion rate by source. Content output and rankings, if you have any. The engine does not magically know what your CAC is. Without the numbers, it will make plausible-sounding ones up.

This is the step everyone skips. The cost of skipping it is having to manually correct the engine's invented numbers later, which is more work than just pasting them in.

Step 3: ask the engine to surface its assumptions before simulating

This is the move that levels up the workflow. Don't ask for the simulation yet. Ask: "What assumptions would you have to make to simulate this? List them and tell me which ones the outcome is most sensitive to."

The engine will produce something like a dozen assumptions — content production cost per article, time to first organic traffic, conversion rate of organic vs. paid traffic, the durability of your current paid channel's efficiency. Read this list carefully. The assumptions that come back as "high sensitivity" are the ones to challenge.

In our example, the most-sensitive assumption usually turns out to be the durability of paid efficiency — how confident are you that your current Google Ads CAC will hold for the next 18 months? That's an assumption a human would have skated past. The engine surfacing it as load-bearing is the most valuable thing it'll do all session.

Step 4: run the simulation, then ignore the headline

The engine runs and returns a tree of branches. The natural temptation is to read the top-level recommendation and stop. Don't. The headline is the least interesting output.

The interesting output is the spread. How different are the best and worst branches? If they're close to each other, the decision doesn't matter much — pick the one you'd defend more easily and move on. If they're far apart, there's a real bet here, and the question shifts to "which branch am I most confident is the actual world?"

Step 5: argue with one branch

Pick the branch that worries you most. Open it. Read the assumptions. Find the one that feels wrong, change it, and ask the engine to rerun just that branch. Watch how the result moves.

This step is where the model in your head and the model in the engine start to merge. After three or four edits, you'll have a calibrated sense of which assumptions are doing the work and which ones are decorative. That sense is the actual deliverable. The simulation is a means to it.

Step 6: write the recommendation yourself

The engine is not a decision-making tool. It's an input. Open a doc, write your recommendation in your own voice, and use the simulation output as the supporting structure. State the decision, state the two or three branches you want the reader to hold in mind, state which assumption is load-bearing, and name a tripwire that would tell you you're in the wrong branch.

The board meeting goes better when you can say "I'm confident in this path because of X, and I'll know within four months if I'm wrong because of Y" than when you say "the AI recommended this." Both statements use the same underlying analysis. Only one of them is credible in a room.

What you'll notice after a few decisions

Two things, in this order. First, you stop running the simulator on small decisions, because the workflow has a real cost and most decisions don't reward it. Second, you start running it earlier on the big decisions — not after you've already half-decided, but at the moment you first realize a decision is coming. That's the right place for it. Used that way, the engine becomes a way of thinking, not a tool you reach for at the end.