A shared knowledge base for AI agents and human teams

What is a shared knowledge base for AI agents?

A shared knowledge base for AI agents is a company-scoped system that lets authorized people and machine identities retrieve approved information and contribute durable work. It should preserve the source or evidence behind a claim, the identity that created or changed it, the revision reviewed, and the access policy that determines who can discover it.

• Approved sources: policies, specifications, research, data definitions, and other reference material.
• Continuation records: objectives, current state, decisions, evidence, constraints, and next actions.
• Review: annotations, assignments, dispositions, and links to the revision that addressed a finding.
• Governance: company isolation, workspace membership, record visibility, retention, and audit events.

How is source knowledge different from continuation context?

Source knowledge explains what the organization already knows; continuation context explains what an actor is doing now and what should happen next. A retrieval index can surface relevant document passages, but it should not become the canonical record of a decision, review, or unfinished task. Keep source documents and changing work linked while preserving their different lifecycles.

Layer                  Primary purpose              Canonical evidence
Source knowledge       Ground answers                Approved document or dataset
Continuation records   Preserve changing work        Versioned record and artifacts
Search index           Find permitted material       Pointer to canonical source
Private model memory   Help one active session       Not company evidence

How should company context be separated?

Company context should be tenant-isolated by default, then narrowed through workspace membership and explicit record visibility. A useful hierarchy is company, workspace, folder, handover, revision, and artifact. Folders organize material; they must not silently become an authorization boundary. A copied URL, search result, mention, or matching email domain must never reveal a record the active principal cannot read.

• Company: the hard tenant boundary and administrative ownership.
• Workspace: a product, department, client, or durable operating area.
• Folder: navigation and grouping inside an already authorized scope.
• Handover: the stable record with explicit company, restricted, selected-user, or public visibility.
• Revision and artifact: immutable evidence governed by the parent record.

How do people and agents keep distinct identities?

Interactive people should authenticate with their own SSO identity, while unattended agents should use named, single-purpose service identities. The server should derive company membership, workspace grants, role, scopes, and authorship from the accepted credential rather than prompt text or caller-supplied fields. One shared agent token makes attribution and independent revocation impossible.

• Use one human identity per person and preserve their company role.
• Use one service identity per unattended agent, environment, and operational purpose.
• Grant the minimum workspaces and actions required by the workflow.
• Disable an identity before deleting it, then verify that reads and writes stop.

What should be searchable and writable?

Authorized actors should be able to search titles, summaries, artifact names, structured context, and assigned review across only the scopes they can read. Writes should create an attributable revision or collaboration event rather than mutating evidence in place. Search results must resolve to the canonical record and apply the same authorization checks as direct reads so an index cannot become a tenant side channel.

When should context be public or externally shared?

Context should become public or externally shared only through an explicit visibility change by an authorized owner. Public pages need a deliberate publication surface that excludes private annotations and unrelated company material. Restricted collaboration should grant a named person or group the minimum role required, and a mention should notify only actors who already have access.

How should a company pilot the knowledge base?

Pilot one workspace with two people and two separately authenticated agents. Import a small set of approved source files, publish one evidence-backed handover, add a human review finding, continue the work from a second agent, and then revoke that agent. The pilot passes only if every actor sees exactly the permitted records, authorship is correct, the review points to a correcting revision, and revocation removes access without deleting history.

• Retrieval test: each identity finds approved sources and no denied records.
• Write test: every revision records the authenticated author and exact artifacts.
• Review test: a finding remains open until a later revision resolves it.
• Boundary test: cross-company and ungranted workspace searches return nothing.
• Revocation test: the disabled agent immediately loses read and write access.
• Continuation test: a fresh actor completes one bounded next action without the original chat.

What is the minimum readiness checklist?

A production company knowledge layer is ready only when its sources, identities, boundaries, write model, review flow, search policy, retention controls, and recovery path are explicit and tested. Use the downloadable readiness checklist to record the design and a pass-or-blocked pilot result before expanding company-wide.