Start with the information people keep repeating
A useful starting point is the question that interrupts someone several times a week. Which template should we use? Has this decision changed? Who can approve an exception? Those interruptions reveal where company knowledge is difficult to find or difficult to trust.
Choose one recurring workflow and ask the people involved what they need to know to finish it. Keep the initial scope small enough to understand. A shared collection of approved service procedures can be more useful than an ambitious attempt to put every company document into one enormous memory.
The benefit should be recognisable to the team: less searching, fewer repeated explanations and more time for the customer waiting for an answer. Define that benefit before choosing the technology.
Give each important decision a maintained home
Imagine a service team preparing answers about delivery arrangements. A procedure changes, but an old presentation still contains the previous wording. A colleague may know which version to use because they attended the meeting. An agent needs an explicit way to distinguish the current instruction from the historical material.
For this illustrative workflow, I would identify the approved procedure, its owner, when it took effect and where the old version is retained. The agent should use that current source and be able to show where its answer came from. An old example can remain useful context without silently becoming today’s policy.
This is what I mean by shared company memory: maintained knowledge that supports the work. It can live across existing systems. What matters is that the people and agents know which source governs which question, and what to do when sources disagree.
Make updating knowledge part of someone’s job
A shared source becomes stale if everyone assumes someone else will maintain it. Name the person responsible for each important area. Give them the time and authority to update it, and make the approval route clear.
An agent can help identify an outdated instruction or propose a clearer explanation. A proposed change and an approved change need different states. The person responsible should be able to inspect the reason, accept or reject it, and see what changed.
This is an HR and operating-model issue as much as a technical one. The person doing the work may take on a broader role: maintaining the instructions, spotting exceptions and improving how colleagues and agents use them. Coaching should cover these responsibilities, alongside how to give an agent a useful brief.
Share the right knowledge with the right role
Shared knowledge does not mean universal access. A service agent may need delivery procedures and approved product information. It may have no reason to see personnel files or unrelated customer records. Decide access from the task and the person accountable for it.
Build those boundaries into the system that retrieves and changes information. A sentence asking an agent to be careful is not a substitute for access controls. Keep the sources available to a role aligned with what that role is allowed to do.
The same applies to action. Finding an approved answer does not automatically grant permission to send it, change a record or make a commercial commitment. Knowledge access, decision authority and permission to act are separate choices that should remain understandable to the team.
Teach the system how to handle doubt
The awkward cases deserve attention before a wider rollout. What happens if the approved source is missing? If two current documents conflict? If a customer asks for an exception that nobody has authorised?
For the service example, the useful response might be a prepared answer with a clearly marked open question for the responsible colleague. The system should preserve what it found and explain why it needs help. That gives the person something concrete to resolve.
Once resolved, decide whether the answer applies only to this case or changes the general procedure. Otherwise, one exceptional decision can spread into a rule it was never meant to become. Record the distinction where the next person or agent will find it.
Test whether the team has less work to do
Use a small set of ordinary questions and difficult examples to test the workflow. Include a changed procedure, a missing source and a request outside the agent’s access. Check whether the answer uses the right information and whether uncertainty reaches the right person.
Measure the whole effort: time spent searching, answering, checking and correcting. Ask employees whether they can understand and challenge the result. A fluent answer that requires another round of detective work has not yet solved the problem.
My work through AI Partners brings these decisions together with hands-on building. I help management choose the useful outcome, work with people on responsibilities, and build the knowledge access and agent workflow around those choices. Start with one area people repeatedly explain. Make it dependable, learn from its use and expand from there.