Agent Knowledge Base: What to Include and Keep Current

To build an agent knowledge base, separate authoritative source documents from current project facts and rules, then define how the assistant reads and checks each part. Start with one real task and save only what would change the assistant's next action. A useful record explains what is known, who approved it, and what still needs verification.

An agent is an AI assistant that can use tools to carry out work. Tools like fenbs give connected assistants a structured record of tasks, Decisions and rules, context notes, and progress. That record can point to your source documents without pretending to be a document search engine or making every statement in those documents an instruction.

How do you build a useful first version?

1. Choose one job. For example, prepare a product comparison from approved specifications. Write what a successful answer must establish and which actions still need a person.
2. Identify authoritative sources. Record the document location, relevant section, version or effective date, and the person responsible for checking it. Keep the original in its established system.
3. Write the current project facts separately. Include the goal, agreed scope, relevant terminology, current task state, and unresolved questions. Avoid copying the entire conversation.
4. Record human-approved rules. Say who decided, what the rule applies to, and when the assistant must stop and ask. Leave proposals visibly unresolved.
5. Tell the assistant what to read first and how to retrieve the supporting material it needs. A saved link does not mean the assistant can open it.
6. Try a fresh-session test. Ask the assistant to explain the next action, cite its basis, and identify missing evidence before letting it continue the task.

Keep the first version small enough for you to review. Anthropic's guide to building effective agents↗ (opens in a new tab) recommends starting with a simple solution and adding complexity when the work requires it. A custom storage system is unnecessary if a readable, maintained project record already solves the problem.

What belongs in sources, project facts, and rules?

The same sentence can belong to different layers depending on its status. A draft saying to replace a component is evidence of a suggestion. It becomes a project decision when an authorized person approves the change. Preserve that difference instead of letting the assistant treat confident wording as authority.

This is also why a knowledge base differs from the broader subject of agent memory. Here, the focus is the material the assistant should consult and trust for a task. Conversation history and learned preferences raise other questions. For the wider category, see our AI knowledge base guide.

Which instructions should the assistant trust?

Write a clear boundary between instructions and reference material. A downloaded document, support ticket, or customer email can contain requests that conflict with the project rules. Tell the assistant to treat those contents as material to inspect, not permission to change its own operating instructions or take unrelated action.

Keep permissions in the connected systems as well. If an assistant should read only one project, do not give its connection wider access simply because the starting prompt says to be careful. Removing access from a source should also prevent that source from entering future answers through a copied or indexed version.

Microsoft's RAG documentation↗ (opens in a new tab) identifies authorized retrieval as a separate requirement from finding relevant results. RAG means finding selected source material before generating an answer. A relevant result can still be inappropriate for a particular person or task.

Keep the human-approved boundaries in fenbs Decisions and rules so connected assistants can read them before beginning the work.

How do you keep changing knowledge current?

Give each important note a clear scope and a review trigger. A product requirement may need review when the specification changes; a task summary needs review when the task moves forward. Use dates to explain when something was checked, not as decoration that makes an unchecked statement look current.

• When a source changes, check which notes or decisions depended on the old version.
• When a decision changes, preserve the earlier choice as history and make the current one explicit.
• When work stops, record what was completed, what was actually checked, and the next action.
• When ownership changes, name who will maintain the record rather than assuming the next assistant will notice.

If you cannot verify a fact, label the uncertainty and identify the evidence needed. Do not delete an inconvenient exception just to shorten the starting context. fenbs keeps reviewed notes and task progress with the work, so the next connected assistant has a clear place to begin; see How it works.

How can you tell whether the knowledge base works?

Test the questions that expose confusion. Ask for a current fact, an exception in a source, a choice awaiting approval, and an answer the available evidence cannot support. The assistant should distinguish all four. A fluent answer to an easy question does not test those boundaries.

Try a deliberate update as well. Replace an approved project choice, then start a fresh session and check that the assistant identifies the current decision and its reason. Next, remove access to a test source and verify that the assistant reports the missing evidence instead of relying on a stale copy.

Record each failure where it happened: the source could not be opened, the current note was missing, or the assistant ignored a supplied exception. Our guide to building agent memory addresses storage and retrieval design when that is the cause. Fix the observed gap before adding more material.

How to do this with fenbs

1. Create a free account, free for one person with no credit card, and add the project you want an assistant to continue.
2. Add current tasks and a short context note explaining the goal, source locations, and open questions. Put shared terms in the Glossary when their meanings affect the work.
3. Record the rules a person has approved in Decisions and rules. Include the reason and scope; assistants can record a person's decision but cannot decide or sign off.
4. Connect a supported AI app through the integration guide. MCP is a standard way for an AI app to use an outside tool, with browser sign-in for the connection.
5. Ask the assistant to read the project context and explain its next step. Before it stops, have it save task progress and Where we left off, including any evidence still needed.

fenbs is not the right fit for automatically indexing a document library or adding vector search, which finds material through numerical representations of meaning. It does not host a model. Use it for the approved work record, with separate source access when the task requires documents.

When should you add a more complex system?

Add retrieval infrastructure when finding relevant material across the collection has become a demonstrated problem. Add automated checks when the same failure is costly and repeatable. Neither change removes the need for ownership, current decisions, and a test that catches an answer based on the wrong source.

If you are still deciding how the assistant itself should operate, start with building an AI agent. For this knowledge base, the first milestone is smaller: another session can find the approved instructions, open the needed evidence, and name the unfinished action. The context engineering hub covers adjacent ways to improve that starting point.