Before You Build an AI Agent, Get Your Information in Order

You can have a really clear idea of what you want an agent to do, but if the information it needs is scattered across different places, stored in formats it struggles to use, out of date or restricted by permissions nobody has properly mapped, you are going to run into problems very quickly.

That experience changed the way I think about AI readiness.

Imagine you want to build an HR agent.

You want employees to be able to ask questions about annual leave, expenses, probation, maternity leave or other company policies and get a useful answer without having to search through folders or contact HR every time.

That sounds straightforward.

But where does the answer come from?

Is there one current HR policy document, or are there several versions stored in different locations? Is the latest policy clearly identifiable? Are there older documents that should no longer be used? Are important exceptions buried somewhere else?

The same applies to a sales agent.

If you want an agent to help employees answer questions about your products and services, it needs reliable access to that information. That may include product descriptions, service scope, pricing rules, exclusions, implementation details and other commercial information.

Again, the question is not simply whether those documents exist.

Can the agent find the right information easily, and can you trust what it finds?

That is where the preparation work starts.

When I started working with agents, I quickly found that information needed to be stored in formats the agent could reliably scan and understand.

That makes you look at documents differently.

A document may work perfectly well for the person who created it because they already know where everything is. They know which section contains the important detail, which table needs interpreting in a certain way and which paragraph overrides something written earlier.

An AI agent does not have that organisational history.

It needs the information to be clear.

That does not mean every business needs to rebuild its entire knowledge base from scratch. It does mean there is value in making information easier to understand for both people and AI.

Clear headings help. Consistent terminology helps. Separating different subjects into logical sections helps. Important information should not be hidden inside a huge paragraph if it can be explained more clearly.

The same applies to tables. If a table only makes sense because somebody understands the colour coding, merged cells or notes sitting elsewhere on the page, it may need some work before you depend on an agent to interpret it consistently.

There is a useful test here.

If an employee has to say, “I know the document says that, but what we actually do is this,” then the information probably is not ready yet.

Most organisations collect documents over time.

A policy gets updated and a new version is uploaded, but the old one is still sitting somewhere.

A sales presentation contains an old service description.

A process changes, but somebody forgets to update the supporting guidance.

Employees usually learn which information to ignore. They ask a colleague, recognise an old template or simply know from experience which version is current.

An AI agent may not have that same ability to recognise organisational history unless you design for it.

That is why part of preparing information for AI should involve deciding what the reliable source is.

If two documents disagree, which one wins?

If a policy has been replaced, should the old one still be accessible to the agent?

If information changes regularly, who is responsible for keeping it current?

Those are governance questions, but they have a very practical impact on the answers users receive.

This leads to another area that can easily be overlooked.

Who owns the information after the agent is launched?

An HR agent may work beautifully when it first goes live because every policy has just been reviewed. Six months later, a policy changes.

Who updates the source?

Who checks that the agent is still using the right information?

Who tests the answer afterwards?

The same applies to product information. Services change. Pricing changes. Processes change. Teams change.

An AI agent should not become another system that quietly drifts away from how the business actually operates.

For each important source, I would want a clear owner and a sensible review process.

That also gives employees somewhere to go when they spot a problem.

If someone receives an answer from the agent and knows it is wrong, there needs to be a way of correcting the information behind it rather than simply telling that individual to ignore the answer.

The other thing I realised very quickly was how important permissions are.

An agent can only be useful if it can access the information it needs, but that does not mean everybody should be able to access everything through it.

Consider the HR example again.

There may be general policies that every employee should be able to access, alongside information that should only be available to HR or managers.

A sales agent may need access to detailed product information, but there may be commercially sensitive material that only certain roles should see.

This means you need to understand both the agent’s access and the user’s access.

Who can see what?

Should the answer change depending on the person asking?

Are the permissions inherited from the source system?

Are there folders or documents with access settings nobody has reviewed for years?

A proper permissions overview becomes essential.

Otherwise, you risk creating an agent that either cannot access enough information to be useful or can access information it should never surface to certain users.

Neither outcome is particularly helpful.

Testing also needs to go beyond asking the agent a few questions and checking that the answer looks sensible.

I would want to test it using different users and different permission sets.

One of the simplest tests is also one of the most important.

If two people have the same permissions and ask the same question, do they receive the same answer?

They should.

If they do not, you need to understand why.

Perhaps one user can access a source the other cannot. Perhaps the agent is finding conflicting information. Perhaps there is a problem with how permissions have been applied. Whatever the reason, you need to know about it before employees begin relying on the agent.

You should also deliberately test different permission levels.

What happens when an employee asks a question that requires manager-only information?

What does HR see?

What does a salesperson see?

What happens when somebody has recently changed roles?

The answers should make sense for the level of access each person has.

That is where testing becomes part of governance rather than simply part of the build.

There are a few practical things I would look at before connecting an agent to a large amount of business information.

I would remove or archive outdated documents where possible, make sure current versions are clearly identifiable and use consistent names for products, services and processes.

I would also separate different types of information where that makes sense. Policies, procedures, FAQs and reference information all serve slightly different purposes, and making those distinctions clear can make information easier to manage.

Exceptions are worth documenting too.

Businesses often document the standard process well but rely on experienced employees to know what to do when something unusual happens. Those exceptions are exactly the kind of thing an AI agent may struggle with if nobody has captured them.

And where several sources contain related information, decide which source is authoritative.

The goal is fairly simple: make the information easy to find and difficult to misunderstand.

That is useful whether an AI agent ever touches it or not.

I think businesses will increasingly create agents for HR, sales, service delivery, finance and many other areas.

There is a huge amount of potential there.

But building the agent is probably going to expose something many organisations already know: their information has grown organically over years and has never really been designed as one joined-up source of knowledge.

That is not necessarily a reason to delay using AI.

It is a reason to do the preparation properly.

Understand what information the agent needs. Make sure the information is current and structured clearly. Decide who owns it. Map the permissions. Test different users. Keep testing after launch.

If you get those foundations right, you are giving the agent a much better chance of producing answers people can actually trust.

And trust is going to be crucial.

If employees have to double-check every answer because they are not sure whether the information is current, the agent will quickly lose its value.