Talk to us
← All insights

Operations

What Should an Operator Automate First With AI Agents?

The first agent workflow should have costly coordination, a clear owner, and bounded action. Repetition alone is a weak reason to automate work.

Repetitive Work Is an Incomplete Signal

Operators are often told to find the most repetitive task and automate it. That advice came from systems that needed fixed steps. Agents can interpret language and decide within policy, so the candidate set is wider.

But repetition still doesn't tell you where to begin.

A task can repeat often while depending on broken source data and unwritten judgment. Automating it first may create a fast exception generator. Another workflow with lower volume might consume days because information has to be gathered across systems before a routine decision.

Our position is that coordination cost is a better starting signal than repetition. I’d change my mind if high-volume tasks consistently produced faster, safer agent releases regardless of process condition. The hidden exceptions usually decide the result.

Look for Waiting and Reassembly

Follow a case through the operation. Notice where it stops because a person needs a fact from another system or waits for someone to interpret a request. Watch for work that gets copied into a new format so the next team can use it.

Those handoffs are promising. An agent can gather context, reconcile obvious conflicts, and prepare the next action without forcing the whole process into one rigid script. The value often comes from removing elapsed time rather than reducing keystrokes.

Ask operators what they check before moving a case forward. Their answer reveals the real workflow. The written procedure may say “validate request,” while the operator describes six conditions and a known exception for one region.

Don't turn every judgment into prompt text. Some conditions belong in policy code. Others indicate that the source system needs repair before any agent should act.

Demand a Named Owner

The first workflow needs one person who owns its result. That owner can decide which cases are in scope and accept changes to the operating process. A committee can advise, but it can't handle a Tuesday morning incident.

Ownership is a readiness test. If finance believes the workflow belongs to operations and operations believes it belongs to IT, the agent will inherit the dispute. Its exceptions will sit in a queue with no service expectation.

The owner also defines value. Maybe speed matters because delayed cases block revenue. Maybe accuracy matters more because corrections are expensive. Pick the measure that reflects the reason for doing the work.

Engineering needs an owner too, but don't confuse technical custody with business accountability. Keeping the service available isn't the same as deciding whether its action policy is acceptable.

Choose a Narrow Action Boundary

Good first workflows create useful work before they receive broad authority. An agent might assemble a case and recommend a disposition while a person executes it. It may draft a supplier response but never send one when a contract term is disputed.

This isn't permanent training wheels. It is a way to observe decisions using production inputs without accepting every consequence at once.

Write the boundary as an action contract. State what the agent can read, what it may propose, and what changes it can make. Identify the conditions that force escalation. If the contract needs pages of exceptions, the slice is still too broad.

Reversibility helps. A tagged internal record can be corrected. Funds sent to the wrong party require recovery. Start where errors remain visible and containable while the team learns how the agent behaves.

Inspect the Input Distribution

Pull a recent sample of real cases. Don't let subject matter experts choose only clean examples. Include incomplete requests and records created under old policy.

Group failures by what prevents completion. Missing evidence is different from ambiguous policy. An unavailable system requires a different fix than an agent that misreads a document.

Then estimate how much of the queue fits a stable boundary. The first release doesn't need to handle everything. It needs enough eligible work to justify operation and reveal normal variation.

Avoid inventing a target percentage. The right coverage depends on value per case and review capacity. A small slice of slow, expensive work can matter more than broad coverage of trivial tasks.

Count the Human Work That Remains

An agent can move labor instead of removing it. Someone may now review drafts, repair malformed inputs, or investigate alerts. Measure that work during the pilot.

Watch the review queue by reason. If the same missing field blocks many cases, fix intake. If operators routinely override one recommendation, the policy or evaluation rubric may be wrong. If reviewers approve everything without inspection, the gate has become ceremony.

The comparison should use elapsed time and accepted outcomes. Faster generation means little if completed work waits in a new queue.

Also ask whether the remaining human work is better. Operators may welcome fewer searches while keeping the consequential decision. Or they may receive only the hardest cases without enough context, making the job worse.

Score Readiness Without Hiding Tradeoffs

A simple decision sheet can keep selection honest. Record the workflow owner, the measurable outcome, source accessibility, action consequence, and expected review path. Don't collapse them into one magic score.

A strong value case can't cancel an unacceptable action boundary. Excellent data can't supply missing ownership. Keep veto conditions visible.

Compare a few candidates using evidence from observed work. Avoid a company-wide idea contest that rewards the most polished pitch. Operators closest to the queue can show where cases stall and which exceptions consume attention.

Pick the workflow whose uncertainties can be tested in a bounded release. Some high-value candidates should wait because a policy decision or system change comes first. That is sequencing, not failure.

Automate the Next Constraint

Once the first agent runs, resist expanding it just because the architecture exists. Look at what still limits the outcome. The bottleneck may have moved downstream.

If case preparation is now fast but approvals take days, improve the decision packet or approval policy. If source errors dominate, repair the record creation path. Adding more reasoning won't help either problem.

An internal agent workforce should grow from observed constraints, with each new role attached to an owner and a work unit. That produces less theater and more durable capacity. Start where coordination is expensive, action can be bounded, and the operation is ready to own the result.

FAQ

Frequently asked questions

What is the best first workflow for an AI agent?

Choose a workflow with a named owner, observable inputs, and an outcome the business already measures. It should contain enough language or judgment to need an agent while keeping action authority narrow.

Should the most repetitive task be automated first?

Repetition can indicate volume, but it doesn't show whether the work is safe or valuable to automate. A repetitive task with poor source data and many hidden exceptions can be a bad first target.

How can an operator tell if a workflow is ready for an agent?

Follow real cases from intake to completion and document where people seek context or make exceptions. The workflow is ready when its sources, owner, action boundary, and failure path can be stated plainly.

What should remain manual during the first release?

Keep rare cases and actions with hard-to-reverse consequences on the existing path. Let the agent handle the bounded slice while collecting evidence about what can safely move next.