In This Issue
Why choosing a model, agent, or tool too early distorts the problem.
A practical way to map the work before deciding where AI belongs.
How to separate deterministic steps from judgment-heavy work.
Where human authority, data access, and handoffs should shape the design.
A simple test for choosing the smallest AI intervention that can improve the workflow.
The signal
AI projects often start with a technology question: Which model should we use? Should this be an agent? Do we need RAG? Which platform should we buy?
Those questions matter later. They are weak starting points.
The first design object is the workflow. A workflow shows how work actually moves from an initial trigger to a finished outcome. It exposes the tasks people perform, the decisions they make, the information they need, the systems they touch, and the points where responsibility changes hands.
Until that is visible, choosing the AI is mostly guesswork.
My working rule is simple: draw the work before drawing the AI architecture. The goal is not to automate a job title or attach AI to a process. The goal is to locate the parts of the workflow where better prediction, interpretation, generation, or judgment can change the outcome.
That shift matters because one workflow can contain several different kinds of work. Some steps are fixed. Some are repetitive. Some depend on context. Some require approval. Some exist only because information is scattered across systems. Treating all of them as one AI use case hides the real design problem.
What workflow mapping reveals
Start with the outcome. What finished state is the workflow supposed to produce?
Then work backward.
For each step, record what triggers it, what input arrives, what action happens, what decision may be required, what output is produced, and where the work goes next. Mark the system or person responsible for the step. Record the common exceptions that send the work down a different path.
The useful map is not a polished process diagram. It is a decision map of how work gets done.
A good map exposes friction that is easy to miss when the conversation begins with technology. A task may be fast while the workflow waits on missing information. A process may look repetitive until the exceptions appear. A handoff may create more delay than the task before it.
This is where the AI opportunity becomes specific.
You are no longer asking, “Where can we use AI?” You are asking, “Which step is limiting the outcome, and what kind of capability would improve it?”
Separate the work before assigning the technology
Once the workflow is visible, classify the work by what it requires.
Stable steps with clear rules usually belong in conventional software or automation. Calculations, field validation, deterministic routing, database updates, and fixed policy checks often need reliability more than reasoning.
AI becomes more interesting where the work depends on language, ambiguity, incomplete context, changing inputs, or judgment. OpenAI’s current agent guidance makes a similar distinction: it recommends prioritizing agentic approaches for workflows with complex decisions, difficult-to-maintain rule sets, or heavy unstructured data, and notes that deterministic solutions may be enough when those conditions are absent.
That does not mean every such step needs an agent. It means the step deserves closer inspection.
A model may only need to classify an input. Retrieval may be enough to bring the right context into a decision. A model can draft a recommendation while a human approves it. A fixed workflow can call an LLM at one point and continue through normal software. An agent becomes relevant only when the system needs more freedom to decide what to do next, use tools, recover from changing conditions, or navigate a path that cannot be fully specified in advance.
Anthropic draws a similar architectural distinction between predefined workflows and agents that dynamically direct their own process. Its guidance is to start with the simplest workable solution and increase complexity only when the outcome requires it.
The workflow tells you which of those patterns fits.
Map decisions, not only tasks
Task inventories are useful, but decisions are where much of the design value sits.
For every important decision, ask what information the person uses, what makes the decision difficult, which exceptions matter, how much discretion exists, and what happens if the decision is wrong.
This changes the architecture.
A high-volume decision with clear criteria may be automated completely. A contextual decision may be assisted by AI but kept under human authority. A low-frequency decision with severe consequences may need AI only for research, summarization, or evidence preparation.
Assign AI according to the nature of the decision, not the novelty of the technology.
This also gives you an evaluation target. Instead of asking whether the model produced an impressive answer, you can ask whether it improved the decision: faster resolution, fewer errors, better consistency, lower handling cost, or less work pushed to the next person.
Handoffs are part of the AI design
Many workflow problems do not live inside a task. They live between tasks.
One person finishes work and another person needs context. A system produces data in a form another system cannot use. An exception moves into email. An approval waits in a queue. A customer repeats information already provided. A human receives an AI output without knowing what evidence produced it.
These handoffs deserve the same attention as the AI step itself.
Map what crosses each boundary. Identify the required context, owner, timing, and authority. If AI produces an output, define what the next person or system must receive with it. If a human reviews the result, specify the evidence and the action they can take. If the AI lacks the context required for a decision, the problem may be workflow design rather than model capability.
This is also where platform concerns begin to matter. A single application may solve a handoff with a direct integration. A shared workflow across teams may introduce access control, auditability, reusable tools, identity, reliability, and cost allocation. The platform lens should enter only when those constraints materially change the design.
Choose the smallest useful AI intervention
After the map is complete, choose the narrowest intervention that changes the workflow outcome.
Do not start by asking how autonomous the system can become. Start by asking how little intelligence needs to be added to remove the constraint.
If classification removes manual sorting, stop there. If retrieval gives a person the missing context, stop there. If a draft plus human approval removes most of the effort, that may be enough. If the work requires a sequence of model calls with known branches, build the workflow. Use an agent when the system truly needs to choose its own path through changing conditions.
This keeps the design easier to evaluate and keeps failure boundaries visible.
Before implementation, define where the AI starts, where it stops, what systems it can access, what actions require approval, and how the work returns to a person. Those boundaries are part of the product.
When the workflow says “do not use AI”
A workflow map can also kill an AI idea early, which is useful.
If the process rarely occurs, the economics may be weak. If the task is already governed by simple stable rules, normal automation may be better. If the required context is unavailable or unreliable, adding a model does not fix the underlying information problem. If nobody owns the workflow, automation can make the confusion faster. If the outcome cannot be measured, you will struggle to know whether the AI improved anything.
The strongest AI opportunities usually become clearer after these weak candidates are removed.
Takeaways
Map the outcome and the workflow before evaluating models, agents, or vendors.
Break the workflow into tasks, decisions, handoffs, inputs, outputs, exceptions, and owners.
Keep deterministic work deterministic when rules already solve the problem well.
Look more closely at steps dominated by language, ambiguity, changing context, or hard-to-maintain rules.
Design human authority, data access, failure paths, and handoffs before increasing autonomy.
Choose the smallest AI intervention that measurably improves the workflow.
Worth reading
OpenAI’s A practical guide to building agents is useful for one specific reason: its use-case filter starts from workflow characteristics, then moves to agent design. The sections on complex decisions, brittle rules, unstructured data, and model selection are a good companion to this approach.
What part of your current workflow would you map first if you were not allowed to choose the AI yet?
If this briefing helped you, leave a comment or your reaction. I’d like to hear where you landed.
INVENEW exists to help tech builders, operators, founders, and leaders turn AI from experiments into working systems.