Hi there!
I read all about the new Pinecone integration! It seems awesome that you can create context-aware AI agents right from the Glide frontend, does anyone already uses it and how?
I am eager to learn some example cases. 2025 is all about 2025 agents but we struggle to find real use cases for our marketing agency.
Thank you, looking forward to your awesome creations!
Here’s one from @eltintero .
And I just added voice to text and text to voice with eleven labs yesterday! Updates video coming soon
That’s interesting, watched it! What I would love is that Glide would add an integrated AI agent in Glide so that you can chat with ALL your data in Glide. Something like the Notion AI Agent.
Going to add this as a feature request!
I am using the integration to upsert profiles into an index and then compare them for similarity, I can do a deeper dive when I get through the fully implemented end result. One important limitation of the Glide integration is lack of support for metadata. (of course if I’m wrong about this please correct me). This requires that I use make.com integrations instead of Glide’s native implementation, because metadata cannot be included in the text-based index body. I would love Glide to enable metadata support!
Metadata is important for pre-filtering results when querying the index for vector similarity, in such a case where you don’t want to return results that are obviously not what the user wanted. For example, we would want to use pre-filter to restrict similarity results to metadata that fits preferences stored in the profile. If a user is looking for a specific set of circumstances when comparing values, the end resulting similarity should fall within the confines of those preferences.
Note I am using indexes and not document search or assistant (yet).
An update: Upon further investigation, make.com pinecone modules are pre-configured for storing vectors, not actually performing the embeddings, which means you need to select an embedding API (a model) in addition to storing the vectors. That means that the vectors themselves can be queried in a make scenario, but that embedding is managed separately which complicates the workflow compared to Glide’s integration. I filed a feature request for metadata support here:
Another quick update…
I am running across a situation where vector matching is not returning as accurate scores as I’d like, so I am working on making the matching return higher confidence results. Currently my index and my query are returning about 60% vector match scores on average, based on a split of index and query.
Some side notes about my use case: I store attributes about an object and index those (upsert them) into pinecone, using a contextually written template column with the values inserted as text. I then write a contextual prompt with “preferences” that I am attempting to retrieve from the existing indexes as a query, wherein indexes with matching attributes should return a high confidence match based on the preferences in the query.
One way to optimize this is to use higher dimensionality for vectors, wherein I attempt to use a larger embedding model that may be able to better understand the semantic context I am providing. However, changing to use the text-3-embedding-large model breaks the Glide integration because the integration limits you to only being able to work with 1536 dimensions on a small embedding model, and a larger one uses 3072.
So in short, there are some limitations to doing vector matching with indexes through the Pinecone integration, but it may be good enough for some use cases. I am finding it somewhat limiting for mine, so would be cool to see more use cases shared in webinarts for Experts and other posts here in the community.
Hey c0bbler, thanks for the updates on this, I’m currently building an app that’ll let users upload an image as a way to search similar products in my database and concerned the results might not be good enough. Wondering if you’ve tried the below approach from OpenAI’s docs? If so, has it helped?
Both of our new embedding models were trained with a technique that allows developers to trade-off performance and cost of using embeddings. Specifically, developers can shorten embeddings (i.e. remove some numbers from the end of the sequence) without the embedding losing its concept-representing properties by passing in the
dimensionsAPI parameter. For example, on the MTEB benchmark, atext-embedding-3-largeembedding can be shortened to a size of 256 while still outperforming an unshortenedtext-embedding-ada-002embedding with a size of 1536. You can read more about how changing the dimensions impacts performance in our embeddings v3 launch blog post.
For the purposes of the Glide integration, my findings were that the index has to be configured to exactly 1532 or won’t work. (eg., I tried to adjust the index settings to use different values and Glide simply refuses to upsert data).
If I wanted to interact with Pinecone directly and only use Glide, my take on the OpenAI documentation is that you don’t have the configuration capabilities even in the custom index settings within Pinecone to make this work. I believe you’d have to use something like Make.com or another intermediary to tune this dimensions parameter in the manner described. With Pinecone indexes you simply choose a model and dimensions, but unless you can provide more “instructions” to the model to use this approach over API (you can’t via Glide to my knowledge), then this is not available without more custom engineering work beyond the integration.
I feel you could still use the Glide integration, but your method of upsert and embedding assignment would have to be customized, then Glide integration could interact with the results, assuming it can work with dimension settings that are different that 1532.
Right. That’s really good to know. Appreciate it.
@c0bbler I’m touching this the first time today so very limited knowledge about how this works.
I have a table of Contacts in Glide. Every time I add/edit/delete I do index/delete the according ID. That part works.
But when I do a Send Message step, every time it returns an error without any additional info on why it failed. Can I only do queries, not questions on indexes?
Do you have any insights on this? Thanks a lot.
Spoke to @DJP about this a few weeks ago.
We might end up using the api instead of the Glide integration more than I would want to…
Hope Glide finishes the integration so we can do everything via the integration since right now this feels like a half baked integration.
Can you give more details about the use case and overall logic?
Things to check - assistant name matches. Context size of the index matches the 1532 requirement of Glide (you wouldn’t be able to index or delete if there was a mismatch, but just checking).
For the record I feel funny asking you the questions you usually ask others! 
But here to help!
Thank you so much!
I have a table of Contacts like this.
My goal is app users can ask questions about this table.
On every add/edit/delete of these records, I have been able to index/delete relevant records.
But when I create an assistant, it can’t seem to connect to my index to answer.
I wonder if my approach was wrong. Would “Send Message” only work with files, not indexes, and “Query Data” should be the one to work with indexes?
My workaround at the moment is to generate and upload a JSON file to the “assistant” every time a record is added/edited/deleted. It works beautifully, but I still wonder if my original approach was wrong.
Yes, this is my understanding of the split between use cases in Pinecone. Indexes are commonly pushed to databases, and are semantic representations of information used to generate vectors. Vectors, as you may know, are typically used in comparing the similarity of values, such as in matching cases.
The second use case is to be able to query information stored in documents, and provide an assistant to answer questions about those documents. This may not be that far away for you based on your initial architecture, you just might have to change the format of your upload, or duplicate it into a document format.
It sounds like you have done this workaround, but adding a use case for the general reader for better understanding:
Let’s say you are already indexing contact profiles using the create/update/delete index. You could duplicate the format of your created index, and store it as a .txt file (or as you’ve mentioned .json), and perform the document upload from that, then enable the assistant use case on top of those. Duplicating this means you could offer a solution for assistant queries as you intended, and the use case below, which might be interesting. I would suggest trying .txt files to see if you find better performance with the assistant with simple semantics.
For the first case of indexing and querying, you can write prompts in indexes and in queries to assist the LLM in developing a stronger semantic understanding of the information you are indexing and querying. In your example, if you wanted to allow your users to write a query, you could put their query into a template column with a prompt and return results with vector matches that measure the similarity of the contact to the contact query submitted by your users. You could then display them in order of vector closeness (eg., similarity).
Thank you so much for the detailed response!
