The phrase "AI-first" has lost most of its meaning. A company that lets its sales team use ChatGPT is not AI-first. A company that prompts its support agents into a Copilot tab is not AI-first. AI-first is a claim about how the work itself is shaped — what gets written down, what gets delegated, and how problems get solved when the team is stuck.
For a small consulting team, three operational changes follow if you take it literally.
Change 01Capture everything
In a non-AI-first team, what gets captured is whatever someone judged worth writing down. Most of the work — the calls, the corridor conversations, the half-formed thinking on the drive home — vanishes as soon as it happens. The team relies on memory, proximity, and the assumption that the important parts will stick.
The discipline in an AI-first team is the opposite. The default is to capture, and the default is automatic. Every meeting that matters gets transcribed by the conferencing tool. Every working call with a client gets recorded with consent and dropped into a transcript. Every solo working session that involves thinking out loud — on a walk, in the car, between flights — gets a voice note. The transcripts land in a place the team and the model can reach. Modern transcription is good enough that the team almost never re-reads the raw output; it's there for the model.
Writing things down becomes the fallback, not the default. It's what you do when transcription wasn't possible (the conversation happened in a corridor, the meeting wasn't recorded), or when the artefact needs to be more structured than a transcript — a project brief, a decision log, a one-pager for the client. Those higher-order documents still matter, but they now sit on top of a much richer base of raw capture than they used to.
This works because modern models reason over raw transcripts and disjointed notes substantially better than humans do. They will happily synthesise structure from chaos when asked. The team doesn't need to polish the input; it just needs to make sure the input exists. The cost of capture has collapsed from "carve out an hour to write a brief" to "press record and forget about it".
What this changes in practice is the threshold for capturing anything at all. In a non-AI-first team, a thought is captured only if it's worth the effort of formalising; most thoughts fall below that bar. In an AI-first team, the bar drops to "is this even slightly worth the model seeing later", and the answer is almost always yes — because the cost of capturing is now negligible. The team accumulates a much richer trace of its own thinking, and the model becomes correspondingly more useful when it's asked to recall, summarise, or extend that thinking weeks later.
The unexpected side effect: the team that does this is a much better consultancy even before the model gets involved. The act of going back to read what a transcript actually says — versus what people remember — clarifies thinking and surfaces things that would otherwise be lost. The capture creates the trace; the trace creates the leverage.
Change 02Every recurring task becomes a candidate for delegation, but only with an eval
A common pattern: a senior person on the team does a recurring task. Maybe it's writing weekly status updates. Maybe it's reviewing a junior person's draft proposal. Maybe it's grading the outputs of an upstream pipeline. The task takes thirty minutes a week, the person is good at it, and it has stayed manual for years because automating it didn't seem worth the engineering investment.
In an AI-first team, the question becomes: can a model do this task at the bar we hold ourselves to? The answer is almost always yes, with conditions, and the conditions are testable.
The discipline is that the answer is never prompt it and hope. The discipline is:
- Write down the criteria the task is graded against.
- Collect twenty examples of inputs and the outputs that pass the bar.
- Build a small prompt or pipeline against the examples.
- Run the pipeline on the examples and score it. Adjust until the score is acceptable.
- Move the task to the pipeline, and run the eval every week so you notice if the model drifts.
This is not a five-minute exercise. The first time a team does it, the eval takes longer to write than the prompt. That's the point. The eval is what makes the delegation safe. Without an eval, you've just hidden the recurring task behind an unaudited model call, which is worse than not delegating it at all.
The teams that do this routinely have ten or fifteen of their internal recurring tasks delegated to models, each with a small eval, each running on a schedule. The team spends less time on the recurring tasks, and more importantly, the recurring tasks happen on a predictable rhythm — they aren't dependent on the senior person being in the right mood.
Change 03Pairing on hard problems with a model in the room
This is the operational change that looks the strangest from the outside. When a senior person on the team gets stuck on a hard problem — a design choice, a tricky piece of writing, a strategic call — the model gets pulled into the working session as a participant.
Not as an oracle. The senior person isn't asking the model "what should I do?". The pairing is more like the way two senior people pair: one of them is the lead, the other tests assumptions, offers counter-examples, plays back what they've heard, and occasionally proposes something the lead would not have arrived at alone.
The reason this works for small teams in particular: small teams don't have the bench depth of large firms. There is often nobody else on the team with the right combination of context and expertise to genuinely challenge the senior person's thinking on a specific problem. The model is a tireless, well-read, narrowly-aligned junior partner who can hold the context the senior person is loading into the conversation and push back on it.
The pairing is verbal as often as it is written. It happens in the middle of a call to a client, on the way to a workshop, while waiting for a flight. The shift is that the senior person no longer thinks of "consulting the model" as a separate activity. The model is in the room.
What AI-first does not change
It does not change the requirement for senior judgement. If anything, it intensifies it. The model is competent at producing output. It is not competent at deciding which output the client actually needs. Most of the value the team produces comes from the moments where the senior person makes a call the model could not have made — refusing to recommend something the model would have happily produced, picking up a non-obvious cue from the client, knowing which of three plausible-sounding recommendations is the one that will land.
Models accelerate good engineers and senior advisors. They also expose the gaps in a team that didn't have the underlying judgement to begin with. AI-first is a multiplier; it isn't a substitute.
The thing nobody talks about
The change that takes the longest to internalise is not technical. It is the change in how the team feels about speed. In a non-AI-first team, fast feels reckless. Producing a polished output in a day is suspicious. Skipping the third revision is unprofessional.
In an AI-first team, fast is the baseline. The first draft of anything is forty minutes old. The third revision happens in the same afternoon. The team that internalises this stops apologising for moving quickly, and starts using the saved time to do the work that actually requires the senior person — the conversations with the client, the judgement calls, the framing decisions that don't compress.
That last shift is the one that separates AI-first as a slogan from AI-first as an operational pattern. The slogan promises speed. The pattern produces more thinking, faster, with the senior judgement still firmly in place.
We help teams make this shift in practice, not in a slide deck. Start a conversation →