Skip to content

AI Workforce & Assistance

Internal knowledge assistant: answers with sources, or an honest “I don't know”

The answers your team needs are already written down, in policies, procedures, past jobs and tickets. The assistant finds them for each person, inside what they're allowed to see, and answers with links to the source. When the sources don't cover it, it says so and asks the person who owns that content. We build it on your own documents and permissions.
Talk through your knowledgeAsk it three ways ↓
Ask · Eastside teamT4 · field technicianDo we cover labour on a heater we installed 8 months ago?searching 3 sources you can see[1] Warranty policy v4 · §3[2] Callback procedureYes. Labour on our installs is covered for one year [1].Log it as a warranty callback, not a new job [2].T4 · field technicianDo we service Kestrel tankless units?searching 3 sources you can seeI couldn't find this in the approved sources.Sent to Operations, who own the service list.

The answer exists. Finding it is the problem.

The answers employees need usually exist somewhere: in policies, procedures, past proposals, support tickets, shared drives, and the heads of long-tenured staff. Finding them means searching several tools with the right keywords, or interrupting a colleague who knows.

New hires take longer to become useful, and the same questions get answered again and again, not always the same way.

Today, and with the assistant

Today

  1. 01Someone needs an answer: a policy detail, how a process works, what was agreed with a client.
  2. 02They search a shared drive or wiki by keyword and open several documents, hoping the one they find is current.
  3. 03If that fails, they ask the person who usually knows.
  4. 04The answer, given in chat, never gets written back anywhere.

Outdated documents look as authoritative as current ones, and the people who know become the bottleneck.

With the assistant

  1. 01They ask in plain language, where they already work.
  2. 02The assistant searches only what they're allowed to see.
  3. 03It answers from the most relevant passages, with a link to each source.
  4. 04If the sources don't cover it, it says so and routes the question to the content's owner.
  5. 05Unanswered and flagged questions show what to write or fix next.

The knowledge was already written down. Now people can use it.

Ask it three ways

The same assistant, three kinds of question. What matters is what it does when it can't, or shouldn't, answer.

T4 · field technician

Do we cover labour on a heater we installed 8 months ago?

Yes. Labour on our installs is covered for one year [1]. Log it as a warranty callback, not a new job [2].

Sources

  • [1] Warranty policy v4 · §3 Labour
  • [2] Callback procedure · step 2

Every claim links to the passage it came from, so checking an answer takes one click.

How it fits together

The assistant in two halves. Ingestion connects approved sources, extracts and chunks them by structure, tags each passage with its source, version and access, and indexes it. Answering filters by the asker's permissions, retrieves, and writes an answer with citations, or says the sources don't cover it and routes the question to its owner. Source owners decide what's included; an access map carries permissions from the source systems.

One rule shapes the design: permission comes before relevance. A perfectly relevant passage from a document the employee isn't allowed to see is not a valid result. Every answer keeps its provenance, which sources and versions it drew on, so employees can check it and the system can be tested over time.

The parts it's built from

Each part is built and tested on its own, so you can start with one and add the rest.

  1. Organise

    Knowledge Base Engineering

    Sources with owners, versions and access rules.

  2. Find

    Semantic Search

    Passages by meaning, inside each person's permissions.

  3. Answer

    Retrieval-Augmented Generation (RAG) · LLM Application Development

    • question
    • permitted passages
    • instructions

    no supporting passage → say so, route to the owner

  4. Check

    AI Evaluation & Guardrails · Human-in-the-Loop AI

    Test questions, flagged answers and owners.

Underneath every stepAPI IntegrationConnects to the drives, wikis and tools where your sources live.

Where people stay in charge

  1. Source ownership

    Who decides what's in

    A named owner chooses which sources are included and keeps them current.

  2. Unanswerable questions

    Who closes the gap

    Questions the sources can't answer go to an owner, not to the model's general knowledge.

  3. Feedback

    Who fixes what's wrong

    Employees flag wrong or unhelpful answers. Flags feed testing and content fixes.

  4. Sensitive content

    Who may see it

    Some sources can be left out entirely, or limited to specific roles.

What changes from one business to the next

SourcesWhich are connected, and how often they're re-indexed
PermissionsHow access maps from the source systems: drive groups, wiki spaces, roles
Where it livesA web app, an internal tool, or a chat workspace your team already uses
How strictHow closely answers must stay within the sources, and when to hand off to a person

A common starting point is Docling for document extraction; PostgreSQL or Supabase with pgvector for storage and retrieval; a hosted language model; and Langfuse for tracing and evaluation where answer quality matters. A dedicated vector database such as Qdrant comes in only when scale, advanced hybrid retrieval or operational separation justifies it. These are starting candidates, not requirements.

Is a knowledge assistant the right system?

Good fit

  • Important knowledge lives in documents, but people can't find it reliably.
  • The same internal questions come up repeatedly.
  • Sources have an owner and can be kept reasonably current.
  • Access rules exist and can be mapped, because not everyone should see everything.

Avoid when

  • The documents are badly out of date and nobody owns them. The assistant will answer fluently from bad sources.
  • The answers live in structured data, such as orders or account status. That's a reporting or application problem.
  • Permissions for the source material can't be worked out.
  • The team is small enough that a well-organised wiki and ordinary search already work.

How we'd approach it

Most of the early work is choosing the sources, matching your permissions and deciding how strict the answers should be.

  1. 01

    Understand

    As much as the problem needs

    We map how the work runs today: who does what, which systems hold the records, and where it breaks.

  2. 02

    Design

    Decided before it's built

    Ownership, rules, integrations and exceptions, agreed with you and written down with acceptance criteria.

  3. 03

    Build

    Connected to what you use

    We build the scoped system, connect it to the tools you already run, and test it on the cases that matter.

Related systems

The capabilities underneath

For your industry

Questions about internal knowledge assistants

Can it see everything in our drive?

Only the sources you connect, and each person only gets answers from what they could already open.

What happens when it gives a wrong answer?

Employees flag it, and the flag goes to the content's owner and into the test questions. Because every answer cites its sources, a wrong answer usually points straight at a document that needs fixing.

Where do employees use it?

Where they already work: a web app, an internal tool, or a chat workspace such as the one your team uses every day.

Does it learn from our conversations?

Not by default. Questions and feedback are logged to improve the sources and the tests; the model itself isn't retrained.

Put your team's knowledge one question away

Tell us where your team looks for answers today. We'll show you which questions an assistant could answer with a source.

Start a project