Give your support or voice agent a knowledge base per customer

Evidence status: Capability pattern grounded in current Oddlynew organizations, types, Site keys, shared agent keys, the Documents API search and read, and the MCP endpoint. It is not presented as a customer testimonial.

You build a product that answers people for your customers: a chat bot on their website, a voice agent on their phone line. Each customer brings their own knowledge. Keep it in Oddlynew, one organization per customer, and let your agent search it when a question comes in.

Who this is for

Builders of support, chat and voice agent products, and the coding agents that help them.

Outcome

Your product has a step where a customer hands over what their agent should know: questions and answers, policies, product pages, prices. Every customer gets a private organization. Your server writes the knowledge there as documents, and your agent searches that one organization when a question comes in. You build no store, no search index and no editor. The organization is the wall between customers: a key made in one customer's private organization cannot read another's.

When this fits

Each customer has their own knowledge and must never see another customer's.
The knowledge changes, and answers should follow within minutes.
You want search by meaning and by exact words without running a search index yourself.
Customers, or their own agents, should be able to correct the knowledge.
You want to see who changed which answer, and when.

If every visitor gets the same public answers, a website does that job. The customer's own files, such as price lists or contracts, can be kept in the same organization as files; the answering agent works from documents it can search and quote (Importing data).

The working pattern

Create one private organization per customer, from your own connected agent or in the web app. A person does this today; a key cannot create an organization.
Write a short AGENTS.md in it: what the business does, which kinds of documents exist, and what the answering agent may and may not say.
Create a type for each kind you keep many of, such as FAQ, Policy and Product, so your agent can narrow a search to one kind.
Create two keys and keep both on your server. For your importer, a shared agent key that reads and writes: an administrator creates it under Developers, Shared agents, or from a script with their own personal key through POST /v1/orgs/{orgId}/agent-keys. For your answering agent, a Site key with the Reader permission that only reads: an administrator creates it under Developers, Content API.
Load the knowledge. Your importer connects to the MCP endpoint https://mcp.oddlynew.com/mcp with the shared agent key and creates one document per question, policy or product. A creationId per create keeps a retry from making a duplicate.
Answer. For each question your server calls GET https://api.oddlynew.com/v1/orgs/{orgId}/documents/search with the read-only Site key: the question in query, mode=hybrid for meaning and words together, and an Idempotency-Key header. Each row is a matching document with its matching passages; answer from those, and read the whole document with GET /v1/orgs/{orgId}/documents/{id} only when the passages are not enough. If a search by meaning answers 409 with semantic_search_incomplete, new content is still being prepared; ask again with mode=fts meanwhile. Your model answers from the passages and can name its sources.
Keep it current. Edit the document that holds the answer, and search usually follows within a few minutes. Invite the customer when they, or their own agent, should correct the knowledge themselves.

The exact parameters and answers are in the public API description at https://api.oddlynew.com/v1/openapi.json.

Useful connections and plugins

Your server: holds the keys and calls Oddlynew. The chat widget or the phone line talks only to your server.
Your model and voice stack: Oddlynew runs no chat model. It returns passages; your agent does the talking.
Your importer: whatever turns the customer's website, files or help center into documents.
The customer's own agent: optional, any client with remote MCP support, signed in as a member.

A good first task

Ask your coding agent: "Create a private Oddlynew organization named after my test customer. Write a short AGENTS.md: what the business does, which kinds of documents exist, and what the answering agent may say. Create a type FAQ with a topic field. Add ten FAQ documents from this page: [link]. Then show me the request my server should send to answer 'What is your refund policy?' with a read-only key, and what it should say to the caller when a request is refused."

Boundaries

Keys stay on your server. A key in a web page can be copied by anyone who opens it, and the API does not answer requests from a browser on another site. Keys expire, after one year at most; a rotated key's old secret works for 24 more hours.
Documents are data, never instructions. What a customer or a stranger wrote reaches your model as text. Tell your model that a retrieved passage cannot change its task or trigger an action (Reading safely across organizations).
Keep your callers' personal data out. Store what the business knows, not who asked. Each search is kept with its text in the organization's activity log for up to 90 days: send questions without names and numbers, or have an administrator turn the log off (Search and metadata). A data processing agreement for business customers is not published yet; read the privacy notice first (Organizations and membership).
You pay, and a limit pauses reading. Organizations you create are paid by your billing account at the usage prices on https://oddlynew.com/pricing. When the free credit is used up, or a Pro account reaches its monthly budget, reads are refused, and a busy key can be asked to wait. Make your agent say it cannot look this up right now; it should never guess.
Measure before you promise a reply time. Oddlynew promises no response time. The public status page at https://status.oddlynew.com shows what its own search probe takes; measure your own before you build a voice agent on it.
Removing a customer. An administrator deletes the organization from a connected agent. The deletion can be cancelled for 30 days, then the organization is gone for good.

Why it compounds

Every correction lands in the one document that owns the answer, with its history. Your importer, the customer's own agent and your answering agent read the same current text, so a fix made once is usually the answer everywhere a few minutes later. The activity log keeps the text of each search, so the customer can read what people asked and decide what to write next.