Your AI Coworker's Knowledge Base Needs an Editor, Not Just More Documents

An AI Coworker Knowledge Base Is a Publishing System

On October 14, Microsoft introduced a SharePoint team knowledge-base preview: Copilot and other AI coworkers can help create, contribute to, curate, and use interconnected markdown files assembled from a team's content. That sounds like the end of the familiar problem of searching five folders for the answer to one customer question. It is also the beginning of a less familiar problem: who decided that the answer in those folders was true?

The announcement describes a practical shift. A knowledge base is no longer merely a place where people look things up. It can become the shared context from which AI coworkers answer questions and prepare work. Microsoft says the feature is rolling out to Frontier preview tenants, not that every business can use every proposed integration today. Its internal testing found faster, more token-efficient retrieval, but those results are not proof that any particular company's answers are accurate or authorized.

A folder can contain an outdated contract, a sales draft, a corrected policy, and a customer's exception request. A system that compiles them into one clean-looking answer may improve retrieval while obscuring the disagreement. Better access to information is not the same as an approved interpretation of it. When that interpretation is reused across roles, a small source error becomes an operating rule.

This is why an AI coworker knowledge base needs an editor. Not necessarily someone who approves each harmless sentence, but a named person who owns the status of consequential claims. A team needs a way to distinguish a proposed fact from an approved one, retain the source and date, correct it, and withdraw it everywhere it appears. Otherwise a more efficient knowledge base simply makes mistakes easier to repeat.

The Hard Part Is Deciding What Becomes Shared Knowledge

A search result is evidence to inspect. A curated knowledge entry makes a stronger promise: this is information the team can rely on again. Treating the two as interchangeable is especially risky when an AI coworker drafts a customer reply, checks a contract term, or recommends an operational decision.

Imagine an account folder containing three documents. The current signed agreement gives a customer a 30-day notice period. An old template says 60 days. A sales recap says the customer asked for 15, but nobody accepted that request. A simple summary might report any of those numbers with great confidence. A useful knowledge entry says: “For this account, the signed agreement dated September 3 specifies 30 days; the 60-day template is superseded; the 15-day request was not incorporated. Verify amendments before issuing notice.” It cites the agreement, names its owner, and records when the conclusion was last checked.

The same distinction applies to less formal work. A service team may have a workaround in a chat thread, a tested procedure in the handbook, and a newer message saying the workaround broke after an update. If the knowledge base promotes the chat thread without status, it can turn a one-off fix into routine advice. The error is not that the AI coworker cannot read; it is that the organization has not defined which source has authority.

What a useful knowledge entry contains

For operationally important knowledge, record six fields alongside the plain-language answer:

• Claim: One specific statement the team will reuse, not a sprawling summary of an entire folder.
• Source and version: A link or stable reference to the document, record, or decision that supports it, including the date and applicable account or process.
• Owner: A person or accountable team that can resolve a challenge to the claim.
• Status: Draft, approved, disputed, superseded, or retired. Do not let a draft masquerade as policy.
• Scope and access: Which role, customer, location, or time period the claim applies to, and who may retrieve it.
• Review trigger: A date or event—new contract, policy revision, product release, customer exception—that forces revalidation.

These fields are not bureaucratic decoration. They prevent the most common shortcut: storing a plausible sentence with no way to tell where it came from or whether it still applies. A claim without provenance should be usable as a lead for research, not as decision-grade context. Where the source itself is sensitive, the reference and access policy must not disclose it to a role that cannot open it.

This differs from simply giving an AI coworker durable memory. The distinction between session context and governed memory matters, but shared knowledge adds a second layer of responsibility. An individual role's working notes can be incomplete and provisional. A team-wide knowledge entry may shape many roles' decisions. Promotion from one to the other must be an explicit process, not an automatic side effect of ingestion.

What Good and Bad Knowledge Curation Look Like

Consider a small service business with separate sales and operations roles. Both need information about delivery commitments, but they need different authority. Sales can draft a proposal; operations confirms staffing and dates. A customer email saying “Friday would be ideal” is a request, not a committed delivery date.

Bad: The AI coworker imports emails, proposals, schedules, and meeting notes into one shared index. It writes “Delivery on Friday” into a summarized account page because that phrase appears frequently. Sales quotes Friday to a new customer. Operations plans around it. No one can identify which document established the date or whether an employee actually approved it. The index is technically current and operationally wrong.

Good: The account entry records “Friday requested; delivery not confirmed,” links the customer's message, and marks the commitment field pending operations approval. Once the operations lead approves a dated schedule, that record becomes the authoritative source. The old tentative claim is superseded rather than silently overwritten. Sales can see the approved commitment; unrelated customer records remain outside its retrieval scope.

Notice that the good version still permits the AI coworker to help. It can assemble the evidence, flag a conflict, draft a question to operations, and update the proposal after a human decision. The boundary is not “AI must never write knowledge.” It is “AI may propose and organize; designated owners approve consequential shared claims.” This is seam design in practice: automate collection and comparison, keep the ambiguous business commitment with the accountable human, then allow the coworker to continue.

A second example makes the correction problem clearer. Suppose a finance procedure says invoice reminders go out after seven days, but the owner changes the policy to ten. If the old guidance survives in a compiled summary, a new policy document alone will not fix the workflow. The team must locate derived entries, cached answers, scheduled work, and any role instructions that still rely on seven days. A correction needs a propagation path, not just an edit button.

Microsoft's announcement emphasizes turning scattered content into an organized knowledge base and describes future automated curation as a roadmap item. Its SharePoint guidance on monitoring AI coworker access is a useful complement: knowing which roles reached which content helps investigate exposure. But access logs do not, by themselves, establish that a derived claim was correct, approved, or retired. Content governance and access governance must work together.

Build a Small Knowledge Base You Can Actually Correct

Start with one recurring decision, not every file your company owns. Pick a task where inaccurate shared context is costly but a reviewer can verify the source. Customer commitments, approved product descriptions, or escalation rules are better starting points than a giant “everything we know” import.

1. Define the decision. Write down what the AI coworker will do with the answer. “Find the approved refund rule for this customer” is testable; “know the business” is not. Decide whether the output is informational, a draft, or something that can trigger an external action.
2. Name the source of authority. Rank signed agreements, current policy, approved records, and informal notes for this use case. A Slack message may explain a decision without replacing the signed document. Record how exceptions are approved.
3. Assign a knowledge owner. Give one person authority to approve, dispute, and retire consequential entries. An approval is a business decision, not a reward for a fluent summary. Set a backup owner for absences.
4. Separate proposal from publication. Let the AI coworker gather citations and propose a claim. Publish to the shared knowledge base only after the owner checks the underlying evidence. Low-risk entries can use lighter review; commitments, financial instructions, and sensitive account details deserve stricter review.
5. Test conflicting evidence. Seed a stale policy, a customer request, and a current approved record. Ask the coworker for an answer. The correct behavior is to cite the applicable source, mark unresolved conflict, and escalate when authority is unclear—not to blend three documents into a new rule.
6. Test a correction end to end. Change an approved fact in a controlled example. Check the source entry, derived summaries, retrieval results, draft templates, and any scheduled work. Make sure an old answer cannot reappear as if still approved.
7. Set expiry and a review rhythm. A price, service term, staffing contact, or regulatory procedure may change on different clocks. Review on relevant events and periodically sample answers against source documents. Measure unresolved disputes, stale entries, and correction time—not just how fast a question gets answered.

Keep an audit trail of who proposed, approved, changed, and used important entries. Where sensitive material is involved, enforce the underlying source permissions and test retrieval as each role; a shared index must not turn a private file into general team knowledge. If a claim cannot be shared across roles, create an appropriately scoped entry or leave it in the source system rather than copying it into a universal page.

This is a practical form of intent engineering. The system needs to know not only which documents exist, but what the organization meant by an approval, an exception, and an unresolved question. A policy that says “be accurate” cannot resolve an old agreement against a new one. A typed status, a named owner, and a retrieval boundary can.

It is also a portability test. If the business changes model providers or moves its AI coworkers to another agent server, can it export the knowledge entries with their sources, ownership, status, and correction history? A plain markdown answer without that metadata is easy to move but hard to trust. A governed knowledge base is an asset only if the organization can inspect and maintain it independently of one conversation interface.

FAQ

Q: What is an AI coworker knowledge base? A: It is a curated set of reusable business knowledge that AI coworkers can retrieve while doing work. Unlike a raw document search index, it should preserve source references, ownership, status, scope, and a way to correct or retire claims.

Q: Can an AI coworker update the knowledge base automatically? A: It can propose updates and organize evidence. Consequential shared claims should pass a review appropriate to their risk before they become authoritative. Low-risk formatting and categorization need less oversight than a customer commitment or payment instruction.

Q: Isn't a citation enough to make an answer trustworthy? A: No. A citation can point to an obsolete template or a request that was never approved. Check source authority, version, scope, and whether a newer decision supersedes it. A valid link proves where a statement came from, not that the business adopted it.

Q: How is a shared knowledge base different from AI memory? A: Memory can include a role's working context and past interactions. A shared knowledge base is a curated source for multiple people or roles to rely on. Promoting a personal note into shared authority requires an explicit decision and access review.

Q: What should a small business measure first? A: Sample answers against authoritative sources; track disputed and stale claims, the time to propagate corrections, and whether each role sees only permitted material. Speed and retrieval cost matter, but not before correctness and scope.

An AI coworker can turn scattered evidence into useful shared context, but someone still has to decide what the business will stand behind. If you're ready to build a team with governed knowledge, clear roles, and human decision boundaries, explore Associates AI Teammates and choose a plan.