buddhiAIAgent memory
What your team's AI assistants learn becomes company memory only after a person approves it.
People on your team work with AI assistants all day: Claude, Cursor, a ChatGPT connector. Useful things come out of those conversations — a decision reached, how a bug was fixed, what a customer asked for — and then the chat ends and it is gone.
Agent memory keeps that knowledge without treating a chat as company truth.
How it works
An assistant proposes
When an assistant connected to Buddhi saves something, it is stored as a proposal, not as memory. Nobody can recall it and it does not appear in search.
A person reviews
The proposal appears in Governance → Agent Memory. The reviewer sees what the assistant wants to keep, which assistant and whose session it came from, how sure it is, and the evidence it gave.
Approve, edit or reject
Approving files it under a scope the reviewer chooses, as normal company memory. The reviewer can correct the wording first. Rejecting erases the proposed text.
Who can review
- The person the assistant was working for. It is their own work.
- Anyone who can write to the scope the assistant suggested.
- The workspace owner, for everything.
A reviewer can only file a proposal under a scope they could write to themselves. So an Employee cannot use a proposal to put something into Sales, or into Publishable.
An assistant can never approve anything. Approval needs a signed-in person.
What an assistant can and cannot do
| It can | It cannot |
|---|---|
| Propose a memory with a category, a confidence and its evidence | Write company memory directly |
| Suggest a scope its person can write to | Suggest the Publishable scope |
| See whether its proposals were approved or rejected | Approve or reject a proposal |
| Group what it proposes under a session id | Have a proposal recalled before approval |
Proposal categories: decision, fact, customer_feedback, process, task, lesson.
What approval does
Approving runs the same steps as adding a memory by hand: it is summarised and indexed, checked against existing memories for contradictions, and recorded in the audit log. The memory then carries where it came from:
- the assistant and the session that proposed it,
- the proposal it was approved from,
- the person who approved it.
That person is recorded as the author. They read it and vouched for it, so their standing is what counts if it contradicts something else.
What rejection does
The proposed text and its evidence are erased. Only the fact that something was proposed and declined is kept, with a fingerprint, so the same text proposed again is recognised.
Already known
If a proposal says much the same as an existing memory the assistant's person can read, the inbox says so. Reject it, or approve it if it adds something.
Trusted keys
The workspace owner can issue a key that writes without review. Its writes go straight into memory. Use it for a system you control that records things a person has already approved, and for nothing else. Every other key proposes.
In Gateway & Agents, a trusted key is labelled "writes without review".
Limits
- An assistant can have up to 100 proposals waiting, and 20 per session, so a chatty one cannot bury the inbox.
- Proposing the same text twice returns the first proposal.
- A revoked or expired key cannot propose.
For assistants and integrators
Over MCP, remember proposes automatically. submit_memory_candidate does the same with a category, confidence, evidence and session id, and list_memory_candidates shows what became of earlier proposals.
Over the Product API, POST /api/v1/memory-candidates proposes, and POST /api/v1/memories from an untrusted key returns 202 with status: "pending_review". See Write a memory.