Skip to main content

Pinecone

Agentheya calls Pinecone’s REST API directly (no SDK). For every chat turn the runtime:
  1. Embeds the user query with the embedding provider you configured.
  2. Sends POST https://<your-host>/query with the vector + your topK + optional filter.
  3. Maps the resulting matches into the agent’s retrieval context to ground its answer.

Connection settings

Embedding settings

Pinecone does not embed on its own — you supply a query vector with each POST /query. Agentheya needs the same embedding provider + model your data was indexed with, plus an API key.

Common shapes

Standard 1536-D OpenAI setup:
Multi-tenant namespace + filter:

“Test connection” button

Hits POST https://<host>/describe_index_stats first. If credentials work, the editor runs a one-shot embedding round-trip (when embedding fields are filled in) so a dimension mismatch is caught immediately. Both halves of the result are surfaced inline; either passing is enough to write the connection, but you usually want both.

Gotchas

  • Wrong host: Pinecone returns 404 if the host is right but the index name is wrong, and ENOTFOUND / connection refused if the host itself is wrong. The “Test connection” button surfaces the raw error.
  • Dimension mismatch: querying a 1536-D index with text-embedding-3-large (3072-D) returns a 400 from Pinecone. Setting embedding_dimensions makes Agentheya fail-fast before the request, with a clearer error.
  • Filter syntax: Pinecone uses MongoDB-flavored filter language ($and, $or, $eq, $in, …). Mistakes here surface at chat time, not save time — test with the dashboard editor’s connection check.
  • Subscriber scoping: if you store per-tenant content in one index, use filter to scope. Agentheya does not automatically inject power_user_id into Pinecone queries today.