Docs
Memory
Memory is what camada knows about your setup, kept per project, so you stop explaining the same thing twice. It is a list of plain facts, and none of them is hidden from you: every one is on the Memory page in the app, where anyone in the organization can read them and members and admins can add, edit and delete them.
What a fact is
| Field | Meaning |
|---|---|
| kind | One of preference, infrastructure, decision, contact or note. |
| text | The fact itself, up to 500 characters. Write it the way you would tell a colleague. |
| source | user when you typed it, agent when the chat agent stored it, system when camada wrote it for you. |
| author | The person who wrote it, for a fact with source user. |
| entity | Optional. An IP, CIDR, ASN, path or country the fact is about, so it can be matched to traffic. |
| created | When it was written. Editing a fact updates it in place and re-indexes it. |
| expires | Optional. After it passes, the fact stops being used and stops being sent to the analyst. |
The database row is the source of truth. When the agent stores one during a conversation you see it at once as "remembered: …", with an Undo that deletes it.
Facts camada writes for you
Adding an allow-list entry writes an infrastructure fact from the reason you gave — "Allow-listed asn 12345: our SEO crawler" — because that reason is exactly the kind of thing the analyst should know. Removing the entry retires the fact: it stops being sent to the analyst and stops appearing in search, rather than being silently rewritten behind you.
How facts are indexed
Every fact, every conversation summary and every run report summary is embedded with Cloudflare Workers AI (@cf/baai/bge-m3) into a Cloudflare Vectorize index, tagged with the project and the kind. Every query is filtered by project id, so a search can only ever return this project's rows. The embeddings are an index, not the store: delete the fact and its vector goes with it.
Summaries camada writes into the index
Besides your facts, camada writes short model-written summaries into the same index: one per conversation, so the agent can recall what you discussed before, and one per analysis run report. They are searchable on the Memory page and included in the export, so you can always read what was written. They are not facts: they are never pushed to the analyst, and they go when the conversation or the project goes.
How facts reach the investigation agent
This is the part that pays for itself. After every change, camada pushes the project's live facts — up to 200 facts that have not expired, as a full replacement — to the analyst that investigates your traffic.
- While investigating an entity, the analyst can call
get_tenant_context, which returns up to 20 of your facts: the ones that match the entity first (an IP inside one of your CIDRs, the same ASN, a path prefix, the same country), then general ones. - A fact it used is quoted in the verdict's evidence as
context: <the fact>, so you can see which piece of your own knowledge changed the answer. - "Our SEO crawler runs from ASN 12345" stops being a false positive on every run that reads it, instead of being re-litigated each time.
- Facts are handed to that agent as delimited customer data, never as instructions — a fact cannot rewrite how the analyst reasons.
Export, retention and deletion
- Export: the Memory page hands you the whole project's memory as JSON — the facts and the indexed documents — with one button.
- Transcripts are separate. Chat conversations are stored in their own tables, apart from memory and apart from your analysis data, under their own retention: an organization setting between 7 and 365 days, 90 days by default. Conversations older than that are deleted; memory is untouched.
- Deletion: deleting the project deletes its facts, its vectors and its transcripts.
What the agent can read and change, and what is sent to the model, is on the chat page; retention of everything else is on the security page.