AI adoption at work is spreading remarkably quickly, but that does not mean companies have figured out how to use it well.
New data from the Federal Reserve Bank of St. Louis captures the distinction nicely. By May 2026, 45% of U.S. workers reported using generative AI at work. AI use appears in more than 80% of occupations and across more than 40% of job tasks. Yet adoption remains surprisingly shallow: fewer than 3% of tasks have AI adoption above 50%.
That should not surprise us. The difficult part of adopting AI is no longer discovering that ChatGPT exists or giving employees access to a model. The difficult part is figuring out what a productive AI-native workflow actually looks like.
We are trying to solve that problem while the underlying technology changes every few months. A workflow that looked sophisticated six months ago may already be obsolete. A new model can suddenly handle more context. Tool calling improves. Coding agents become capable of working autonomously for hours. An approach that required elaborate orchestration may collapse into a single agent loop.
Companies are therefore redesigning work on top of a platform whose capabilities are still moving underneath them.
The St. Louis Fed researchers themselves point toward learning and experimentation as part of the explanation. Workers who have used generative AI for longer tend to apply it to more parts of their work, even after comparing people performing similar tasks. The authors describe the evidence as consistent with costly learning or experimentation.
I think the problem is broader than simply learning how to use AI. Companies need to discover which parts of a workflow should be delegated, how much autonomy the system should have, which context it needs, and how they will know whether the resulting workflow is actually better.
Finding the right boundary is hard
Consider a software engineering workflow. The easiest adoption step is obvious: give developers an AI coding assistant. The harder part is deciding the boundary of the agent's responsibility. An agent might work at the level of a function, a ticket, or a complete pull request. It might review code, flag architectural conflicts, or challenge assumptions in the requirement. Each additional layer changes the amount of context, authority, and human oversight the system needs.
There is no universal answer because the productive unit of automation is rarely identical to the existing human task boundary. Sometimes the right scope is smaller. Sometimes it is dramatically larger.
This is why adding AI to an existing workflow often produces disappointing results. You have automated a step without reconsidering the system around it.
The same pattern appears outside software engineering. An AI sales assistant that drafts emails is useful. A system that understands CRM history, customer context, prior conversations, pricing constraints, product documentation, and the current sales strategy can transform the workflow. But that system is also much harder to build.
The model is often the easy part.
Why "let the AI improve itself" is not enough
One tempting response is to make the system recursive. Ask the AI to inspect its own work, let another model critique it, have one agent improve another agent's prompt, generate synthetic examples, or use an LLM to judge whether an answer was good and feed that judgment back into the next iteration.
These techniques can be useful, but they also contain an obvious failure mode: AI improving AI can reinforce the same mistakes.
If the system has the wrong assumptions about what success looks like, another model operating inside the same context can simply optimize those assumptions more effectively. You end up with a beautifully optimized wrong answer.
The problem is that the system is evaluating itself using information generated largely by the same system. What makes a feedback loop valuable is not recursion. It is contact with reality.
The missing ingredient is ground truth
The most productive AI systems have something around them that produces signals about whether the work was actually successful.
Software engineering happens to be unusually rich in these signals. Code can fail to compile, tests can break, deployments can produce errors, latency can increase, security scanners can detect vulnerabilities, reviewers can reject implementations, and users can report that the feature does not work.
These signals matter because they exist outside the model's own judgment.
This is why systems such as DeepMind's AlphaEvolve can genuinely improve their outputs. The language model generates candidate programs, but an external evaluator runs and scores them. The model provides creativity; the environment provides selection pressure.
The same principle applies to agents. Once an agent operates across many steps, inspecting the final answer is insufficient. You need enough of the trajectory to understand which tools were used, where incorrect assumptions entered, which errors occurred, what humans corrected, and what happened downstream.
Build the feedback loop around the agent
A productive improvement loop starts by letting the agent perform real work under realistic conditions and capturing enough detail to reconstruct what happened. That includes the final result, relevant tool calls, intermediate state, retries, errors, human interventions, latency, cost, and downstream consequences.
The next step is to connect those traces to external signals. A successful code change might be reflected in passing tests and a clean deployment. A support workflow might be judged by reopen rates or human overrides. A sales workflow might be measured through response rates, conversions, or the quality of follow-up actions. The exact signal varies by domain, but the principle is the same: the system needs evidence from outside its own reasoning process.
Those signals turn production behavior into evidence.
Failures should then become evaluation cases rather than disappearing after someone fixes them. Over time, the organization accumulates a dataset representing the edge cases its AI systems encounter in the real world. The evaluation set becomes increasingly specific to the company's workflows, customers, architecture, and definition of good work.
At that point, AI can become useful for improving the system itself. An agent can cluster failures, identify recurring patterns, suggest changes to prompts, tools, context, routing logic, or workflow boundaries, and propose new skills or safeguards.
Those proposals should still be treated as hypotheses, not proof of improvement. The changed system needs to be replayed against the accumulated evidence and compared against the previous version. The goal is to determine whether the original failure disappears, whether new regressions appear, and whether performance improves reliably across repeated trials.
The model proposes changes; the feedback system decides whether those changes survive.
The real asset is the feedback system
This changes how I think about the strategic value of AI infrastructure inside a company.
The obvious assets are models, prompts, and proprietary documents, but all of those are becoming increasingly reproducible. The harder-to-copy asset is the continuously growing record of how your AI systems interact with your actual business and what reality tells you about their performance.
A generic model lacks the history of your organization's recurring edge cases, expert rejections, delayed failures, customer-specific patterns, and operational exceptions. Those details are usually invisible in generic training data, yet they often determine whether an AI workflow is genuinely useful.
Your feedback system learns those things.
Over time, traces, evaluations, metrics, incident data, and expert corrections become a form of organizational memory. They capture the company's accumulated lessons about how its automated workflows behave in practice and where those workflows still fail.
That data can improve prompts and agents today. It may eventually support fine-tuning or other forms of model adaptation. More importantly, it tells you what the next version of the workflow should look like.
AI adoption is an experimental discipline
This is why broad but shallow workplace AI adoption should not be surprising.
We are still discovering the operating principles. Models are changing, agent architectures are changing, tool interfaces are changing, and organizations are still learning where autonomy helps and where it creates new failure modes.
The companies that make the most progress will probably be those that build strong learning loops around their AI systems. Choosing a capable model and writing a good prompt still matters, but neither provides a durable advantage if the organization cannot observe failures, measure outcomes, and turn those observations into better workflows.
That requires giving agents context and tools, but also exposing them to the consequences of their actions. Preserve failures instead of hiding them. Capture the traces. Record the human corrections. Measure downstream outcomes. Turn incidents into evaluation cases and feed those findings back into the next iteration.
Don't just ask the AI to improve itself. Engineer the environment that can tell it why it was wrong.