01 / FOUNDATIONS
Start with a problem.
Then reach for a model.
“We should use AI” is an interesting thought, but it isn’t a task. “I spend half an hour turning meeting notes into a list of decisions” is a much better starting point: there is an input, a repeatable activity, and an outcome you can inspect.
A language model generates responses from the context it receives. It can help with drafting, summarising, extracting, and classifying text. Its output can also be incomplete or wrong, even when it sounds confident. Treat the first result as something to evaluate.
Try this small exercise
- Write down one repeated task and how you do it today.
- Choose a few non-sensitive examples, including an awkward one.
- Describe a good result in terms you can check: preserved decisions, correct names, or a specific output structure.
- Compare the assisted result with your usual process. Include the time you spend reviewing and correcting it.
A useful question: does this task need flexible language understanding, or would a simple rule do the job? Use a normal filter or script when it is enough.
02 / AI AGENTS
More than a chatbot
with a name.
A chatbot usually responds to a message. An agent system can go further: use a model to choose a next step, call an available tool, inspect what happened, and continue toward a goal. The surrounding application controls which tools exist and what they are allowed to do.
Imagine a research assistant. You supply a question; it searches an approved collection, reads relevant documents, and drafts an answer with links. If the documents don’t contain an answer, a useful assistant should say so instead of inventing one.
The moving parts
- A goal: a specific result, such as a draft comparison of three documents.
- Context: the question, relevant material, and constraints.
- Tools: controlled operations such as search or document retrieval.
- A loop: choose an action, observe the result, decide what comes next.
- A stopping point: success criteria, a limit on steps, or a request for human help.
Start narrow. An assistant that reads a small approved folder and prepares a draft is easier to understand and evaluate than one that can change everything in your workspace.
03 / AUTOMATION
Your first workflow
can be wonderfully ordinary.
A workflow connects a trigger to a set of actions. The trigger might be a new form submission, a scheduled time, or a document you add to a folder. The actions might validate a field, create a draft, and notify you.
Not every workflow needs an agent. A fixed sequence is often easier to operate when you already know the steps. Add AI where a step needs to interpret language, such as proposing a category for a message with varied wording.
A first experiment: a reading roundup
- Trigger: manually add an article you have permission to process.
- Input: supply the text, title, and source URL.
- Assist: request three key ideas and any unanswered questions, using only the provided text.
- Review: check the draft against the source.
- Save: add the approved summary and its source link to your notes.
Run this manually on a few examples before scheduling it. That gives you a chance to discover missing inputs and poor summaries while the experiment is easy to change.
04 / CONTEXT & PROMPTING
Better answers begin
before the prompt.
A model cannot reliably infer all the details you have in mind. Give it the actual task, the audience, the relevant source material, and what a useful response looks like. Tell it how to handle missing information.
A simple brief you can adapt
Goal: Turn these meeting notes into a draft action list.
Audience: The project team.
Source: [Paste approved notes here.]
Output: A table of action, proposed owner, and due date.
Boundaries: Use only the supplied notes. Mark missing owners
or dates as "not specified". Do not invent commitments.
Review: List unclear items separately for a person to confirm.
Then inspect the result. Did it preserve the original meaning? Did it introduce an action nobody agreed to? A clear brief helps, but checking against the source is still part of the work.
Context is a choice. Include what the task needs, and check your organisation’s policies before sharing private or sensitive material with a service.
05 / THE HUMAN PART
Give it useful tools.
Keep your final say.
Drafting a reply and sending it are two different actions. A good workflow makes the difference visible. Let the assistant prepare work; require a clear approval before it sends a message, publishes a change, or commits to a purchase.
Make the handoff easy to inspect
- Show the proposed action and the exact content that will be used.
- Include source links or supporting information.
- Let the reviewer edit, approve, or decline.
- Only execute the approved version, and record what happened.
Permissions should be enforced by the application and its tools, rather than depending only on a sentence in a prompt. An agent that is meant to read documents should not automatically receive permission to delete or publish them.
06 / RELIABLE WORKFLOWS
Make room for
the messy bits.
A service times out. A form arrives twice. A model returns prose where you expected a category. These are ordinary things to plan for when a useful experiment becomes a recurring workflow.
- Validate inputs and outputs. Check required fields and allowed values before the next action.
- Handle repeated events. Track a stable event ID so an incoming retry does not create duplicate records.
- Retry deliberately. Use limits and delays for temporary errors; avoid blindly repeating actions that may already have succeeded.
- Make failures visible. Keep a review queue and enough logs to understand what went wrong.
- Budget the work. Set limits on runtime, model calls, and steps.
- Evaluate changes. Re-run representative examples when prompts, tools, or models change.
The goal is useful, dependable assistance. A small workflow with a clear owner and a visible review step is a solid place to begin.