Private knowledgefor AI agentswith source boundaries.

Private source context

Use the console when saved notes and documents should ground a task.

MCP Tool Access

Connect files, browser state, APIs, and services through explicit tool boundaries.

Agent skills

Turn good knowledge use into a repeatable workflow with checks.

Latest LLM routes

Choose the model route that should read, reason, or review the material.

Why private knowledge matters for AI agents

Most failed agent memory feels too magical from the outside. The assistant claims it remembers, but the user cannot tell which document was used, which preference was saved, whether a fact is stale, or how to correct a bad assumption. A private knowledge layer should make those details ordinary and inspectable.

The practical job is not to give the model more text. It is to decide what the agent is allowed to know, how that knowledge is labeled, how retrieval happens, and what evidence returns with the answer. For Coachix, the Knowledge hub is the operating layer between a blank chatbot and a private assistant that can use your material responsibly.

This is why private knowledge for AI agents belongs next to philosophy, MCP tools, skills, and model routing. Knowledge tells the assistant what context it may use. Philosophy tells it how to judge uncertainty. MCP tools tell it how to act. Skills tell it how to repeat the work. Model routing decides which system should read, draft, or review.

What belongs in the knowledge vault

Start with source material that changes future output in a concrete way: product notes, operating rules, research summaries, customer language, coding conventions, release checklists, evaluation examples, and decisions that explain why a workflow changed. Each item should have an owner, a freshness expectation, and a reason it deserves recall.

Separate durable knowledge from working memory. A conversation can hold temporary details such as the current task, open tabs, pending files, or a draft structure. The long-term vault should keep facts and lessons that remain useful after the session ends. Mixing the two creates memory clutter and makes the assistant less predictable over time.

Treat corrections as first-class knowledge. When a user rejects an answer because the source was weak, the tone was wrong, or the tool boundary was unsafe, the correction is often more valuable than the original task. Save the reviewed lesson with the task type and the condition where it applies.

How retrieval should behave

A good retrieval result is not just a hidden prompt injection into the model context. It should return the source title, the relevant passage or summary, the date or version, the confidence boundary, and the reason the result matched. When the user can inspect the retrieval path, they can improve the vault instead of arguing with the assistant.

Use different retrieval shapes for different questions. Exact lookup works for policies and price rules. Semantic search works for exploratory questions. Graph traversal works when the answer depends on relationships between people, projects, entities, decisions, and outcomes. Recent session state works when the user is still inside the same task.

The assistant should also know when not to retrieve. If a question asks for current public facts, the model may need fresh sources. If the request touches a private account, it may need permission. If the answer would change a file, send a message, spend money, or publish something, knowledge should prepare the decision, not silently authorize the action.

How to keep knowledge trustworthy

Private knowledge is a trust system. Every saved item should answer five questions: who owns it, where it came from, when it was last valid, what job it supports, and when it should be ignored. Without those answers, memory can become a quiet source of confident mistakes.

Plan for memory poisoning and stale context. Agents can absorb wrong instructions from compromised pages, messy documents, pasted chats, or old project notes. Keep ingestion reviewable, separate trusted sources from untrusted imports, and require stronger checks before retrieved memory influences high-stakes work.

The healthiest vault is editable by humans. Users should be able to add a source, rename it, mark it stale, delete it, or save a correction after a run. That turns memory into a living workspace rather than a black box attached to a model.

Citation before confidence

The assistant should be able to show which saved source shaped a claim. If the answer cannot name a source, it should say it is reasoning generally or ask for the missing material.

Freshness window

Attach a freshness expectation to volatile facts such as model pricing, product limits, policies, rankings, or deployment state. Old knowledge should trigger a recheck rather than flow into the answer unchanged.

Permission scope

Private knowledge should remain scoped by user, workspace, tenant, project, and task. A useful recall from one context can be a privacy failure in another.

Source trust labels

Separate owned notes, official docs, third-party pages, community reports, generated drafts, and untrusted imports. The model should not treat all retrieved text as equally authoritative.

Correction loop

When a user fixes the answer, save the lesson only after the correction is clear. Good memory turns feedback into a narrow rule, example, or source update.

Action boundary

Retrieved knowledge can inform a plan, but it should not automatically grant permission to send, delete, deploy, purchase, change settings, or expose private data.