A senior leader I work with had been telling everyone who would listen that AI was going to transform her team. She had funding. She had air cover. She had a pilot in the wild and a deck full of green ticks. Six weeks after launch, only two people on a team of forty were using the tool. Both of them sat one desk away from the engineer who built it.
The AI worked. The integration worked. The training worked, in the sense that everyone had been trained. What had not worked was the part nobody put on a slide: the operating rhythm of the team that was supposed to use the thing.
That experience, and a dozen others like it I have watched up close in the last 12 months, is why I have come to believe one stubborn idea about innovation in mid-2026.
Innovation only compounds when people adopt it.
Capability is cheap now. Adoption is not. The teams that will pull ahead in the next 18 months are not the ones with the smartest models or the fanciest agents. They are the ones whose AI tooling has become inseparable from the way work actually gets done. That distinction is doing enormous work in this sentence and I want to spend the rest of this essay unpacking it.
The disconnect at the heart of every AI strategy
Walk into almost any enterprise in Australia today and you will find two things running at the same time.
The first is an AI strategy. There are committees, vendors, platforms and a Friday demo. There is a Copilot rollout, an internal use-case backlog, a partnership with Microsoft or Anthropic or OpenAI or all three. The strategy looks like progress because progress, as everyone knows, is what you put on a slide.
The second is the actual work the business runs on. The proposals that need to ship. The pipeline that needs to be inspected. The customer reviews that need to be prepared. The deal hygiene that nobody enjoys but that determines whether the quarter lands. That work runs on muscle memory, custom spreadsheets, half-remembered shortcuts and an enormous amount of human judgement compressed into Slack messages and one-line replies.
The AI strategy and the actual work mostly do not touch.
When they do touch, it is usually because an individual contributor figured out on their own that pasting a meeting transcript into Claude beats writing the recap by hand. The adoption that has happened, in other words, is bottom-up, undocumented and entirely dependent on whoever happens to be motivated this week.
You can run a perfectly respectable business this way for a while. You cannot compound advantage this way, because compounding requires the gain to outlive the individual who discovered it. That is the gap I have spent most of the last year trying to close.
The operating rhythm matters more than the roadmap
Most AI strategies I see lead with a roadmap. A sequence of capabilities, mapped against quarters, with budget allocated and milestones agreed. The roadmap is fine. Roadmaps are easy. Roadmaps survive contact with reality for about six weeks.
What does not survive without active maintenance is the operating rhythm. By which I mean: the recurring forum, with the right people, with the authority to make decisions, that meets often enough that AI work does not drift to the bottom of everyone's priority list.
At Brennan we co-established something called the Customer Team Innovation Centre. The name is duller than the function. It is a cross-functional group of leaders who meet to use AI to rethink systems, processes and ways of working. The implicit mandate is "do more with the same". Increase revenue without adding headcount. Lift quality without lifting effort. Find the leverage points where small AI investments produce disproportionate change in how the business runs.
What makes the Innovation Centre work is not a methodology. It is the simple fact that the right people are in the same room, with sufficient frequency, with enough seniority to do something about what they discover. Anything that gets surfaced has an owner before the meeting ends.
I am not romantic about this. The Innovation Centre is unglamorous in practice. Most weeks it is people staring at a spreadsheet of opportunities and arguing about which two to prioritise. But the forum exists, it has not lapsed, it produces decisions and the decisions become tools. That is the operating rhythm. Roadmaps die. Operating rhythms compound.
A practical test, if you are building an AI practice inside an organisation: if the Innovation forum stopped meeting next month, would the AI work stop? If yes, you have a roadmap problem. If no, you have an operating rhythm and you can build on it.
Three patterns we built
Most of the tools we have shipped in the last 12 months fall into three patterns. I think of them as the building blocks of an AI-enabled practice, not because they map to any particular vendor's taxonomy, but because each one solves a different shape of problem.
Skills: the consistency layer
A Skill, in the way we use the word, is a tool that enforces a standard. It knows the right way to do something the organisation already had a right way for, and it makes that right way the default.
The example I use most often is brand standards. Every organisation says it has a brand voice. Most organisations cannot describe it precisely enough that two different people would write the same paragraph and produce something on-brand. The brand standard exists in tribal memory and senior approval rounds.
A Skill turns the tribal memory into an artefact. It encodes the standard once, then applies it consistently every time someone uses it. The first version is usually disappointing. The standard turns out to be less stable than people thought. So you go talk to the people who hold the standard in their heads and you ask better questions. You iterate the encoding. After three or four passes the Skill is producing output that the senior approvers nod at rather than rewrite.
The interesting thing about a good Skill is that it is the opposite of clever. It is not a model showing off. It is a model constrained inside an organisation's specific definition of "right". The cleverness lives in the constraints, not the output.
Adoption of Skills follows a predictable curve. The first few users are tentative. They double-check the output, they edit lightly, they spot the edge cases. Once they trust the Skill they stop double-checking. Their colleagues see them stop double-checking and try the Skill themselves. Within a few weeks the Skill is being used as a default, not a tool. That is the moment you know it has stuck.
Agents: the synthesis layer
An Agent is a tool that does the cognitive work of synthesis on someone's behalf. It pulls together information from multiple places, makes sense of it, and proposes a path forward. The user is not commissioning a single output, they are asking for an opinion informed by context they did not have time to gather themselves.
The pattern I see working best is the coaching agent. Someone walking into a customer meeting can ask an agent for a briefing. The agent ingests the account history, the recent activity, the deal stage and the open risks. It returns a short synthesis: here are the three questions you have not asked yet, here is what you should listen for, here is the risk to your close date if you do not address it this meeting.
The user does not need to read every email and CRM note before the meeting. They need the agent to have read them and surfaced the bits that matter. The cognitive load shift is the value, not the model behind it.
The trap with Agents is overbuilding. The first version of every Agent I have built has been too sophisticated. We optimised for impressive reasoning when what users wanted was a fast, opinionated answer. The second version is always stripped down. Less context, fewer steps, a faster reply. Adoption climbs every time we cut, not when we add.
Projects: the leverage layer
A Project is a longer-running collaboration between a person and AI that goes beyond a single output. It is the shape of work where the AI is participating in an ongoing operating process, not just generating a thing.
The example I lean on is sales management. A sales manager has a recurring rhythm: weekly forecast, monthly review, quarterly planning. Each of those touchpoints requires the same shape of analysis run on slightly different inputs. A Project is the artefact that captures the recurring shape. It includes the prompts, the data connections, the tone of the manager's coaching style and the way the manager prefers to consume the information.
Each week the manager opens the Project. The Project pulls in the new pipeline data. The Project produces the weekly view. The manager makes decisions. The Project absorbs those decisions and shapes the next week's view. Over weeks and months the Project becomes increasingly attuned to how that specific manager runs their territory.
The leverage in a Project is durability. A Skill does one thing well. An Agent does one synthesis well. A Project compounds because it is participating in a process that itself compounds. The third month of a Project produces sharper insight than the first because the Project has internalised three months of corrections, preferences and decisions.
Three things we got wrong
I am suspicious of writing in this format that does not include the parts that did not work. Most innovation essays read like the building of the pyramids viewed from the top. Mine should not, because the next 12 months of this work depends on being honest about where the first 12 went sideways.
We built too much before testing
The early instinct in any AI practice is to build big. The capability is genuinely astonishing and the team is excited. So you scope an Agent that does seventeen things and you spend three weeks polishing it.
Then you put it in front of users. They do not understand what the seventeen things are. They cannot remember which thing to ask for. They get one answer they did not expect and they stop using the tool entirely.
The fix is to ship smaller. Build the Skill that does one thing, brilliantly, with no settings. Put it in front of users. Watch which features they reach for and which they ignore. Add the next capability only when usage data tells you what to add. This is unglamorous and it bruises the ego of whoever wanted to ship the seventeen-feature version. But it is the only path to adoption I have seen work consistently.
We treated AI literacy as binary
For a long stretch I assumed that someone in the team either "got AI" or they did not. The early adopters and the laggards. This framing is comfortable because it lets you focus your effort on the converts and stop worrying about the rest.
It is also wrong. AI literacy is a continuum. The person who looks like a laggard might just need a different entry point. The early adopter might be using AI brilliantly for one workflow and not at all for another. Treating literacy as binary leaves enormous adoption gains on the table because you stop investing in the people who would benefit most from a more careful onboarding.
The corrective is to build entry points at multiple levels. A Skill that requires no skill at all is the gateway. A Project that demands more sophistication is the deep end. Most people need to start in the shallows and graduate over months. Treat that journey as real and you find adoption in places you would have written off.
We underestimated how much of the work is communication
Halfway through the first year I noticed something uncomfortable. The tools that were getting the most usage were not always the technically most sophisticated. They were the ones whose framing had landed. Where the team understood not just what the tool did, but why it mattered to their specific role, what behaviour it was replacing and what they would do with the time it saved.
In other words, the tool was right. The story was not. We had to rebuild the narrative around several pieces of work that were already shipped, then watch adoption climb because we had finally explained the thing properly.
The lesson is that an AI tool is two products. The code is one product. The story that gets people to try the code, sustain through the awkward first week and integrate it into their week is the other product. The story is at least half the work. Most engineers I know would rather build the code product. The teams that produce compounding outcomes treat the story product as equally important.
What's next
The next 12 months of this work, as I see them from where I am sitting, are going to be about three things.
The first is moving from single-practice tools to cross-practice agents. Most of what we have built so far has lived inside one practice: pre-sales, sales management, marketing. The harder and more interesting work is agents that span practices, where a customer outcome requires consultancy, delivery and support to be working from the same view of the world. The plumbing for this is not impossible. The change management is hard.
The second is data fabric as connective tissue. None of these tools work properly without the data underneath being clean, current and reachable. Microsoft Fabric, Data 360, similar platforms from the major vendors, all of them are doing useful work here. The unglamorous truth is that the success of an AI practice in 2027 will be determined more by data hygiene in 2026 than by model selection.
The third is the customer-facing version of all this. So far we have built AI to make our team better at serving customers. The next horizon is AI that customers experience directly: agents that handle aspects of the customer journey, surfaces that personalise without feeling creepy, tooling that makes a customer's relationship with an organisation feel like one continuous conversation rather than a series of handoffs. This is harder, riskier and where the next wave of differentiation will land.
Underneath all of it, the same principle applies. The technology is no longer the hard part. Earning adoption is. Build for the people who have to run the tool on Monday morning, give them a forum where the tools can compound into operating rhythm and tell the story properly. That has been the lesson of the last 12 months and I expect it will be the lesson of the next twelve too.
Nobody has all the answers at the forefront of technology. The best outcomes have come from working it out alongside colleagues and industry peers navigating the same territory. If you are building something in this space, I would love to compare notes.