Start with recurring work
Good candidates are visible and frequent: a report rebuilt every week, leads that sit without follow-up, inbox triage, document classification, quality checks, research preparation, or handoffs that repeatedly lose context.
Do not start with the most impressive use case. Start where the current process is understood well enough to measure and the downside of a mistake can be controlled.
Define the workflow before the model
Map the trigger, inputs, permissions, decisions, outputs, owner, exception path, and record of what happened. A model is one component inside that system. Without an operating design, even a strong model becomes an unreliable demo.
- What starts the workflow?
- Which systems and data may it access?
- What can it decide, draft, or change?
- Where is human approval mandatory?
- How will errors be detected and reversed?
Put judgment at the risk boundary
Internal research, classification, summarization, and draft preparation are different from sending a message, changing a record, approving payment, or publishing content. Human review belongs before the consequential action, not after damage is already possible.
Permissions should be narrow, identities explicit, and logs readable. A workflow that cannot explain which source it used or what it changed is not ready for important work.
Use proof and kill criteria
Measure the baseline first: time, error rate, backlog, response time, conversion, or another business outcome. Then run a bounded pilot and compare. Usage is not proof if the workflow creates more review burden than it removes.
Kill or redesign the automation when it repeatedly needs rescue, cannot achieve an agreed accuracy threshold, creates new security or relationship risk, or costs more attention than the original process. Practical AI earns trust through observable work—not claims about intelligence.