Skip to main content

Overview

An agent can look things up in your documents while it talks. There are two sources. An agent uses one of them. Setting both on one agent returns 422 KNOWLEDGE_SOURCE_CONFLICT. Pick one.

Why it adds no delay to a reply

A search takes longer than a turn, so no reply ever waits for one. 60db searches in the background: once at the start with the agent’s script, then on the caller’s words while they are still talking. A reply reads the newest result that has already arrived, from memory, with no network call.
  • A slow or failing source never delays or fails a call. A failed or timed-out current search clears its passages, so the next reply does not reuse notes from an older question.
  • The first reply after a sudden change of topic can use the previous topic’s passages. The new ones arrive a moment later and are used from the reply after.
See also Agents, Memory, Bring your own SIP and Move from LiveKit or Pipecat.

A. Use a Smart Memory collection

1

Create a workspace collection

POST /memory/collections with kind: "knowledge". Owner or admin only. See Collections
2

Ingest your documents

POST /memory/ingest with type: "knowledge" and the collection. Type knowledge is admin or owner only. See Ingest. To read files first, use Extract document
3

Attach the collection to the agent

Set knowledge_collection_id to the collection’s UUID (the hash_id that List collections returns) on Create agent or Update agent
4

Verify with a test call

Open the agent, choose Test call, Talk in browser, and ask about something only your documents cover

Rules and errors

Send knowledge_collection_id: null to detach.

B. A knowledge base on your own server

If the documents live on your machine, the agent asks your server for them during the call. Nothing is copied to 60db. Set knowledge_webhook_url on the agent and run one HTTP endpoint. There is no separate secret field. Requests are signed with the agent’s existing whsec_... webhook secret, the same one that signs tool calls and call events. It is shown when the agent is created and when you rotate it. One verifier serves tools, events and knowledge. 60db calls your endpoint itself. Your URL is re-checked for safety on every call, so a URL that later resolves to a private address is refused.

What your endpoint receives

  • query is the caller’s latest words, at most 240 characters.
  • max_results is 4.

What it answers

Status 200 and:
Each passage is a string or { "text": "..." }. At most 4 are used. Answer with whole paragraphs, about 2,000 characters each at most. Any other status, a body that is not this shape, or an answer over 256 KB counts as a failed search and returns no passages.

Limits

Verify the signature

The signature is v1= followed by the hex HMAC-SHA256, keyed with the agent’s whsec_... secret, of {timestamp}.{raw request body}. Use the raw bytes of the body, not re-serialised JSON. Reject a timestamp more than a few minutes old, which stops a captured request being replayed.
The samples show the structure and have not been run against a live 60db agent. Put them behind HTTPS with a valid certificate; the platform refuses plain http.

What 60db does with the text

Your text goes into the model’s prompt as reference data, never as instructions. Angle brackets are removed, long passages are cut, and the block is framed so the model does not follow anything written inside it. Keep your own documents clean anyway. Text copied from web pages or customer messages can try to steer a model (prompt injection), and the framing reduces that risk but cannot remove it.

What is billed

  • Collection searches are billed as Memory searches ($0.0003 per query), from your AI credits. Ingesting is billed per character. See Memory pricing.
  • Webhook searches are not billed by 60db. Your own infrastructure costs are yours.

Where it applies

  • Phone calls (inbound and outbound) use the agent’s knowledge source.
  • Stream calls started from an agent use the agent’s knowledge source, searched the same way. A stream call placed with an inline agent definition takes knowledge_webhook_url or knowledge_collection_id in that definition, never both.
  • Web (browser) calls started from an agent use the agent’s saved knowledge source. Per-call overrides on web calls do not include knowledge fields: change the agent instead.

Checklist

  • Exactly one of knowledge_collection_id or knowledge_webhook_url is set.
  • Collection: documents ingested as type: "knowledge", and the collection is a workspace one.
  • Webhook: answers within a second or so, over HTTPS with a valid certificate.
  • Webhook: signature and timestamp checked with the agent’s whsec_... secret.
  • A test call answers something only your documents cover.
  • Your logs show about one search per turn. 150 per call is a ceiling, not a target.