# 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. Version 1.0 · 2026-07-29 · 8 min ## 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 - Choose a repeated job with a named user and a visible result. - Embed help where the work already happens instead of opening another destination. - Extend only after the first workflow survives real questions and exceptions. ## 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. ## 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. ### 1. Name 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. ### 2. Define 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. ### 3. Reuse 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. ### 4. Connect 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. ### 5. Observe 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. ## Examples ### 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. ## Checklist 1. One named user group and one recurring moment. 2. A clear distinction between answer, guidance, handoff and execution. 3. A server-validated identity and product context. 4. A short list of authoritative sources and useful tools. 5. Representative questions, including ambiguous and denied cases. 6. A human escalation or recovery path. 7. An owner who reviews failures and source gaps. ## Limitations - 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 1. [Guidelines for Human-AI Interaction](https://www.microsoft.com/en-us/research/wp-content/uploads/2019/01/Guidelines-for-Human-AI-Interaction-camera-ready.pdf) — Amershi et al., Microsoft Research, 2019; type: research. 2. [Artificial Intelligence Risk Management Framework 1.0](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10) — NIST, 2023; type: standard. 3. [Owning the Workflow in B2B AI Apps](https://a16z.com/owning-the-workflow-in-b2b-ai-apps/) — Andreessen Horowitz, 2025; type: field-practice. 4. [Software Is Changing (Again)](https://www.youtube.com/watch?v=LCEmiRjPEtQ) — Andrej Karpathy, 2025; type: field-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. --- Canonical: https://scoperail.fokalabs.io/en/guides/bring-ai-into-existing-workflows Author: Ramzi Laieb, FokaLabs