A good HR agent doesn't answer everything – How to build a reliable agent with Copilot Studio

When it comes to HR and error isn’t just technical. It affects real people. When an employee asks about salary, occupational health, leave or terms of employment, the wrong answer can eat away at trust faster than any process reform can build it. So, when you’re building an HR agent, you have to be able to trust the answers.

When we built an HR agent in Copilot Studio and published it to Teams, the most important lesson was not born from technology choices, but from limitations. A good HR agent should know when to answer – and when to pass it on to a human.

A free-roaming chatbot can look useful because it responds to almost everything. In the context of HR, this is precisely the risk: if the agent's boundaries, sources and responsibilities are not clear, they may interpret outdated instructions, confuse different practices, or give a confident answer in a situation where the matter should be referred to a human.

A reliable agent is built on four limitations. It must give the right answer, stay in the right context, use the right sources of information and identify when the matter belongs to the person. Everything else is built on these limitations.

When we started the development of the HR agent, we started with the people. We mapped out with HR which questions are repeated, which tasks take up the most HR working time, and where employees feel that information is difficult to find. Employees' wishes were also collected with a Forms survey. Only after this did we start thinking about what kind of agent would be really useful.

We built an HR agent that starts the conversation by choosing a topic. In the Adaptive Card, the employee chooses one of five HR themes: salary and compensation, benefits and occupational health, time off and absences, onboarding and departure process, or employment and working hours.

The choice is not just a user interface solution. It defines the context before the conversation begins, directs the agent to the right sources, and immediately tells the employee where to get help. At the same time, the structure improves usability; the user does not need to know the correct term or the name of the HR process, but can choose the topic area from clear options.

During the conversation, the user can continue from the same topic, return to the top-level selection within the topic, switch to a completely different HR theme, or end the conversation. The navigation is planned, not left to the interpretation of the model.

In practice, we noticed that this structure solves three problems at the same time, which are often seen in overly limited agents: the quality of the answers improves, the context remains under control, and the user experience feels guided instead of misleading.

The HR agent uses the organization's own SharePoint sources and, if necessary, suitable public websites, such as government sources. The sources have been approved, ownership has been defined and the responsibility for updating has been named.

The same care can be seen in the implementation. The agent was built into the organization's own Microsoft 365 environment, access rights were taken into account in the design, and the impact of data protection was assessed with a separate data protection impact assessment, or DPIA assessment.

In practice, the up-to-dateness of sources can be something quite mundane. For example, the same HR instructions can be found in two places on the intranet with slightly different words. For a person, conflict can be annoying. For an agent, it's an even bigger problem because they have to deduce which piece of information is correct. AI does not correct an inaccurate source, but reproduces it in a persuasive voice.

This is one of the most surprising benefits of an agent project. When the sources are reviewed, the organization's HR information becomes visible at the same time, even where it is outdated, overlapping or missing altogether. Building an agent is also a way to look at how the organization's information works in everyday life.

The quality of the data is also not limited to the date of commissioning. With HR, we went through how SharePoint pages should be updated in the future so that the agent returns the information as reliably as possible. In this way, the maintenance and further development of the agent are intertwined with the organization's own work, not remain a separate project.

A reliable agent comes with a built-in ability to recognize their limits. In the case of this HR agent, identifying the boundary means that the agent can route the matter to HR via a Teams message — without the employee having to know who the question belongs to or how to reach them.

This is a crucial detail for trust. When the employee notices that the agent is guiding forward in uncertain situations instead of pretending to be confident, the agent's overall reliability increases. Escalation is not a failure; it is a promise that the matter will be handled in the right place.

It is also worth looking at the HR agent in the other direction. It is not only a service channel for employees, but a signal channel for HR management.

The data generated in use tells us about things that are otherwise difficult to detect: which HR themes employees ask about the most, where instructions remain unclear, which processes repeatedly cause uncertainty, and when the agent has to refer the matter to HR — and for what reason.

It is important that these signals are viewed as aggregated phenomena, not as questions from individual employees. It is not a question of monitoring employees, but of learning in the organization.

For a business decision-maker, this is often one of the most interesting values of an agent. Metrics don't just tell you about an agent's performance. They tell you where HR processes, guidelines and internal communication work and where they need to be updated or changed.

The user can also provide feedback directly through the agent, and the feedback is stored in SharePoint. In this way, the signal channel is not only based on usage data, but also on employees' own observations.

Once the agent has been limited, sourced and managed, its use can be expanded. This is the main reason why control should be seen as an enabler, not a limitation.

A good example is onboarding. When a new employee is added to a Teams group, the agent can send them an automated welcome message and share key onboarding instructions with a low threshold. The employee learns how to use the agent on the first day, the basic information of onboarding is levelled out between all newcomers, and the manual repetitive work of HR is reduced.

This is only possible because the same agent is controlled anyway. For a free-running chatbot, a new employee could not be safely directed in the same way. For a controlled agent, you can.

A technical solution alone is not enough if the sources, boundaries and responsibilities remain unclear. Once they are in order, the use of the same agent can be expanded in a few months to support onboarding, managerial work, or more extensive HR processes.

Not because it can answer everything. But because we have known from the beginning what it will respond to, where it will get its answers from and when humans will come along.

Boundaries are not the opposite of agent agency. They make its operation safer, more understandable and more extensible.

At Context&, we help design and implement agents with boundaries, sources, responsibilities, and user experience that are thought out from the start. In this way, the agent becomes not just a new user interface for HR information, but a reliable part of the employee's everyday life.