Skip to main content
A good support answer needs two things at once: what the help center says, and what has already happened with this customer. This cookbook keeps the help center in one shared collection and each customer’s history in their own, then queries both together. Triage, billing, and technical agents all read the same context.

Prerequisites

  • A HydraDB API key from dashboard.hydradb.com, set as HYDRADB_API_KEY.
  • An OpenAI API key, set as OPENAI_API_KEY. HydraDB returns context, not answers, so any model works; swap the answer function below for your own.
  • Python 3.10 or later, with the SDKs: pip install "hydradb-sdk>=2.1.7,<3" openai.
Save this as hydra.py. Every cookbook imports it. It holds what every HydraDB application does around its own logic: wait for the database, check what an ingest accepted, wait for indexing, and pass query results to a model.
hydra.py

1. Create a database with a shared collection

support.py

2. Upload the help center

Upload help articles as files. Give each a stable id so that publishing a new version replaces the old one.
support.py

3. Remember each conversation

When a conversation ends, save it as a memory in that customer’s collection. With infer: true, HydraDB extracts what matters: the customer’s plan, what they asked for, what they were told.
support.py

4. Answer from both collections

Name both collections and set type: "all". The query reads this customer’s memories and the shared help center, and nothing else. Take customer_id from the authenticated session, never from the message: the collection name is what keeps one customer’s history out of another’s answers.
support.py

Run it

The billing answer should combine both sources: the refund was requested on September 30 and is waiting on the billing cycle, and annual plans are refunded pro rata.

Use real data

Sync the public help center into the shared collection with a connector. Put only public content there: every customer’s query reads that collection, and it is not filtered by acl. A customer’s past tickets are private, so ingest each one into that customer’s collection as a ticket app source. Keep step 3 in your application, called when a conversation closes. If each of your customers is a company with its own private knowledge, give each company its own database. See Databases and Collections.

Common mistakes

  • Saving customer memories or tickets in the shared collection: every customer’s query then reads every other customer’s history.
  • Using collection with one name: the query then misses either the help center or the customer. Use collections with both.
  • Querying a customer with no history: every collection named in collections must exist, and a collection is created by its first write. For a new customer, query the help center alone.
  • Building the collection name from user input: derive it from the session’s customer ID on your server.

Next steps