16 September 20267 minute read
The first AI-agent project should prove that a specific piece of work can be helped, not that the organisation “has AI”. That sounds conservative. It is how you avoid spending a quarter on a widget nobody trusts and nobody can measure.
A good first use case is boring in the best sense. It happens often. People already know what a good answer or a good next step looks like. The knowledge can be gathered and approved. If the agent is wrong, someone can catch it before the business is committed.
Score the candidate, do not audition demos
List the operational pains you already have: repeated questions, slow triage, hunting for the current procedure, re-keying between systems, preparing drafts from the same information. Then score each candidate against a handful of tests.
- Volume: does this happen often enough that improvement would be felt?
- Clarity: can you describe a successful outcome in one sentence?
- Knowledge: is the required information written down and ownable?
- Systems: can the agent connect to the place work already lives, or would it sit off to the side?
- Failure: if it is wrong, is the harm bounded and visible?
- Owner: who will maintain the content and review the results after launch?
- Measure: what number or observable behaviour would change?
The highest score is not always the most fashionable idea. An internal assistant that helps staff find the current process can beat a public chatbot that has nothing reliable to say. A triage agent that prepares cases for a team can beat a fully automated reply that the business is not ready to stand behind.
Prefer a pilot with a back door
Run the first version with a limited audience, a clear escalation path and a human in the loop. Use real examples, not workshop fiction. Keep a log of misses. Decide before you start what would cause you to widen the pilot, change the scope or stop. If you cannot name that decision, you are not ready to build.
Do not start with the shop window unless that is the work
A website agent is the right first project when a large share of genuine enquiries are repetitive, the answers exist, and the team is ready to maintain them. It is the wrong first project when the real pain is inside operations, when knowledge is scattered, or when leadership mainly wants something visible. Visibility without a use case becomes a support burden.
Choose the work that already costs time. Design the smallest agent that can help with that work under control. Then let evidence, not enthusiasm, decide what comes second.
