Introducing AI agents responsibly

#What this is about

An AI agent is more than a chatbot with better language skills. It understands a request, acts in connected systems and hands over to a person when it cannot, or should not, go further. It reschedules an appointment, changes an address, checks an order status.

That ability to act is what makes introducing one more demanding than a system that only answers questions. Anything that acts needs rights, limits and a log. This guide walks through the points to settle before the first live conversation.

The glossary explains AI agent and agentic AI. The AI agents page describes what Univerx offers.

#Choosing the right starting point

The most common mistake is a brief that is too broad: “The agent should answer every enquiry.” A short list of requests works better: ones that come up often, are clearly bounded and where a mistake can still be corrected.

You usually have the data for that choice already. Contact reasons from the ticketing system, topics from conversation analytics and your team leads’ experience show which requests recur and how they are resolved.

#Roles in the project

An AI agent is not an IT project that the business signs off at the end. It is a new way of handling requests, so it needs owners from several areas. Name those roles before the first agent is built.

• Business owner: decides which requests the agent handles and what counts as resolved.
• Knowledge editors: maintain the content that answers are based on.
• Receiving team: takes handovers and reports where context is missing.
• Engineering and integration: connects systems and manages the agent’s credentials.
• Privacy and works council: review data, logs and reports.
• Approver: releases versions and is accountable for live operation.

In small teams one person holds several roles. What matters is that every role has a name. Otherwise nobody knows who corrects a wrong answer when it counts.

#Disclosure: clear from the first line

Art. 50 of the EU AI Act requires that people are told when they interact with an AI system, unless that is obvious. The duty has applied since 2 August 2026. In customer service, disclosure is a matter of trust anyway.

Good disclosure is short, unambiguous and repeatable. It comes at the start, not in the small print. It pairs the notice with the offer to reach a person at any time.

In email and SMS, disclosure belongs in every message the agent writes, not just the first. Nobody rereads a greeting from three messages ago.

On the phone there is no chat window to signal what is going on, which makes the opening announcement especially important. The post Disclosing AI without breaking the conversation shows how disclosure fits the flow.

#Handover: the moment that decides

An AI agent is not judged by how many conversations it ends on its own, but by how good its handovers are. Customers forgive a handover. They do not forgive having to tell the whole story again.

#When to hand over

Define triggers instead of leaving handover to chance. Typical triggers are an explicit request for a person, repeated misunderstanding, a request outside the agent’s brief, and topics you deliberately reserve for people, such as complaints or emergencies.

#What to hand over

The handover carries the recognised request, the steps taken so far, details already verified and the reason for the handover. A short summary on top, the full transcript below. The employee sees both on the agent desktop before accepting the conversation.

Service EN· active

Queues

Voice3 waiting

Chat5 waiting

Email2 waiting

Messaging1 waiting

Conversation

AI agent, disclosedHandover from AI agent · context complete

I received the decision letter, but the amount does not match my application.

I have the case in front of me. One moment, I am checking the calculation.

Sentiment: calmVoice

Context

Case

2026-0412

History

3 · 14 d

Univerx Assist

Suggested reply

The letter deviates from the application. I will propose a correction and send you the confirmation by message.

InsertAccept

Summary

Request: deviation in the letter. Documents on file. Next step: correction, confirmation by message.

The post Why the handover decides goes into what a good handover contains.

#Phone and chat: what differs

The phone follows different rules from chat. Spoken answers need to be shorter, because nobody can scroll back. Lists of more than three items overwhelm. Numbers, dates and names should be repeated and confirmed.

Speech recognition also makes mistakes that chat never sees: swapped digits, background noise, regional accents. Build in confirmation questions such as “Did I get that right: your customer number ends in 4711?” And allow a switch to a person at any point.

In chat, by contrast, customers can pause and come back later. The agent must still know hours later where the conversation stood. Web messaging is a good first channel for that reason: histories stay visible and are easy to review.

#Actions and permissions

What an agent may do is a business decision, not a technical one. Write it down as a list of actions: which systems, which fields, which limits. Anything not on the list is off limits.

1. Read before write. The agent starts with information from connected systems. Write actions follow once reading works reliably.
2. State limits explicitly. Amounts, time ranges, number of changes per conversation. Anything beyond goes to a person.
3. Identity before action. Account changes only after a check that matches your phone procedure.
4. Ask for confirmation. Before any change, the agent summarises what it will do and waits for a yes.
5. Use its own credentials. The agent acts under its own technical identity, never a person’s account.

These rules do not slow the agent down. They make it explainable, and that is what business owners, privacy and audit need before they trust it.

#Knowledge and grounded answers

An agent is only as good as the knowledge it relies on. Generated answers should be tied to your knowledge base, not to a model’s general knowledge of the world. The technical term is grounding.

Where no grounded answer exists, the agent says so and hands over instead of guessing. That is how you contain hallucinations: plausible-sounding but wrong answers. The guide Knowledge management for customer service shows how to build the knowledge base.

Tone is part of knowledge too. Decide how formal the agent is, how long answers may be and which terms your organisation uses. A short style guide that your service team also follows makes agent and people sound like one company.

#Logging: traceable, not invisible

Every action an agent takes is logged: what it recognised, which knowledge source it used, which action it carried out and why it handed over. The log serves quality assurance, error analysis and the handling of complaints.

Logs are personal data. Purpose, retention and role rights apply to them as they do to recordings. Decide who may see logs and how long they are kept. The guide Running a contact centre in Europe puts the rules in context.

#Privacy for the agent

An agent often sees more data than it needs. Give it only the fields its requests require. That follows the GDPR principle of data minimisation in Art. 5 and lowers the risk of sensitive details surfacing in answers.

Ask the provider where speech recognition and language models run, whether conversation content leaves the chosen region and whether it is used to train models. Get the answers in writing and include them in your impact assessment.

#Approval and versioning

An agent is made of instructions, knowledge, actions and a model. A change to any of them can change its behaviour. So every change takes the same path: build, test, approve, roll out.

In Agent Studio, agents and prompts are built, tested, approved and versioned without code. Models and prompts are approved centrally. You decide who approves; for agents with write actions, a four-eyes principle is advisable.

#Testing before launch

Test with real phrasing, not ideal phrasing. Customers write in half-sentences, with typos, with several requests at once. Collect anonymised examples from past contacts and add deliberately difficult cases.

Let the employees who will take handovers test too. They are the quickest to spot an answer that is wrong on substance.

#People, literacy and co-determination

Since February 2025, Art. 4 of the AI Act has required deployers to ensure sufficient AI literacy among their staff. In customer service, that covers everyone who works with the agent: those who take handovers, review answers, maintain knowledge or approve versions.

Involve the works council early. An agent changes work, and its logs can allow conclusions about employees, such as who handled which handover and how. In Germany such analyses are subject to co-determination under Section 87(1) no. 6 BetrVG.

#Measuring what matters

The obvious metric is the share of conversations that end without a handover. On its own it misleads: an agent that sends customers away without a solution scores well on it. So always measure whether the request was actually resolved.

Collect the same figures before launch for the requests the agent will take over. Without that baseline you cannot tell later whether the agent improved things or merely shifted work. Compare like with like: same requests, same period, same channel.

The post Measuring customer experience without vanity metrics covers metrics that support decisions.

#Operating after launch

Go-live is where the real work starts. An agent in operation needs a fixed rhythm in which the business owner, knowledge editors and receiving team meet. Weekly in the first weeks, monthly later.

1. Review handover reasons. Which are growing, which are new?
2. Read samples. A fixed number of conversations per week, chosen at random, not by what stands out.
3. Pass on knowledge gaps. Every missing or wrong source becomes a task for the knowledge editors.
4. Review feedback. Look at customer ratings and notes from the receiving team together.
5. Plan changes. Collect improvements and test and approve them as a new version.

Also decide how an agent is switched off quickly, or limited to information only, when something goes wrong. Who may make that call and how contacts are rerouted belongs in the operations manual, not in an improvised meeting.

#Checklist before launch

#From pilot to rollout

A good pilot runs until handover reasons are stable and no new kinds of error appear. Then the agent grows in stages: more requests, more channels and finally the phone line with voicebots.

Never extend two things at once. A new channel and new requests in the same week make it impossible to tell what caused a dip. Every stage starts with a new version, new tests and an approval.

Employees benefit in parallel from Univerx Assist: suggested replies, knowledge and summaries during the conversation. The Trust Center describes how Univerx designs AI features for transparency, oversight and logging. For a workshop on your requests, talk to us.