The best first AI loop is usually frequent enough to generate learning, painful enough that people want it, clear enough to specify, bounded enough to control and small enough to reach production quickly.
Do not begin with the process that looks most impressive in a strategy deck.
Begin with the smallest whole loop that matters and can teach you something quickly.
The easiest task is rarely the best task
When organisations begin experimenting with AI, they often look for something safe and easy.
Summarise a document. Generate a few social posts. Draft an internal email.
Those tasks are easy to demonstrate because the downside is small.
But nobody was especially worried about them before the demonstration. Nobody owns the result. Nobody is waiting for the improvement. When the novelty wears off, the experiment quietly disappears.
The organisation concludes that adoption is difficult.
The real problem is that it chose work nobody cared about.
A useful first loop should solve a problem people already feel.
Look for repeated waiting, rework, risk or customer friction. Look for a workflow that repeatedly loses context at a handoff. Look for work that depends on somebody remembering to move it forward.
That is where adoption has a reason to happen.
Start with a bottleneck, not a labour estimate
Theoretical hours saved can be misleading.
Automating a task that consumes 100 hours may create little value if nothing is waiting for it and the result does not affect the system around it.
Improving a 20-minute step can matter enormously if every customer, project or decision has to pass through it.
Ask:
- Where does work repeatedly wait?
- Where do people copy the same context between systems?
- Where does the same information get reinterpreted by several teams?
- Where do errors create downstream rework?
- Where does a customer have to carry context from one department to another?
- Where does one manager repeatedly become the approval queue?
The first loop should improve the speed or reliability of the whole workflow, not simply make one participant faster. This is the same logic behind why AI ROI isn't incremental: you're only as fast as your tightest bottleneck.
Use three tests: valuable, ready and safe
An exciting idea is not necessarily a credible first implementation.
Test it against three categories.
1. Is it valuable?
Value begins with a visible problem.
Ask:
- Does the work happen frequently?
- Does it consume meaningful time or attention?
- Does delay, inconsistency or error create a recognisable cost?
- Would a better outcome matter to a customer, employee or decision-maker?
- Does the improvement remove a genuine bottleneck or merely create more output?
Frequency matters because a loop needs opportunities to learn.
A painful workflow that occurs once every two years may be valuable, but it will not give the organisation a fast feedback cycle.
A weekly reporting process, repeated sales follow-up or customer-support handoff can generate useful evidence within days.
The people affected should also want the result.
Adoption is easier when the loop removes a frustration they already experience. It is much harder when a transformation team has to persuade them that an invented problem matters.
2. Is it ready?
Technical capability is not the same as organisational readiness. I've written about what makes a process ready for an AI agent; readiness asks whether the work can be delegated, while prioritisation asks whether this is the work the organisation should delegate first.
A process is ready when the business can answer:
- What observable event starts it?
- What must be true when it is done?
- What real-world state should it create?
- Who owns the specification?
- Which resources are authoritative?
- Can the agent access the tools it needs?
- What may it act on?
- When must it ask?
- When must it stop?
If sales, finance and delivery disagree about what a good proposal is, building a proposal agent will not resolve the disagreement.
The agent may make the ambiguity more visible. It cannot make the missing business decision on the organisation's behalf.
Readiness does not mean everything is perfectly documented.
It means the first version has enough clarity to run end to end without inventing its goal, its authority or its source of truth.
3. Is it safe to learn with?
The first version does not need maximum autonomy.
It needs a controlled way to generate evidence.
Ask:
- Can the first version be small and whole?
- Are most actions recoverable?
- Are act, ask and stop boundaries clear?
- Can sensitive permissions begin conservatively?
- Can the affected people observe what happened?
- Will the business receive evidence quickly?
The important distinction is between a small whole loop and a partial demonstration.
A small whole loop starts from a real trigger, completes real work and creates a real business state.
A partial demonstration generates an impressive artefact but leaves the remaining work to a person.
For example, an agent that drafts a follow-up email is a partial capability.
A small sales follow-up loop might handle only standard enquiries for one approved service. But it receives the enquiry, gathers the context, sends an accurate response, updates the CRM and gives the next action an owner and date.
Its scope is narrow, but the loop is whole.
A practical comparison
Imagine a fictional 240-person services business considering three first projects. The situation is a composite of recurring patterns rather than one identifiable client.
Candidate one: company-wide AI knowledge assistant
It sounds impressive.
But the company has conflicting documents, unclear ownership and no agreement about which policies are authoritative.
It may be valuable, but it is not ready.
Candidate two: automatic birthday messages
It is easy, bounded and safe.
But nobody experiences birthday messages as a meaningful business bottleneck.
It is ready and safe, but not valuable enough to drive adoption.
Candidate three: meeting-to-action for the delivery team
Project meetings happen every day. Actions are frequently lost. The transcript, calendar and project system are accessible. The first version can be restricted to one team.
It is valuable, ready and safe to learn with.
That is the strongest first loop.
Do not optimise only one function
A first loop should have a clear boundary, but its definition of success should include the handoff.
If marketing triples its output while sales, legal and delivery remain unchanged, the organisation has not tripled its productivity. It has sent more work into the same downstream constraints.
This is why "when done" matters.
A content campaign loop should not end when twelve posts exist. It should end when a coherent campaign is in market, responses enter the correct system and measurement links back to the goal.
A proposal loop should not end when a document looks good. It should end when the customer has a proposal it can accept and the business has a commitment it can deliver profitably.
Choose a loop whose outcome matters beyond the person operating the tool.
Speed is part of the selection decision
The larger the first project, the more likely the original context will disappear before anybody uses it.
The request is made. A business case is assembled. The work is scoped. Several approvals are sought. By the time something reaches staging, the people involved have moved on, priorities have changed and nobody wants to reopen the decision.
That does not mean every useful loop must be built in five days.
It means a first loop should be capable of reaching real work before attention and ownership disappear. The evidence for this is in why small AI builds get adopted faster.
Prefer a narrow version that can be tested now over a broad version that promises completeness later.
A simple first-loop scorecard
Score each candidate from one to five.
Value
- Frequency
- Cost of delay
- Rework or error
- Customer or employee impact
- Importance of the bottleneck
Readiness
- Observable trigger
- Agreed outcome
- Testable definition of done
- Named owner
- Accessible tools and authoritative resources
Safety to learn
- Recoverable actions
- Clear authority boundaries
- Narrow first scope
- Fast evidence
- Ability to supervise temporarily without making approval permanent
Do not automatically choose the highest total.
Look for a candidate with no fatal weakness. A valuable loop with no owner is not ready. A safe and clear loop nobody cares about will not create momentum.
What should happen in the first 90 days?
In the first 30 days, map candidate workflows, select one loop, name its owner and establish a baseline.
In the next 30 days, build the smallest whole version and put it into real work.
In the final 30 days, study the corrections, exceptions and failures. Update the specification deliberately. Decide whether to stabilise it, expand it, connect an adjacent loop or stop.
Thirty days to understand and choose.
Thirty days to build and run.
Thirty days to stabilise and compound.
Bottom line
Your first AI loop should not be the easiest task to automate or the grandest transformation you can imagine. Choose work that already matters, and make the first version small enough to finish, whole enough to create a real result and safe enough to learn from.
The goal of the first loop is not to prove that AI works.
It is to teach the organisation how to put useful AI work into production.
