We Skipped RAG for Our Internal Rulebook — 40 Pages Fit in the Context Window

Why does an executive end up as the company's lookup service?

Our travel expense agent showed how a problematic business process can be turned into a painless side activity, permanently. So what about everything else? All the other administrative activity in a company – can that be automated the same way?

For most of it, the answer turned out to be yes. This article describes the corporate AI assistant we built and use internally: what it answers, where the data actually lives, why we deliberately did not build a retrieval layer for our internal documents, and what it still cannot do.

As a manager, I constantly got questions like "How many days of vacation do I have left?" or "How much do I owe for the company-subsidised gym?". All of that information is available to everyone in the appropriate software, and I always tried to show people where they could find the answers themselves. But people forget where a document lives when they need it a few times a year at most.

These questions arrived weekly, and considerably more often at peaks. They were never a team-wide batch – always an individual, triggered by a personal need, question or situation. Each one cost a few minutes. But the real cost was not the lookup. It was the interruption.

“As you can guess, I didn't know any of those facts by heart. So I ended up looking them up for my team members.

That framing matters, because it tells you what kind of problem this actually is. In an SME it is not about processing a large number of requests. It is about protecting an executive's time and focus.

What can a corporate AI assistant actually answer?

How does it answer personal data questions like leave balance?

So how does it get to your leave balance? Our corporate AI assistant uses tools to access the appropriate databases and answer questions like these. Tools are basically normal software functions – database queries or API calls. The difference is that they are now called by an LLM. That is why such solutions are called AI agents in the first place.

The leave-balance question is answered by a tool that reads our digital records of days off. That is the whole of the AI leave balance assistant part. The gym subsidy sits in the same place.

How does it answer questions about company policy and rules?

The next line of questions is about fixed rules rather than personal data. "How many free days do I get for childbirth?", for example. That answer is not in any database. It is in our corporate rulebook. The assistant answers from the rulebook text itself, and always quotes the document section or paragraph the answer came from.

Why several orchestrated agents instead of one general agent?

Why not one agent that knows everything? Under the hood, our corporate assistant is more than just one agent. It consists of several orchestrated agents, because some functions are too specialised for a single know-it-all agent. A travel expense query is routed directly to the travel expense agent. From the user's point of view it is all one solution with one interface. Under the hood you still need to know what you are doing to make it work well across all the different scenarios.

New cases to automate keep arriving. That is why it is so important to keep the architecture modular. New functionality gets added without disrupting what already works.

Why this is a corporate assistant, not an AI assistant for HR

The single most useful thing to understand about this system is that the departments behind it are different departments. A leave balance or a childbirth-leave rule is HR. A travel expense report is more likely accounting. Organising attendance at a conference is marketing, or some form of administrative support. The assistant switches between them automatically, based on what is being asked.

“So it is not an AI assistant for HR. It is – as the name says – a true corporate assistant.

The event organising agent shows how far outside HR this reaches. We attend more than one conference or event per month, and most of them are outside our city, so planning accommodation and transport is real overhead. The agent handles that. It also scrapes the web for decision makers and prepares a list of interesting people for whoever from our side is attending. So when a cold-approach opportunity comes up at a coffee break or an afterparty, we are already prepared. That agent, like the travel expense agent, gets an article of its own.

Do you need RAG for internal documents? We evaluated it and did not build it

Almost everything written about an enterprise AI assistant for internal documents assumes the answer is Retrieval-Augmented Generation. For our rulebook, it is not. At least not yet.

Our corporate rulebook with general procedures is only about 30–40 pages long. That fits into the context window. We did try RAG out. But the sizing question – do we need retrieval for this quantity of text – was one we put to the model rather than guessing at. The answer was no.

The rulebook is rewritten into an appropriate Markdown file rather than being parsed from .docx or PDF at query time. One preparation step. That is what makes the in-context approach practical.

We are not claiming the context window scales forever. There is a document volume at which retrieval becomes the better design for an internal knowledge base AI assistant, and we would not guess where that is. We would consult the literature to determine the volume at which it is better to switch to RAG.

Why must every answer quote the rulebook section it came from?

Whichever way the documents are supplied, the answer must quote the section or paragraph it came from. This is not a nice-to-have for auditability. It is how we decide whether the answer is plausible at all. That is why this is an enterprise AI assistant with source citations.

While experimenting with RAG, we saw far too many times that the LLM reverted to its training corpus. The childbirth-leave question is the perfect example. Parental leave is heavily covered by national law, which the model obviously knows, while our own internal rule is very specific. When the model started explaining national regulation instead of giving a clear, direct answer, it was immediately obvious that it was no longer reading our rulebook.

A quotation makes that failure visible instantly. No citation, or a citation that does not match the rulebook, and the answer does not count. The requirement is enforced through the system prompt and guardrails.

Where does the leave data actually live — and why is it a spreadsheet?

The honest version of our own architecture is one most enterprises will recognise. The system of record for leave is not the official system.

Both leave balances and the gym subsidy are kept in Google Sheets. That sounds like a shortcut until you look at the alternative. The accounting application we use is 1990s desktop software. I don't believe it has any API at all – only a few file-reading and system-to-system interfaces, none of them suitable for this purpose.

More importantly, the limitation is structural rather than technical. The accounting app is focused on registering the past: days off are entered during payroll processing. It says nothing about the present and the future. The spreadsheet lets us register past days off and also future vacation, as announced and planned by our employees. So the Sheet is the real system of record for leave. The accounting application catches up at payroll.

We name Google deliberately. Cloud spreadsheets are considerably more reliable and scalable than desktop ones.

What changes when a corporate AI assistant is deployed in an enterprise?

Does swapping a spreadsheet for an ERP HR module mean a rebuild?

A large enterprise has a real HR module inside an ERP, not a spreadsheet. That does not require a rebuild. We try to build interfaces with a sufficient level of abstraction, so the agent does not care which system is underneath. It only cares about getting the right data – in this case, data about leave and absence.

What stops an employee from asking about a colleague's leave balance?

The first question an HR buyer asks is what stops a colleague from asking the assistant about somebody else's balance. In an enterprise deployment, the assistant queries the real ERP or HR module, and the user asking has exactly the same privileges they have in the ERP. If the data is available to that user in the ERP, they will see it through the assistant. If not, then not.

Internally the principle is identical. Everyone can already see everybody else's absence in the source spreadsheet, so the assistant does not withhold anything the source does not withhold. The assistant does have usernames and authorisation, so per-user access levels could be added where a deployment requires them.

Is the buyer HR or IT?

At enterprise scale the pitch is HR-targeted. But HR rarely purchases a software solution without IT, which is why scalability, security and cloud hosting belong in the conversation. The assistant is a web-based application, and it could theoretically serve hundreds or thousands of users. Deployed to the cloud, the number is practically limitless.

How fast can a corporate AI assistant be built?

The travel expense agent was designed from the start as a single module of the corporate assistant, not as a standalone tool later absorbed into one. VIS Solutions built it from scratch thanks to expertise in agentic coding, and the prototype took days to develop.

That speed is the capability claim worth making, and it comes with an important caveat. As with all business solutions, this one is never done. Upgrades and maintenance are a process, not a project.

What can the assistant still not do?

If somebody asks a question that has never been asked before, and the agent has neither the tool nor the context for it, of course it will not be able to answer. That is exactly why this is a process rather than a project. If we judge that a question is likely to repeat, we upgrade the assistant.

The most recent example is a good one. A colleague phoned me to ask when her sick leave finished. It was a side question in a conversation that was mostly about coordinating her return. She simply could not remember the exact end date, so she tried me. I was on vacation and could not have looked it up even if I had wanted to.

The interesting part is the fix. It is not code. Adding an absence type of "sick leave" to the spreadsheet closes that gap without changing the assistant at all.

Does that generalise? It depends. A completely new type of problem needs the agent upgraded. An extension of an existing type can often be handled by extending the data source, as in this case.

Has it worked, and what can honestly be measured?

The questions have not stopped. What changed is that I can now simply forward people to a single source, and people tend to remember that one. The frequency of questions is declining.

That is a subjective judgement and should be read as one. Nobody keeps a register of informal communication with colleagues, so there is no measured before-and-after to quote. What can be stated precisely is the design. A modular assistant with one interface, specialist modules routed automatically, a rulebook held in context with mandatory quotation. And data interfaces abstracted enough that swapping a spreadsheet for an ERP is a configuration problem rather than a rewrite.

Rulebook in context vs a RAG retrieval layer, as VIS evaluated it

Your own corporate assistant almost certainly exists already, just in a scattered form – someone forwarding salary questions, someone else explaining gym benefits, a third person looking up conference logistics. You have the data, you have the questions, you just need the routing. We are publishing next on how the event organiser agent prepares for cold calls, and what it cannot yet do in the wild – including the failures we are still debugging. Subscribe to see it.