Chat on Confluence/Jira/Sharepoint?… data with access control. Google Agent Builder. From sandbox to production. Part?2

In today’s fast-paced business environment, finding the right information quickly is more important than ever before. Traditional enterprise search often leaves users sifting through countless documents and disparate informations sources, hindering productivity and decision-making. Imagine having a single, unified search interface that not only pinpoints relevant documents but also synthesizes key information into concise, actionable insights?—?just like Google Search, but tailored to your company’s data.

In my previous article, we explored how to secure your generative AI agents with robust authentication, ensuring they act responsibly on behalf of users. Now, we’re taking a giant leap forward in empowering your organization with knowledge.

In this blog post, we’ll guide you through creating your very own “Google Search” for your enterprise. We’ll begin by harnessing the power of Agent Builder Search to construct a search application that seamlessly indexes your information sources into Agent Builder Datastores. Whether it’s Confluence, SharePoint, or Jira, built-in connectors will not only pull your valuable data but also crucial access control metadata, ensuring data security and privacy.

This is one of the key things to understand that source systems (Confluence, Sharepoint, ...) are the only place where you control WHO can access which information. Agent Builder Search just reads access control information and uses it when generating responses.

Next, we’ll supercharge the generative AI agent application we built in the previous article by seamlessly integrating this search app that is able to search across the configured sources of information (so-called blended search) into agent capabilities. Leveraging the powerful mechanism of tools, our agent will use our instructions for reasoning and intelligently relay user queries to the search app. But here’s the key: the AI-synthesized answers it delivers will be generated exclusively from data to which the logged-in user has access. This ensures that sensitive information remains protected while empowering your users with the precise knowledge they need to excel:

Let’s get our hands dirty and dive into creating the Agent Builder Search application!

Agent Builder offers a versatile generic search option alongside two specialized searches tailored for retail and media content. For our purposes, we’ll focus on building the flexible generic search functionality.

Moving forward, you’ll be prompted to connect Datastores to your search application. Datastores are where Agent Builder securely stores embeddings, which are numerical representations of your source data. Additionally, Datastores also house access control metadata. Assuming you don’t have an existing Datastore for Confluence, I’ll guide you through creating one.

From the list of available connectors, select Confluence. You’ll then be asked to provide the necessary details to establish a connection with your Confluence instance. If you followed my previous article, the Client ID and Client Secret should ring a bell. These represent our application (in this case, the Confluence Connector) that we registered within Confluence.

To successfully register our application within Confluence, you’ll need to establish an OAuth 2.0 application link directly in your Confluence instance.

Furthermore, you’ll need to define the specific scopes that this application requires. For a comprehensive list of available scopes, refer to the official documentation for Agent Builder Connectors . ?

As part of this process, you’ll also obtain the CLIENT ID and CLIENT SECRET associated with this link.

Once the configuration is complete, you’ll be asked to authorize the Connector application to access your Confluence data (ensure you have Confluence admin privileges for this).

After the connection is successfully established, the connector will perform an initial data load. Subsequently, it will also carry out incremental synchronizations at the configured interval, ensuring your data stays up-to-date.

Once the initial data load is complete, you can head to the preview section and begin testing your search application with sample queries.

You have various options to seamlessly integrate and utilize this search application within your organization:

• As a standalone web application: Deploy it as a user-friendly web application accessible across your organization.
• Embedded widget: Integrate the search functionality directly into your existing applications as a convenient widget.
• API access: Leverage the power of the search through API calls, enabling flexible integration with your custom workflows and systems.

And this API integration will be the key to incorporating this search application as a powerful tool for the conversational agent we developed in the previous article.

Let’s proceed by creating a tool within our Agent application to represent our search application. We’ll name it blended_search_confluence.

For the Open API specification of this tool, I utilized the following (modify paths attribute?—?include your project id and your datastore id):

openapi: 3.0.0
info:
  title: Google Discovery Engine Search API
  description: Search API for the Google Discovery Engine
  version: v1alpha
servers:
  - url: https://discoveryengine.googleapis.com 
paths:
/v1alpha/projects/XXXXXX/locations/global/collections/default_collection/engines/XXXXXXyourdatstoreidXXXXXXX/servingConfigs/default_search:search: 
    post:
      operationId: searchDocuments
      summary: Search documents in the specified collection.
      requestBody: 
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                query:
                  type: string
                  description: The search query.
                pageSize:
                  type: integer
                  description: The number of results to return.
                  enum:
                    - 3
                contentSearchSpec:
                  type: object
                  properties:
                    summarySpec:
                      type: object
                      properties:
                        ignoreAdversarialQuery:
                          type: boolean
                          description: Whether to ignore adversarial queries.
                          enum:
                            - true
                        includeCitations:
                          type: boolean
                          description: Whether to include citations in the summary.
                          enum:
                            - false
                        summaryResultCount:
                          type: integer
                          description: The number of summary results to return.
                          enum:
                            - 5
                        modelSpec:
                          type: object
                          properties:
                            version:
                              type: string
                              description: The model version to use for summarization.
                              enum:
                                 - "gemini-1.5-flash-001/answer_gen/v1"
      responses:
        '200':
          description: Successful search response.
          content:
            application/json:
              schema:
                type: object
                properties:
                  results:
                    type: array
                    items:
                      type: object
                      properties:
                        id:
                          type: string
                          description: The document ID.
                        document:
                          type: object
                          properties:
                            name:
                              type: string
                              description: The document name.
                            id:
                              type: string
                              description: The document ID.
                            structData:
                              type: object
                              description: The structured data of the document.

                  totalSize:
                    type: integer
                    description: The total number of results.
                  attributionToken:
                    type: string
                    description: The attribution token.
                  nextPageToken:
                    type: string
                    description: The token to use to retrieve the next page of results.
                  guidedSearchResult:
                    type: object
                    description: The guided search result.
                  summary:
                    type: object
                    properties:
                      summaryText:
                        type: string
                        description: The summary text.
                      summaryWithMetadata:
                        type: object
                        properties:
                          summary:
                            type: string
                            description: The summary text with metadata.
                          citationMetadata:
                            type: object
                            description: The citation metadata.        

If you analyze this configuration closely, you’ll notice I’ve set it up with these default parameters:

• modelSpec: gemini-1.5-flash-001/answer_gen/v1
• summaryResultCount: 5
• includeCitations: FALSE (Agent Builder Search excels at performing additional cross-validations of the generated answer to provide citations for statements supported by the search results. I disabled citations in this demo to maintain focus on the integration itself.)
• ignoreAdversarialQuery: TRUE

Therefore, the only unknown input parameter our agent needs to gather from the conversation and include in the JSON message sent to the Search application is the user query.

Now, the crucial step is to configure the Authorization option for this TOOL. In this scenario, we’ll also employ [Bearer Token] because we intend for our Agent to relay queries to the Search application and execute searches as logged-in user. This ensures the Search application generates answers considering ONLY the data accessible to this specific logged-in user.

This seamless integration is made possible by the Agent Builder built-in support for the OAuth2 Authorization Code flow. This mechanism enables the agent application to securely inject the user’s access token into the API requests directed to the Search application.

We’ll insert the same value here: $session.params.token, which represents the session parameter where the agent anticipates finding the user's access token.

Finally, let’s update the reasoning rules for our Agent. Whenever a user inquires about deposits, we want our agent to relay their queries directly to the Search application.

Let’s put this integration to the test and see how it performs within our Flask application, where we have our agent accessible through the Dialogflow Messenger UI.

If we are authenticated as a user with access to data on Confluence, we should anticipate the agent to present a summary generated by the search application based on that user’s specific permissions.

Additionally, when we audit this conversation from the Agent Builder console, we’ll gain the valuable capability to debug API requests, ensuring seamless functionality and troubleshooting any potential issues.

Now, let’s test the scenario where we log in with a user who has absolutely no access to Confluence data. In this case, we expect the search to yield no results, and the agent should gracefully inform us that it cannot answer the query. (We have the flexibility to further customize the response we’d like to display in such situations by defining “examples,” which we’ll explore in a separate article.)

And when you audit the conversation, you’ll observe that the search yielded no data for this particular user.

Summary:?

In this exploration, we bridged the power of Agent Builder Search with the valuable information stored within Confluence. We started by setting up a generic search application in Agent Builder and carefully linked it to a Confluence Datastore, ensuring data security through OAuth 2.0 credentials.

With the connector actively syncing data, we shifted our focus to our conversational agent. We meticulously designed a tool to represent the search application, empowering it to securely handle user queries while respecting individual access privileges. The agent’s decision-making was enhanced to intelligently utilize the search tool whenever relevant topics like deposits arose in conversation.

To see this integration in action, we used a Flask application with a Dialogflow Messenger UI. This allowed us to test the system, observing how the agent skillfully provided summaries from Confluence, always adhering to the user’s access permissions. We also delved into the Agent Builder console to examine conversation logs and API requests, ensuring seamless operation.

Through this project, we showcased the effective integration of Agent Builder Search and Confluence. It demonstrated how personalized and contextually relevant search results can significantly enhance the capabilities of conversational AI, all while upholding the crucial principle of data access control.

Please clap for this article if you enjoyed reading it. For more about google cloud, data science, data engineering, and AI/ML follow me on LinkedIn .

This article is authored by Lukasz Olejniczak? —?AI Specialist at Google Cloud. The views expressed are those of the authors and don’t necessarily reflect those of Google.