AI adoption in the team: how to organize the operation to use AI for real.

ask any technology leader today whether the team uses AI and the answer is always yes. Everyone uses it: opens ChatGPT, pastes a question, copies the answer. And even so, when I look at the KPIs that should have moved (cycle time, cost per task, team throughput), almost nothing changed. I came to see that usage, on its own, tells me nothing about what the business actually gained.

This is the mismatch that defines the moment. Using AI became universal. Capturing value with AI is still rare. The tools are in everyone hands, so they do not explain the difference. What explains it is the method: who uses it for what, with what structure, inside what routine, with what control. Without that, AI on the team is a crowd of people chatting with a chatbot alongside the real work. Individual noise, zero operational gain.

This piece is about closing that mismatch.

§ 01 / DiagnosisWhy “using ChatGPT” doesn’t create value.

Three reasons, and none of them is in the tool.

• First: one-off use never becomes a process. Someone finds a good way to use AI to draft an email. Great, but only for them and only that day. It does not scale to the team, does not become a step in any flow, is not measured. It is invisible personal gain that dies when the person goes on vacation.
• Second: the average prompt is bad. Most people treat the model like search: a short question, no context, no expected format. The model answers at the level of the question. Generic question, generic answer. The person concludes that “AI is not that good after all” and goes back to doing it by hand.
• Third: no guardrails, so no confidence. With no rule about what may and may not go into the model, the team splits between those who throw sensitive data in without thinking and those who use it for nothing out of fear of getting it wrong. Both extremes kill adoption.

None of these problems is solved by switching models. All of them are solved with organization.

§ 02 / Operating modelThe operating model for adoption.

Adoption that produces results has four questions answered in writing, not left to chance:

• Who uses it. Not everyone, for everything, at the same time. Start with the roles where the work is most repetitive and text-based, such as support, writing, analysis, and triage. A small group that uses it well teaches the rest better than a training session for everyone.
• For what. Named use cases, not “use AI wherever”. “Summarize a support ticket before routing it.” “Draft the first version of the sales reply.” “Extract contract data into the spreadsheet.” A named use case is a use case you can measure.
• With which guardrails. The rule for what does not go into the model (customer data, financial information, credentials) has to be written, short, and known by everyone. Which tool is approved, which is not. A guardrail is what unlocks adoption, because it removes the fear of getting it wrong.
• Where it enters the routine. The gain shows up when AI becomes a step in a flow that already exists, not a detour to a separate tab. “Every ticket goes through an automatic summary before the queue” creates value. “Use ChatGPT if you want” creates nothing.

§ 03 / MethodWhat a well-built prompt is.

Most of the short-term gain is here, and this is the cheapest part to teach. A few principles carry almost all the weight.

• Structure: role + context + task + format. Tell the model who it is, give the context only you have, define the task precisely, and specify the output format. That structure alone improves quality more than any model swap.
• Decomposition. A complex task is broken into a sequence of steps, each verifiable, instead of becoming one giant prompt. The model, like any executor, errs less on small, clear steps than on a huge, ambiguous request.
• Few-shot. Showing two or three examples of what you want is worth more than any description. The model learns the pattern from the example faster than from the explanation.
• Chain-of-thought. For reasoning tasks, asking the model to think step by step before concluding reduces errors. It “shows its work” and gets it right more often.
• Tool use and RAG. The model on its own does not know your business or reach your systems. Tool use lets it query an API, a calculator, a database. RAG, which means bringing snippets of your own base into the prompt, is what turns a generic model into something that answers about your operation. Without RAG, it answers about the world; with RAG, it answers about your company. For serious corporate adoption, RAG is almost always the turning point.

Three examples, side by side.

Example 1: a support reply. Poorly built:

“Reply to this customer who is complaining about the delay.”

Well built:

“You are a support analyst at our company. Context: the customer bought plan X, had a 3-day delivery delay due to a logistics failure on our side, and has been a customer for 2 years. Task: write a reply that acknowledges the failure without promising a refund (not authorized), offers daily follow-up until delivery, and keeps a respectful, direct tone. Format: an email of up to 120 words, in Portuguese, no generic greeting.”

The first returns plausible, useless text that the person will rewrite entirely. The second returns something that only needs review, because it carries a role, context only the company has, a business constraint (do not promise a refund), and a format. The effort difference to write the two is 30 seconds. The difference in the result is the whole project.

Example 2: data extraction. Poorly built:

“Pull the data from this contract.”

Well built:

“Extract from the contract below only these fields, in this order, as JSON: razao_social, cnpj, valor_total, data_inicio, data_fim, indice_reajuste. If a field is not in the text, return null, do not make it up. Do not add fields beyond the listed ones. Contract: [text]”

The first returns a prose summary nobody can drop into a spreadsheet. The second returns structured data, ready to integrate, and, most importantly, instructs the model to return null instead of inventing. In a production extraction, “do not make it up” decides whether the data comes out reliable or still needs manual checking, which wipes out the gain.

Example 3: analysis. Poorly built:

“What do you think of these sales numbers?”

Well built:

“You are a sales analyst. Below are the monthly sales for the last 12 months by region. Task, in three steps: (1) identify the region with the largest relative drop in the last quarter; (2) list three possible hypotheses for that drop, marking which can be confirmed with this data alone and which need external information; (3) recommend which to investigate first and why. Do not assert a cause without pointing to the evidence. Data: [table]”

The first invites the model to opine freely, and it opines nicely and emptily. The second decomposes the task, forces a separation between what the data supports and what is a hypothesis, and asks for explicit reasoning. One asks for an impression; the other asks for analysis.

The pattern across all three is the same: context only you have, a precise task, a defined format, and a constraint that stops the model from failing the expensive way. This can be taught in one afternoon. The return shows up the next day.

§ 04 / ToolsThe everyday tools.

Claude, ChatGPT, and Gemini are the working tools of most teams today, and there are real behavior differences between them in writing, code, and reasoning. But choosing which to use before organizing how to use it is solving the wrong problem. The most capable tool used badly loses to the average tool used well, every day. Approve one or two, define where each serves best, and put the energy into the method. Switching tools is a half-hour decision; the method is what produces the gain.

§ 05 / MeasurementHow to know it’s working.

Adoption without measurement is faith. Measure little, but measure for real:

• Measure what the operation delivers. “How many people opened ChatGPT” says nothing. “Average time to answer a ticket dropped from 12 to 7 minutes” says everything. Tie each use case to a KPI that already mattered before AI.
• Baseline before you start. Without the before number, you have no way to prove the gain, and what is not proven gets no budget to scale.
• Quality alongside speed. A speed gain that drops quality is a loss in disguise. Measure both side by side.
• Adoption that survives the pilot. Is the step really in the flow, or did the team go back to doing it by hand once the pilot ended? Only the process reveals that.

§ 06 / RolloutStep by step for rollout.

1. Pick one use case, just one. The most repetitive and text-based you have. Resist the urge to do ten.
2. Measure the baseline. How much time, how much cost, what quality, today, without AI.
3. Write the guardrails. What does not go into the model, which tool is approved. One page, at most.
4. Build the prompts with the team that does the work. Role + context + task + format, with real examples from the operation. If the case needs its own context, this is where RAG comes in.
5. Put AI in as a step in the flow, integrated into what already runs, without becoming a parallel tab.
6. Run it for a few weeks and compare against the baseline. Speed and quality, both.
7. If it moved the KPI, scale to the next case. If it did not move, understand why before expanding, because expanding a case that does not work only multiplies what does not work.

The team already has the AI it needs. What is missing is a method to use the one it already has. The technology is ready and accessible like never before; what separates those who capture value from those who just “use ChatGPT” is the discipline of organizing the operation around it. It always was.

end  ·  field note #47  ·  noûs / aug 26