From AI acceleration to an AI operating system

Atlassian's "State of Teams 2026" report puts two numbers next to each other that explain most of what is happening inside companies right now. 85% of knowledge workers say they use AI at work. 29% say it is embedded in their daily workflow. Executives see the same split from the other side: 89% report that AI has increased the speed of work, and 6% can point to a clear example of return at the level of the whole organization.

That gap is not an adoption problem. People adopted. It is a coordination problem. Speed accumulates individually while the company goes on working the way it always did. The knowledge is T-shaped.

Velir had been doing AI work for years already. We have very curious and forward-looking team members finding ways to individually rebuild every day workflows using generative AI tools which showed up in our machine learning and data science, marketing segmentation, personalized experiences and search, and DXP operational efficiency enhancements. However, that does not always add up to a company that operates differently.

Individual speed is not company speed

In a services business, the distinction shows up first in the sales cycle. An estimate that comes back in two days instead of six, or a set of requirements a client can review while the conversation is still warm, shortens the window in which an opportunity can go cold. Time kills opportunities. You do not lose a pitch dramatically. You lose it at the edges.

The same logic runs through delivery. One person's faster workflow saves that person time. A workflow that carries information out of business development, through estimation, and into the delivery team's kickoff changes what the company can commit to and how confidently it can price. That is the threshold. Individual acceleration is something capable people do for themselves. Company transformation is what happens when work crosses a team boundary without being rebuilt on the other side.

Crossing that boundary is nobody's job by default. Everyone's incentives point at their own throughput, which is exactly why the coordination work goes undone. That is the argument for a dedicated role, and it is the argument we made.

The role, and why it reports where it does

Velir created a VP of AI Enablement reporting to the CTO, working with a core group of subject matter experts drawn from each function. The mandate has two halves:

1. Drive AI adoption inside the company and across teams.
2. Own client-facing AI enablement services, helping clients benefit from the same insights and techniques we use to transform our own work.

Those halves run together rather than in sequence, which is why the services we take to clients are ones our own teams use every week.

Three principles decided everything after that

Every choice that followed traces back to one of three.

1. Centralized guidance, with flexibility built in

Two failure modes are common. A central AI team that owns all AI becomes a queue, and everyone waits behind it. No center at all, and you get hundreds of private experiments that never compound into anything.

We split it. The center owns the standard: one charter, one library, one maturity ladder, one approved-tools list, one intake path for use cases, one person accountable for the roadmap. The functions own what gets built and how it behaves in their world.

The center's real work, though, is circulation rather than governance. It carries what one pilot learned to the three teams about to hit the same wall. It notices when four groups have independently converged on the same pattern and turns that pattern into a standard before it fragments into four incompatible versions. And it answers for adoption at the level of the whole company, not the level of any single team's enthusiasm.

In practice that meant seventeen role playbooks rather than one curriculum, so a QA engineer and a content strategist each find their own starting point. Our internal tooling encodes the same split: shared logic lives in one place, and each function's own experts change the procedure their commands follow without touching what another team depends on.

2. Unlock what individuals already know, then connect it

The people who know where the time goes are the ones doing the work. They did not need convincing that AI was useful, because most of them had already proved it to themselves. What they needed was a way to turn a personal shortcut into something a colleague could run.

So we taught building, not just using. Fundamentals training for everyone, then a second session a month later on building a reusable skill. That second session is the one most programs skip and the one that changes the trajectory, because it turns users into builders. Biweekly office hours came with an explicit rule: bring a stuck prompt or a workflow you want faster, not a hypothetical. A bimonthly Science Fair gave teams a stage for what they built and what failed. Everyone got a sandbox, so a workflow that writes to a project board does it somewhere harmless first.

The result shows in where the work came from. The build that cut a thirty-two-model data project to forty-three seconds end to end came from an analytics engineer. Bulk test case generation came from QA. Rapid prototyping workflows came from design. Figma-to-Jira functional specification bootstrapping came from the analysts. None of it came from a central AI team directly.

The wins that changed the company, though, were the ones that crossed a team. Business development's opportunity brief, scope of work, and estimate now feed the estimation workbook and the delivery team's internal kickoff deck. The assumptions a salesperson made about scope arrive at the project manager and the technical lead intact, rather than being reconstructed from a call recording three weeks after the opportunity closed. That handoff was always the expensive part of starting a project, and it was expensive for reasons that had nothing to do with anyone's individual speed. Fixing it required two functions to agree on what a scope document contains and what a kickoff needs from it - the kind of agreement that only happens when someone is accountable for making it happen.

There is a noticeable tipping point when scattered AI experimentation turns into coordinated, cross-functional acceleration. And with the right approach, it happens faster than you would expect. Where there was once resistance to change, there is now genuine appetite for what this makes possible.

3. Startup mentality, at scale

A company of Velir's size can neither plan AI centrally nor leave it to chance. What we could do was make experiments cheap to run and make winners cheap to copy.

A short set of rules did most of the deciding. Start with real work rather than theory. Go after the small tasks people do constantly, because ten minutes off a daily task beats four hours off something that happens twice a year. Keep a person in the loop. Prefer a simple workflow over an elaborate automation. Share what works, and retire what doesn't.

That last rule is the one most programs skip. Every pilot we run ends with a decision — scale it, revise it, or stop it — instead of sitting at "in progress" until everyone forgets about it.

Ninety days, condensed

We did not run this in a clean ninety-day block, and neither will you. What follows is the sequence we would use if we started over, with the detours removed.

Days 1 to 30: Make coordination someone's job, and find out where the work hurts

Name one owner whose mandate covers both adoption and the work that crosses teams, reporting high enough to unblock things, and publish a charter covering purpose, goals, success measures, and approved tools. Get the acceptable-use policy out in month one, when it reads as permission to experiment, rather than month four, when it reads as a crackdown. Then interview every function with two questions: what do you do every week that you resent, and where does your work stall waiting on another team? The second one finds the cross-team wins, and it is the question most programs never ask. Those conversations set our entire backlog. Set your adoption baseline before you try to move it, and name AI champions by function instead of hiring a central team.

Days 31 to 60: Teach the fundamentals, then teach people to build

Train everyone on what the tools do well and badly, then run the build-a-skill session within a month. Open office hours on a fixed cadence and stand up the library (use case intake, a prompt and skill library, role playbooks) so people find their own entry point instead of waiting to be assigned one. Pick three to five pilots, each with one owner and success defined before it starts, and make at least one of them a handoff between two teams rather than a task inside one. That is the pilot that teaches you the most and the one you will be tempted to skip.

Days 61 to 90: Make the winners repeatable and the learning visible

Package what worked into skills grouped by function, so a person gets a command set that matches their job rather than a directory to browse, and put each one on a maturity ladder with promotion gates. Run your first Science Fair, demoed by the people who built the work rather than by the program lead. Then report to leadership by department, with each team stating its own goals and status in front of its peers — that accountability moved AI from an interest to a commitment faster than any training did. Every pilot exits the quarter with a decision: scale, revise, or stop.

What happens after day 90

Ninety days gets you a working program, not a finished one. Ours runs on a cadence now, and the cadence is the part that compounds.

Office hours stay biweekly, because the questions change as people get better, and those questions are how we find the next quarter's backlog. The Science Fair runs every other month. Every department reports its AI goals and progress at the quarterly readout, in front of the other departments. The skill inventory gets re-scored every quarter, which is how a skill nobody has run in three months gets retired rather than quietly rotting in the library. And every quarter we publish what actually shipped to the whole company, with contributors named.

The maturity ladder is what carries the work past the finish line. A skill enters as a concept, becomes a prototype, gets documented, gets validated by someone other than its author, and only then becomes a firm-wide standard. A good share of what we run today sits in the middle of that ladder, which is the honest state of it. The gates are what keep us from mistaking activity for capability.

What changed in our work

An agent now touches almost every phase of our delivery pipeline, and a person reviews every one: design, environment setup, functional specifications, component build, code review, information architecture, data and systems integration, content migration, and QA. The depth is uneven by design. It is furthest along where the work is most repetitive, such as content migration, code review, and QA, and stays light where judgment dominates.

Several skill families run daily now, organized into plugins that cover broadly shared tasks as well as role-specific workflows. Those gains come less from any single tool than from connecting the systems the work already lives in: the weekly client status report is assembled from the Jira project, the Smartsheet plan and risk register, internal Zoom standups, the project Slack channel, and the SOW in SharePoint, then published to the client's Confluence space. Weekly client status reports went from two to three hours of writing to about thirty minutes of review. Business requirements drafting went from roughly two days to two hours. A quarterly business review that took eight to twelve hours of preparation now takes about three. A scope of work went from six hours to two, and an opportunity brief from three hours to forty-five minutes. On one SitecoreAI build, component development ran eight times faster. On a thirty-two-model data project, a full build finished in forty-three seconds and a changed model rebuilt in 2.77 seconds.

Across every team we can point to dozens of tasks that are hours or days shorter than they were, often with better consistency, because the output is built on a team's shared agreement about what good looks like rather than on whoever happened to be writing that day.

Five things we would tell you

1. Measure the baseline before you automate anything. If you do not know what the manual version costs, you cannot prove what changed, and you will spend the next year arguing about estimates. Time the old way once. It is the highest-return hour in the program. Keep a matrix that tracks skills and pilots, and update it.
2. Prioritize the handoffs, and let depth stay uneven. Chasing even coverage across a delivery pipeline is how a program spends a quarter automating something that happens twice a year. The highest-value targets are the points where work passes from one team to another, because that is where information gets rebuilt from scratch.
3. A skill needs an owner who is not its author. The person who built a workflow is the wrong person to judge whether a stranger can run it. Handing ownership over is what turns a clever tool into a company capability.
4. Instrument adoption separately from the tools. We changed platforms mid-stream and lost part of our measurement baseline with it. Track the behavior rather than the license dashboard, and the number survives the next migration.
5. Set your contract language ahead of your adoption curve. Client agreements were written before any of this existed. Updating master agreements and statements of work should start the same month the training does.

Where this goes next

The services we now take to clients are the ones we needed ourselves.

Agentic Content Operations. Redesign how content gets planned, produced, governed, and shipped once agents are in the workflow.

DXP AI Enablement. Build and orchestrate the AI touchpoints inside Sitecore, Optimizely, and Drupal. Velir's work on AI-powered build accelerators, Horizon Financial Intelligence engine for Sitecore, and embedded agents in all 3 platforms is where that started for us.

AI Data Readiness and Governance. Fix quality, lineage, and the semantic layer so an AI answer can be checked.

Decision Intelligence and Applied ML. Put forecasting and next-best-action models where someone acts on them.

AI Training and Enablement. Role-based, hands-on guidance for the people doing the work. For most teams this is the front door.

If you are somewhere in the middle of this (plenty of people using AI well, not all of it compounding) the next move is usually not just more training. It is picking one handoff between two teams and making it work end to end. Contact Velir if you want help finding the one worth starting with.