An internal knowledge agent your team won't have to manage

The companies we talk to are not asking for more AI. Another AI tool to configure and manage is not the thing that is missing.

What they ask for is more ordinary. Fewer headaches. Less worry about where company information ends up, or whether it went somewhere nobody meant it to go. Customers who get an answer instead of being put on hold. Less time spent answering a question a colleague already answered last week.

The same pattern comes up in these conversations. An employee learns something useful at work, a better way to handle a request, a decision made in a meeting, a process worked out and never written down and it stays in that person's head or a document nobody else opens. A colleague hits the same problem days later and asks around again, while a customer waits on hold for an answer that already exists inside the company, not anywhere they can find it.

This article works through what a company would set up in response to that pattern, using a case built from several conversations like it and is honest about where the real work and the real limits are.

What do these companies actually want from AI?

Not more AI. None of them opened the conversation by asking for an agent, a skill, or a "second brain." They described a problem: the same questions come up again and again, some of it confidential and nobody wants to hand over more of the company's information than necessary just to get an answer out of a machine. An agent is one way to solve that, not the request itself and not the point of building one.

What is an internal knowledge agent?

An internal knowledge agent is one AI agent for the whole company that answers employee questions from the company's own documents and data, reachable from a tool employees already use, with what it can see and say scoped by who is asking.

It is not a separate agent per department and not a new app for anyone to learn. Employees talk to the same agent from Microsoft Teams, the way they would message a colleague. Behind that conversation, the agent draws on the company's knowledge bases (the material it is allowed to look things up in) and grounds its answers in them through retrieval-augmented generation, or RAG: instead of answering purely from what a general model already knows, it looks up the relevant passages first.

How does one agent answer IT, finance and sales differently?

This kind of setup is designed so the role set for whoever is asking decides what the agent can reach and how it answers, so the same agent gives IT a technical answer and finance a financial one.

Confidential knowledge is reachable only by the roles allowed to see it; knowledge marked for everyone is reachable by everyone. An IT question pulls from IT's material and comes back technical; a finance question pulls from finance's material and comes back financial. It is one agent the whole company talks to, not a different bot for every department and what it says changes with who is asking, not which door they walked through.

How does shared knowledge reach the right people?

Automatically and only the people its scope allows. In this kind of setup, when an employee shares something worth knowing with the agent, meeting notes, a new method, a document, the agent is designed to post about it in Teams so the roles allowed to see it are informed, without anyone having to chase it down or remember to pass it on.

A share scoped to particular roles reaches only those roles. A share marked for everyone reaches everyone. Nothing is being judged for relevance on the fly; it is reaching the people the scope already says it should reach. That is the second half of what these companies describe: alongside an answer when someone asks, useful information reaches the right people on its own, without anyone having to remember to forward it.

What can the agent reach and where is company data stored?

What the agent can reach is bounded by four things, scoped by you: knowledge, tools, network access and retention, the same four boundaries any Commt agent runs inside. Application, database and document storage run in the EU on private networking.

Guardrails sit alongside those boundaries: they set what the agent must never repeat back and what it does when it is not confident and they are checked before an answer goes out.

MCP is the open protocol the agent uses to reach a system, such as a database, through a server that exposes only what it is built to expose. A custom MCP server, the way the agent reaches the company's own database, runs in an isolated environment and is checked for security issues before it can be used, on every plan.

What does this change on a normal workday?

This kind of setup is designed so a customer gets answered without a wait and a colleague stops hunting for information that already exists somewhere in the company. Two situations came up in these conversations that show what that looks like in practice.

A customer call

In this kind of setup, a customer calls finance asking about their credit limit, their outstanding balance and recent payments. The finance employee taking the call asks the agent. It reaches that one customer's finance records through a custom MCP server connected to the company database and nothing from sales or engineering. The customer gets an answer on the call, instead of being put on hold while someone hunts through separate systems.

A follow-up before a meeting

In this kind of setup, a salesperson wants to know what was decided in the last meeting with a customer before a follow-up call. They ask the agent. It reads the meeting notes that were shared with it and answers from those notes, so the salesperson walks into the call already knowing where things stood.

Both scenarios use information the company already had, reaching the person who needed it at the moment they needed it, instead of sitting in a folder or a colleague's memory.

What are the tradeoffs?

Role scoping has to be set up correctly and kept current, the agent only knows what people actually share with it and retrieval can miss. None of these disappear because the agent is well built; they are the real cost of this approach.

A wrong role assignment is the main failure mode: too wide and confidential material reaches people who shouldn't see it; too narrow and people who need an answer don't get one. Getting it right and keeping it right as teams and knowledge change, is ongoing work, not a setting configured once.

The agent is also only as good as what people actually share. If a decision was never written up or shared with it, it has no way to know that decision happened. An internal knowledge agent formalizes a habit of sharing what people learn; the habit has to already exist for the agent to formalize it.

Retrieval can miss, too. Grounding an agent's answers in a knowledge base through RAG makes a relevant answer more likely, not guaranteed; a badly organized set of notes, or a question asked very differently from how the source was written, can still come back thin. This is why setup takes real effort and why getting it right matters more than getting it built quickly.

How Commt approaches this

During early access, Commt will work with you through that setup: which knowledge bases and connectors the agent needs and how roles should be scoped for your company's structure. After setup, Commt will observe the agent's answer quality and performance and report back to you, so gaps in scope or retrieval get caught rather than left to surface on their own.

If your company keeps having this conversation, get in touch to talk through what it would take, or look at the full list of connectors an agent can be scoped to, including MCP for AI agents for connecting your own systems. The boundaries used here are covered in how to limit what an AI agent can reach and what is a private AI agent; weighing this against a general assistant, private AI agent vs. ChatGPT covers that comparison. Read more about how Commt approaches agents built this way.

Key takeaways

• The companies asking for this are not asking for more AI. They want fewer headaches, less worry about their data, customers who get answered properly and less time spent repeating the same information.
• One agent serves the whole company from a tool employees already use (Microsoft Teams); what it can reach and how it answers changes with the role of whoever is asking, not with a separate bot for each department.
• Shared knowledge reaches the right people automatically, scoped to the roles allowed to see it, not judged for relevance on the fly.
• What the agent can reach is bounded by four things: knowledge, tools, network and retention, all scoped by you; web access is off for this kind of setup by design.
• The real costs are keeping role scoping correct as the company changes, an agent that only knows what people share with it and retrieval that can miss rather than guarantee a complete answer.