An organization wants to “add AI” to intake requests. The existing form asks for a name, order number and a fixed set of options. A chatbot could collect those fields in conversation, but it would add latency, ambiguity and a bill to a task the form already explains. This is not a failure of imagination; it is a useful design decision.
Begin with the work people already do
The interesting part may be elsewhere. The request could arrive as a long, unstructured email; a person might spend twenty minutes interpreting attachments before they can use the form. That is where language understanding may help. The job is to find the uncertain step, rather than to wrap the entire journey in AI.
- Map the user journey in plain language.
- Mark tasks with fixed rules and tasks needing interpretation.
- Identify the point where a person currently spends judgment or reading time.
Four patterns, four different promises
Conventional code handles known rules reliably: calculating totals, validating an order number or deciding whether a required field exists. Retrieval finds relevant material in a changing set of documents. Generation produces a draft, summary or structured interpretation that should be reviewed when stakes warrant. An agent can select and call tools for a bounded task that genuinely requires flexible decisions.
These patterns can be combined, but each adds new operational questions. A retrieval system needs document owners, permissions and freshness. Generation needs examples of good and bad output. An agent needs narrow tool scopes and an approval model. Start with the smallest pattern that solves the recurring problem.
- If rules are explicit, start with code.
- If the answer lives in documents, start with search and retrieval.
- If language must be transformed, try generation with a review path.
- If a bounded task requires choices among tools, consider an agent.
Run a short discovery experiment
Collect ten real examples of the work and ask the people doing it where they lose time. Estimate how often a straightforward solution would already help. Prototype the uncertain step and compare against the current process using effort saved, error rate and the cost of recovery when the system is wrong.
If the AI version is more delightful but slower and less accurate, find out whether the delight matters to the actual user. A product team should be willing to discover that better labels, faster search or one removed approval step would solve more than a model integration.
The decision matrix in one example
Suppose a support team processes refund requests. Fixed eligibility rules belong in code. Finding the current refund policy belongs in retrieval. Drafting a courteous explanation from the approved result can use generation. Actually issuing a refund is a protected action, perhaps assisted by an agent workflow but enforced by server-side permissions and, for exceptional amounts, a human checkpoint.
The benefit of this division is clarity. The policy can change without retraining a model; the message can be rewritten without changing eligibility; the action remains auditable. Each part has a separate owner and a way to test it. That is more useful than labelling the whole journey “AI-powered” and treating every failure as a mysterious model problem.
- Rules: deterministic and testable.
- Policy: searchable and versioned.
- Communication: editable and reviewable.
- Money movement: authorized and auditable.
What a good decision looks like
Write a one-page feature brief with the user job, current failure, proposed pattern, expected benefit, boundaries and the examples that would change your mind. That brief becomes the basis for an experiment and, if the experiment works, a useful implementation plan.
A sophisticated AI product does not advertise intelligence at every turn. It uses intelligence quietly at the point where it makes a person more capable. Sometimes the best AI decision is a better form.