The Real Cost of an AI-First Data Practice: Tokens, Time, and Influence

Here is the framing I keep coming back to, because I think it applies to any mid-size company trying this, including consulting firms weighing an AI operating model for consulting firms. Every change you push, from first idea to real adoption of agentic AI in professional services, draws down three separate reserves, and you have a fixed amount of each.

Tokens. Your model subscription gives you only so much capacity per week or session, your token budget for the week. At a low-spend tier, this is a real wall. Above that, it is a budget line you can raise, so treat it as the cheapest and most elastic of the three. If tokens are your binding constraint, you are usually optimizing the wrong thing.

Time and attention. You get 8 to 10 working hours on a normal day, 12 in a peak, and no more. The harder limit is attention, because those hours are split across parallel work, and focus does not divide as cleanly as time does.

Influence. Your ability to get leadership to hear an idea, budget it, secure licenses and infrastructure, and get other teams to adopt the change. This is the scarcest of the three and the slowest to refill.

The point is that you spend from all three at once; you can trade between them, but only so far, and the trades that look cheap often are not.

The trade that went badly

One month, every consultant in the Lab was fully booked. The overflow landed on me: helping with new opportunities, owning three new offerings, and building agent-retrievable indexes of our collateral, an early example of AI agents for enterprise operations, so retrieval stopped eating my manual hours.

The proper build was to wire the indexes straight into the source storage, the SharePoint libraries and our internal platform, running against live data. That cost influence: approvals, new connections, infrastructure changes, and cross-team coordination. I decided not to spend it that month. I took the cheaper local path and tried to cover the gap with tokens, building the first index and telling Claude to mimic the approach for the rest rather than building each one carefully myself.

It failed on both counts. I burned my entire weekly token limit in a few days, and the indexes came back mostly empty because the source documents did not hydrate properly, and I did not check the output early enough. I had spent the tokens, gotten almost nothing, and still had to put in the time to do it right anyway. I had declined to spend influence, and I ended up paying in tokens and time regardless. The direct connection build is still ahead of me. I will spend the influence on it when the cost is worth paying.

Where this came from

A year ago, this was not abstract. Two months after I joined the Lab, we had a month with zero wins across the dozen-plus opportunities we were supporting. The Lab had run for years, but it relied on peopleware: no central tracking of in-flight work, no prioritization, no visibility into who had capacity. The first real volume spike broke it.

The cause was structural, not effort. Almost everything the Lab knew lived in a few senior heads: how to scope a discovery, how to position a Snowflake or Databricks offering, and how to write a winning proposal. And demand arrived across content, presales, go-to-market, and reporting at once, with no way to see or rank it. Hiring could not be fixed quickly because you cannot onboard people to knowledge that exists only in someone's memory. It has to be written down and made usable first.

So, the first thing I did was not build. I got a few of us access to Claude Code through the company AI workgroup, then made it a standing process: one message, you get a license, no approval chain. Access first, building second. In hindsight, that access-first process is close to a small Claude Code enterprise adoption case study for the rest of the org.

What followed is an AI-first operating model for the Lab, which some would call an AI-native operating model. I led it, set the standards, procured the foundations, and built most of the tools myself, a hands-on exercise in building AI agents for internal operations, which was only possible because they sit on Claude as skills and tools rather than applications I had to engineer from scratch. The two that map straight to the zero-win failure: a Lab operations tool that connects to our corporate platforms and gives the single prioritized view of in-flight work we lacked in May, and a presales assistant, a form of presales automation with AI, that codifies how we run an engagement from first call to proposal, so a proposal that needed our most experienced people for two days is now within reach of a wider set of the team. Around those, about a dozen more: offering and case-study assistants, a deck builder in our corporate template, and search and retrieval over our own collateral.

What the numbers do and do not say

In mid-summer, we moved to focused campaigns, and leads jumped 7 to 10 times. The campaigns created that demand. The operating model and the AI-first team structure behind it let a near-doubled team capture demand it would otherwise have dropped, the way it dropped everything in that zero-win month. Booked revenue is roughly 3 times the same period in 2025, on a lag, because we open doors with small engagements that convert as each SOW signs.

Two causes drove this result, and I will not pretend to separate them cleanly. If you want a single AI adoption ROI figure to hold me to: team up roughly 2 times, won deals up roughly 4 times. The work I am describing is what closed the gap between those two figures.

The Gap named

A piece about removing dependency on a few people's tribal knowledge should reckon honestly with its own version of that problem: right now, the new system depends heavily on one person — me, a textbook case of bus factor in AI transformation. I built the tools, set the standards, and I'm still the person most people come to when they get stuck. The bus factor is close to one, and that's the real key person risk in AI transformation, more than tokens or budget.

What gives me confidence is that we're reducing tribal knowledge dependency with AI, the only way that actually holds up: standards are documented rather than living in my head, the tools and their underlying logic sit in a shared repository instead of my laptop, and adoption support is deliberately shifting from me answering every question to the team reading docs and helping each other. That shift is already underway, and the structural pieces (documentation, shared ownership, repeatable processes) are designed to outlast any person by default.

It isn't solved yet. If I'm honest, this is the part I'm least far along on, but it's also the part the company is treating as a first-class priority rather than an afterthought, because everyone involved understands it's what decides whether any of this survives me.

The bet

For anyone scaling a data team with AI, here is the rule I'm running the Lab on: we nearly doubled the team this year, and it worked. Repeating that for the next jump is a different bet, and I do not think the economics will support it. That is a forecast off one year of data, not a proven law, so treat it as my working bet rather than a finding. Get more out of every person and every hour, and spend tokens, time, and influence wisely, because you will eventually run short on at least one of them.