Introducing an AI agent in your company: choosing the first process correctly

Management has decided to try out an AI agent. Then the real conflict begins. Sales wants quotes prepared, customer service wants the inbox sorted, accounting wants invoices checked, project management wants minutes written. All the requests are understandable, and each department considers its own the most urgent.

In this scenario there is budget and attention for exactly one trial. That makes the choice delicate, because the first process shapes the image of the whole undertaking. If it goes well, the willingness to tackle further processes grows. If it goes badly, people in the company quickly say AI is useless, although perhaps only the wrong process was chosen.

On top of that there is a misunderstanding about the term. An AI agent is more than a chat window: it pursues a goal, calls tools to do so, reads and writes in systems and makes interim decisions. The more freedom of action it has, the more important the question of where it may work first. Choosing the process is therefore not preparation but already the first security decision.

A pattern stands out: the process that hurts most is rarely the best way in. It hurts because it is complex, knows many exceptions and relies on experience that was never written down. These are exactly the properties on which an agent fails at the first attempt. Anyone who starts there mainly learns how much preparation is missing.

The second failure pattern is the prestige process. The choice falls on the workflow that is most visible in the company, such as customer communication in an ongoing complaint. There, a single wrong sentence is enough to annoy a customer. The damage is public, and those involved become more cautious instead of bolder.

Third, there is the process without data. Today it is handled verbally or by calling out, with no templates, no filing, no history. An agent needs material to orient itself by, and standards against which its work can be checked. If both are missing, the pilot becomes a documentation project, a useful one, but a different one than planned.

Finally, the opposite direction: some businesses choose a process that occurs so rarely that after eight weeks there are hardly any cases. The risk is small, but so is the learning effect. Without enough runs, in the end nobody knows whether the agent works reliably or was simply never seriously challenged.

Five criteria can be derived from these failure patterns. First, frequency: the process should occur regularly so that effort and learning curve pay off and the pilot collects enough cases quickly. Second, regularity: it need not be rigid, but an experienced employee should be able to describe in a few sentences how they proceed and when they make an exception.

Third, limited damage from errors. This is the most important criterion, because errors can never be ruled out. What matters is what an error costs and whether it can be corrected before it takes effect. A draft that a person reviews is forgivable. A payment demand sent automatically is not.

Fourth, the data situation: are there examples of good results, clean inputs and accessible connections to the systems needed? Fifth, measurability: how will you know after four weeks whether the agent helps? Processing time, correction rate and follow-up questions can be counted. A feeling that things are going better is not enough as proof.

Technical fascination is deliberately not included as a criterion. Whether a process sounds especially modern is irrelevant. What counts is whether it passes the five questions. An unremarkable workflow that recurs daily and is easy to check makes a better pilot than a spectacular one that only convinces in the presentation.

The criteria become a matrix. Each candidate gets a rating from one to five per criterion, justified in one sentence. The justification matters more than the number, because it forces a conversation. If two people rate the same data situation differently, one of them has seen something the other missed.

The criteria should not be weighted equally. We would count limited damage most heavily and also treat it as an exclusion criterion: if a process fails there, it is out, no matter how good the other scores are. A high total score must not hide a high risk. The weights are not laws of nature but an agreement that you adapt to your industry.

An alternative is to drop points in favor of a simple scheme with two axes: benefit on one side, risk and effort on the other. This is faster and often sufficient for small teams. The matrix pays off as soon as more than three candidates compete or several departments are involved in the decision, because it makes arguments comparable and keeps the selection explainable later.

An example of the scoring: a business is considering quote drafts and invoice approvals. Both occur regularly and are rule-based. With the quote, the damage before approval is internal and the template situation is good; with invoice approval, an error hits money directly. Even with otherwise equal scores, the first candidate stays ahead because the exclusion criterion takes the second out of the running.

Finally, a plausibility test: if the matrix's winner contradicts your gut feeling, don't look at the matrix first. Ask which assumption your feeling rests on. Sometimes a criterion really is missing, such as the team's willingness to cooperate. Then it belongs in the matrix, not beside it.

Concrete examples make the criteria tangible. Preparing quotes as a draft is often well suited: the agent reads the inquiry, looks for similar earlier quotes, assembles line items and has a person review and approve. The process occurs regularly, follows recognizable patterns, the damage stays internal before approval, and templates are usually available.

Sorting the inbox in advance is also suitable. The agent assigns messages to categories, suggests a priority and drafts replies to standard questions, but sends nothing itself. Research in internal documents belongs here too: where is the rule for a particular case, what documents exist for a customer? Here employees check the source the agent names.

Borderline are processes with external effect but clear rules, such as appointment confirmations or status messages to customers. They can follow later, once the agent has shown reliability and approval rules apply. Unsuitable at the start are workflows with financial or legal consequences and no review body: payment approvals, contract changes, terminations, decisions about people or medical information.

The classification is not a permanent ruling. It describes the starting point. A process that is unsuitable today can well become suitable after a learning phase with approval steps, logging and limited rights. What matters is the sequence, not the ban.

A pilot is not a small production operation but an experiment with a question, a deadline and a result rule. The question is not whether AI works, but whether this agent supports this process reliably enough under these conditions. Four to eight weeks is a common guideline for the deadline, depending on how quickly enough cases come together.

You set the success criteria before the start and write them down. They include a quality measure, such as the share of drafts accepted without content corrections, the time per case compared with the previous handling, and the number of cases in which the agent correctly asked for help. You agree concrete thresholds based on your own starting position, which you briefly measure beforehand.

The abort criteria are at least as important. They are the difference between a pilot and a stopgap that nobody switches off any more. Typical triggers are an error with external effect, repeated disregard of a rule, a data protection incident or permanently more correction effort than time saved. If you agree them in advance, you don't have to negotiate in an emergency, only establish the facts.

In the pilot the agent works with minimal rights. It reads where it must read and writes only to a draft area. Every action is logged so that it can later be traced what it did and why. Permissions and approvals are a topic of their own, which we explore in other studies in this series.

The most common special case is a mixed result. The agent works well in most cases but fails with an identifiable group, such as inquiries with attachments or special terms. That is not a failure but a finding. Usually the group can be recognized by a simple rule and kept away from the agent, so that it limits itself to what it masters.

More difficult is beginner's luck. If the pilot runs smoothly in the first weeks because only simple cases turned up, that tempts people into expanding too soon. A deliberate stress test helps as a precaution: collect the most difficult cases of recent months and have the agent rework them, without anything being delivered. The failure patterns that become visible there might have shown up in day-to-day business only late.

A third case: the measurement itself is distorted. If employees wave through the agent's drafts out of habit, the correction rate looks excellent. The same applies if they rewrite every draft completely out of distrust. Spot checks by a second person and occasionally inserted control cases with a known solution show whether the review is taken seriously.

Another stumbling block is system boundaries. The agent is supposed to read data from industry software that offers no clean interface, or write into a mailbox that several people use. This leads to workarounds that work in the pilot and are brittle in regular operation. Check early whether access is possible on a permanent, controlled and revocable basis, and if necessary plan a smaller scope that works only with cleanly accessible data.

Finally, data protection. If the process handles personal data, data processing, storage locations, retention and access by those involved need to be clarified before the start. This is not legal advice but a reminder that clarification should not wait until after the pilot, and that a data protection officer or a lawyer should be involved if there is uncertainty.

The realistic aim is to measurably relieve a clearly defined workflow while gaining experience for further steps. For processes that meet the five criteria, it is plausible that employees spend less time on preparing, searching and compiling. How large this effect turns out depends on the process, the data situation and the care taken in introduction, and cannot be credibly quantified in advance.

Measurement falls into three groups. The first is efficiency: time per case, lead time, share of cases that go through without follow-up questions. The second is quality: share of drafts with content corrections, type of errors, complaints. The third is acceptance: do employees use the agent voluntarily, and do they perceive it as relief? The third group is easily forgotten and decides on long-term operation.

Part of the benefit is shown by no counter: the pilot makes visible how the process actually runs. It often turns out that workflows were less clear than assumed or that templates are outdated. This insight has value even if the agent is not deployed in the end. It should be recorded in the evaluation instead of disappearing into conversation.

There are no guarantees. A pilot can show that an approach holds up, or show that it does not. Both results are useful as long as they are recorded honestly. The worst outcome is a pilot that is never ended and whose result everyone interprets as they please. So record the decision in writing, with the date, the reasoning and the figures it rests on, so that it can still be understood a year from now.

The role of employees is often reduced to nodding things through: the agent delivers, a person confirms. This picture underestimates where the knowledge lies. The person who has handled the process for years knows the exceptions, the pitfalls and the unwritten rules. Without them no agent can be instructed sensibly, and nobody can judge whether its results are usable.

That is why at least one experienced person from the department belongs in the pilot from the start. They describe the target workflow, provide examples of good and bad results and assess the drafts. It makes sense to give them real decision-making power, such as the right to pause a pilot. Those who may only watch develop skepticism, and those who help decide develop responsibility.

Honesty about the consequences is part of it. When a process is automated, those involved rightly wonder what that means for their work. A credible answer says what the agent takes over, what stays with people and how freed-up time is used. Evasive wording undermines the cooperation the pilot depends on. Also invite the team to the evaluation so that it can contribute its own observations.

Training is simple and practical. People should understand what the agent can do, where it errs and how to report mistakes. A simple feedback channel, such as a field in the draft where corrections are recorded with a reason, provides the best learning signals. It also shows whether the review is being taken seriously.

After the pilot, one of three decisions follows: continue, adjust or end. Continuing does not mean connecting more processes right away. First the pilot process is moved into regular operation, with logging, monitoring and clearly named responsibility. A learning phase follows, in which you observe whether results stay stable even when circumstances change.

Scaling is the repetition of the selection, not its abolition. Every further candidate goes through the same matrix, and the ratings shift as experience grows. A process that was too risky at first may now be acceptable thanks to existing approval steps. The same applies in the other direction: if the first pilot shows limits, add them to the criteria.

What matters is what is observed in the learning phase. Errors that pile up are the less interesting signals, because they are noticed. More revealing is gradual loss of quality: templates change, a product is added, employees change, and the agent keeps working to the old state. That is why the learning phase needs a fixed rhythm in which samples are drawn, corrections are evaluated and the agent's instructions are adjusted.

Responsibility must also be named. You need one person who looks after the agent from a subject-matter perspective and one who decides on permissions and data access. In small businesses these are often the same people, which is fine as long as it has been agreed explicitly. Without this assignment, a pilot that went well fizzles out in everyday business, because nobody feels responsible when something stands out.

The next step is small. Collect the three to five processes under discussion in your company for the agent, and answer the five questions for each in one sentence. A favorite usually emerges already, and just as often it turns out that the data situation or measurability still needs to be prepared. We are happy to assess this list together with you and will say openly if a pilot would still come too early.