Start with the job
“Help with my business” leaves a lot for a system to guess. “Turn these meeting notes into a draft task list” gives it something you can inspect. You know what goes in, what should come out, and who needs to check it.
That distinction matters when you move beyond a conversation. A useful system needs a specific responsibility and a way to tell whether the work is complete.
In this example, the first version produces a draft. It does not invent missing deadlines or assign people work without review. If the notes do not name an owner, the output says so.
The pieces it needs
- Context
- The job, source material, relevant background, and examples of a good result.
- Working knowledge
- The documents and decisions the system is allowed to use. Someone needs to keep them current.
- Tools
- The connections required to do the job, with access limited to what the task needs.
- Review
- A person who checks the result and decides what can happen next.
More access adds more ways for a mistake to matter. Before connecting a tool, name the action it enables and the point where a person approves it. Drafting a reply and sending one are separate responsibilities.
Build a first version
Choose a task you already understand. Gather a few representative examples, including an awkward one. Write down what a useful answer looks like and which missing facts should cause the system to stop.
Run the draft through those examples and keep a record of corrections. Were names omitted? Were uncertain facts presented confidently? Was the format hard to use? Those corrections tell you what to change in the instructions.
Expand the workflow when the small version is dependable enough for its purpose. You should be able to explain the job, the information it uses, and who checks the result without opening the software.