Bring AI into the workflow, not beside it.
A practical way to choose one useful workflow, embed AI in the software people already use and avoid building another empty chat surface.
Short answer
Start with work that already happens often and has a clear handoff. Put assistance at the point where the person has the question, reuse the identity and context already available, and improve one observable outcome. Do not begin with a general assistant or a connector catalogue. A narrow production workflow teaches you more than a broad demo because it exposes access rules, missing data, exceptions and the real cost of recovery.
Key points
- 01
Choose a repeated job with a named user and a visible result.
- 02
Embed help where the work already happens instead of opening another destination.
- 03
Extend only after the first workflow survives real questions and exceptions.
01 / SITUATION
The extra tool is often the first source of friction
A small industrial company may already use an ERP, shared folders, email and a maintenance tool. A construction team may move between a planning application, procedures and phone calls. A SaaS user is already inside the product when a question appears. Sending any of them to a separate AI workspace removes the screen, record, role and decision that made the question meaningful.
The useful unit is therefore not “an assistant for the company”. It is a workflow: one person is trying to reach one outcome under known constraints. The interface can still be conversational, but the product is the passage from question to valid progress.
02 / MECHANISM
A five-part production slice
The first slice should be small enough to understand end to end and important enough that people will actually use it.
- 01Name the user and moment
Specify who is asking, which tool is open and what event created the need. “Operators reviewing a blocked request” is testable. “Employees using AI” is not.
- 02Define the useful outcome
Choose whether the system should answer, guide, prepare a handoff or propose an action. Keep execution separate until its risks and recovery path are explicit.
- 03Reuse available context
Pass identity, route, selected record and effective permissions from the host product. Do not ask the user to restate information the software already knows.
- 04Connect the minimum evidence
Use only the documents, live fields and tools required by this workflow. A smaller context is easier to evaluate and easier to keep current.
- 05Observe and extend
Review weak answers, missing sources, denied actions and human escalations. Add a second workflow when the first one has a stable owner and feedback loop.
03 / In real work
Field operations
A site manager opens an incident record. The assistant combines the current site, equipment type and approved procedure, then prepares a complete escalation if the procedure does not resolve the issue.
Accounting
A clerk asks why an entry is blocked. The answer uses the current record and policy, distinguishes missing evidence from insufficient access and points to the next valid step.
B2B software
A customer asks how to configure a feature from the relevant screen. The answer uses the plan, role and current settings instead of returning a generic help article.
Internal support
A vague message becomes a proposed ticket containing the current module, observed behavior, expected outcome and sources. The employee checks it before sending.
Common failure modes
- Launching a company-wide assistant before anyone owns a first workflow.
- Moving the user into another tab and losing the product state that explains the question.
- Calling document search a complete answer when live state changes the result.
- Measuring message volume instead of whether the intended work moved forward.
- Adding actions before permissions, confirmation and recovery are testable.
Implementation checklist
- One named user group and one recurring moment.
- A clear distinction between answer, guidance, handoff and execution.
- A server-validated identity and product context.
- A short list of authoritative sources and useful tools.
- Representative questions, including ambiguous and denied cases.
- A human escalation or recovery path.
- An owner who reviews failures and source gaps.
What this approach does not claim
- A narrow workflow does not prove that the same design will generalise to every team.
- Embedding assistance does not repair unreliable source systems or unclear ownership.
- The best first workflow is a product decision. It cannot be selected from model capability alone.
Sources and reference types
- 01Guidelines for Human-AI InteractionAmershi et al., Microsoft Research · 2019Research
- 02Artificial Intelligence Risk Management Framework 1.0NIST · 2023Standard
- 03Owning the Workflow in B2B AI AppsAndreessen Horowitz · 2025Field practice
- 04Software Is Changing (Again)Andrej Karpathy · 2025Field practice
Practical questions
Should the first workflow be the most valuable one?
It should be valuable enough to matter, but bounded enough to test. Avoid starting with the highest-risk decision if a nearby read or prepare workflow can establish the context and evaluation first.
Does the experience need to be chat?
No. The same context layer can power inline guidance, a command surface, a form assistant or a chat. Use the interaction that best fits the work.
When should we add a second workflow?
After the first has representative evaluations, a visible recovery path and an owner who can explain its failures. Usage alone is not enough.