The Best First AI Project Is Usually Boring
The first AI project in your business probably should not be the most ambitious one. It probably should not transform an entire department, require access to every system you own, or give an autonomous agent permission to make important decisions on behalf of the business. And it definitely does not need to impress anyone in a demo.
A good first AI project is usually much less exciting. It solves a problem that happens regularly. The problem is painful enough that people actually care about fixing it. The task has reasonably clear boundaries. And, importantly, you can tell whether AI made things better.
Frequent. Painful. Bounded. Measurable.
That combination sounds almost boring. That is exactly why it works. In the previous article in this series, we looked at finding AI opportunities by looking for friction in the work: repetition, searching, copying, checking, waiting, summarising, re-keying and information chasing.
Once you start looking that way, the problem changes. You usually do not have too few AI opportunities. You have too many. The next question is: which one should you start with?
Your first AI project has a different job
Businesses often evaluate their first AI project the same way they would evaluate a mature technology investment. Which project has the biggest potential return? Which process could we automate end-to-end? Where could AI have the largest strategic impact? Those are useful questions later. They are not necessarily the best questions for the first project.
Your first production AI project also needs to teach the business how to operate AI: how to define the problem clearly, get appropriate information into the system, evaluate whether the output is good enough, handle mistakes, decide where human review is required, monitor what happens in real use and establish who owns the result. Those are operating capabilities. You do not learn them from a presentation about AI strategy. You learn them by putting something useful into operation.
This is one reason simpler systems are valuable early. Anthropic's guidance on building AI systems recommends starting with the simplest solution that works and increasing complexity only when it demonstrably improves outcomes. It distinguishes predictable workflows, where the steps can be defined in advance, from agents that dynamically decide what to do next.
The more autonomy and complexity you introduce, the more flexibility you gain, but also the more behaviour you need to test, observe and control. For a first project, learning how to operate a constrained AI workflow is often more valuable than proving you can build the cleverest agent.
A good first AI project passes four tests
You do not need a complicated scoring model to narrow the list. Start with four questions.
1. Is it frequent?
Look for work that happens every day or every week. Frequency matters because small improvements compound. Saving ten minutes from something that happens once a year is not especially interesting. Saving ten minutes from something performed by five people twenty times every week is different.
Frequency also gives you something important with AI: examples. If a task happens repeatedly, you can inspect historical cases, compare AI outputs against work people already completed, identify common cases and unusual ones, and build a useful test set. Once the system is operating, you also get regular feedback about whether it is actually working.
A process that happens twice a year gives you very little opportunity to learn. A process that happens fifty times a week gives you a feedback loop. For an early AI implementation, that feedback loop can be more valuable than the theoretical size of the opportunity.
2. Is it painful?
Frequent is not enough. The task also needs to hurt. Pain can mean too much time, a queue customers are waiting behind, repeated searching across systems, copying information between tools, frequent errors or rework, or simply a job experienced people hate doing because it pulls them away from more valuable work.
The point is not to manufacture an AI use case. It is to remove real operational friction. If nobody particularly cares whether the problem gets solved, it is probably not the right first project. This is also why talking to the people who perform the work matters. A process that looks trivial from a management meeting can be a constant source of frustration for the people doing it every day.
3. Is it bounded?
Can you describe where the task starts and ends? Can you identify the information required, the expected output, what the system is allowed to do and when it should stop and hand the work to a person?
Help our sales team with AI.
That is not bounded. Now consider:
After a customer meeting, take the approved meeting transcript, identify the agreed actions, draft the follow-up email and present it to the salesperson for review before anything is sent.
Now we have boundaries. We know the input, the outputs, where human review occurs and that the AI does not send anything itself. We can collect examples of good and bad outputs. We can measure whether it saves time.
Boundaries matter because language models are probabilistic systems. Give an AI system an open-ended objective, broad access to tools and ambiguous instructions and you create a much larger space of possible behaviour. Constrain the task and the system becomes easier to test, operate and govern.
4. Can you measure whether it worked?
This is the filter businesses skip most often. The AI output looks impressive. People like the demonstration. Everyone agrees it feels faster. The project is declared a success.
But nobody knows what improved.
Before introducing AI, establish a baseline. Depending on the process, that might include average handling time, turnaround time, cases completed, error or rework rate, percentage of cases requiring escalation, cost per case, customer response time, or quality against an agreed rubric.
Then decide what improvement would justify changing the process. OpenAI's evaluation guidance frames this as Specify → Measure → Improve: define what good performance means in business terms, understand the actual workflow, evaluate the system under realistic conditions and improve it from evidence rather than intuition. NIST's AI Risk Management Framework takes a similar operational view. Its Measure function calls for testing before deployment and regularly while systems are in operation, using metrics and performance assessments tied to the real deployment context.
For a small business, this does not need to become a formal laboratory. You just need to know what you are comparing. If a process currently takes 30 minutes per case, measure it. If 15% of work comes back for rework, measure it. If customers wait two days for a response, measure it. Then introduce AI and see what actually changes. Without the baseline, you do not have an AI result. You have an AI story.
What a good first AI project actually looks like
The best candidates are often ordinary operational tasks.
Customer enquiry triage. An AI system reads an incoming enquiry, identifies the type of request, extracts important information and drafts a response for a person to review. The system is not independently managing the customer relationship. It is reducing the work required to understand and prepare the response.
Document information extraction. A team repeatedly receives similar documents and manually copies important fields into another system. AI extracts the relevant information, presents it in a structured format and flags uncertain fields for review.
Meeting follow-up. After customer meetings, somebody spends twenty minutes reviewing notes, identifying actions, updating the CRM and drafting follow-up communication. AI prepares those outputs. A person checks them. Nothing is automatically sent or committed.
Internal knowledge retrieval. Employees repeatedly spend time searching policies, procedures, product information or internal documentation. An AI assistant searches an approved knowledge source, produces an answer and points the employee back to the supporting information.
None of these ideas sounds revolutionary. The process is understandable. The people involved can tell you what good looks like. The output can be reviewed. The impact can be measured. And if the system does not work, the blast radius is relatively small.
Bad first AI projects usually share the same characteristics
Be cautious when your first AI project has several of these characteristics:
the task only happens occasionally
nobody can clearly explain the current process
success is subjective and difficult to evaluate
mistakes create significant financial, legal, safety or customer consequences
the AI needs broad access across many systems
the AI must take irreversible actions
nobody clearly owns the process
there is no useful baseline
success requires several teams to change how they work at the same time
most of the excitement comes from how impressive the demonstration looks
None of those automatically means the project should never happen. It means you may be stacking unnecessary difficulty into the first implementation.
Imagine two potential projects. The first takes customer enquiries, categorises them, finds relevant information and drafts a response for review. The second creates an autonomous sales agent that monitors leads, decides who to contact, searches company systems for context, writes messages, sends them, schedules follow-ups, updates the CRM and decides when to offer a discount. The second project makes for the better demo. The first may make for the better first production system.
Start with a workflow before you start with an agent
The word agent has become attached to almost every AI conversation. Sometimes an agent is exactly what is required. But autonomy is not automatically an improvement.
If the process is reasonably well understood, a defined workflow is often a better place to begin.
Receive document → extract information → validate required fields → draft result → human review → save approved result
The model still performs useful reasoning, but the architecture determines what happens next.
Anthropic describes workflows as systems where models and tools operate through predefined paths, while agents dynamically direct their own processes and tool use. Its recommendation is to match complexity to the problem rather than assuming the most autonomous design is the best one.
For many early business applications, a workflow gives you something extremely valuable: predictability. You can see each step. You can log what happened. You can put deterministic validation around the model. You can decide exactly where human approval is required. And you can add autonomy later if the evidence shows that doing so solves a real limitation.
Start with the architecture you can operate, not the architecture that gives you the best demo.
Build the measurement into the project
Before development starts, write down what you intend to improve. A simple baseline is enough:
Handling time: how long does the task take today?
Quality: how often is the output correct or acceptable?
Rework: how often does someone need to redo the work?
Escalation: which cases require a person?
Cost: what does the current process cost per case?
Then collect representative examples before you build. Include easy examples, normal examples and the annoying edge cases people know cause problems. Have the people who understand the process define what a good result looks like.
This gives you something far more useful than saying, "The AI appears to work well."
You can say: "For this type of case, under these conditions, the system achieved a result we are comfortable putting into the workflow."
That is how AI becomes operational.
Use a five-minute test to choose between projects
If you have a list of potential AI projects, take each one and ask:
Does it happen frequently? Would solving it generate enough repeated value and enough examples to learn from?
Does somebody genuinely care about the problem? Is there meaningful time, delay, cost, frustration or rework attached to it?
Can we draw a box around the task? Do we understand the inputs, outputs, allowed actions and escalation points?
Can someone judge whether the result is good? Is there an employee, customer outcome, rule or rubric that lets us evaluate it?
Can failure be caught before it causes significant harm? Can a person review important outputs, can an action be reversed, or can the system safely hand uncertain cases back?
If a project passes all five, it deserves serious consideration. If it fails most of them, putting AI into it probably will not make the underlying problem simpler.
The real output of the first project is operating experience
Suppose your first AI implementation saves one employee an hour every day. That is useful. But the business may have gained something even more important: it has learned how to take AI from experiment to operation.
You now know more about how business data needs to be accessed, where permissions should be limited, how outputs should be evaluated, which mistakes matter, where human review belongs, what needs to be logged, how performance should be monitored, who owns the system after launch and how employees actually respond to AI entering a workflow.
Those capabilities carry into the second project and the third. This is why a modest first project can be more strategically valuable than an ambitious pilot that never survives contact with the real business. The objective is not to stay small forever. The objective is to learn how to scale without losing control.
From AI experiment to AI operations
AI strategy can quickly become a search for the biggest possible opportunity. That is understandable. The technology is capable of increasingly impressive things, and there is no shortage of demonstrations showing what might eventually be automated. But businesses do not create value from what AI can theoretically do. They create value from systems that work repeatedly inside real processes.
So do not choose your first AI project because it sounds transformative. Choose something frequent. Choose something painful. Choose something bounded. Choose something measurable.
Understand the process first. Establish the baseline. Keep the architecture as simple as the problem allows. Put the right controls around it. Then run it often enough to learn.
Your first useful AI system may not be the project you show everyone. It may simply be the thing your team quietly stops wasting an hour on every day.
And that is a very good place to start.
Cypher Agency helps businesses understand where AI can create practical value, then designs and builds the systems, integrations and controls needed to make it work reliably in the real world.
References
Anthropic. (n.d.). Building effective agents. anthropic.com
OpenAI. (n.d.). How evals drive the next chapter in AI for businesses. openai.com
National Institute of Standards and Technology. (n.d.). AI Risk Management Framework: Measure. airc.nist.gov
National Institute of Standards and Technology. (n.d.). Challenges to the monitoring of deployed AI systems. nist.gov
Comments