Key Takeaway
- Useful agent memory needs both a working MCP connection and a deliberate save-and-retrieve routine.
- Keep small, single-client notes in Markdown when that is enough; use a shared store when growing records or multiple clients need permissioned access.
Dnotitia’s AKB (Agent Knowledge Base) makes project knowledge available to coding agents through MCP. A new terminal does not necessarily erase local history, but another client may not have that history. The workflow below shows how to save a useful decision and retrieve the same record in a later session.
Connect and test in four steps
- Choose your server and access scope. Use your running AKB deployment, your own account, and a vault you are authorized to use. A public demo is not a private production workspace. Connecting to the same server does not give colleagues access to one another’s private memory.
- Add AKB to the client. Follow the official installation and client setup instructions for your client. Where the setup requires an endpoint and Personal Access Token, use your deployment’s endpoint and your own token; never commit tokens to a repository or include them in shared screenshots.
- Save one useful decision. Ask the agent to create a short note in the permitted vault with a project, decision, reason, source reference, and next step. The illustrative note below is a starting point.
- Retrieve the record in a fresh session. Ask the agent to find that decision and show the saved record’s location and relevant text. Confirm it retrieved the record, rather than accepting a conversational claim that it remembers.
An illustrative coding-session note
- Project: Webhook delivery
- Decision: Keep retries in the existing worker instead of adding a second queue.
- Reason: Avoid an additional recovery path during the initial release.
- Source: The project’s design note and, in this example,
services/webhooks/RetryPolicy.ts. - Next step: Add a metric for exhausted retries.
Later, a question such as “Why are webhook retries handled in the worker?” can use hybrid semantic and keyword retrieval through akb_search. For a known identifier such as RetryPolicy, use literal lookup through akb_grep. Use akb_drill_down to list headings or read a matching section, and akb_get to retrieve a known record.
When the decision changes, update the note, reason, and source reference. Document revisions and diffs help reviewers see what changed without treating an old decision as the current instruction.
Session capture is a separate integration
AKB’s optional akb-sessions plugin turns session material into structured notes such as decisions, learnings, tasks, and reports. The note should preserve useful project knowledge rather than every conversational detail.
Automatic behavior at session events depends on client-specific lifecycle integrations, such as the optional akb-claude-code plugin. See the plugin documentation; an MCP connection alone does not automatically archive every conversation.
When local notes are enough
Markdown files and local history can be simpler for a small project using one client. A shared store becomes useful when multiple clients need the same permitted records, or growing notes need hybrid search, exact lookup, and document history.
FAQ
Does connecting the MCP server capture every session?
No. Connection provides access to tools; saving a decision or configuring a capture integration is a separate step.
Why can the agent connect but fail to find a note?
First check that it is using the expected identity and vault and that the record was actually saved. Try the known record location or an exact identifier before broadening the search; a search miss alone does not prove the record is absent.
Next step
Start with one permitted vault and one decision. Follow the official client setup, save the note, and retrieve it in a fresh session before expanding the workflow to more projects or tools.