What I would do differently if I were starting with AI now

You're reading The AI Directive - practical AI intelligence for business leaders. [Subscribe here](https://theaidirective.co.uk/subscribe) if someone forwarded this.

Last week I wrote about what 90 days in my personal AI lab taught us.

That lab framing matters. This is not a corporate case study or a claim that a company-wide AI programme has been running in the background.

The lab is deliberately personal, built around evenings and weekends alongside the day job: a place to test AI against practical work, recurring workflows, content production, research, decision support and automation failures, then turn the lessons into something useful for business leaders.

That is the point of this newsletter. You should not have to build the whole test environment yourself to learn what works, what breaks and what I would do differently next time.

Some of it worked well. AI was good at first drafts, comparison work, exception lists, status summaries and pulling messy evidence into something a person could act on.

Some of it was more awkward. Chat promises were too easy to lose. Scheduled jobs could look healthy while the actual business output was missing. AI writing had to be edited harder than expected. Broad instructions created movement, but not always progress.

So this week is the follow-on.

If I were advising a leadership team starting now, what would I tell them to do differently?

Not as a complete consultancy programme. Not as a 47-slide strategy pack. Just the recommendations I would make after seeing what actually helped and what caused problems.

Most AI plans start too broad.

They begin with language like:

Those may be legitimate ambitions. They are just poor starting points.

The better first move is to pick one piece of work that already exists and already irritates people.

Good candidates:

The point is not to find the most exciting use case. The point is to find work where the result is easy to inspect.

If the first AI workflow cannot be checked quickly by the person who owns the work, it is the wrong first workflow.

That follows directly from the first lesson in the lab: narrow jobs worked better than broad instructions.

The most useful early role for AI is preparation.

Let it prepare the draft.

Let it prepare the comparison.

Let it prepare the exception list.

Let it prepare the decision brief.

Do not confuse that with letting it own the outcome.

The person still decides whether to send, publish, approve, buy, reject, change, escalate or stop.

That distinction keeps the useful part of AI without pretending the risk has disappeared.

If the output is wrong, a prepared draft is irritating. An automatically sent email is a problem. A draft public post is manageable. A published public claim is not. A recommended decision is reviewable. An executed decision may not be.

This is the line I would draw early and hold firmly.

AI can prepare more than it is allowed to do.

This is the recommendation that comes from the second lesson: AI saved time when it shortened the route to a human decision, not when it tried to replace the decision.

Tool-first AI projects drift quickly.

Someone buys or licences a system, then the business tries to work out what to do with it. That usually leads to demos, enthusiasm and very little change to actual work.

I would do it the other way round.

For the first workflow, write five lines:

If those five lines are unclear, the problem is not tooling.

It means the business has not yet described the work well enough.

The brief does not need to be elegant. It needs to be specific enough that a manager can look at the output and say, "yes, that is what we asked for" or "no, that missed the point".

That is usually where the quality improves.

This is where the "chat promises" problem from last week gets fixed. If the brief names the trigger, source, output, approval and stop point, the work has somewhere firmer to stand than a conversation thread.

The best AI output is not the longest, cleverest or most polished.

It is the one that makes the next human action easier.

A good handoff tells the owner:

If the owner has to re-open every source and redo the reasoning, AI has not saved time. It has produced another thing to manage.

This is why I would not measure early AI work by prompts written, documents generated, tools adopted or hours claimed.

I would measure it by whether decisions moved faster without lowering the standard of review.

That is the test I would use before expanding the work.

This is the practical version of last week's handoff lesson. The question is not whether AI produced something. The question is whether the person receiving it can act faster and with more confidence.

Most teams talk about what AI should do.

Fewer talk clearly enough about what AI should not do.

That is where problems start.

Every early workflow should have stop points. AI should stop and ask for a person when it reaches:

This does not make the workflow slow; it makes the workflow usable.

People trust AI more when they can see the fence.

This is where preparation and permission have to stay separate. The more useful AI becomes, the more important it is to be explicit about where it must stop.

This was one of the sharper lessons.

A scheduled job can run and still fail the business.

It can send a reminder but not create the draft. It can exit cleanly but leave the output missing. It can say the buffer is low but not prepare the next article. It can prepare a post but fail to notify the person who needs to approve it.

That is not a technical distinction; it is the whole point.

For recurring AI work, success has to mean the intended business output exists.

If the job was meant to produce a draft, where is the draft?

If it was meant to ask for approval, where is the approval request?

If it was meant to check the queue, what changed afterwards?

Anything else is process theatre.

That recommendation comes from the recurring-job failures in the lab. A green tick in a scheduler is not a business result.

AI writing can be useful, but it has a strong tendency to sound tidy rather than true.

You get neat little sentences. Balanced contrasts. Sensible-sounding paragraphs. Advice that feels polished until you ask what the reader should do differently.

That is not good enough for leadership content.

The edit should ask:

If the writing is going to represent you, this part cannot be delegated completely.

AI can get you started. It should not get the final say on your voice.

This is not a cosmetic point. If you use AI for leadership communication, the edit is part of the control system.

If I were starting again, I would not begin with an AI strategy.

I would pick one recurring workflow and make it work properly.

I would choose something that happens often, takes time, and can be checked by the person who already owns it.

I would ask AI to prepare the work, not complete the decision.

I would write the five-line brief.

I would add a stop point before anything external, public, financial or hard to reverse.

I would judge the result by the quality of the handoff.

Then, only after it had worked a few times, I would move to the next workflow.

That is less exciting than a grand AI roadmap, but it is far more likely to survive Monday morning.

That is the real recommendation from the 90-day lab: do not try to look mature early. Prove one useful handoff, with the right controls, and build from there.

Choose one workflow and write this down:

What should AI prepare?

What must a person still decide?

If you cannot separate those two things, you are not ready to automate the workflow.

If you can, you have a sensible place to start.

The mistake is trying to make AI adoption look mature too early.

Start with one useful handoff, make it reviewable, put permission gates around the risky bits, and prove it helps before moving on to the next workflow.

See you Tuesday.

[@TobySmithFirth on YouTube](https://youtube.com/@TobySmithFirth)

These are tools I use personally. Affiliate links marked - I earn a small commission if you sign up, at no extra cost to you.

Some links in this issue are affiliate links. I only recommend tools I actually use.