Make AI useful. Start with the work.

The first AI project does not need to cover the whole business. It needs to help someone finish a real piece of work.

That is the starting point I recommend when a team wants to use AI but has a long list of possibilities. Choose one recurring task. Understand it well enough to explain its inputs, its decisions, and its finished result. Then decide which part is worth testing.

My work spans AI discovery, design, and operational systems. That combination makes me interested in the handoffs as much as the tool. A promising output still needs somewhere to go, someone to review it, and a clear next action.

Map the task before choosing the tool

Take a recurring piece of work and follow it from the first request to the final handoff. Write down what arrives, what someone does with it, and what the next person needs. Include the ordinary problems: missing details, unclear ownership, a file in the wrong place, or a decision waiting in a message thread.

For a simple example, consider a website inquiry. A person describes a project in a form. Someone reads it, identifies missing information, and prepares a reply. AI might help summarize the request or suggest questions. It cannot supply facts the person never gave you.

This is an illustrative workflow, not a claim about a particular client implementation. Its value is in making the boundaries visible. You can often improve the form or the handoff before adding any AI at all.

Separate assistance from authority

Producing a draft and making a decision carry different responsibilities. Decide which one you are asking the system to perform.

In the inquiry example, an assistant could organize the request into a short brief. The original message should remain available beside it. A person can then check that the summary preserves the meaning, correct anything it missed, and choose the response. Pricing, delivery commitments, and permissions should not be inferred from a plausible-sounding draft.

The review step deserves to be designed as carefully as the generation step. Give the reviewer enough context to spot an error. Show what the output was based on. Make it easy to correct, reject, or continue manually.

A draft becomes useful when someone can judge it.

Build a test you can learn from

Use material you are permitted to use. Start with fictional or appropriately sanitized examples if sensitive information is involved. Choose a mix of clear requests, incomplete requests, and requests that do not fit the normal pattern.

Before running the test, describe what a good result should contain. For an inquiry summary, that might be the requested service, the stated objective, the known constraints, and the questions still unanswered. An unknown budget should stay unknown. An uncertain date should stay uncertain.

Compare the assisted workflow with doing the work yourself. Include review and correction time, not only the time it takes to generate the first answer. Notice whether the output helps the next person act with less confusion. A quick draft that needs extensive checking may not be an improvement.

Plan for the ordinary failures

Decide what happens when the output is incomplete, the tool is unavailable, or the request needs more judgment than the workflow can support. A visible queue and a manual route are often more useful than an elaborate recovery process nobody understands.

Assign someone to own the workflow after the initial build. That person should know where requests land, how errors are surfaced, and when the instructions need updating. A small test becomes a business process when other people start depending on it.

This is where design and operations meet. Clear labels, sensible defaults, and an obvious review state can make the difference between a useful assistant and another place people have to check.

Your first useful experiment

Write a one-paragraph brief for a recurring task. Name the input, the expected result, the person who reviews it, and the action that follows approval. Add one sentence describing what the system must never assume.

That gives you something concrete to test. Keep the scope small enough that you can inspect the results yourself. Continue if it helps, revise it if the task was poorly framed, and stop if the extra complexity is not justified.

For more context on how I approach this work, see AI discovery and workflow design and AI Council experience at Razorfish. These cases describe the contribution and stage of the work without exposing client information.