Why AI contract briefs go vague
Most AI contract briefs are written backwards. They start from a list of technologies (LLMs, LangChain, vector databases, Python) because those are easy to name, and stop before the hard part: what the engineer should change, who will direct them, and how anyone will know it worked.
A contractor reading that brief can only guess. Good ones ask a dozen questions before quoting; others quote anyway and discover the real requirement in week three. Either way, the start slips.
The builder above asks for the parts that usually go missing, in the order a contractor reads them.
What each section is for
- Role type. An agent engineer, a retrieval engineer and an enablement engineer are different hires with different experience. Naming the type matches the right person to the work.
- Outcomes. One to three results someone could check. These are what the contract is for; everything else supports them.
- Current state. What exists, who built it, where it runs and what is known to be wrong. One paragraph here replaces most of a discovery call.
- Working pattern and contract basis. Start window, duration, days per week, location and time zone, contract route and who makes the status determination. Part-time patterns change what is realistic by day 30.
- Authority. The person who sets priorities and reviews work. If nobody has time to direct the work, a contract is usually the wrong vehicle and scoped delivery is a better buy.
- Access. Repositories, environments, data and approvals. Access delays are the most common reason a contractor’s first fortnight is lost.
- Success at 30, 60 and 90 days. Checkable milestones that give you a natural fit review, rather than finding out at the end.
- Handover. Who takes over and what they need. Deciding this at the start shapes how the work is done throughout.
Illustrative example
Illustrative example, not a real client brief. An extract of what the builder produces for a retrieval role:
What the engineer should own or deliver
- Answers to policy questions come from the current policy version, measured on an agreed set of 100 real support questions
- Retrieval changes ship through our normal pull-request review, each with a before-and-after evaluation run
Success measures
- By day 30: baseline evaluation agreed with the support leads
- By day 60: superseded-policy answers fixed and measured
- By day 90: two of our engineers can run the evaluation and make retrieval changes unaided
The missing list for the same draft flagged two items: no status determination owner, and no start window. Both are quick to settle internally, and both would otherwise have been the first two questions back from any contractor.
Assumptions and limitations
The builder formats what you give it and checks for gaps; it does not judge whether your outcomes are achievable in the time you set, or whether the role type is right for the work. It is not a contract, it does not cover legal terms, and it gives no employment-status or tax advice. Treat the output as a requirement document that goes alongside your own contract.
What to do next
Once the brief is complete, use the contractor selection checklist to assess whoever responds, and the contract cost model to compare quotes on total cost rather than day rate. If you are not yet sure an individual contractor is the right model, try the engagement comparison.
If you want me to read it, press “Send this to Dipankar as a brief” above. It fills in the form at the bottom of this page for you to check and submit. I reply with questions, an honest view on fit and confirmed availability, including when the answer is that someone else would suit the role better. The roles I take on are listed under contract AI engineering.