AI Agent Interactions as a Data Source

Almost every discussion about AI agents revolves around a single question: what data does the agent need to give good answers? Knowledge base, product data, service history, technical documentation. Data as fuel. That view is correct — but it describes only one half of the picture.

Because the interaction with the agent generates data in its own right. The agent doesn’t just deliver answers; it also observes who is speaking with it, with which questions, in which context, and with what outcome. That observation is a data source — and in implementation projects it goes almost entirely unused.

This holds true for any counterpart. The customer remains a valid source, of course. What gets overlooked is that the same mechanism applies to a company’s own employees — and that is precisely where one of the largest untapped levers for agent adoption lies. And adoption, as we know, is what most agent projects actually fail on — not the technology.

The standard case: data flows in only one direction

In typical service scenarios, the agent is oriented toward the customer. It draws its knowledge from the configured sources, answers the request, and escalates to a human where needed. Whatever could be learned from the interaction itself flows back nowhere. This becomes most apparent with the employee who operates the agent or works alongside it: in this model they are a neutral pass-through — interchangeable, without context.

That is exactly the blind spot. The agent treats a newcomer in their third week exactly like a service technician with fifteen years of experience. Both receive the same answer, the same depth, the same tone. For one it is too terse, for the other superfluous. In both cases friction arises — and friction is the beginning of rejection.

Lever one: real-time adaptation

The first lever is immediately actionable and uncritical from a data-protection standpoint, because it requires no profile — only the context of the running session.

Within a single interaction, an agent can recognise how an employee engages with it: which terms do they use? How precisely is the request phrased? Do they ask follow-up questions or act directly? From this, the appropriate answer depth can be derived. To one, the agent delivers the concise solution; to the other, the step-by-step explanation with background. On a complex escalation, it can proactively suggest bringing in a more experienced colleague — rather than letting the employee struggle alone with a problem beyond their current level.

This sounds unremarkable, but it fundamentally changes the perceived quality of the agent. It turns from a rigid answer machine into a tool that thinks along.

Lever two: learning over time

The second lever is the truly significant one — and the more demanding. If an agent observes not only the single session but patterns across many interactions, a picture of the team’s capabilities and strengths emerges.

From this, things become possible that today happen only laboriously, or not at all. Escalations can be routed by demonstrated competence rather than mere availability: the specific machine problem goes not to the next available colleague, but to the one who has provably solved it three times before. Recurring weak points become visible — if a team systematically stalls on a particular configuration topic, that is a signal for training needs. The agent thereby produces a side effect for which organisations otherwise run elaborate analyses: it makes competence gaps visible as a data point.

The same pattern applies in sales. An agent in quote processing that notices an employee repeatedly catching on the same step in complex CPQ configurations can guide more precisely at exactly that point — instead of assisting generically.

Why this loop is missing in projects

The reason is structural. Implementation projects model the customer loop: request in, answer out. The employee loop — what the agent could learn about the team — simply doesn’t appear in the scoping. No one writes it into the requirements, because no one thinks of it as a data source. Business context about a company’s own workforce is a blind spot in agent design.

This is not a technical hurdle. It is a question of process design. And that is precisely why the lever is overlooked — it sits between responsibilities.

What this means for industrial companies

Anyone introducing an agent should treat the employee learning loop as a deliberate design decision — not as a side effect that happens to arise, or doesn’t. Real-time adaptation is feasible today and should be considered from the outset, because it raises adoption immediately.

Cumulative learning across employee profiles is the larger lever, but in the DACH region it carries an additional dimension: the moment a system records the capabilities, tenure, or performance patterns of individual employees, it touches on co-determination and purpose limitation. This does not rule the approach out — but it makes it a decision that must be taken transparently and together with those affected, not a silent by-product. That transparency, incidentally, is the very precondition for employees to experience the loop as support rather than surveillance.

The common core lies in a simple shift of perspective: it is not only the knowledge that flows into the agent that holds value — but also what could be learned, from every interaction, about the counterpart. An agent that knows the person it works with is experienced as active, purposeful support, not as paternalism. And that, in the end, is the difference between an agent a team tolerates and one it wants to use.