The demo is not the job.
A model summarizing a document is impressive for about thirty seconds. The operational question is what happens next: where the document comes from, which facts matter, who uses the summary, and what a mistake could cause.
Start with a repeated piece of work. Describe the input, the judgment, the output and the person waiting for it. A weekly account review, inquiry classification or meeting follow-up can be useful candidates. 'Make our company AI-powered' is not an assignment. It is a conference theme.
Separate language judgment from deterministic rules. Software can validate a field or route an approved status without asking a model to improvise. Reserve model work for ambiguity it can usefully handle. Fewer discretionary steps make the system easier to test and explain.
Permission is part of the design.
Reading, drafting and acting are different capabilities. A system that drafts a follow-up is not automatically authorized to send it. A system that spots an inconsistent record should not silently rewrite the source. Decide these boundaries before connecting live tools.
Use only the data the job needs. Identify the source of truth, who can access it, where it is processed and how long it remains available. Business records can contain instructions written by other people; those instructions are data, not authority to change the system's job.
Put consequential decisions behind an appropriate approval step. That does not mean every harmless formatting choice needs a human click. The design should reflect the impact of being wrong, the reversibility of the action and the authority actually delegated.
Test the awkward cases first.
Happy-path examples are easy to curate. Include incomplete records, contradictory notes, duplicate events, stale information and requests outside the workflow's remit. Include cases where the right answer is a question or no action.
Judge the result against the job, not whether the prose sounds polished. Did it retain important facts? Distinguish a confirmed purchase request from someone exploring options? Expose uncertainty? Stay inside the allowed action?
Exercise the surrounding system. Can a late response overwrite a newer decision? Does a duplicate event create two actions? After a timeout, can the workflow reconcile the outcome rather than blindly repeat it? Adding a model does not make ordinary operational questions optional.
Expand authority after evidence.
Start with a bounded pilot and an owner who can review the work. Compare quality and total handling effort with the current process, including corrections and exceptions. Time saved generating a draft can disappear if someone must investigate every sentence.
Keep an understandable record of inputs, decisions, approvals and outcomes appropriate to the data. Give operators a way to stop work and recover. The process owner should be able to tell what happened without reverse-engineering a conversation.
Expand one boundary at a time. A workflow that drafts reliably may still be unready to publish. A workflow that handles one account type may still be unready for another. The goal is not maximum autonomy. It is useful work you can trust enough to keep using.
Write the job before choosing the model
- Input and authoritative source
- Required output and quality criteria
- Allowed actions and approval boundaries
- Exception owner and recovery path
- Test cases that should make the workflow stop
