← All insights

OriginLines field notes

How to choose the first AI workflow worth automating

· 5 min read · OriginLines, Product and AI Engineering

Start with the work slowing the team down

The best first AI project is a repeatable task that takes real time and produces a result the business can measure.

Begin with the people doing the work today. What triggers the process? What information do they collect? Which decisions require judgment? What systems do they update? Where do they wait, repeat themselves, or correct mistakes?

Write those answers down before choosing a model. If you want help mapping the workflow, see our AI automation service.

Five signals that a workflow is a good candidate

The work happens often enough to matter

A workflow that runs several times a day gives you more observations and a larger payoff than one used quarterly.

The input and output can be described

Production automation needs boundaries. The input may be a customer request, a document, an account event, or a set of records. The output may be a recommendation, a drafted response, an updated system, or a case routed for review.

If neither side can be defined, the workflow is probably still too broad.

The required data and tools are accessible

An agent cannot improve a workflow if the necessary information lives in inaccessible systems or if the actions it needs to take have no dependable interface. Data access, permissions, and integration work should be assessed before model quality.

Success can be measured

Useful measures include time to completion, manual touches per case, error rate, escalation rate, cost per outcome, and the percentage of work completed without rework. Choose the measure before building.

A safe review path exists

The first release should make uncertainty visible. Low-confidence or high-impact decisions can be prepared by the system and approved by a person. Keep review in the design when the decision is uncertain or high impact.

Define the first production release

The first release should automate one complete path rather than partially touching ten paths. Define the trigger, required context, allowed actions, approval rules, success measure, and fallback behavior.

For example, "automate onboarding" is too broad. "When a signed customer enters the CRM, verify the required data, prepare the workspace configuration, and route exceptions to an operations specialist" is specific enough to engineer and evaluate.

Avoid building a platform first

Teams often respond to uncertainty by designing a general AI platform. That moves the work away from the operating problem and creates infrastructure before the team has learned what production behavior actually requires.

Build the narrow workflow, log what happens, and learn from real use. Shared infrastructure becomes obvious after more than one workflow needs it.

The decision to make

Pick the workflow with frequent work, accessible data, a measurable result, and a review path. Build that first.

Put it into production

Have a related workflow or product?

Talk through the outcome, the operating constraint, and the smallest release that could create evidence.

Discuss the first release (opens in a new tab)