Most companies that stall on AI do not stall because the technology is too hard. They stall because they start with the technology and try to solve the whole problem at once.

The fix is to start with the outcome. Decide what you want to be different. Find the smallest repeated task that moves it. Automate that one job, with a person approving the output before it goes anywhere that matters. Then judge it by what your people do with the time it gives back.

Start with the outcome

Before anyone talks about agents or models, write down what you want to be different. Fewer hours spent on a task. Faster turnaround for customers. Fewer errors in something that gets rekeyed by hand. Be specific enough that you would know in a month whether it had happened.

Most conversations start the other way round, with a capability looking for a use. Turning it round is most of the work.

Why doing everything stalls

People look at a workflow and try to automate every step of it. The agent then has to handle every exception, connect to every system and be trusted with every decision. That is a lot to ask of the first thing you build, especially when your team has never built one.

Reference architectures can make this worse. AWS has published one for building agents on Bedrock AgentCore that runs to seven layers.

It is worth a look: the AgentCore reference architecture sets out each layer and what it is for.

It is not wrong. A large enterprise with dozens of agents in production will need to think about every layer. But when a 200-person company with no AI team treats it as a to-do list, each layer becomes a workstream. The project turns into an infrastructure programme before a single task has been automated. Months pass and nothing reaches production.

Pick one small, repeated job

Look for one step inside a workflow, not the whole thing. For a first use case I would want all of these:

• Volume. It happens often enough that the time saved adds up. A task done twice a month is not worth it, however annoying it is.
• Repetition. It is done the same way most of the time.
• Low stakes. If the output is wrong, someone catches it and the cost is a few minutes, not a lost customer or a compliance issue.
• A human who does it today. Someone knows what good looks like and can check the output quickly.

That last one gets underestimated. The person who does the task today is your quality control, your test data and your best source of edge cases.

Then write down the boundaries. A known input, such as an inbound email or a ticket of a particular type. A known output, such as a draft reply or a populated record. And it stops there. If the description keeps growing “and then it also” clauses, you have found the next project, not this one.

One of the most useful quick wins I built was about as simple as an agent gets. Data about our platform was posted into a Slack channel every day. The information was all there, but not in a form that was easy to take in. The agent took that data and published it to a shared dashboard, turning it into something visual and quick to read.

It met the criteria. It ran daily. The input arrived in the same shape each time. If the dashboard was ever wrong, the raw data was still sitting in the channel to check against. And the person reading the output was me, using it to spot potential issues with the platform that I could then go and investigate.

What made it work was what I left out. I did not try to get it to resolve issues or send alerts. Those were the obvious “and then it also” clauses, and both were jobs for another agent. This one took data in and published it to a dashboard. That was enough to be useful, and small enough to actually ship.

Put a human at the gate and name an owner

Nothing the agent produces goes to a customer, into a system of record or near sensitive data without a person saying yes. This is how you learn. Every approval and correction shows you where the agent is reliable, and after a few weeks you have evidence about which outputs no longer need checking. It also keeps the risk conversation short.

Once it is live, someone in the team that relies on it has to own it. Not the supplier, and not whoever built it as a side project. I covered why in The tools your team built are now your problem.

Measure what people do instead

The instinct is to count minutes saved and stop there. Time saved matters, but it is not where the value is. The value comes from what people can now give their attention to. The analyst who stops copying numbers between systems and spends that time on the analysis. The client service lead who stops triaging the inbox and talks to the customers who need it.

So track the time taken out of the task, then track where that time went and whether it moved the outcome you wrote down at the start. If the freed-up hours disappear into more of the same, the agent is working and the organisation has not caught up yet. That is a management question, not a technology one. There is a related trap in judging AI purely on cost, which I wrote about in More efficient, more expensive.

My customer operations team gave me a good example of this. A lot of their day went on copying data by hand. Information arrived by email, through support tickets and from website updates, and someone had to take it and key it into several different places in our backend. The same piece of information, typed in again and again.

They added an AI-assisted automation that took the data from those inputs and put it where it needed to go. It saved many hours of work. If I had stopped counting there, it would have looked like a decent result.

The bigger change was in the errors. Every manual copy is a chance to get something wrong. When the same data is keyed into several systems, a mistake in one place tends to surface somewhere else later, sometimes in front of a customer. Taking the copying out took most of those mistakes with it.

The stakes were high. An error could mean we failed to cover an event, started our services at the wrong time or covered the wrong event entirely. All of those would be very visible to clients, and none of them would be easy to explain.

Because those mistakes mattered so much, we had put a four-step peer review process in place to catch them. Frankly, it was a waste of time. Four rounds of checking slowed everything down, and most of what they were catching came from the copying itself.

With the copying automated, we cut it to a single human review. A separate agent sat alongside it, with one job: highlight potential errors for the reviewer to look at. The person at the gate stayed. The extra rounds did not.

Then there was where the time went. The team did not just get through the same work faster. They put the hours into work that improved the quality of the service we provided.

Some of the time went into capacity. We could onboard more customers without adding headcount, which on its own would have justified the work.

The rest went into quality. The team spent more time on research and discovery, the kind of work that had always been squeezed out by the copying. They also started building agents of their own to improve how the service was delivered. The people who had been typing data into the backend were now the ones deciding what to automate next.

The improvement showed up in the results.

The agents the team built to speed up research increased our overall coverage. They also made targeted coverage possible in specific areas where it had always been a struggle.

That fed straight into our ability to deliver the service in new regions. With the business expanding globally, that mattered far more than the hours saved on copying.

That was how I knew it was worth it. The hours saved were the easy number to count. The real return was fewer errors to chase and a team spending its attention on making the service better.

Small is how you get to big

The seven-layer architecture may well be where you end up. You get there by building one agent that works, then another, and finding out which layers you actually need. A small first project gives you an immediate impact and something harder to buy: a team that knows how to scope, test and own an agent, learned on a problem where mistakes are cheap.

Start with the outcome. Pick one job. Put a person at the gate. Measure what people do with the time you gave them back.