What should a company automate with AI first?

Handoffs rather than tasks. Most organizational time is spent waiting for context, for an answer, or for someone to look at something, not on the work itself. A useful test before building: does this output have a named consumer and a deadline? Automation producing artifacts nobody is waiting for creates review debt rather than saving time.

What can AI automate for each team in a company?

Support: ticket triage with account history attached and routing, which has a lower trust bar than customer-facing deflection. Sales: turning calls into structured CRM records and flagging what changed since last contact. Finance: answering recurring warehouse questions while always showing the query. R and D: release notes, migrations, test repair. Product: scheduled research synthesis and data questions answered in the channel. Leadership: a monitoring digest of what changed and what needs a decision.

Why do AI automation projects stall?

Access, not model quality. The agent needs to reach a system somebody owns, under permissions somebody must approve, with a record of what it did. Teams that treat access as paperwork at the end lose weeks. Granting an agent access to a shared channel also grants everyone in that channel whatever the agent can query.

What is review debt in AI automation?

A correct output that a person still has to read line by line before anyone can use it. That is a second draft with extra steps rather than automation. The fix is scope rather than prompting: narrow the job until the output is trustworthy without inspection, then widen slowly. An agent doing one thing you no longer check beats an agent doing nine things you always check.

Automating a Company With AI: Handoffs Over Tasks

What should a company actually automate with AI? Not tasks. Handoffs. The time in most organizations does not go into doing the work, it goes into waiting: for context, for an answer, for somebody to look at something.

A useful test before building anything: does this output have a named consumer and a deadline? Automation that produces artifacts nobody is waiting for does not save time. It creates review debt and calls it progress.

Task lists are the wrong unit

Every list of AI use cases looks the same. Summarize the meeting, draft the email, write the ticket. Each saves a few minutes, the minutes are real, and none of it changes how the company runs.

Look at where a week actually goes and the pattern is different. A question sits in a channel for 2 days because the person who can answer it is in meetings. A decision waits on a number nobody has pulled. A customer issue crosses 3 teams and loses context at every boundary. The work was never the bottleneck. The gap between the work was.

Going stakeholder by stakeholder

Support is where most companies start, usually on deflection, which is the harder problem. Triage is the better first target: read the ticket, attach the account history, route it, and say what has been tried before. Nothing customer-facing, which means a much lower trust bar.

Sales loses value between the call and the record. Notes exist, the CRM is stale, and the follow-up gets written from memory. The automation is not writing the email. It is turning the call into a structured record, then telling the rep the 2 things that changed since last time.

Finance spends an unreasonable share of its time answering the same 6 questions in different clothing. An agent with read access to the warehouse and a skill describing what the numbers mean here answers them, provided it always shows the query it ran.

R&D already has this well mapped: release notes, migration work, test repair, review. The unglamorous win is the changelog nobody writes, which is also the thing every other team asks for.

Product gets 2. Research synthesis on a schedule rather than when someone has a free afternoon. And the data question, answered in the channel where it was asked instead of becoming a 3-day queue for an analyst.

Leadership wants one thing: what changed and what needs a decision. That is a monitoring job, and it is the only one on this list where the output is genuinely read every time.

Access is the hard part, not the model

Every automation above is easy to describe and hard to ship, and the reason is almost never model quality. It is that the agent needs to reach a system somebody owns, under permissions somebody has to approve, with a record of what it did.

Which turns an automation project into an access project. Who approves the connection, what the agent can read, what it can write, and where the log goes. Teams that treat this as paperwork at the end lose weeks. Teams that start there ship.

It is also worth being explicit that granting an agent access to a shared channel grants everyone in that channel whatever the agent can query. That is a permissions decision wearing a convenience costume, and I went into it in Agent Teams for a Product Org.

The review-debt trap

The most common failure is not a wrong output. It is a correct output that a person still has to read line by line before anyone can use it. That is not automation, it is a second draft with extra steps, and it is how enthusiasm turns into a graveyard of unread summaries.

The fix is scope, not prompting. Narrow the job until the output is trustworthy without inspection, then widen it slowly. An agent that does 1 thing you no longer check beats an agent that does 9 things you always do.

Where to start

Start where the process is already written down, because that work is half done and the gap between the document and reality is about to become visible, which is useful on its own.

Then pick the queue with the longest wait and the lowest stakes. Not the most impressive use case. The one where being 20 minutes faster changes somebody's day and being wrong changes nothing. Trust compounds from there, and it is the only currency that matters, because an organization that has watched one automation quietly fail will not fund the next 5.