Training

• What a language model is actually doing, and why it can be confidently wrong.
• What leaves the building. Which data must never go into a prompt, how to strip names, dates of birth and identifiers before a model call, and how to read a provider’s data terms.
• Checking outputs. Cite or decline, never trust an uncited claim, and keep a person in the loop for anything that goes to a customer, a patient or a parent.
• Guardrails that do not slow people down: approved tools, what may be pasted where, and who signs off what.
• The short policy your organisation needs, written together in the session.

• The anatomy of a prompt that works: role, context, the task, the format you want back, and the examples that pin it down.
• Give the model the documents, not the memory of them. Why grounding beats clever wording, and how to paste context without leaking what should not be shared.
• Ask for the source, ask for the uncertainty, ask what it did not use. Prompts that make a model show its working.
• System prompts for repeatable jobs: turning a good one-off prompt into a template the whole team uses the same way.
• Testing prompts like code: a small set of real cases, run every time the prompt changes, so a tweak that breaks something is caught before it ships.

• Start with the six questions, not the diagram: problem, users, current process, outcomes, constraints, metrics.
• From prompt to agent: when a single call is enough, when the model needs to plan and act in steps, and how to keep each step small and checkable.
• Connecting tools. Giving the model a document store, a database, a calendar or an API: what it may read, what it may do, and what always needs a person’s approval.
• Ground the agent in your own documents, with retrieval that cites the passage it used and refuses when confidence is low.
• Guardrails as code: a single choke-point for anything that sends, spends or deletes; append-only records of consent and decisions; logs you would be happy to show a regulator.
• Testing and evaluation: automated checks that run before a model is paid to review anything, and a sign-off that is invalidated when the output changes.
• Cost, and when an agent is the wrong answer. A rule-based parser or a database query often beats a model in the hot path.

• What to expect from AI in your organisation over the next two years, without the vendor gloss.
• The questions to ask any supplier: where does our data go, what does it cite, who approves what it sends, what happens when it is wrong.
• Governance that fits on one page: roles, approvals, records, and what you would say to an inspector, a regulator or a parent.
• Where the value actually is for a school, a clinic or a property business, drawn from the business cases on this site.

A short call first, where we pick two or three of your own use cases and put them through the six questions. Then a half day or a full day with the team, on site or remote, working on those cases rather than on examples. I have run sessions for groups of more than a hundred over Zoom and for a handful of people in a room; the format changes, the content does not. You keep the materials, the policy we wrote and a list of what to do next. Follow-up by email for the questions that come up once people start using it.