Using Internal Company Knowledge to Build Focused AI Systems

You build a focused AI system from internal knowledge by choosing one job, writing down the question it has to answer, and giving it only the sources that answer that question. Then you decide who may read each source, keep the assistant's collection separate from every other assistant's, and test it with questions whose answers you planted yourself. The opposite approach, pointing a model at everything and hoping, produces an assistant that is vague, hard to test and hard to defend when someone asks where an answer came from.

This post walks through that method in order, marking each practice as in use at Swfte, built in the product, or designed for. Where a worked Swfte example would help and does not exist yet, it says so.

Why start with one job and one question?

Because "index everything" has no finish line and no test. If the goal is to make the company's knowledge searchable, you cannot say when you are done, and you cannot say whether the assistant is any good.

A job is narrower. "Answer new starters' questions about our expenses policy." "Tell the support team which runbook applies to this alert." "Help a solicitor find the clause in our standard terms that covers data return." Each one has a person who asks, a body of material that answers, and an answer you can check against a page.

Write the job as one sentence and the question as one example. Then list the three or four documents a competent colleague would open to answer it. That list is your first collection. If you cannot produce it, the job is not ready.

It also tells you what to leave out. A focused assistant with fewer, better documents usually beats a broad one, because less irrelevant text competes for each answer. The company brain, RAG and knowledge base comparison covers when a wider shared layer is worth building. For a first system, narrow wins.

Which sources go in, and who may read them?

Sort every candidate source by one question before you index it: who is allowed to read this today? Do it in the source system, not in the AI tool.

A simple three-way sort is enough to start:

Access is a property of the source, and the AI system has to inherit it rather than invent its own. If five people can read a document, an assistant serving fifty has quietly widened its audience.

Be wary of sources that look harmless and are not: shared drives with unreviewed inherited permissions, exported tickets containing customer details, meeting notes with a performance discussion in the middle. Reading a sample of each source before indexing is dull work and the cheapest control you have. The wider view of this layer is on the data and context page.

One assistant per job, each with its own collection

Give each job its own assistant and its own collection. Resist the shared pool.

A separate collection means you can name its owner, say what is in it, remove a document and know the effect, and test it on its own. It also keeps the access rule simple, because a collection can carry the restriction of the most sensitive thing inside it. A single pool of everything inherits the worst case for every user.

In Cortex, the assistant is the unit you shape. An assistant has a prompt, bound knowledge, optional memory and the tools it may use. For cloud work, an agent has attached collections and answers from those. That is built in the product: you bind a knowledge base or a governed collection to an assistant or agent, and the assistant's reach is what you bound to it.

One practical rule: if two jobs need different people to see different answers, they are two assistants, even if they share most of their documents.

Local-first or a governed cloud collection?

There are two routes in Cortex, and they suit different material.

The local route is an on-device knowledge base. Files, folders, URLs, sitemaps and notes are indexed on the machine, and with Ollama embeddings the whole path can stay local. It is built in the product, it works without a sign-in, and it suits personal material and anything that should not leave the device. It is also the route that suits a first experiment, because it costs nothing to try and nothing is shared.

The cloud route is for material a team shares. Sources are ingested, organised into spaces that carry access rules, and curated into collections that an agent can use. Spaces have per-space roles, and a collection inherits the most restrictive governance of what it contains. The code for the enforcement points is merged. We describe it as built, and we are candid that live end-to-end validation of the whole cloud route was still being finished when we last looked.

Choose by audience. One person's working notes: local. A shared body of material with owners and restrictions: a governed collection. If you start local and later need to share, you will re-import, so keep a list of what you indexed. The Cortex product page has the current picture of both routes.

What access rule should the assistant follow?

The rule is simple to state and demanding to build: the asker never gets more than they could read themselves.

If a user cannot open a document in the source system, the assistant must not paraphrase it for them. That sounds obvious until you notice how often an AI layer runs on one service account that can read everything and answers for anyone.

In the governed cloud route, the design is that Cortex reaches what the asking user may read. Access is checked at several points: when a collection is composed, when retrieval runs, when the gateway uses a knowledge tool, when a collection is attached to an agent, and when it is shared. Checking in one place is not enough, because any unchecked path becomes the easy one.

You can test the rule without special tooling. Create two test users, one who can read a restricted document and one who cannot, and ask both the same question. The second must get an answer that does not contain it, nor its title. Repeat the test whenever permissions change. For the wider governance picture, see governance on the platform.

How do you test that the assistant works?

Plant answers, then ask for them. Then run a negative control.

For the planted-answer test, add to the collection a document containing a fact that appears nowhere else, such as an invented room-booking code or an unusual rule in a fictional policy. Ask a question whose only correct answer is that fact. If the assistant gives it back with a citation to the right document, retrieval is working. If it gives a plausible answer from general knowledge, you have learned that it is not grounded.

For the negative control, ask the same question of an empty collection. A well-behaved assistant says that it has no documents on the subject. If it answers anyway, it is filling the gap from the model's own memory, and every earlier pass is suspect. A test that cannot fail is not evidence.

Add three more checks. Ask something outside the job and confirm it declines. Remove the planted document and confirm the answer disappears. And confirm the assistant actually received the collection at all: our own validation notes for the cloud route recorded a defect where an agent created without a workspace identifier could never get knowledge, which is exactly the kind of silent failure the planted answer catches. Those notes use the same two tests, planted answer and empty collection, for the connectors they cover.

What is the honest state of connectors, and how do tools reach knowledge?

Connectors are where knowledge projects stall, so be sceptical of any long list. In Cortex, the connectors checked all the way to a grounded, cited answer are a short vetted list: several common databases and one file store. Others are gated or not yet validated, and at least one indexes titles only, which is not the same as indexing content. A connector in a gallery is not evidence that your documents will be retrievable through it.

For your own project, apply the same bar: a connector counts when you have seen a real question answered with a citation to a real document from that source, not when it connects.

Tools reach knowledge through MCP, the Model Context Protocol. Today that happens in-process: Cortex ships its own knowledge tools for its own assistants. One detail matters for planning. The in-process search tool retrieves from local on-device bases; cloud collections are grounded by the gateway on the server side. Serving Cortex knowledge to outside MCP clients, such as another vendor's desktop assistant, is design intent, set out in a proposal and not built. If your plan depends on that, it is not available yet.

What does Swfte do itself?

Here the honest answer is smaller than the title of this post might suggest.

In use at Swfte: our website repository carries a rules file that coding agents must follow, and some of those rules are enforced by scripts that run before every build. Slug translations are append-only and the build fails if one is missing. A data-staleness check fails the build when price rows pass a verification age. That is knowledge turned into a gate rather than a document, and it is the pattern we would point you to first: the rule that matters should be checked by a machine, not remembered by a person. The engineering workflow page says more about how we build.

Not in use: we do not run our own docs, tickets or code through Cortex or a company brain, and this post does not claim we do. A worked example of Swfte indexing its own knowledge is not published yet. If we have one, it will go on the internal knowledge page. Until then, treat this post as a method, not a case study.

For a related method that starts from your own data and ends in an agent, see building AI agents from your own data insights, and for a plain definition of the foundation, what a knowledge base is.

What is built, and what is design intent?

Built in the product: on-device knowledge bases with a local embedding option, assistants bound to those bases, governed cloud collections with per-space roles and several enforcement points, in-process MCP tools for Cortex's own assistants, and a short vetted connector list. The cloud route's live end-to-end validation was still being completed. Designed for: Cortex serving knowledge to outside MCP clients, Cortex reading a company brain, and a company-wide knowledge layer that other products draw on. In use at Swfte: rule files enforced by build scripts and staleness checks, which are practices, not Cortex features. Exact fit for your organisation depends on your data, deployment and configuration. See the governed agents pages for how the same discipline applies once an assistant can act.