Your first AI project should start with the work.

It's easy to begin an AI project with a capability: a chatbot, an agent, a document summarizer. The technology is tangible, and a working demo comes together quickly. But a capability is not yet a reason for someone to change how they work.

A more useful question is simple: where does work get stuck?

Perhaps a support specialist has to search three systems before drafting a response. Perhaps a new team member cannot tell which version of a policy is current. Perhaps an operations team spends each morning extracting the same fields from incoming documents. Each situation gives you a task, a context, and a person who can tell you whether the result helps.

Follow the friction.

Spend time with the people doing the work. Ask them to walk through a recent example rather than describe the ideal process. Notice where they search, copy, reconcile, check, or ask a colleague for clarification.

A useful opportunity often sits at the intersection of three conditions:

• The task repeats. There are enough examples to understand the pattern and enough frequency for an improvement to matter.
• Relevant information exists. The answer isn't unknowable; it is difficult to find, interpret, or use.
• A person can judge the result. Someone can explain the difference between a helpful output and a plausible one.

These conditions don't guarantee AI is the right answer. They make the problem concrete enough to investigate. A better search interface, a clearer form, or a conventional rule may solve part of it more simply.

Collect examples before writing prompts.

A handful of real tasks will tell you more than a long list of desired features. Collect typical requests, difficult requests, and examples where information is missing or contradictory. Include the material a person used to complete the task and what the final result looked like.

For a support drafting assistant, that could mean representative questions, the relevant knowledge articles, and responses reviewed by the support team. For document intake, it could mean several document formats, expected extracted fields, and known exceptions.

Treat this collection as a design tool. It exposes the context the system needs, the limits it must respect, and the decisions that still require a person.

Define better in observable terms.

“Save time” is a direction, not a complete success criterion. A system might draft quickly and still create more review work than it removes. Write down the conditions that make the output usable.

For a knowledge assistant, a useful answer may need to cite the current policy, stay within the user's access permissions, and admit when the source doesn't contain an answer. For intake automation, extracted fields may need to match the original document and incomplete cases must be routed for review.

Combine quality criteria with workflow measures. How much correction is required? Does the person understand the result? Where does the process stop? You want to measure whether the work improved, not simply whether the model responded.

Make the first scope deliberately small.

Start with one request category, one approved source collection, or one operational process. A narrow scope helps you find failures and understand their causes. It also makes it possible to set a clear boundary around what the system should do.

Be explicit about what happens outside that boundary. An unfamiliar request can be sent to the existing workflow. A missing source can trigger clarification. A consequential action can require approval. A useful system does not have to handle every situation to improve one important task.

Let evidence shape the next step.

A first project should produce a working system and a better understanding of the problem. Put it in front of the people who will use it. Review difficult cases together. Separate failures caused by missing knowledge, poor retrieval, confusing interfaces, and model behavior.

Then decide whether to improve the same workflow, expand its scope, or stop. Each is a reasonable outcome when it follows evidence. The aim is useful progress, not a larger collection of AI experiments.

Start with the work. The architecture will have a much clearer job to do.