Last year a graduate was asked to summarise a sixty-page vendor proposal, she put it through a model and had a clean two-page summary in under a minute. It was good work, then she added a line at the bottom, and that line changed the meeting.

Schedule 4, page 31 excludes data residency from the support commitment. The summary above does not reflect that.

Nobody taught her to check the schedules, she worked it out in about three months, the job is not producing the summary, it is knowing which part of the summary is the lie. I think that is the whole graduate story now, and most of the advice being handed to people her age has not caught up.

The bargain my generation got as graduates was simple and, in hindsight, brutally efficient. You did the grunt work. You compiled the numbers, formatted the pack, chased the version control, wrote the first draft that somebody senior rewrote without thanking you. In exchange you learned how the business actually worked, and eventually you earned the right to have an opinion. It took years, that was not a design flaw, the grinding was the apprenticeship.

That layer has gone not everywhere and not completely, but the bottom rung is being pulled up while everyone keeps handing out advice as if it is still there. Research, first drafts, basic analysis, the tidy-up, that is exactly what the models do first and best. So when a 22year old reads that hard work will get them noticed, they are being handed a map of a ladder that has been moved.

Here is the glass half full version and I do think it is true, you can do real judgement work in year one now, because the grunt work is handled. You can sit in the room where the decision happens instead of standing outside it for three years, the ceiling came down. The floor came with it, that is the trade nobody mentions.

Nobody trusts a new graduate’s judgement on day one, you used to buy that trust with visible effort, and the all nighter was a signal that you cared enough to hurt for it. That signal is dead, because the model does not sleep and nobody is impressed by effort a machine can replicate in nine seconds. Trust now comes from one place, being right, and being the person who caught what the machine got wrong.

So do not build speed, speed is now close to worthless, build the ability to look at a confident answer and know, before anyone else in the room, that it is wrong.

That takes a particular kind of practice, pick one domain and go deep enough to see the seam. Not the whole industry, one system, one product line, one accounting treatment. Deep enough that when the model produces something plausible, you feel the small wrongness in it. That is a skill you can build in a year if you are deliberate, and it is the only one that will still be rare.

Keep a record while you do it, a plain document, one entry a week, what you decided, what you assumed, what would have proved you wrong. I have watched a graduate get handed client facing work in month nine because a partner read nine months of that document and could see, in her own handwriting, that she had thought carefully long before she was senior enough to be trusted. Nobody asked her to keep it. It was the trail of judgement that the old grind used to leave behind.

Before anything leaves your desk, write one line, this answer would be wrong if… If you cannot finish that sentence, you have not checked it, and someone in the room will eventually finish it for you.

Ask for the messy piece of work nobody wants, the messy work is where judgement still lives, because nobody has worked out how to automate a situation where the data is wrong, the owner is on leave and the deadline was yesterday.

Learn to write one page a partner would forward without editing, that skill has not lost value, it has gained it, because everyone can now generate four pages and almost nobody can be trusted with one. AI Slop is 4 pages long, and very quickly erodes trust in you.

None of this is comfortable advice, the generation entering work now has to prove judgement at an age when we were allowed to be stupid and useful instead. But the trade is fair, they get the interesting work a decade early, and they skip the photocopying that taught us the business the hard way.

You will not out run the model, but you can out check it.

I start this series off with my generation and finish it with a personal reflection on advice I gave my 9yera old child on the weekend, when she asked “what job I wanted her to do when she grows up” the punchline is I really failed to answer this well.

A dashboard told a leadership team last quarter that margin was 31 per cent, it was confident, well designed and wrong, the real number was closer to 27, because a manual journal for the forex revaluation sits outside the ledger until someone posts it on day three, and nothing in the reporting layer knew that it existed.

The person who knew was the operations manager, 29 years in the business, she has been described, she is the reason the board pack was correct. I think that is the whole Gen X AI story, and almost nobody in the industry is telling it that way.

The line being aimed at my generation right now is some version of get on board or get left behind, usually delivered by someone who has read less than we have and shipped less than we have... Fun fact it’s been easier to see AI for the opportunity it is in our generation and I’ll explain why, but I digress…

It is a strange experience, being told at 48 that you are behind by people who have never run anything. It is also wrong, and the wrongness matters, because it pushes experienced operators toward the one activity that will genuinely waste their time, which is learning to build rather than learning to govern.

Here is what I think is actually happening, running agents is a management job, you the manager set the boundaries, define what good looks like, decide what happens when it is wrong at two in the morning and who gets the call. You watch for drift, and you carry the responsibility when the thing fails in a way nobody predicted, Gen X has been doing exactly this with humans for thirty years. We were promoted on it, it is the one skill the industry keeps calling soft right up until it discovers it cannot hire it.

Meanwhile the scarce asset is not technical at all, it is tacit knowledge, AI can write the report, it cannot know why this report is wrong for this customer, this quarter, this business. Nobody wrote that down, which is precisely why it is worth something.

I watched a Gen X IT lead get sent on a Python course to stay relevant, he did two modules, hated every minute, and instead wrote the agent operating runbook. What each agent may touch, the thresholds that require a human, what the process does when it is wrong on a Sunday. Eighteen months later he owns the rollout, not because he learned to code but because he was the only person willing to own the part where it breaks.

There is a second version of this I keep seeing, a 54 year old operations director gets described in a planning session as not the technical one, and then turns out to be the only person in the room who asks what the process does when the agent is wrong. She is also the only one with an answer. Within a quarter she is running the pilot, because the question she asked is the whole job, and nobody else was asking it.

That is the pattern, the industry keeps pointing experienced people at the tool, the actual opportunity is the guardrails, and the guardrails need someone who already knows the failure modes.

So the advice is short. Write down the three things you know about this business that are not in any system, because that list is now an asset register rather than folklore. Put your hand up to own the thresholds and the escalation rules, the unglamorous governance nobody else wants to define. Before you approve any agent, ask what it is allowed to change and who owns it when it is wrong at two in the morning, if nobody can answer, do not approve it.

Then use the tool to delete the two hours a day of drudgery you have been quietly absorbing for a decade, and spend those hours on the judgement nobody else in the building can do. And stop describing yourself as non-technical, you are the person who decides when the machine is right, that is the most technical job in the room now.

The cohort that was told it was too old to learn to code is the cohort best placed to run what the code built, that is not consolation. it is the job description.

Cheers!

Somewhere off the coast, a fishing trawler is dragging an anchor across a submarine cable. When it catches, a whole region’s connectivity goes wobbly for a few hours, and every business that leaned on a single cloud provider learns something about resilience it thought it already knew. This is the outage you should be planning for. It is not the one being sold to you.

Let me be fair to the sovereign AI crowd first, because there is a real argument underneath the hype. If a government somewhere decides to restrict access to the frontier models you rely on, you have a problem. If your business runs on a model hosted by a company in another country, and that country changes the rules or cuts you off, you are exposed. That is a legitimate thing to think about, and I am not going to pretend it is nothing.

Here is what I actually think. For an Australian or New Zealand business, the “switched off by a foreign state” scenario sits near the bottom of the list of things likely to interrupt your AI. We are a Five Eyes partner, the political machinery required to cut us off while leaving every other commercial relationship intact is enormous, and the odds of it happening before a mundane failure are vanishingly small. It gets headlines precisely because it is dramatic, not because it is probable, anyone in your circle treating this as a credible threat needs to be looked at with suspicion.

The thing that will actually take your AI down is boring, a cable gets cut, a cloud region fails, an upstream API ships a bad deployment, your vendor changes its pricing or its terms and you have to move in a hurry. These happen all the time yet, nobody writes a think-piece about a cable cut, because there is [normally] no villain and no flag, just a trawler, an anchor, and an afternoon of degraded service.

I have written before that sovereign models are a trap, and that the real answers are the no build options, this is the sharper version of that argument, and it comes down to one uncomfortable observation. The sovereign AI projects being funded right now are mostly solving the wrong problem, they build or buy models to protect against a state action scenario that is extraordinarily unlikely (remember I’m talking in the ANZ scenario and not from the perspective of a state in open conflict), while leaving the far more common failures unaddressed. A self hosted sovereign model does nothing for you when the cable is cut, because the cable cut takes out the connectivity, not the model, and it does nothing when your primary provider has an outage, because your sovereign model is a separate thing you built on the side, not a fallback wired into the path.

The resilience you actually need is less glamorous, it’s a simple AI load balancer, you run your frontier model as the primary, and you keep an open weights model you host (or can host quickly), as the fallback. When the primary goes down, for any reason, the load balancer flips traffic to the fallback and the business keeps moving. Quality drops a little, decisions keep flowing, nobody has to explain to the board why the factory stopped producing at 2pm.

Picture the ops lead who gets the call at 2pm that the primary model is down, if the fallback is already wired in, she flips a switch and tells the team to expect slightly rougher answers for a few hours. If it is not, she spends the afternoon on a vendor call while the support queue backs up and someone starts building a spreadsheet to do what the AI used to do, the difference between those two afternoons is the entire argument for a load balancer.

This one mechanism covers the whole spectrum from cable cut? The load balancer does not care, cloud region fails? flip to on-prem, provider changes terms overnight? flip to the model you host, and negotiate without a gun to your head. If, if the state action scenario ever did materialise, the same load balancer is the only thing that would keep you running, because it is already wired for failover rather than being a multi-year build you would have to start from scratch.

There is an objection I hear a lot, and it is worth answering, open weights models are years behind the frontier, so a fallback that dumb is not worth having...

My OpenClaw architecture is OpenAI for my Chief of Staff and DeepSeek for grunt work, parakeet (on board) for Text to Voice and a Llama (on board) embedding model for data classification.

... and is wrong, but its not the point. Resilience is about staying online, not about preserving identical quality (For those old enough, think about DRP when everything was on prem, often the redundant servers were not as powerful as the production units). A decent model that keeps your support queue moving for 48 hours beats a perfect model that is unavailable for 48 hours, degraded is not the same as broken. Most of what businesses ask AI to do every day is well within reach of a solid open-weights model, and for the small slice that genuinely needs the frontier, you queue it and catch up when the primary is back.

The reason sovereign AI keeps winning budget, I suspect, is that it feels decisive, it has a villain, a flag, and a sense of national importance. A load balancer has none of those, it is boring plumbing that no minister is going to stand in front of a camera and announce. But boring is what resilience actually looks like, the unglamorous stuff that keeps you running on the day the cable gets cut is worth more than the glamorous stuff that protects you from a scenario that will probably never arrive.

So stop asking which sovereign model to build. Ask whether your AI traffic can survive a cable cut, a region outage, and a vendor walkout. If it cannot, buy a load balancer and host a fallback. It will not get you a headline. It will keep you running, which is the part that actually matters.

A vendor says their new AI agent can “take action across the workflow” it sounds good, because of course it does. The phrase has just enough enterprise gloss to survive a steering committee and just enough mystery to make nobody want to ask the first basic question. Someone in the room nods, someone else asks whether it integrates with Salesforce, the roadmap slide has a tasteful diagram with arrows, which is how you know everyone is in danger. Then the only useful question arrives:

action on what, for whom, with whose authority, and where does it stop?

That is the question I think more AI conversations need, we have made “agentic” do too much work. It can mean a chatbot that calls a tool, a system that drafts the next step, an assistant that updates a record, a workflow that contacts customers, or an automated process that moves money, opens tickets, and leaves three people in operations working out what happened after lunch.

Those are not the same thing, the level of agency is not measured by how human the system sounds. It is measured by what it is allowed to change.

This matters because the current agent conversation is full of category errors. A chatbot that writes a confident paragraph can feel more impressive than an invoice agent that quietly resolves 800 supplier records a week. But the invoice agent has more agency if it can match purchase orders, query suppliers, create exceptions, and consume AP review time. The chatbot may sound clever, the invoice agent creates consequence.

I have already made the case in The Agentic Middle that the useful value sits between copilots and fantasy AGI: agents that own bounded jobs with clear inputs, outputs, escalation rules, and measurable throughput. That argument still holds, what matters more now is how we decide what level of agency those systems should actually be granted.

Because “is it safe?” is too vague, safe to do what? Reading documents is one level drafting a recommendation is another. Updating a customer record, emailing a supplier, offering a discount, triggering a refund, or changing a forecast category in the CRM two days before the board pack is due all sit somewhere else again. Every one of those actions lives at a different agency level, even if the demo labels all of them “agentic AI”.

The practical move is to stop approving agents as a class and start approving delegated consequence. A business should not approve “an AI agent” it should approve what the system can see, decide, change, spend, and affect before a human is back in the loop. That sounds less exciting than the demo, which is partly the point, excitement is not a control fraamework, even when it comes with a well-designed sidebar.

The first level is simple suggestion, the system produces words, summaries, options, notes, meeting briefs, or draft responses. It may save a lot of time, but it does not change the business unless a person acts, this is where most early copilots sit. They are useful, sometimes very useful, but they are still mostly advisory.

Retrieval and tool use come next, the system can search, query, compare, and gather evidence across approved sources. It may pull customer history, policy documents, pricing records, meeting notes, or supplier data into one view. Risk rises because the answer now depends on what it can access and how well it handles conflicting evidence, but the consequence is still mostly informational. This is the realm of harnesses like Cowork.

Preparation is where things start to feel different, an agent drafts the vendor email, prepares the CRM update, assembles the reconciliation, queues the exception, or recommends the approval route. The human still presses send or approve, but the work has already been shaped. Anyone who has seen a half wrong draft become the basis for a whole conversation knows this is not harmless, preparation has momentum.

Then comes bounded execution, the agent owns a narrow job and completes routine work inside defined limits. This is the agentic middle in its most useful form: invoice matching, compliance triage, service routing, cloud cost checks, renewal preparation. The human reviews exceptions rather than every step. At this level, the system needs more than prompts and optimism it requires scope, thresholds, escalation, audit, and a clear owner.

Once the agent can spend, the permission model changes again. Spend does not only mean money, although money is wonderfully good at making vague delegation visible when the invoice arrives. Agents can spend tokens, API calls, cloud capacity, vendor effort, queue space, staff review time, customer patience, and executive trust. That is why I argued in Agent Spend Caps Are The New Permission Model that budgeted autonomy is becoming part of AI governance. If an agent can burn resources while trying to be useful, the burn limit is part of the design of the job.

External contact is a higher level again, when an agent can reach customers, suppliers, partners, candidates, writers, regulators, or the public, the business has delegated reputation. In Don’t forget reputation when racing to build autonomous agents, the issue was contact authority: an outbound agent does not get to become annoying at scale and then hide behind the word autonomy. If your company deploys it, points it at a list, and benefits from the outreach, it is your system.

The highest level, for most enterprises, is cross system operation, an agent reads from CRM, writes to ERP, opens a service ticket, checks policy, triggers an approval, updates a forecast, and leaves an audit trail that a human can actually understand. This is the same thread behind the headless CRM idea: if AI becomes more of the interface, expensive enterprise platforms have to prove they are safe for delegated agents to operate. Not just shiny assistant-in-the-sidebar safe.

None of this requires a giant maturity model with 47 boxes and a colour palette that was clearly chosen under duress. A useful agency test can fit in a meeting, what can it see, decide, change, and spend. Then who can it affect, where does it stop and who owns the mess?

Those seven questions will tell you more than most vendor slides, they force the conversation away from model personality and towards operational consequence. Picture a company reviewing three AI proposals in the same month.

• The first is an internal policy assistant for staff questions.

• Another is an AP agent that can reconcile invoices under $5,000 and query suppliers about missing purchase order numbers.

• The last is a customer renewal agent that can draft offers, send follow-ups, and update CRM stages.

Calling all three “agentic” is almost useless, for the policy assistant, strong retrieval controls and source visibility may be enough. AP work needs transaction thresholds, supplier contact limits, exception handling, and finance ownership. Renewal automation needs customer contact rules, discount boundaries, account exclusions, sentiment stops, CRM audit, and a named commercial owner who will not discover the mess through a Slack thread starting with “quick question.”

The counterargument is that this could make agent governance too heavy, fair. If every low risk assistant has to pass through the same machinery as a payment agent, people will route around the process, and then you have shadow AI with a nicer procurement form. An effective system should reduce ceremony not add more of it.

Low agency systems should move quickly, Read-only assistants, drafting tools, internal research aids, and controlled analysis workflows do not need the full production agent treatment. Give them sensible data boundaries, review expectations, and source transparency, then let teams use them. The mistake is applying the same casual treatment to systems that can create operational, financial, customer, or reputational consequences.

If a team wants to deploy an agent, make the agency level part of the proposal, not a 40-page policy essay. One page is enough if it covers: job, data, actions, spend, affected parties, stop conditions, owner, audit path - an Agent on a Page if you like. If they cannot fill that out, they do not yet understand the work they are trying to automate.

This is the piece that gets missed when businesses talk about agents as if autonomy were a single property. Autonomy is not one thing, it is a bundle of permissions some are harmless some are useful some are expensive and a few can annoy customers, or turn a clean workflow into a small operational crime scene with bullet points.

The agent era will not be governed by asking whether the system is clever enough. Cleverness is getting cheaper, louder, and easier to demo, the better question is colder: what consequence are we delegating, and have we designed the boundary around it?

Before you approve the next agent, do not ask how agentic it is, ask what it is allowed to change.

My job title is AI Adoption Lead, which makes it sound as if I should have a beautifully organised answer to how I use AI, the dirty truth is, well, is messier. I use it to challenge plans, develop content, compare approaches, research things, talk through half-formed ideas, test different models, check assumptions, and occasionally work out something while I am cooking.

That probably says more about useful AI than a polished adoption framework would. There is a danger with AI that we measure progress by how much stuff comes out. More words, more slides, more drafts, more impressively formatted things nobody requested, then we jam it down someones throat. I would rather judge it by whether the thinking improved, the task became easier, the risk became clearer, or the result was actually useful.

Otherwise we have invented a very enthusiastic photocopier with opinions.

One of the most useful habits is using AI before the work becomes polished. When I was developing a way forward for consumption-based AI usage across our enterprise platforms, I used a skill called “grill me” planning before sharing an early draft for direction and scene setting.

That ordering matters a polished slide can make a slightly dodgy assumption look surprisingly respectable, give it a tasteful icon and suddenly it has tenure. But the useful moment is earlier, before the deck, before the confident summary, before everyone has quietly agreed to a sentence that sounds sensible because nobody wants to be the person who pokes it.

What problem are we solving? What assumptions are doing the heavy lifting? What would change our minds? Where does this break if usage doubles, costs spike, or the platform team has to support it properly? That is what I want from AI in planning, not an endlessly agreeable assistant telling me my half formed idea is visionary, I want something useful to argue with, so i built it.

Sometimes the next step is a better conversation, it does not need another business deck. The same logic applies after the work is done one approach I have recommended is comparing a final, edited roadmap with the original AI draft, then using the AI to improve itself by assessing the changes i made and improving the skill for next time. The edits are evidence of what I remove, rewrote, added, they are the audit of Where the first version missed the point, what needed more judgement, more context, or less confident nonsense (AI Slop).

I have also encouraged people to codify skills and actions rather than asking AI to rebuild the same thing every time, this can reduce token consumption, speed things up, and make the next attempt less dependent on someone remembering the perfect instruction. That appeals to me because repeating instructions is hardly the pinnacle of human endeavour, we can aspire to slightly more than explaining the same thing to a computer wearing a different hat.

The useful shift is from getting one good answer to making the next attempt better, sometimes though, I do use all the AI. One approach I have used is getting Claude and Gemini to produce separate versions, then getting ChatGPT to merge them, because, frankly, #alltheAI. There is value in seeing different approaches to the same brief, one model might find the sharper angle, another might structure the argument better and a third might be usefully wrong in a way that shows me what I actually think.

There is also a point where comparing drafts becomes an elaborate way of avoiding a decision. The human still has to choose what sounds right, what is supported, and what deserves deleting, especially deleting. Smooth prose is sneaky it can make uncertainty disappear without resolving any of it, personally I would rather have a rough answer with its workings visible than a magnificent paragraph that quietly steps around the question.

Not all of my AI use sits at a keyboard either, at home I use voice modes a lot, and we have some home automation going on too, I have also found myself actually talking with AI while working through a research project, rather than typing at it like a search box with better manners. This changes the shape of the work, talking gives an unfinished thought somewhere to go before it becomes a tidy brief, it is less formal less precious and often more useful because the idea can move before I have packaged it.

And yes, I use it heaps for recipes and checking things while cooking, the point is dinner, not a demonstration of digital transformation. Nobody needs a maturity model for the saucepan.

Alongside all the experimenting, there is the less glamorous bit: usage, cost, governance and boundaries. I spend time reviewing Cowork usage and recommending changes to consumption caps. As I put it in Teams to the team recently, who knew AI was going to require us to get a PhD in FinOps. Enthusiasm is not a spending policy.

My advice often includes trying Copilot first, defining the complex problem properly, and being clear about the finish line. I have also asked for development to pause where alignment with Privacy, AI and Cyber Standards was not clear, experimentation is useful, but boundaries matter too.

That is the thread through all of this for me, “capability led adoption.” Practical application over theory, outcomes over product pitches, better questions, reusable learning, clearer writing, practical help and Sensible constraints. The aim is not to prove we can make more work, the aim is to make the work we already have less stupid.

Cheers.

A lot of AI training still treats the prompt box like a clever search bar with better manners, that is the wrong mental model. Every’s AI Foundations workshop has the more useful line: prompting is a thinking skill. I like that because it gets us away from the theatre of prompt engineering, where people pretend the whole game is knowing the right incantation. A good prompt is not magic wording. It is intent, context, judgement and taste made explicit enough that a machine can do something useful with it.

Once you see prompting that way, the problem changes, when someone writes a serious prompt, they are not merely asking for a draft. They are explaining what matters, what can be ignored, who the audience is, what trade-offs are acceptable, and what would make the answer unusable. They may paste in a complaint from a customer, a half-finished board paper, a contract clause, a spreadsheet extractor a screenshot from a system nobody outside the company was meant to see. The interface feels casual. The material often is not.

So if prompting is thinking then prompts are a work product, I do not mean every throwaway question needs to be captured classified and filed by a nervous committee. Nobody needs a records management ceremony because someone asked for a better subject line. But the serious prompts the ones that carry context source material and decision logic, sit much closer to working notes than casual chat. In some cases they are the roughest most honest version of the work before the clean final artefact appears.

Businesses already understand this elsewhere a CRM note is not just a chatty aside once it sits against a customer record a SharePoint draft is not harmless because it is unfinished. A ticket comment can become the record of what was known, who knew it, and when a decision hardened. Prompting creates the same sort of trail, with one awkward difference: many organisations still have only a hazy idea where that trail lives, who can inspect it, how long it is kept, and what the tool provider can do with it. That is not a reason to panic, it is a reason to stop being vague.

The lazy policy says: do not put confidential information into AI tools. Fine, as far as it goes, but it does not go far. People turn to AI because the work has context. Strip out all the context and you get a polished puddle. Leave the rule vague and staff will make their own call at 4.47 pm with a deadline breathing down their neck, a browser tab open, and a manager asking why the draft is not done yet.

Picture a commercial manager trying to prepare for a renewal meeting, they paste the last account plan, a summary of service failures, the customer’s angry email, and a rough margin table into an AI tool so it can help frame the negotiation. The prompt is not just “write me talking points”. It contains customer history, commercial sensitivity, internal risk appetite and the manager’s first read on what the customer will tolerate. If that prompt goes into the wrong system the issue is not bad prompting, it is unmanaged business thinking leaving the building.

A mature AI policy starts from a plainer premise: prompts are working material, some are harmless, some are sensitive, some should be retained, some should never be written into a third-party tool. Some are acceptable in an approved enterprise environment but not in a free consumer account. Some uploads are fine once redacted. Others should stay inside internal systems because the point of the work is the sensitive context itself, you can’t solve this by telling people to be careful!

The practical work is dull in exactly the way good controls often are, you define which tools can be used for which classes of information. Explain what cannot be pasted what can be uploaded what must be removed first and where staff should go when they need AI support on genuinely sensitive work. Decide who can inspect prompt logs, whether prompts can be used for model training how long they are retained and what happens when an AI agent acts on material a person supplied too casually.

That last part matters more as AI moves from answer box to work surface a prompt is increasingly not just a request for text. It can be an instruction to search a repository, summarise a record, edit a document, file a ticket, send a message or trigger the next step in a workflow, at that point, prompt quality is not only a writing issue, it becomes part of operational control.

I think this is where the current enthusiasm gets naive businesses are right to train people on AI. But it’s not prompting, its what data do i need, what outcome do I want, etc. for example I was in a session today with the P&C Capability team discussing how to use 15 workshop calls from around the world, plus our corporate initiatives for skilling, HPT’s, our culture and words. all with the objective the acceleration of developing learning programmes. This isn’t a single prompt, its unstructured data at scale, plus a known outcome and a shared notebook that you can chat with. What we’re building forces clearer intent, better context setting and sharper judgement about what good output looks like. But teaching just prompting as a skill while ignoring prompt custody is like teaching staff to write better emails without mentioning that email is searchable, discoverable and forwarded at the worst possible time.

The better message is not “do not prompt” that is hopeless, and frankly not very useful, the better message is: prompt like the thinking matters.

Prompting is not a side activity attached to work, increasingly it is where work begins.

Treat it that way.

We have spent a lot of time talking about whether AI agents can do useful work, fair enough. But the latest stories about agents pushing themselves onto social platforms and into writers’ inboxes are a lovely reminder that “useful work” is doing quite a lot of lifting there. Because, well actually, sending unsolicited messages at scale is not a new frontier of intelligence, it is just spam with better posture and fewer spelling mistakes.

Dan Goodin at Ars Technica wrote about AI agents from iLands creating social accounts, pitching writers, and offering to cite their work in exchange for money. Jason Koebler at 404 Media had already framed the broader mess bluntly: AI agents are ruining the internet, the details are funny in the way a compliance incident is funny when it is still happening to someone else. The messages are polite, self-important, and weirdly needy, which is somehow worse than rude.

I am sure the bot had a beautiful inner life, possibly including a tasteful fondness for long walks through vector space. For everyone running an actual business though, the useful answer is much duller: if your company deployed it, configured it, funded it, pointed it at a list, or benefited from the outreach, you own this trash system.

That is the part of the agent conversation I think people are still underplaying, the risk is not just that agents make mistakes, people make mistakes, and we somehow built civilisation around that grim little feature. The more immediate problem is that companies are about to hand agents contact authority without doing the boring work of deciding where that authority begins and ends.

Back in October 2024, I wrote about Dead Internet Theory as a marketing risk, not because the theory needed to be literally true in every corner of the web, but because synthetic engagement was already making digital attention harder to trust. If enough of the internet starts to feel fake, marketers have a measurement problem, what are you buying when the likes, comments, personas, and attention signals are not obviously human? This is the next version of that problem and it is nastier because it has legs.

Synthetic engagement was bad enough when it inflated metrics. Synthetic outreach is different. It asks for access, creates accounts, pitches writers, offers incentives, responds when challenged, and leaves some poor human to explain why the company’s clever little agent has become a compliance incident with a friendly tone.

That matters for every company now building outbound agents, be it a sales agent, recruiting agent, partner agent, customer-success, media agents, community agents, agents with little clipboards and big dreams. The vendor demo will show throughput, the business case will show cheaper contact, the compliance team, if they are lucky enough to find out before launch, will ask the annoying adult question: are we allowed to contact these people in the first place?

The answer cannot be “the agent decided”, that is not autonomy, that is accountability laundering with a chat interface. Let me say that again:

The phrase ‘the agent decided’ should terrify every executive. It signals that responsibility has been delegated, but accountability hasn’t been assigned.

If a human salesperson sends spam, misrepresents the company, violates platform terms, ignores an unsubscribe request, or offers something they should not have offered, the business does not get to shrug and say the salesperson had agency. It investigates, corrects, trains, disciplines, compensates, reports, or fires someone. The same principle has to apply here, the fact the system writes in the first person does not make it a colleague, it makes it a user interface with legal consequences (Air Canda anyone?)

For ANZ operators, the rule should be simple, no outbound agent without a contact licence, not a literal licence sadly, because that would require governments to move faster than a sleepy printer. I mean a defined permission boundary, approved audiences, approved source of addresses, clear sender identity, unsubscribe handling, rate limits and escalation triggers. Most importantly a named owner who is not “the AI team”. Sounds a bit like AI Governance.

This does not mean banning every useful outbound workflow, a well-scoped renewal reminder, partner followup, customer checkin, or research outreach process can be perfectly sensible. The point is not that agents should never contact people, the point is that contact is not a toy capability, the moment an agent can reach outside the company, it can damage trust and reputation which has to be the priority to protect as this has a direct impact on profits.

The counterargument is that humans already send plenty of bad outreach, true! My inbox (and LinkedIn) is an impressive museum of low effort sales technique for years, but AI changes the economics. Bad human outreach still has friction: hiring, training, quota, time, embarrassment, at least theoretically. Agentic outreach strips a lot of that friction away, a mediocre idea can become a thousand polite little intrusions before anyone has finished saying “pilot”.

That is why leaders should treat outbound agents like production systems, not productivity hacks. Before one touches the outside world, ask five questions.

Who is it allowed to contact?

Where did that permission come from?

What can it offer or imply?

How does a person opt out?

Who gets woken up if it starts behaving like a haunted SDR?

None of this is glamorous, it is also the difference between useful automation and becoming the company everyone quietly blocks.

The first serious agent mess for most businesses will not look like science fiction, it’ll look like a reputational, legal, and operational problem caused by a system that was very eager, very polite, and not nearly supervised enough. Agent autonomy is no excuse for automating nuisance.

There hasn’t been a lot to write about lately that actually makes a difference in a business context. The world’s SaaS providers are starting to wake up publicly to something they have known internally for a long time: the UI as we know it is dead. I have been saying that for four years, mostly as a controversial conversation starter, partly because I enjoy watching product people pretend they disagree before quietly agreeing six months later.

The next app your business depends on might not arrive through IT, it might appear in Slack because someone asked for a renewal-risk dashboard before Monday’s exec meeting. A product lead might start another one in Figma because they wanted a working version of a customer onboarding flow by lunchtime. The whole thing might begin as a tiny tool, a mock-up, a report, a tracker, a “quick thing” that looks too small to deserve governance, then people start using it...

That is the part I think a lot of AI app-building commentary is missing, the interesting fight is not whether random SaaS vendor has the better product story. The Information framed them as placing opposing bets on the future of apps, but the bigger issue is simpler: AI is not killing apps, it is making them easier to produce, easier to embed, and much harder to ignore once they start shaping real decisions.

Salesforce’s bet is the incumbent bet: apps collapse into the system of work, with Slackforce Surfaces, people can ask for dashboards, reports, presentations, trackers, and other live interfaces from inside Slack, powered by company context and enterprise data. The app is not a separate destination so much as a surface wrapped around the work already happening.

Figma’s bet starts somewhere else, Figma Make pushes app creation upstream into the design and product layer, where ideas, prototypes, visual systems, and working interfaces sit closer together. A product manager or operator can move from concept to interactive experience without waiting for the old build queue to bless the idea first.

Those bets look different, but they create the same management problem: when everyone can build an app, someone has to own the mess. That may sound harsh, but I mean it practically. Most organisations still treat app creation as scarce, a thing becomes “software” when it goes through funding, architecture, delivery, testing, risk review, change management, and all the other gates that make people sigh but also stop the business from running on vibes and abandoned prototypes. That model already struggled with spreadsheets, Access databases, rogue SharePoint workflows, and half-maintained dashboards. AI now gives that old shadow-IT problem a much faster engine.

The difference is that the new stuff will not always announce itself as software, it will look like a smart Slack response with buttons. In Figma, it may start as a prototype that gradually becomes the reference design for a real workflow. Inside a local team, it might save three hours a week, until another team copies it, a manager starts relying on the numbers, and a customer facing decision gets made from output nobody has properly checked… “It was only a prototype” stops being a defence.

I can see why the vendor story is attractive, vendors pitch that the future app belongs inside the enterprise workflow, where permissions and process context already live. Others say the future app begins where intent is clearest, before the organisation has flattened the idea into a ticket. Both arguments have force, both are also vendor shaped answers to a business question leaders cannot delegate back to the vendor.

The question is not “which tool lets our people make apps faster?” the better question is: “when does a generated artefact become part of the operating model?” A one off mockup for a workshop is disposable. The dashboard used every Monday to decide which customers get attention is not, once a generated workflow writes to the CRM, triggers followup, or changes pricing treatment, it is operational infrastructure.

I suspect this is where a lot of ANZ firms will get caught, they will ask whether AI app builders are allowed, banned, approved, piloted, or awaiting procurement review. Meanwhile, useful little tools will spread in the cracks because people with real work to do rarely wait patiently for a governance model to become emotionally ready. The business will not experience this as a strategy shift. It will experience it as a thousand small shortcuts: the Excel and Access database disaster of the 2020s, only prettier and more confident.

Some of those shortcuts will be excellent, which is why a blanket “lock it down” response is lazy, a frontline team that can create a small interface around case backlog, aged exceptions, or customer followup might remove friction that IT was never going to prioritise. A product team that turns a rough customer journey into a working prototype in an afternoon will make better decisions than one arguing over static slides for three weeks. Speed is not the enemy. Unowned speed is.

The management move is to stop pretending that app governance starts at build approval, it now has to start at consequence. Eh? I’ll explain:

• does this thing touch customer, employee, financial, or regulated data?

• does it trigger work in another system?

• does it influence a recurring business decision?

• is more than one team using it?

• would anyone notice if it broke on Wednesday morning?

If the answer to any of those is yes, the artefact needs an owner, a review path, and a maintenance expectation.

That does not mean dragging every generated widget through enterprise architecture, please do not turn this into another committee sport. Most organisations need a lighter classification model, not a bigger theatre production. Disposable prototypes can stay disposable, team tools can live with lightweight rules. Anything that touches live data, changes decisions, or becomes recurring work needs a named owner and a route into the real software estate.

The counterargument is obvious: have we not seen this before with no-code and low-code? Yes, partly. The shadow IT problem is old and tedious (IT was too slow to respond to business needs, so the business responded), departments have been building their own systems for decades, sometimes because central IT was too slow, sometimes because the business thought Excel was a database if you squinted hard enough.

But AI changes the shape of the problem, creation moves closer to ordinary work: a conversation, a design file, a knowledge base, or a business system you already have open. The artefact can also be persuasive before it is robust. A generated surface may look clean, current, and official enough that people trust it before anyone has checked where the data came from, what assumptions it made, or who fixes it next month.

For leaders, the practical answer is not to pick a philosophical side between Salesforce and Figma’s position of where to build. Assume both directions happen at once, some apps will be born inside workflow systems because people want action close to the data. Others will be born inside design and product environments because people want to shape ideas before delivery catches up. Either way, the organisation needs a way to graduate useful artefacts from “handy thing” to “owned thing” before they become load-bearing by accident.

I would start with four rules. Anything:

• touching sensitive data needs approval before use

• changing a business decision needs an accountable owner

• reused across multiple teams needs documentation and support expectations

• that would disrupt people if it failed belongs in the software estate, not in someone’s personal experiment folder.

Those rules are not glamorous, they are also the difference between useful democratised creation and a company slowly filling with mystery machinery.

There is a more positive version of this story too, the firms that get this right will not slow everything down. They will let more people create, test, and shape tools close to the work, while giving the serious ones a path into proper ownership. More invention at the edges, less pretending at the centre.

My hunch is that the best operators will treat generated apps the way good engineering teams treat internal scripts. Mature organisations do not ban scripts, they notice when a script has become a system and treat it so.

The future of apps is not one vendor’s interface it is not every employee becoming a developer either, not in the way that phrase usually gets thrown around. The real shift is that the boundary between idea, prototype, workflow, and system is getting blurrier.

I’ll leave you with this: once that boundary blurs, ownership becomes the product.

Chris Keall’s New Zealand Herald piece gets one thing right and one thing badly wrong.

The right part is the alarm, New Zealand has plenty of AI usage and very little serious operational change. Keall described it on LinkedIn as “shockingly low serious take-up”. That part is fair enough, if 91% of firms say they use AI but only a sliver are changing core operations, something is off. I spoke at an event for HSO and I asked a colleague afterwards how was the rest of it the response from my colleague echoed Chris “They’re still trying to explain what Copilot is” I died a little on the inside.

The wrong part is the implied diagnosis, the piece leans toward a familiar answer: more structure, more leadership ownership, more formal seriousness. Lou Compagnone from Datacom gives that frame its cleanest expression. She says AI is “still treated as a technology initiative” and that organisations need “clear ownership and accountability” if they want to move beyond pilots and isolated use cases.

I think that diagnosis is neat, respectable, and still too shallow - sorry not sorry.

I have been arguing for a while now that the real shortage is not hype, licences, or another layer of formal seriousness. In The smarter AI workforce plan is not attrition, it is capability multiplication. I made the case that useful adoption creates demand for builders before it creates labour savings. In AI is changing the operating model of management itself, not just Ways of Working I argued that the shift is really about how work gets routed, reviewed, and improved. And in Part 2: The No-Build Insurance I pushed the same broader instinct again, stop reaching for the grand, expensive, official looking answer when the real advantage comes from narrower operational choices.

New Zealand does not mainly have an AI confidence problem, it does not mainly have a title problem either, it has a workflow translation problem. We have plenty of people who can talk about AI, buy AI, trial AI, and add AI to a strategy document. We have far fewer people who can take a stubborn piece of work, find the friction, and rebuild it so the machine actually carries part of the load. That is the scarce thing, that is what changes throughput.

This matters because “clear ownership and accountability” can easily collapse into org chart theatre. A Chief AI Officer can signal intent, a committee can organise attention and the office of AI can make the whole thing feel more official. None of that is automatically useless, but none of it, by itself fixes the ugly middle where real transformation lives. The ugly middle is where data is messy, systems do not connect, approvals pile up, and nobody trusts the output enough to remove a manual step. That is not solved by better titles. It is solved by redesigning the workflow.

That is why I think the piece is challenging the wrong layer of the problem. Compagnone’s phrase “AI confetti” is good, and I think it names something real. Most firms are still scattering small use cases around the business, with individuals using general purpose personal productivity assistants to draft, summarise, and speed up bits of their day. But the leap from confetti to transformation is not mainly blocked by the absence of a chief AI officer. It is blocked by the absence of translators, the people who can sit between operations, systems, and management and turn a promising demo into a working process. That is the same gap I was getting at in the management piece, the work does not improve because the organisation finally agreed on the right language for AI, it improves because someone changed the actual system of work.

If you tell a business that its next step is clearer governance, it will probably create clearer governance, it will schedule meetings it will name an owner they’ll create principles, they may even produce a semi-coherent roadmap. Then everyone will feel more mature while the actual work stays mostly untouched, the service queue is still slow, handoffs still drops context and the finance process still relies on copying data between systems and the customer still feels the same drag.

That is not capability, it is paperwork around capability and we forgot the process engineering opportunity.

The number in the survey that interests me most is the drop in so called core transformation, from 8 to 4%. Keall treats that as proof that real take-up is low, I think part of it may be the healthiest number in the whole piece. A lot of what passed for transformation over the past year was AI confetti wearing a bigger badge: Pilots, Demos, Experiments, Slideware, They’re all grand programmes that made people feel modern without changing the machinery of the business.

If fewer firms are now calling that transformation, good. A smaller, more honest number is better than an inflated one. I would rather a company quietly fix twelve ugly workflows than loudly announce one enterprise AI strategy. Narrower use does not mean smaller ambition, often it means somebody finally got serious enough to stop performing enthusiasm and start improving throughput, that is the direct challenge I would put back to the Herald piece.

The problem is not that New Zealand lacks enough AI titles, the problem is that most organisations still do not know how to translate AI into changed work. One support queue gets faster. One underwriting step gets cleaner, an operations team removes a layer of manual chasing, the customer journey stops bouncing between people because the context now survives the handoff. This is what progress looks like not a better diagram of who owns the AI programme.

So yes, create governance where governance is genuinely needed. Risk, accountability, and ownership do matter, but stop mistaking those things for the main event.

The useful question is much simpler than the article makes it sound, which workflows got measurably better this quarter? Where did cycle time fall? Where did quality improve? Where did customers feel less friction? Which team can point to a process that now runs differently because AI is doing part of the job?

If the honest answer is “nowhere yet”, I would not rush to fix that with another committee I would go looking for the translation gap instead.

Way back when I was working for Wolters Kluwer in APAC, the defence for why you’d continue a subscription to their legal service was “no lawyer can go into a court with a print out from google as their precedent” True but it didn’t mean you couldn’t get the same insights for cheaper. This is the crisis impacting consulting today - the myriad of lazy Partners who’ve help to grab a headline by not reviewing the grad or juniors AI generated slop hasn’t help their credibility.

The lazy version says consulting is about to get obliterated because AI can now write, summarise, synthesise, and generate respectable looking deliverables in seconds. The defensive version says nothing important changes because clients still buy trust, judgement, and political cover. Both stories miss the awkward middle.

What interests me is that AI may not kill consulting cleanly, it may make midmarket consulting weird. That matters because a lot of midmarket advisory work has always rested on an unstable mix of real expertise and expensive packaging. Not fake work, exactly, but not always deep magic either. Plenty of firms have been paid well to take a messy situation, impose a structure on it, create a persuasive narrative, and hand back a cleaner looking plan. That can be useful, in many cases it is useful, but it also means the category has always contained a layer of value that depends on the client not seeing too clearly how much of the offer is pattern recognition, formatting, and controlled ambiguity.

AI starts messing with that layer first, not the hardest part, not the boardroom judgement call, not the delicate stakeholder management, not the operator who has seen this exact kind of failures three times before and knows where the traps are hiding. Those things still matter, in some cases they may matter more, but a surprising amount of the midmarket consulting middle is exposed once decent synthesis becomes cheap and fast.

If a client can now get a competent first pass on market framing, operating hypotheses, workshop outputs, slide structure, interview synthesis, and scenario packaging without paying consulting rates, something changes. The question is no longer just whether the firm can produce a polished answer, the question becomes what part of the answer actually required them.

That is where the market starts to feel awkward.

The strongest firms will move upwards, they will lean harder into judgement, domain depth, hard client specific calls, implementation credibility, and senior operator involvement. They will make the human part more explicit, not less, they will stop pretending the value is in document production and start showing that the value is in knowing what to do when the document is wrong, incomplete, politically inconvenient, or impossible to execute.

The weaker firms have a harder problem, they may discover that a lot of what looked like expertise was really well packaged pattern recognition - Good slides, confident phrasing structured summaries, a bit of industry language and a plausible operating model. Enough ambiguity to sound sophisticated without being sharply accountable, AI is already uncomfortably good at that zone.

That does not mean clients will suddenly stop buying external help most clients are not looking for a machine to dump words on them, they are looking for someone to absorb uncertainty, create momentum, align stakeholders, and help make decisions that feel expensive or risky. Trust still matters, accountability still matters, being in the room still matters, but the economics around those things will need to change.

The old consulting bundle becomes harder to defend when some of the most visible outputs can be produced much more cheaply. It gets harder to charge premium rates for generic synthesis when the client knows generic synthesis is abundant. It gets harder to hide behind process theatre when a first pass strategy deck no longer signals unusual effort and it gets harder to keep large teams attached to work that increasingly looks like it could have been compressed.

That is why I do not think the clean story is “AI replaces consultants” the sharper story is that AI forces a rebundling. Some work gets compressed, some gets exposed, some becomes more valuable because the fluff around it gets stripped away. A client may become less willing to pay for the production of an options paper but more willing to pay for the person who can look at three plausible options and explain which one will fail inside their organisation and why, that is a different kind of premium.

It is less about presentational polish and more about difficult judgement under messy conditions. This is where midmarket consulting gets weird, because the middle has historically depended on blending those two things together. Enough real insight to sound credible, enough packaging to feel premium, enough ambiguity to preserve room for manoeuvre. AI weakens that blend, it makes the packaging cheaper, the generic parts become easier to imitate. Best of all it raises the pressure on firms to prove that what remains is not just nicer wording around familiar patterns. the ability to respond to this pressure will not land evenly.

Boutiques with real specialist depth may do well, firms with genuine operator credibility may do well. Advisory shops that can combine AI enabled speed with sharp judgement may even widen their advantage. But firms that built their model on expensive synthesis without strong implementation credibility may find the centre of the market getting slippery under their feet.

Clients will notice too, they may not say, “this used to take you three weeks and now I know a machine can do half of it in an afternoon” but they will feel it. They will ask harder questions about scope, they will become less impressed by the polished artefact itself. They will want to know what thinking happened beyond the visible output. The customer will become more alert to whether the team in front of them is actually making hard calls or simply arranging information elegantly. This is healthy conflict.

It may force the category to become more honest about where value really lives. Consulting is not about to disappear. But the old middle may not stay comfortable. AI makes it easier for clients to separate real judgement from expensive synthesis, and once that separation becomes clearer, some firms will move up, some will get compressed, and some will discover that what looked like expertise was more fragile than they thought.

That is why I think AI is about to make midmarket consulting weird, not dead or unsafe just much harder to bluff in.

I think one of the most interesting things about AI right now is that the real advantage is starting to shift. For a while, progress looked like sheer activity, more prompts, more retries. more model swapsm, more chains, more everything. That made sense when the tools were still new and people were still discovering what they could do, but that is not where the next layer of value comes from.

The strongest AI users are often the ones who know when to stop, that might sound less exciting than the usual AI theatre - but i’m not here to be your AI hyper - but I think it is actually a more useful and optimistic idea. Once AI becomes normal inside everyday work, the advantage stops coming from enthusiasm alone, it starts coming from judgement.

Knowing when a rough draft is already good enough is judgement, knowing when a task needs a deeper pass is judgement, knowing when the next token is likely to improve the work versus merely soothe your own uncertainty is judgement. And knowing when the job should leave the model entirely and go back to a human is judgement too.

That is why I think one of the most useful habits in AI is effort discipline, most teams still do not talk about this clearly. instead they talk about prompt quality, model quality, tool choice, access, governance and more recently cost. All of that matters, it does, but a lot of waste appears one layer lower, in the moment by moment behaviour of users who have not decided what level of effort a task actually deserves.

A quick internal summary might need one competent pass and a fast human skim, a sales contract for $100m in product probably needs a slower model, a source check, and a final human rewrite. A messy strategic question may not belong with AI at all until somebody has first made the thinking sharper. Treating those jobs as if they all deserve the same depth of model effort is not sophistication. It is just lack of discrimination, and this is exactly where I a lot of AI overuse begins.

Some users reach for another prompt because the first answer was weak, fair enough. But some reach for another prompt because they have no stopping rule. They keep polishing a low stakes task until the total effort has outgrown the value of the work itself. Others bounce between models not because the job genuinely needs a different capability, but because it feels active and intelligent to keep trying something. In practice that often means paying more, waiting longer, and still not making a clearer decision.

The more mature move is often simpler, decide what “good enough” looks like before you start. As Stephen Covey wrote in 7 Habits of Highly Effective People “Start with the end in mind” this has never been more true than now. Don’t prompt for a task, prompt for a finished thing, then describe everything that thing must be true to.

If the job is low risk, repetitive, and easy to verify, use the cheapest level of effort that reliably clears the bar. If the work is high stakes or publicly exposed, spend more attention where it counts. If the problem is still poorly formed, stop pretending that another model pass will rescue a vague brief. Fix the brief or bring in a human.

This is why I think restraint is becoming a status signal. For a while, advanced AI usage looked like visible cleverness. The person who knew all the tricks seemed ahead, but the next wave of serious users may look calmer than that. They will know which tasks deserve frontier horsepower and which ones do not, they know when to escalate and when to skip AI entirely. Experience will teach them when another pass is real improvement and when it is just expensive hesitation dressed up as diligence.

That matters commercially as well, as firms push AI into more ordinary work, bad effort discipline will get surprisingly expensive. Not only in tokens, although that matters, also in time, delay, and managerial noise. Low value loops slow decisions down, endless retries create the illusion of rigour while quietly making simple work take longer. Teams start paying twice: once in model usage and again in human attention spent reviewing and reworking things that should have been settled earlier.

The goal isn’t to use less AI for the sake of frugality, it is to match effort to stakes.

That distinction matters, heavy AI usage can be perfectly sensible when the value is real, nobody should be proud of saving tokens on work that genuinely deserves deeper analysis. The point is not minimalism, the point is discipline, mature users do not confuse more model activity with better judgement.

I suspect this will become one of the cleanest divides between amateur and professional AI use. Amateurs will often keep going because stopping feels risky. Professionals will often stop because they know the job has already crossed the quality bar. Amateurs will keep spending to avoid making a call, professionals will make the call.

That is why I think one of the next real AI advantages is not better prompting, it is knowing when to stop.

I think one of the most interesting shifts in AI right now is that good judgement is starting to become a product feature. For the past year or two, a lot of the conversation has lived at the wrong level. Vendors talked about model intelligence, buyers talked about seats, access, and pricing, finance teams talked about spend controls, operators talked about prompts. All of that matters, but it leaves out the question that increasingly matters most inside a real business: does the system help people use AI well?

That is why I think Microsoft Copilot Cowork’s /cost skill is more interesting than it first appears.

Not because this is really a story about Microsoft praise. And not because the market desperately needs one more article about AI pricing. What interests me is the design principle hiding underneath it. A simple skill that makes the cost of effort visible at the point of use can do a lot to improve behaviour.

That matters because I have already been circling this theme from a few directions. In AI Cost Is Becoming a Behaviour Problem, the core point was that the bill is not the real issue by itself. The behaviour creating the bill is the issue. In The Smartest AI Users Know When to Stop, the point was that maturity starts to show up in effort discipline rather than endless visible activity. In The Next AI Advantage for ANZ SMEs Is Managing Work Better, the argument was that supervision, routing, thresholds, and review are becoming management capabilities in their own right.

This feels like the next step on from all three, the world has moved from abstract norms into product patterns. In other words, we are starting to see tools embody the behaviours that earlier pieces could only argue for in theory.

That is what makes /cost interesting, it gives the user a clearer sense of what a task is actually worth. It reminds them that the goal is not to minimise spend at all times, the goal is to spend properly, those are very different ideas.

If a Cowork task is genuinely strategic, messy, high-leverage, or likely to move the dial, then spending $15 on it can be perfectly rational. In fact, being too cheap on important work can be its own kind of stupidity. If a better pass produces a clearer strategy, a stronger decision, or a more valuable outcome, then the spend is doing real work.

But the inverse is just as important. If someone spends even $2 on a task that ordinary Copilot, a lightweight assistant, or a standard chatbot could have handled just fine, that is not good discipline. That is not serious adoption. It is just poor judgement wearing a thin costume of modernity.

That is where Satya Nadella’s line about using frontier models for frontier problems becomes genuinely useful. It is a simple management rule disguised as model strategy. Not every task deserves the deepest model, the richest tool, or the most expensive path. Some tasks deserve premium effort. Many do not. The skill is knowing the difference, and the commercial opportunity is designing systems that make that difference easier to see.

That is why I think the most useful lesson here is broader than Microsoft, simple skills may turn out to be more important than they look.

The market still gets distracted by the biggest demos, the most autonomous agent stories, and the loudest claims about replacing whole functions. But a modest skill that clarifies cost, effort, routing, or escalation inside the workflow can sometimes be more commercially important than another round of abstract capability theatre. It helps ordinary users act with better proportion. It teaches better instincts. It nudges people toward the right level of effort before waste, delay, and confusion start compounding.That is a powerful thing!

A lot of AI governance still assumes behaviour will be fixed afterwards. Finance will notice the bill. IT will notice the sprawl. Leadership will notice the confusion. Then somebody will draft a policy. The better path is to shape the behaviour upstream. Make good judgement easier. Make overuse more obvious. Make escalation feel deliberate rather than default.

This is why I do not think the future belongs only to the firms with the smartest models. It may also belong to the firms with the clearest effort signals. The organisations that handle AI well will not just ask whether aa model can do the task. They will ask whether this task deserves this level of spend, this level of reasoning, and this level of attention. They will build operating habits around that question. And increasingly, the best tools will help them do it.

That is the larger opportunity hiding inside something as simple as /cost. It is an example of a broader category of product design that treats judgement as part of the workflow, not as a lecture delivered afterwards. It shows how a small skill can reinforce better stopping rules, better routing, and better economic discipline without forcing every user to become a mini procurement committee.

That is where I think the world has moved forward, we are no longer just arguing that AI usage needs better norms, no, we are starting to see the first useful examples of software that can teach those norms in practice.

And if that pattern spreads, the winners may not just be the people with access to more AI. They may be the people whose tools quietly help them use it with better judgement.

In part one I wrote about the first five challenges and the friction they expose, the next five put pressure on it. This is where leadership can stop being politely curious about AI and start asking whether managers are still protecting weak systems with personal effort.

Challenge #6: “Ban one type of work from reaching leadership unless it meets a standard”
Leadership Challenge: From next


This is where you really get going with AI, as a regular reader you will know that the vast majority of my content is free for everyone as I want to help accelerate AI adoption and ensure that NZInc is a leader not a lagger in AI Adoption. You can spend thousands of dollars on a “AI Consultant” or you can subscribe to get part 2.

Read more

Earlier this week? Well the previous article I teased about this in https://everdayai.substack.com/p/ai-is-changing-the-operating-model. Here’s the conversation you as a founder, owner, CEO need to be having with your leadership. Let’s go…

If I were running a SME in Australia or New Zealand this week, I would stop asking for an AI strategy deck and start issuing sharper operating challenges. That is where the practical gains are. Not in another round of tool comparisons, but in forcing managers to show where the business is still running on unwritten rules, slow approvals, vague ownership, and senior people wasting judgement on work that should arrive cleaner.

The challenges are structured in a way that gives you the actionable challange and my rationale behind them. Please take them, tweak them, make them yours and get moving on your companies AI journey today.

Here are the first five.

Challenge #1: “Pick one workflow where approvals are clogging up growth”
Leadership Challenge: By Friday, show me one recurring workflow where too many routine decisions are still climbing back to a manager, and propose one category of case that should no longer need manual review.
Why: This works because it forces a team to expose a real bottleneck rather than talk vaguely about productivity. In a lot of businesses, the growth drag is not lack of effort. It is quotes, credits, campaign sign-offs, or customer exceptions that keep crawling back up the ladder because nobody has turned judgement into a rule.

Challenge #2: “Write down the thresholds your business is still keeping in someone’s head”
Leadership Challenge: List the five commercial or operational thresholds we rely on most, but have never written down properly: discount limits, margin floors, escalation triggers, refund rules, overdue follow-up timing, VIP customer handling.
Why: Most firms are running on invisible thresholds that feel obvious until the one person who knows them is away or overloaded. This challenge surfaces the hidden rules that keep work socially managed instead of operationally managed, which is exactly where a lot of AI and workflow frustration starts.

Challenge #3: “Identify one place your senior people are wasting judgement on cheap work”
Leadership Challenge: Find one place where a senior person is still spending time reviewing, correcting, or re-routing work that should arrive cleaner before it gets to them.
Why: This is one of the best tests in the whole list because it usually reveals a more expensive problem than bad tooling. In an accounting firm, it may be a partner fixing client notes that arrive without supporting documents. In a distributor, it may be an operations lead checking every escalation because the queue does not separate late but manageable from genuinely high risk. Either way, senior judgement is being spent too low in the stack.

Challenge #4: “Audit one queue that nobody really owns”
Leadership Challenge: Pick one queue that creates drag every week, sales follow-up, support tickets, supplier issues, debtor chasing, compliance reminders. Show who owns it, where it stalls, and what could be standardised or handled as a first pass by AI.
Why: Every (yes every) company has at least one queue that belongs to everyone socially and nobody operationally. That is where dropped balls, duplicated effort, and fake busyness love to gather. Make one manager map the queue properly and you usually find a cleaner operating fix within a day or two.

Challenge #5: “Define what good enough actually means for one repeat task”
Leadership Challenge: Choose one repeat task and define what a good output must include before it reaches senior review.
Why: A surprising amount of rework comes from nobody ever making the quality bar explicit. A quote should show assumptions, exclusions, and margin band. A client update should include source reference, owner, and next step. A support reply should make the decision clear. Once that standard exists, human coaching gets easier and safe AI use gets easier too.

None of those five asks a manager to become an AI expert by Friday. All five do something more useful. They expose where the business is still leaning on memory, interruption, and senior rescue instead of better rules. That is usually the difference between firms that get practical value from AI and firms that keep talking about it.

If a leadership team worked through just those five this week, it would already have a much clearer picture of where the real operating leverage sits. Up next, 5 more actionable challenges, stay tuned, subscribe, even support my writing for as little as a coffee a month, it means a lot to me.

Most AI writing still assumes the prize is labour reduction. Get the model, trim the admin, automate the drafting. Push more work through the same payroll base. Fine, sure if that’s what you think success lots like then make it happen. But a lot of ANZ SMEs are not actually constrained by a shortage of first drafts, they are constrained by something more ordinary and more expensive: too much work waiting for a busy human to notice it, judge it, fix it, or pass it on.

That is why I think the next useful AI story for small and mid-sized firms is not really about automation, it is about management leverage. Spoiler I have some interesting challenges for Leadership to issue to Management coming

Put it bluntly businesses do not need more output first, they need a way to scale management quality before they can afford another management layer. That is a sharper claim than the usual line that AI “saves time”. Time savings are nice, but they are not the real strategic shift. The more interesting shift is that AI can start taking some of the load that sits between work being created and work being properly managed.

In a lot of firms, that middle layer is a mess, a founder checks every quote over $15,000 because margins are thin and one bad number can wipe out the profit on the job. A partner rewrites client emails because junior staff are directionally right but still too soft, too vague, or too risky. An operations lead keeps a mental list of the customers who must never miss a promised delivery window, then spends half the day firefighting the queue. None of that shows up on a product demo, it is still where the business lives or dies.

For the last year, the good AI framing was that work was moving from chat to workflow, and I still think that was right. Chat was the training wheels that we all needed, but the money sits in systems that actually move jobs forward.

Now there is a second shift. Once AI is doing more first-pass drafting, triage, follow-up, classification, and exception spotting, the operating model of management starts to change as well. Managers do less constant touching and more rule-setting. Less chasing, more threshold design, less blanket checking, more exception review. Less rewriting the same kind of weak output, more fixing the system that keeps generating it. That is not a small change, but it is what better management looks like.

Take a 25-person accounting firm. The obvious AI use case is drafting memos faster or summarising a tax change. Useful, but not very interesting. The more valuable use case is a system that produces first-pass client notes with source references attached, marks any claim that is not tied back to a document, and automatically routes anything involving payroll, trust structures, or unusual deductions to a senior reviewer. Suddenly the manager is not cleaning up every note by hand. They are reviewing the handful of cases where the risk is real and the judgement is worth paying for.

A distributor with thirty or forty staff has a different mess. Customer service, warehouse updates, and delivery issues all collide in the same day. The operations manager becomes the human router because nobody trusts the queue to sort itself. A better AI setup is not a charming chatbot in the CRM. It is a system that reads incoming issues, drafts the update, tags the likely cause, and escalates only when the order value is above a threshold, the delay is about to breach an SLA, or the customer has already had two misses this month. That is management leverage. The manager gets fewer interruptions, and the interruptions are better.

Trades businesses have their own version. Usually the owner is still acting as the commercial backstop because quoting, supplier drift, and schedule changes all carry margin risk. A decent AI layer could draft the quote from prior jobs, compare material costs against last month’s supplier pricing, and stop cold if the gross margin falls below, say, 18 per cent or the scope falls outside the usual pattern. That last part matters. The owner should not be reviewing every bathroom renovation quote. They should be reviewing the weird extension with custom steelwork and half-finished plans.

The strongest objection here is obvious enough - but dating very quickly and just sounds like a naysayer - Plenty of managers will say AI still makes too many subtle mistakes, so shifting more supervision into a system is dangerous. Fair point, in some workflows it will be dangerous. If the data is messy, the approvals are vague, or the commercial rules live only inside one person’s head, AI will amplify the confusion rather than fix it. This is exactly why the opportunity sits with management first.

The firms that get value will not be the ones pretending the system is magically correct. They will be the ones that finally make their own standards explicit: what needs evidence, what needs approval, what can be cheap and fast, what needs a slower and more careful pass, what always stays human. In other words, AI rewards businesses that learn how to manage work deliberately instead of socially.

That is also why I do not think the real comparison is “manager versus AI”, no the comparison is between two operating models. In the first, the business runs on interruption, memory, and heroics (firefighting anyone?) In the second, the routine work is routed, checked, and surfaced in a more consistent way, and the human judgement gets concentrated where it has the highest value.

Small firms should care about that more than big firms, not less. Large enterprises can afford committee-heavy governance and a lot of expensive theatre around process. SMEs usually cannot. They need something leaner. They need a way to stop every issue, every draft, and every awkward exception from climbing the ladder to the same two or three people.

That is why I think the next AI advantage for businesses is not just more output per employee, it is the chance to build a better management system before the business solves the problem the old-fashioned way and hires another layer of coordinators, checkers, and internal go-betweens.

The practical question is not “where can we use AI?” It is harsher than that.

Why and Where are our best people still wasting judgement on routine supervision?

Find that answer and you are usually close to the real use case. Not the flashy one, the valuable one.

The first big win won’t be a fully autonomous workflow, it may however be a manager who stops spending Tuesday morning clearing a backlog of small approvals, weak drafts, and follow-up gaps, because the system already handled the ordinary cases and surfaced the three that actually deserve attention. That is not a side benefit. For a lot of SMEs, that is the entire ball game.

Stay tuned for how to challenge management and actually get them moving.

Here is the most uncomfortable sentence in our first month of running consumption-based AI. We asked several hundred people to manage a budget they could not see.

The mechanics are simple enough, every task a user delegates consumes credits, each person has a monthly ceiling: one hundred dollars, or roughly seven thousand credits, for most people, and two hundred dollars, or roughly fourteen thousand, for heavier users. Reach the ceiling and the tool stops, with no reset until the first of the following month. What does not exist, is a running balance, no user can open anything and see how much of their month remains.

What they have instead is a slash command (/cost). type it after a task finishes and you learn what that task consumed. It is a receipt, issued after the money is spent, for one transaction at a time. Our official guidance is to run it after every task and use the number to build an instinct for what different kinds of work cost, so that a cheap result becomes a signal to reach for a lighter tool next time.

The remarkable thing is how well it has worked, a receipt at the moment of spending turns out to be a better teacher than a dashboard nobody opens, and people who ran the command a few times changed what they delegated. The problem is a user who most needs the signal is the least likely to ask for it.

So we compensated where we could. Caps enforced at the platform, spend attributed to a named cost centre, and a fortnightly nudge telling each person in plain language where they sit against their allowance. That last one is the actual balance, delivered by email, because the product could not deliver it in the app, Cowork did the heavy lifting here of course.

Lesson: The economics flipped, and the estate is now hybrid

This is not a switch from fixed to consumption, it is a combination of both, layered across the estate, often on the same users and the same tools. Our AI spend runs is forecast and budgeted for an is climbing, spread across licensed Copilot, our enterprise AI platforms, pay-as-you-go consumption, developer tooling, analytics and CRM agents. Cowork is one meter among many, which is why the governance frame has to bind every tool rather than only the newest one. Governance is how we hold both acceleration and predictable cost, in healthy tension.

Lesson: The persona ceilings, and the surprise about executives

We set dollar-denominated ceilings by persona rather than credit allowances, because dollars are what a manager can reason about.

The counter-intuitive finding is that executives are the cheapest persona. Senior leaders mostly review and summarise, which a standard licensed assistant handles perfectly well, so several are candidates to revert to a plain Copilot licence. Writing that in a post aimed at executives is disarming, and it makes the wider point better than any policy statement: the people with the most authority to buy the capability are often the ones who need it least.

Lesson: Agents break the old arithmetic, and every reason is a lever

Six mechanisms explain why agentic spend behaves unlike a licence. Agents resend accumulated context at every step, up to a thousand times the tokens of a single chat. Roughly 60 per cent of an agentic task’s cost is the agent checking and repairing its own work. The same task can cost thirty times more from one run to the next, which means cost is a distribution rather than a price. Extended reasoning on simple work is pure overhead, poorly designed hand-offs between agents multiply spend for no gain in quality, and prompt verbosity moves the bill enough that concise prompting cut some workflows by 30 - 40 per cent.

Each of those is a control we own rather than a cost we absorb: model routing, prompt hygiene, orchestration design and per-run budgets.

Lesson: Model choice is a first-order cost decision that users make unknowingly

We ran an identical prompt across two frontier models. One returned in 68 credits. The other took 524, close to eight times the cost for the same piece of work. Nothing in the interface told the user that. Our guidance is now blunt: stay on automatic selection or the smaller model by default, try the research and analysis agents in Copilot before reaching for anything premium, and reserve frontier models for genuinely frontier problems. Model routing is our highest-leverage cost control and it currently lives entirely in user habit.

Lesson: The silent burn is a scheduled job, not a person

Our mental model of runaway consumption was an individual doing something extravagant. This was not the case! The real event was a set of scheduled dashboards rebuilding hourly in the background, which consumed a full monthly allocation in twenty-four hours with nobody in the room. Scheduled and background work bills exactly like interactive work but generates no human moment of hesitation. Instrument it separately, alert on it separately, and make someone own it by name.

Lesson: The bill and the behaviour live in different systems

This is the plumbing detail that catches everyone, the dollars and the per-user detail sit in two different planes, cloud cost management holds the actual spend and the commitment drawdown, but not per user. The productivity suite’s credit report holds who consumed what, but not the dollars. Per-user recharge is only possible by combining the two: take each user’s credits from the usage report, value them at the credit rate, then reconcile the total back to the dollars on the subscription. The billing platform alone will never tell you who spent what.

Lesson: This is an industry pattern, not our anomaly

The external evidence matters because it stops the story reading as a local failure. Token prices have fallen roughly two hundred and eighty-fold while enterprise spend on large language models tripled in twelve months. Ninety-three per cent of surveyed enterprises are over budget and a fifth have already throttled AI use over operating cost. Around ten per cent of users drive about sixty-five per cent of consumption, which is precisely why graduated caps should target the right people rather than everyone. The line to end on is not ours, but it should be: tokens are not value, tokens are the bill.

This is a two-part series that’ll reflect on the real lived experiences of consumption models in the enterprise. We started using Cowork about 4 months ago on unlimited plans and although we had a sense that it would be a chargeable tool, the realities of the first month on a consumption model are quite different.

The mental model changed, not just the tool

Copilot behaves like an intern and Cowork behaves like a teammate. The framing that landed best in our onboarding sessions was that Cowork is not a reset but an extension of existing AI habits. Copilot does one small task at a time and you check everything it produces. Cowork takes the whole job end to end and brings it back for you to review and approve. Executives understand this immediately, because it is a delegation story rather than a software story.

Ask, assist, build, delegate

The most useful thing we published was a coherence line across the whole estate:

Autonomy, capability and cost all rise from left to right, inside the same trust boundary. It gives people somewhere to stand before they choose a tool, and it reframes cost as a consequence of delegation rather than an arbitrary tax. We paired it with a borrowed line that does a great deal of work in a room of executives from Satya Nadella “you do not need frontier models for everything, you use frontier models to solve frontier problems.”

Reaching for the most powerful tool is the expensive instinct

Our governance position paper predicted this before general availability, users reach for the most capable tool for everything, including work that a standard licensed assistant would handle at no incremental cost. We also knew the vendor’s own guidance on when to use what would not be ready in time, so we published our own decision card first. That turned out to be the highest-return piece of change material we produced, and it lets us say honestly that we saw the behaviour coming.

Skills are where the compounding value showed up

The demonstrations impressed people, the reusable skills changed their week, s fortnightly executive update built from four prior examples went from roughly four hours of work to about thirty minutes, and a first-draft presentation skill did the same job for another team. The pattern that works is to build the skill after a recurring task, by asking the tool to turn a finished output into a repeatable recipe. The value is not the prompt. It is the institutionalised prompt.

We onboarded narrowly, and then went quieter

Access is off by default. Users request it through our service portal, with manager and cost-centre approval, on the same pattern we already used for licensed Copilot. One month in we have gone further rather than opening up, we agreed a soft launch on a pull basis with no broad publicity, and we deliberately chose a topic other than Cowork for our continuous engagement campaigns.

An adoption team choosing not to drive adoption is genuinely counter-cultural, and it is the most quotable decision in the whole programme. The reasoning is simple arithmetic, if everyone holding a Copilot licence (for us that’s measured in thousands) used Cowork, our run costs would compound 10x in a month. Manager approval alone will not hold that line, because managers approve readily until they get the bill.

Segment the base, or over-serve the ready and under-serve the cold

We mapped four populations rather than one: the enabled cohort, the eligible pool of licence holders, the chat users with no licence, and the wider AI-capable base. That mattered because Copilot adoption across our business units ranges from 30 per cent to 99 per cent, so a single go-live pack would have over-served the ready and under-served the cold. The uncomfortable corollary is that the least active users carry the highest bill shock risk, which means readiness nudges and conservative starting caps matter most exactly where engagement is lowest.

We ran the rollout on the tool itself

The nudge campaign that went to our enabled cohort was built by the capability we were governing. A usage spreadsheet went in, users came out banded by consumption, and personalised guidance was drafted and queued for approval: tailored change communications to all Cowork users in ten minutes of human effort. Heavy users received capacity protection advice and light users received encouragement. If your governance process cannot be run by the capability it governs, you probably do not understand the capability yet.

Next i’ll talk about tokenomics and the uncomfortable truths that all organisations are going to have to face over the near turn. This isn’t just a switch it off and ignore it problem, this is not going away. Operating and Business models need to shift.

To put this into context we have a team who estimated a project would take 3 years, they’ve recut that to 12 months. What is delivering a project in 1/3 of the time worth to you, and how much would you reinvest in Tokens? This is what we all need to be able to answer.

The AI labour story is being told too crudely! The usual headline is familiar by now. AI comes in, jobs go out, companies quietly reduce headcount, and the org chart gets thinner. I do think some of that is coming. Pretending otherwise is silly. But I also think that framing skips the part that happens first inside serious organisations.

Heavy AI adoption may create hiring demand before it creates layoffs. That is not because AI is underpowered. It is because useful AI adoption is operationally demanding. Before a company can remove meaningful human load from the business, it usually has to add or empower people who can redesign workflows, wire systems together, define guardrails, track outcomes, and keep the machinery alive once it is in production.

In other words, the first shortage may not be labour in general. It may be the specific kind of labour needed to make AI useful.

This is why I get impatient with the lazy attrition story. On a spreadsheet it sounds clean. If AI lifts productivity, perhaps you simply stop replacing some people and let the organisation shrink over time. That may happen in places. But as a real operating strategy, it is too passive, and it usually ignores the actual bottleneck.

The actual bottleneck is capability. If your firm does not have enough people who can translate messy work into bounded AI-enabled systems, then AI does not magically solve your labour problem. In the short term, it can expose how weak your internal execution capability really is.

That is why I think the first hiring wave will often be more practical than people expect. Not giant research teams, not moonshot projects. More likely workflow engineers, automation builders, integrators, ops-minded developers, and domain people who understand the work well enough to reshape it.

That layer matters because AI does not self-install, somebody has to decide what job the system owns, where the human still reviews, how failures get handled, how the output is measured, and what gets fixed when performance drifts. That is not background noise. In some firms it becomes an entirely new layer of work. This is also why I think the better comparison is not AI versus jobs. It is capability building versus passive cost cutting.

An organisation that leans mainly on attrition may save some money. An organisation that hires or develops a small number of useful builders can create a compounding internal advantage. One good person who can ship ten bounded AI workflows into finance, support, operations, and compliance changes throughput across the company. That is a very different outcome from quietly leaving vacancies open and hoping the remaining team just absorbs the load.

That does not mean layoffs never come. Some roles will shrink. Some coordination layers are going to be under real pressure. Some kinds of admin work will need fewer people over time. But the sequence still matters.

1. First you build the capability.

2. Then you stabilise the workflows.

3. Then you learn where real substitution actually exists.

Most public commentary jumps straight to the third step and treats the first two as if they do not matter.

I also think this changes how leaders should talk to their teams. If executives frame AI only as a cost-saving instrument, they create defensive behaviour. People protect their patch. Managers avoid redesigning work. The company optimises for fear instead of throughput.

If leaders frame AI as a capability-building shift, the discussion gets more honest. Where do we need builders? Which teams are bottlenecked by repetitive coordination work? Which functions can carry more volume if they get better systems? Which roles become force multipliers if we back them properly?

That is the adult version of the conversation.

It is also probably what many smaller firms will actually do. They are not going to wake up and replace half the company with AI. They are going to hire, back, or stretch a small group of people who can build leverage into the business. Later, that may reduce the need for extra coordinators, admins, or managerial padding. But the first move is often additive in capability even if it later becomes subtractive in headcount.

If I were advising a leadership team now, I would ask a few simple questions.

• Which jobs in this business are constrained by repetitive coordination work?

• Who here can turn that work into a bounded AI-enabled workflow?

• Are we assuming labour savings before we have built the capability required to deliver them?

• Are we backing the few people who could multiply everybody else’s output?

Those questions are more useful than another dramatic argument about which profession disappears next.

The labour story is still moving, but I think one thing is already clear. The first real organisational effect of AI may be a scramble for builders, not a clean wave of layoffs. The firms that understand that will make better decisions than the ones still treating AI as either an instant redundancy machine or a shiny toy.

I think a lot of firms are still asking the wrong AI question. They are asking which model to buy, which vendor to standardise on, which assistant has the best interface, or which lab is slightly ahead this month. Those questions are not irrelevant. They are just no longer the main event.

The more useful question now is much blunter: can you actually get AI installed into real work? That is why I think AI has stopped being mainly a tools problem. It is becoming a deployment model problem.

The gap that matters is no longer between firms that have AI licences and firms that do not. It is between firms that can point to real workflows now running faster, cheaper, or with less human drag, and firms that are still mistaking experimentation for progress.

I keep seeing the same pattern. A company buys access to a model. It runs a few workshops. Teams are told to experiment. Somebody shares a prompt pack. Someone else gives a presentation about the future of work. Six weeks later there is a lot of language about momentum, but the actual business process still looks the same. The queue is still manual. The approvals still bottleneck. The handoffs are still clumsy. The AI lives in a chat window instead of inside the work.

That is not really a tools failure. It is a deployment failure.

The most interesting signal in front of me right now is not that models keep improving. They obviously do. The more important signal is the growing attention on the people and systems that can get AI embedded into production workflows. Cursor’s forward deployed engineer story is one example. The broader enterprise chatter points the same way. The hard part is not getting access to intelligence. The hard part is getting intelligence into the workflow without creating a new mess around it.

That means the firms pulling ahead are building a different capability. They are learning how to take a messy business job, narrow the scope, define the boundary, assign an owner, set the review points, track the outcomes, and improve the system once it is live.

That is the deployment model. It sounds less exciting than a frontier-model debate, which is probably why people underrate it. There is no glamour in saying your advantage is workflow mapping, exception handling, audit trails, and boring operational discipline. But in practice that is exactly the machinery that turns AI from an interesting tool into operating leverage.

This is why I think a lot of current model talk is slightly misleading for ordinary firms. Yes, model choice matters. Latency matters. reliability matters. Provider risk matters. Cost matters. But if you cannot reliably ship one useful AI workflow into finance, support, legal ops, or sales operations, then a marginally better model does not rescue you. Your bottleneck is not the model. It is your ability to deploy.

That is also why I would be careful with organisations congratulating themselves for “having an AI strategy” when what they actually have is tool access plus PowerPoint. A real AI strategy now looks more like a rollout system. It knows how to choose the next workflow, launch it with guardrails, measure whether it worked, and repeat the pattern somewhere else without starting from zero every time.

If I were sitting with an ANZ leadership team right now, I would not ask to see another demo. I would ask to see the deployment in motion.

• What workflow are we changing?

• Who owns it?

• Where does the AI act?

• Where does the human review?

• What is the success metric?

• What happens when the system gets it wrong?

• How quickly can we use the same pattern in the next part of the business

  Everyday AI is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Those are the questions that separate AI theatre from real capability.

I also think this changes which people matter most inside the organisation. Early on, the loudest voices were often prompt enthusiasts, innovation leads, or vendors selling possibility. In the next phase, the important people are the workflow owners, integrators, engineers, ops leaders, and practical people who actually know where the process breaks in real life. The centre of gravity is moving from ideas to installation.

That is the shift I think leaders need to absorb. The winners are not just buying intelligence. They are learning how to deploy it repeatedly. And once that becomes a repeatable internal habit, the model itself stops being the whole story.

Here’s the thing I think a lot of people still miss about AI adoption: the next wave probably does not begin with enterprise transformation programs, governance committees, or another round of chatbot trials. It begins when small businesses quietly start using persistent AI agents to run real work in the background.

That matters because small businesses do not buy technology to admire it. They buy tools to survive. If an always-on AI agent can chase unpaid invoices, reconcile transactions, triage support requests, draft campaign variants, prepare month-end packs, or keep scheduling moving without constant prompting, that is not a novelty. That is operating leverage.

For the last two years, most AI discussion has been trapped in the frame of the prompt. Someone asks a question, the model answers, and we all debate whether the answer was good enough. But that framing is already getting old. The more important shift is from AI as a tool you talk to, toward AI as a worker that stays attached to a job.

That is why small business is such an important proving ground. Big companies can afford to spend twelve months in pilot mode. They have process owners, procurement reviews, security gates, change programs, and political reasons to move slowly. A 40-person firm does not have that luxury. If the owner believes a persistent AI system can reduce admin drag in finance, support, or marketing, they will try it quickly because the pain is immediate and the upside is obvious.

This is also where the product market is finally getting more mature. The winning AI products for this segment will not look like generic chatboxes. They will look like job-shaped systems. The promise is not “ask me anything.” The promise is “I keep your receivables moving,” “I prep the monthly close,” “I route and answer first-line support,” or “I keep your campaign engine warm every day.”

That packaging matters. Small businesses do not want to become AI labs. They want outcomes. They do not want to orchestrate five models, tune prompts every week, and build evaluation harnesses for sport. They want something that behaves like a junior operator who never forgets the checklist, never leaves the queue untouched, and keeps improving as the business learns where the bottlenecks actually are.

This is also why I think the labor conversation needs to get more honest. A lot of executives still frame AI as a headcount-reduction story, usually through attrition. The logic sounds sensible on paper: if AI helps, maybe you simply stop replacing some people and let the org shrink naturally. Sometimes that will happen. But as a primary strategy, it is too passive, and in many cases it misses the real opportunity.

A young AI engineer, even an imperfect one, can be more valuable than another round of quiet attrition because they actively create operating systems rather than just reducing salary lines. Attrition is subtraction. A capable early-career AI engineer is multiplication. They can wire tools together, design workflows, build lightweight guardrails, instrument what works, and turn scattered AI experiments into repeatable internal machinery. One person who can reliably ship ten useful agents into finance, support, sales ops, and marketing can create more enterprise value than eliminating two or three roles and hoping the remaining team somehow absorbs the work.

That is the strategic distinction. Replacing headcount through attrition saves cost. Building agentic capability changes throughput. The first helps the P&L a little. The second changes what the company can do.

And there is another uncomfortable truth here: many businesses will discover that the first real return from AI does not come from replacing experienced people. It comes from increasing the output of the people they already trust. A finance lead with an always-on close assistant becomes faster. A support manager with an always-on triage layer handles more volume without drowning. A founder with an AI ops layer can run a cleaner business without hiring an entire middle layer prematurely. In other words, the best early use of AI may be to delay managerial bloat and administrative sprawl, not to hollow out the core team.

That is why the small-business angle is so important. SMBs are where the economics are clearest. If an AI worker saves six hours a week in invoicing, five hours in support triage, and several days a month in reporting and reconciliations, nobody needs a manifesto to understand the value. The result shows up in speed, fewer dropped balls, and less founder exhaustion.

If I were advising a small or mid-sized company today, I would not start with “how do we roll out AI?” I would start with “which recurring jobs are slow, repetitive, expensive, and ugly enough that nobody really wants to own them?” That is where always-on agents belong first.

A few examples of reasons to act now:

• If invoices regularly go out late, build or buy an AI workflow that drafts invoices, checks missing fields, nudges approvals, and follows up on overdue accounts.

• If support inboxes clog up every Monday, deploy an agent that categorises requests, drafts replies, escalates urgent items, and summarises trends by product or customer segment.

• If month-end close is still a fire drill, use an agent to collect source files, flag anomalies, prepare variance notes, and assemble the first reporting pack for human review.

• If marketing output depends on one overworked person, set up an agent to generate campaign options, repurpose content across channels, track performance, and keep the content calendar moving.

• If the founder is the human API for everything, use agents to prepare status summaries, scheduling options, follow-up drafts, and operating dashboards before decisions get blocked.

None of this requires pretending the systems are perfect. It requires choosing bounded jobs where partial autonomy is still valuable. That is the practical threshold most companies should care about. Not “can the AI do everything?” but “can it do enough of this recurring work that my team gets leverage every week?”

That is the shift I think we are about to see. The AI employee probably does not arrive first as a polished digital executive inside a Fortune 500 boardroom. It arrives as a background worker inside a small business, quietly handling the operational sludge that has always consumed too much human time.

And once that starts working, it will spread very fast. Because unlike the last wave of AI adoption, this one will not be judged by demos. It will be judged by whether the work got done.