The Model Got Better. The Bigger Gain Was Learning to Use It.

The first Statement of Work (SOW) I wrote by hand took two to three days, most of it spent going back and forth, rewriting scope language, and finding gaps later than I should have. My most recent one took two to three hours.

What changed most was how I work with AI.

I’ve been in presales for 10 years, and for the last year nearly all of my work has been in generative AI. I’m still learning. But one thing has become clear to me, and it rarely makes it into an AI business case: what you get back from AI depends heavily on how well your people know how to use it.

How I got here

A year ago, I used AI like a faster search box. I’d ask a question, skim the answer, and move on.

Practice changed that first. I started putting real work through AI every day, and it didn’t always go well. One time it added private pricing agreements and margin figures to a client-facing document. I caught it on my final read before it went out. That was when I stopped treating AI output as finished work.

Now it transcribes my meetings and pokes holes in my solution designs before clients see them. Agents handle most of the paperwork that used to eat my week.

This summer I added structured study with the Harvard Data Science Initiative’s three-month AI Leadership Intensive. On the first day, Professor Suraj Srinivasan defined fluency as “enough hands-on familiarity … to ask the right questions and exercise independent judgment.” The program gave me language for much of what I’d been doing by feel, from deciding which workflows are worth redesigning to governing agents once they’re running. What it couldn’t give me was the hands-on part of that definition. Nothing in the program covered checking an AI meeting summary before acting on it, and none of it was about prompting. That knowledge came from getting things wrong on real work. The closest the program came was its one-on-one AI tutorials, which pushed back on every answer I gave and went straight for the weakest point in my reasoning. That’s close to how I pressure-test my own designs now.

The four lessons below line up closely with the 4D AI Fluency Framework, developed by professors Rick Dakan and Joseph Feller with Anthropic, which splits fluency into Delegation, Description, Discernment, and Diligence. I’ve noted where each one fits.

The SOW that filled its own gaps

My first AI-drafted SOW invented client responsibilities we had never discussed, and it made assumptions about what was out of scope that didn’t make sense. The draft still read like a real contract. I had handed it too much of the job, and it filled every gap with something plausible. The framework calls this skill Delegation: deciding which parts of a job AI takes and which parts you keep.

Now the work runs in stages. One agent drafts the scope sections from a discovery-call transcript and a solution summary. A second reviews that draft the way a deal desk would, checking it against rules for risky language, missing assumptions, and staffing that doesn’t match the scope. A third turns reviewer comments into tracked-change redlines.

What stays with me is judgment. The review agent can tell me a term is used two different ways in the same document. It can’t tell me how this particular client is going to read it.

A year of context

Most AI training focuses on prompting, which the framework groups under Description. For me, prompts mattered less than context.

My SOW time dropped mostly because of what the agents had to work from. That context took a year to build: client notes, discovery transcripts, past proposals, and feedback from every review that sent a draft back to me. A lot of fluency, it turns out, is knowing what to give the model before you ask it for anything.

Summaries that read cleanly and were wrong

The mistakes that cost money are usually the confident ones. The AI gets something wrong, says it smoothly, and the person reading can’t tell. Catching them is what the framework calls Discernment.

I learned this from AI meeting summaries, which I rely on constantly. I’ve seen them assign an action item to someone who wasn’t on the call, put a date on a decision nobody had dated, and drop the one dollar figure that mattered. Every one of those read cleanly. Nothing in the formatting suggested I should double-check.

These days I use a summary to find my place in the transcript. If I’m going to act on something or send it to a client, I check it against what was actually said.

After you’ve seen it a few times, you start spotting it quickly. Someone newer to these tools forwards the summary as is. Across a whole company, that turns into something I see in a lot of stalled AI programs: usage looks healthy, results don’t move, and people slowly stop trusting the output without being able to say why.

My name is still on it

I use AI to pressure-test solutions all the time. I ask it to argue against my design and to find assumptions I never wrote down. The design I bring to the client is still my responsibility, and so is every SOW, even when one agent drafted it and another reviewed it. I treat the AI review as an extra reviewer. The sign-off is mine, which is what the framework means by Diligence.

Leadership won’t scale AI it doesn’t trust, and good governance is what lets an organization move faster with it. Presidio put this into practice internally with a tiered access model: employees get more capabilities as their fluency grows, so the people who have shown they can judge the output are the ones trusted to do more with it.

If you own an AI budget

Most AI spend today goes to individual productivity. That’s worth having, but it rarely sets a company apart. The larger return comes later, when fluent people start spotting which workflows should be rebuilt around AI and which steps can safely go to an agent. A company can only redesign work as far as its people understand the tools.

A few practical suggestions:

1. Look past license counts. Access tells you very little. Ask people what they handed to AI this week and what they caught it getting wrong.

2. Train on real work. Feature tours go out of date with each release. People learn more from building something on their own workflow than from a classroom session.

3. Make time for practice. If people are expected to pick up AI in their spare minutes, most won’t.

4. Give someone ownership of quality. Each team benefits from a person who knows where the model is reliable and where it bluffs, and who can teach the rest.

5. Start with the department you’re transforming. Invest in that group’s fluency before a company-wide rollout. They’ll end up teaching the next wave.

Closing thought

Models will keep improving whether your people do or not. My SOWs got faster partly because the models got better, but mostly because I spent a year learning what to hand off, what to give the model, what to check, and what I still own. I often got it wrong first. None of that took special talent. It took repetition, and anyone on your team can get it. I expect the companies that get the most out of AI over the next few years will be the ones that invest in their people’s fluency instead of assuming it will show up on its own.