Managed AI in practice / FIELD NOTES
AI Work Request Template: Define a Task Someone Can Accept
Specify the outcome, source material, action boundaries and acceptance example for AI-assisted work, with a practical meeting-summary brief.
What should a work request contain before an AI assistant or managed team starts?
A request to “improve efficiency with AI” leaves the actual work undefined. A useful brief identifies the user, inputs, permitted actions and acceptance conditions. NIST's AI RMF likewise treats task definition and human responsibilities as explicit considerations.
Describe an observable deliverable
Record the task name, intended user, trigger, format, language, destination and deadline. Replace “organize meetings” with “turn the supplied meeting notes into a summary and action table for the project owner to review.” State exclusions, such as scheduling meetings or making commitments for attendees.
For recurring work, add the expected input volume and frequency so another person can identify each task's start and finish.
Identify evidence and action boundaries
List source links, versions, owners and allowed uses. Separate confirmed facts, background material and unanswered questions. Arrange access through an approved authorization process rather than placing passwords in the brief.
Distinguish reading, drafting, editing records and sending externally. Name the reviewer for actions requiring approval and describe what happens when evidence conflicts or access fails.
Worked example: notes into actions
For an illustrative meeting task, request up to five summary points plus columns for action, owner, deadline and supporting passage. If the notes say “confirm the launch date next week,” the deadline remains unconfirmed.
Check every owner and date against the input. Discussion, suggestions and decisions must remain distinguishable. Agree this sample before processing additional meetings.
Copy this handoff checklist
Keep the accepted example and rejection reasons beside the brief. Version the acceptance rules when they change.
- Outcome and intended user.
- Source links, versions, owners and gaps.
- Output format, destination and deadline.
- Permitted actions, approval points and reviewer.
- Accepted example and return conditions.
Before you hand over the work
- Define a checkable result before choosing tools.
- Preserve unknowns and assign their next owner.
Demonstration projects and examples illustrate working methods. Follow the receiving party’s specifications and the scope agreed for your project.