Practical AI adoption
Make AI useful in the work that matters. Choose a specific problem, give people a safe way to use it, and measure what remains after checking and correcting the output.
I help connect AI adoption to working practices, delivery ownership and commercial judgement. A convincing demonstration is a starting point. The real test is whether the team can use the workflow reliably in everyday work.
Prototype service outline. The activities below are proposed ways of working, subject to an agreed scope. They are not a fixed package or a promise of savings.
A pilot is easy to start.
A useful practice takes judgement.
This work is useful when experiments are spreading but the business cannot yet say which ones help, who owns the risks, or how much expert attention they consume.
You may have engineers using coding agents, teams drafting internal material, or a promising workflow that depends on one enthusiastic person. The next decision is where to invest, what to constrain and what to stop.
My starting point is the task and its consequences: who needs the result, what a good result looks like, and how someone will recognise a plausible but wrong answer.
Choose the work before the tool.
A first use case should be bounded enough to learn from. Prefer a task with a visible baseline, an accountable owner and an output that someone can check.
Questions that narrow the field
- Value: is the task frequent or costly enough for an improvement to matter?
- Evidence: can we compare the result with the current way of working?
- Review: does the team have the expertise and time to catch mistakes?
- Exposure: what data, systems and people could be affected by an error?
- Ownership: who can change the workflow and decide whether it continues?
What might a bounded first use case look like?
For example, an engineer could use an agent to propose tests for a contained code change. Existing access controls remain in place; a named engineer reviews the tests and code, runs the checks and retains the merge decision.
The evaluation would include time spent preparing context, reviewing generated tests and removing misleading coverage. This is an illustrative starting point, not a claim about a client engagement.
A workflow that cannot be checked, or requires broad production access just to demonstrate value, needs a different boundary before a pilot begins.
Set the boundaries before increasing autonomy.
Safeguards belong in the working process. A policy document alone will not tell someone whether an agent may read a repository, send a message or change a live system.
Agree what the workflow may do
Define permitted inputs, approved tools and data handling expectations. Use the minimum access needed, separate experimentation from live systems and make external actions subject to explicit approval.
Keep a person accountable
Name the owner of the output and the reviewer. Specify which checks must pass, what evidence to retain and where uncertainty or a failed check must be escalated. Generated output is a proposal until the agreed review is complete.
Make stopping practical
Keep a manual fallback, a way to revoke access and a clear response to mistakes. If review cannot keep up, sensitive information appears unexpectedly or quality falls below the agreed threshold, pause the workflow and investigate.
Count the cost of an accepted result.
A cheap generation can be expensive to trust. Compare the whole task, from preparing the input to accepting the final output, with the existing workflow.
Total workflow cost includes tool usage, context preparation, human review, rework and ongoing support.
Review time includes reading unfamiliar code, checking sources, testing assumptions and correcting subtle errors. Include the people downstream who receive the output, not just the person generating it.
Separate initial setup and training from recurring costs. Report time released as capacity first; whether it becomes a cash saving or better delivery depends on how the business uses it.
Why faster drafting may not mean faster delivery
If a draft arrives sooner but needs more specialist correction, the bottleneck may simply move to review. A pilot should record the wait for review as well as the time spent doing it.
A more capable tool may justify a higher usage cost if it reduces correction and verification effort. Equally, a simpler non-AI workflow may be the better choice. The comparison needs evidence from the actual task.
Read the unpublished prototype draft on AI engineering economics.
Agree the evidence for continuing.
Define the baseline and decision criteria before running the pilot. Compare similar work, keep the evaluation set stable and record failures alongside successful examples.
No universal improvement target is assumed. Measures and thresholds should reflect the task, its consequences and the team's starting point.
Useful measures
- End-to-end time: preparation, generation, review, correction and waiting.
- Accepted quality: outputs meeting the same acceptance criteria as the baseline; defects discovered later remain part of the assessment.
- Cost per accepted task: tool spend and the effort of everyone involved.
- Operational fit: exceptions, escalations and dependence on specialist support.
Three legitimate decisions
Expand when the evidence supports value and the controls hold. Adjust when the task shows promise but review or integration needs work. Stop when the costs or consequences outweigh the benefit.
Recheck after significant model, tool or workflow changes. A successful pilot does not establish permanent reliability.
Leave the team with a working decision.
The aim is a practice the team can own, with enough evidence to decide what happens next.
Depending on scope, useful outputs could include a prioritised use-case shortlist, a pilot brief, a permissions and review checklist, an evaluation record and a recommendation to expand, adjust or stop.
Each should identify an owner. Tool configuration, team guidance and the manual fallback should be understandable to the people who will maintain them.
The v3 track record includes introducing agentic workflows with governance and safeguards. That experience informs this approach; it is not evidence of a guaranteed outcome for another business.
Bring one workflow worth questioning.
Describe the task, who does it today, what a mistake would cost and what you hope will improve. A high-level description is enough to start; leave confidential data out of the enquiry.
Prepare an enquiryThe prototype contact page prepares a local enquiry. It does not send a message or book a meeting.