Engagement format
Practical AI Training and Mentoring for Teams
Work on the team’s real workflow and repository to produce a specification, working artifact, quality tests, and a transferable handoff.
Describe the taskProblem framing
What must be resolved
A team knows the tool names but has not practised turning its own workflow into a specification, artifact, test, and safe improvement cycle.
Fit
Suitable for
For teams and individuals learning RAG, agent workflows, Legal AI, and AI-native development.
Deliverables
What remains after the engagement
- Work plan
- Repository or prototype
- Tests
- Next-experiment list
Process
How the work proceeds
- 01Level diagnostic
- 02Task
- 03Iterative work
- 04Review
Scope
From input to a decision
When it is needed
Training and mentoring are appropriate when a team wants to transfer a way of working, not merely learn a tool. The material is a real workflow or repository in which a small, inspectable artifact can be built and assessed together.
Input material
Inputs include the team workflow or repository, starting level, intended artifact, and handoff owner. This keeps the work from becoming a demonstration of generic prompts detached from the next stage of practice.
What we do
The team creates a specification, bounded artifact, quality tests, and a decision record. The work separates implementation from verification, makes source boundaries visible, and shows how to return to a test after a code, data, or tool change.
Artifact and outcome
The result is a specification, working artifact, test set, and handoff runbook. Participants receive not a promise of competence but a concrete package they can extend, challenge, or safely retire.
Acceptance criterion
Acceptance occurs when the team can run the artifact, identify its quality check, explain the material boundary, and name the next-step owner without depending on the facilitator.
Boundary of responsibility
This is practical work on the team’s own material, not certification, an employment guarantee, or a replacement for internal ownership. If no workflow or handoff owner exists, the collaboration conditions should be prepared first.
Decision record
After a workshop, a team should be able to name its own artifact, verification criterion, source boundary, and person responsible for further work. A handover record captures those elements and open questions. It does not replace an internal tool decision or continuing organisational support.
Boundaries
Risks checked early
- Topic too abstract
- No practice time
- No test data
Evidence path
Existing material that demonstrates the scope of work
FAQ
Practical questions
Can we work on our own project?
Yes, when context and anonymised examples can be shared safely.
Does training end with a tool presentation?
No. The work uses one real team workflow or repository and leaves a specification, artifact, test, and runbook. If that material is absent, preparation conditions are identified first rather than simulating an implementation.
How can a team tell it can take over the result?
The team should be able to run the artifact, identify its quality check, explain source boundaries, and name the next-step owner. That is a handoff criterion, not an individual competence certificate.
Scope and cost
Evidence before an estimate
I do not publish a fictional ‘from’. Scope and estimate follow a review of the workflow, material access, risk, expected artifact, and acceptance criterion.
Start by describing the workflow
The first response will identify whether this format fits and what is needed for an honest scope.