AI strategy starts with the workflow
A founder usually reaches for an AI roadmap after a demo works once. The demo answers a support ticket, summarizes a document, classifies a lead, or drafts a paragraph. That is the easiest part of the system.
The roadmap starts when the team names the workflow around the model. Who creates the input? Which system owns the source data? Where does the model response go? Who reviews the answer before a customer sees it? What happens when the answer is missing, too expensive, or wrong?
Those questions decide the architecture before model choice does.
The first decision is not OpenAI, Anthropic, or open source
Model choice matters, but it is rarely the first constraint. A workflow that needs a human approval step, a searchable audit trail, and deterministic retries has a different shape than a chat feature inside an admin panel.
For a support workflow, the useful plan might be a retrieval step, a drafted response, a confidence threshold, a queue for human review, and a log that stores which documents were shown to the model. For an internal data-cleanup workflow, the plan might be a batch job, a schema validator, and a retry path that writes rejected records to a review table.
Those are product and systems decisions. The model is one dependency inside them.
Cost control belongs in the first design
Inference cost is not only a finance problem. It changes product behavior. A workflow that sends a long customer history to a frontier model on every request will have different margins than a workflow that retrieves five narrow records, summarizes them once, and reuses the result.
The roadmap should name the budget mechanism before production traffic arrives. That can mean token limits, cached summaries, cheaper models for low-risk steps, batch processing, or a rule that sends only reviewed data into the model context.
If the plan does not say how cost will be measured, the team will learn from the invoice.
The roadmap should produce engineering work
A useful AI roadmap does not end with "build an agent." It ends with tickets an engineering team can estimate:
- Add an event log for model inputs, selected context, outputs, latency, and review status.
- Create a retrieval index from the product documents that support this workflow.
- Add a human review queue for answers below the confidence threshold.
- Define the fallback response shown when the model call fails.
- Run a production pilot against one customer segment, not the whole user base.
That is the difference between AI strategy and AI enthusiasm. Strategy changes what the team builds on Monday.