Begin with the operating problem
A brief such as 'build us an AI agent' skips the most important part. Name the work that currently consumes time, causes delay, or loses information. Describe who does it, what they receive, what they produce, and what can go wrong.
The model is one component of the eventual system. The workflow, interface, data access, review process, and handoff usually determine whether anyone can rely on it.
Write the contract of the workflow
Before implementation, define the smallest complete loop.
- Trigger: the event or input that starts the work
- Output: the exact artifact or state the system must produce
- Authority: actions the system may take without approval
- Review: decisions that remain with a person
- Failure: how the system stops, retries, or escalates
- Evidence: the measure that will justify keeping it
Prototype the riskiest real path
A useful prototype should process realistic inputs end to end. It should include at least one awkward case, because clean demo data hides the expensive parts: missing fields, conflicting documents, vague requests, and integration failures.
The goal is not to imitate the final interface. It is to learn whether the core decision and handoff can be made dependable enough to continue.
Evaluate more than answer quality
The output may read well and still fail as a system. Evaluation should cover the full operating loop.
- Accuracy or usefulness of the model output
- Coverage of normal and edge-case inputs
- Time saved after human review is included
- Visibility of sources and decisions
- Recovery from provider, data, or integration failure
Require a handoff you can operate
An outsourced AI system should arrive with clear ownership, configuration, deployment notes, known limitations, and a way to update prompts or sources safely. If the provider is the only person who can understand why the system works, the project is still a demo with a dependency attached.