Lesson 1: Your experts' time is the ultimate AI bottleneck

Agentic AI projects rarely stall because of the technology. They stall because the client's most knowledgeable people, the ones who understand the process, the data, and the exceptions, are also the ones the business cannot spare. Their time becomes the true bottleneck. Knowledge management studies suggest that around 42% of critical business knowledge lives only in experts' heads, which is exactly what an AI system must capture. This first lesson in our four-part series explains why expert availability must be planned and formally secured before engineering begins, and what client and vendor owe each other to protect it.

This article is part one of a four part series in which we share the most valuable elements to successful agentic AI transformation. The availability of the client's best people is a resource you must fight for.

When an agentic AI project runs behind schedule, the technology is rarely the reason. Across the implementations we have delivered at Vstorm, the constraint that shapes a project's pace is almost always the availability of a small number of people on the client's side: those who truly understand the process, the hidden dependencies in the data, and the exceptions to the rules. And these are often the same people the organization relies on most heavily in its day-to-day operations.

Their time is essential to keeping the business running, but their involvement is equally important to the success of any transformation project. As a result, operational priorities and project needs compete for the same limited resource: the time and attention of a small number of key individuals.

Before discussing the technical aspects of artificial intelligence implementation, it is worth acknowledging this challenge explicitly, as it is often one of the underlying reasons why agentic AI projects fail to meet their timelines and quality expectations.

This tension is particularly visible in several areas:

1. Quality and preparation of reference data

To use large language models (LLMs) successfully in estimation automation, the model needs relevant and representative examples to work with. These examples must be structured and validated well enough for the engineering team to identify patterns, define business rules, and evaluate the quality of the model's output.

Reference data, frequently spread across multiple data sources, is what allows the team to determine when the system is correct and when it is not. However, preparing and validating this data requires the involvement of Subject Matter Experts (SMEs), whose availability is usually limited.

2. POV (Proof of Value) testing

In the early stages of an implementation, testing is not primarily about verifying whether the code works. It is about assessing whether the model's recommendations are substantively correct.

For example, only an experienced service advisor may notice that the algorithm has selected an incorrect gasket for a particular engine variant. Without timely expert feedback, such issues remain unidentified and cannot be properly addressed.

3. Broadening context and catching exceptions

Algorithms are generally effective at applying defined rules, but SMEs understand where those rules do not apply. When the system encounters an unusual request or an exceptional case, the lack of timely expert input can block the development of entire areas of the solution or knowledge graph. Domain-related questions may remain unanswered for days or even weeks.

When an expert eventually finds time to respond between urgent operational tasks, they must also reconstruct the full context of the question. This context switching creates an additional cognitive burden and reduces their effectiveness in both operational and project-related work.

4. The tacit knowledge barrier

Even when sufficient time is secured, transferring knowledge from an expert to the project team is not straightforward. Experienced professionals often make decisions intuitively, based on years of practice and exposure to many different cases.

Simply placing an expert and an engineer in the same meeting will not automatically translate that intuition into the structured rules, examples, and decision criteria that agentic AI systems require to perform in the real world. The knowledge extraction process must therefore be carefully designed and facilitated.

A natural consequence of transformation #

This should not be interpreted as a list of shortcomings on the client's side. It is a natural consequence of how organizations function during transformation.

The project and day-to-day operations compete for the same people, and operational work will usually take priority because it has an immediate impact on customers, revenue, and the company's monthly financial performance, rather than on the long-term value the project is intended to create.

This is understandable. From a business perspective, we would often make the same decision in the same circumstances.

Observation from practice #

Agentic AI implementation projects tend to face expert availability constraints earlier and more severely than traditional software development projects, because they require an intensive transfer of unstructured domain knowledge.

When a project is underway, SMEs are usually already responsible for several other high-priority activities. As a result, unanswered questions accumulate, testing slows down, and progress can come to a standstill.

The resulting delays are sometimes attributed to the technology provider, even when the implementation team is primarily waiting for the domain knowledge, decisions, or reference material required to continue.

What to do about it? #

The answer should not simply be "greater involvement" or "more commitment." These statements are too general to be actionable.

Any organization that intends to adopt agentic AI must treat this as a resource-planning issue that both parties address before the project begins.

The key individuals on the client's side should be identified at the start of the project and their availability should be formally secured. Ideally, this should be expressed as a specific number of hours per week allocated to workshops, testing, data validation, and answering domain-related questions.

When an expert cannot participate because of operational responsibilities, the client and implementation team should establish a replacement or delegation plan. Some of the expert's daily responsibilities may need to be reassigned temporarily so that they can contribute to the project without putting ongoing operations at risk.

This needs to happen before unanswered questions begin to block the development team.

The other side of the coin: the implementation team's commitment #

However, the responsibility does not lie solely with the client. As technology vendors, we must make a hard promise: if the client's management organizes operational replacements and "buys" us a few hours of their best advisor's time per week, it is our absolute duty not to waste a single minute of it on administrative friction.

Respecting this hard-won time requires perfect ergonomics. If the domain expert has to test the model's output in unreadable Excel spreadsheets, raw JSON formats, or by jumping between disjointed systems, that valuable time will slip through our fingers. The feedback collection process must be ruthlessly streamlined (e.g., a dedicated, simple UI with Accept / Reject / Correct buttons). The SME should log in, apply 100% of their domain knowledge, and log out, without ever wasting energy fighting with the engineers' tools. This is human-in-the-loop review in its most practical form, and it works only when the human oversight step is made effortless rather than bolted on as an afterthought.

In a traditional IT project, you can usually work from a specification. In an agentic project, the specification lives in the heads of two or three people, and it is unstructured. That is why we reach expert-availability limits sooner and harder than most teams expect. Our job is to extract that knowledge deliberately, not to hope it surfaces in a meeting. Wojciech Achtelik PhD(c), AI Engineer Lead, Vstorm

For analysts and businesses: what the numbers say #

The Scale of Tacit Knowledge: Knowledge management studies (e.g., Carl Frappaolo, "Knowledge Management") indicate that in a typical organization, a staggering 42% of critical business knowledge resides solely in the heads of experts, while at most 30% is structured within IT systems. This is as true for generative AI work as it is for agentic systems, and it ruthlessly exposes why the declaration "we have all the data in the system" almost always misses the mark in projects that aim to automate complex business processes.

In summary #

Expert availability is not a soft constraint to be managed with appeals for greater commitment. It is a resource-planning decision that both parties must settle before the first workshop, ideally as a defined number of hours per week protected against operational pressure, with a delegation plan for the weeks when that protection fails.

The obligation runs in both directions. When a client's management reorganises operations to buy back a few hours of its best advisor's time, we consider it our duty not to waste a minute of it on administrative friction. Hard-won expert time deserves ruthless ergonomics: a simple interface to accept, reject, or correct model output, rather than raw spreadsheets and disjointed systems that drain the very attention we asked the client to protect.

Get this right and the rest of the transformation has room to succeed. Get it wrong and no amount of engineering will compensate. In the next lesson, we turn to the difference between programming and AI, why data without context is worthless, and how it compounds when expert time is already scarce.