Build the smallest
complete piece of work.

1. Write down the job before the feature list.

Choose one person, one repeated situation, and one result. “An AI assistant for the company” leaves almost every important decision open. “An account manager can draft an answer using the current product documentation and review the cited passages” gives the project a useful boundary.

Describe the existing process from input to result. Name the systems it touches and the person who owns each step. Separate a slow task from a task that is unclear: software can accelerate a defined process, but it will not settle an unresolved policy.

Choose a primary success measure that belongs to the workflow. It might be the share of drafts accepted with limited changes, the time needed to complete a review, or the number of fields correctly extracted. Record the current baseline if one exists. Do not promise a percentage improvement before observing it.

2. Inspect the inputs and the permissions.

Inventory the material the system needs: files, records, messages, and reference documents. Check which versions are authoritative, how they change, and whether the project can access them in the required way. A connector listed on a vendor website is not proof that a particular account has the permissions or plan needed.

Decide which user can see which information. A tool should not make a restricted document available simply because it can retrieve it. Agree how examples can be used during development, what may appear in logs, and how long those records should remain. Verify the selected providers' current data-handling settings before sending real material.

• Who owns the source and can grant access?
• How will updates and deletions reach the tool?
• What happens when access expires or a source is unavailable?
• What can be demonstrated using synthetic or redacted examples?

3. Evaluate examples before expanding the build.

Create a small review set that reflects the work: straightforward cases, ambiguous inputs, incomplete records, and requests outside the intended scope. Write down what a usable result would look like for each. Where several answers are acceptable, describe the properties that matter instead of requiring an exact sentence.

Keep some examples separate from the ones used to shape prompts or rules. Otherwise, a convincing demonstration can show familiarity with the examples rather than useful behavior on new work. Review failures by type: missing context, wrong extraction, unsupported statement, incorrect routing, or inappropriate action.

Choose acceptance criteria for this workflow. A draft-writing tool and a tool that changes customer records need different review boundaries. Keep a person in the approval path wherever an incorrect action would be difficult to undo.

4. Build a complete first workflow.

The first release needs the input screen, the useful result, a way to correct it, and an honest failure state. It may also need sign-in, permissions, a review queue, and a record of changes. These are part of the product even when the model interaction is the most visible feature.

Deliver one coherent path before adding unrelated tasks. Test with the person who will operate it. Watch where they hesitate, where they switch to another tool, and which corrections they make repeatedly. A smaller tool that fits an existing routine is easier to evaluate than a broad assistant with no clear finish line.

5. Decide who owns it after launch.

Agree on source-code and account access, deployment responsibility, provider costs, and the support arrangement. Identify who can pause the workflow, investigate a failed run, and approve a change. Include a short operating guide and a practical walkthrough.

Review the first real usage against the original acceptance criteria. A working deployment starts the observation period; it does not prove the intended benefit. Expand only when the next use case has a clear owner and the existing workflow is understandable to the people using it.