@oloUser , that’s great to hear, thanks for letting us know how things turned out! I wonder if restarting the session solved a different issue like dirty state or Python package versions of things that were installed but not active in the session yet.
And I’m happy to hear that the LangGraph notebook example for Reasoning Engine was helpful for you in figuring out a clean way to handle Tool interoperability with Vertex AI Search RAG + Grounding in Google Search. I had a similar epiphany this week when implementing a reAct agent w/ LangGraph as described in this tutorial, and I was able to make use of Tools + general Gemini knowledge that has been not as straightforward to figure out using only the Vertex AI SDK + LangChain, similar to your “two tools” problem. Stay tuned for more content from us about using LangGraph in Reasoning Engine and Vertex AI!
We have successfully deployed the local Langchain Vertexai Agent with firebase function. Now I am trying to use the deploy version of the local Langchain Vertexai Agent. I have a few questions to ask.
Q1. How are environment variables handled? For example, in my local Langchain Vertexai Agent (on firebase function), I am setting the GCP Project ID to the dev, staging, prod GCP project. How can we do this with the deployed Langchain Vertexai Agent?
Q2. Similar to Q1, what is the recommended way to access GCP Secret Manager with the deployed version? I am using the firebase function secret parameter in my current firebase function.
Q3. We have some custom tools that require a setup script. For example: playwright install, how to do it with the deployed version?
Q4. About
extra_packages: A list of internal package dependencies. These package dependencies are local files or directories that correspond to the local Python packages required by the application.
Does it mean local pip packages? or import statements like from utils import libs?
If it means import statements, do we put everything in 1 file for deployment?
Sorry for asking so many questions. To sum up, I think the confusion comes from the gap between the local and deployed versions seems to be very large/unclear. Will the scope/variables in memory got deployed as well (like the env variables question I was asking)… How the code will be packaged … The process now seems to be too magical.
Also, what is the benefit of using the deployed version over deploying the local version to the firebase function / cloud function / cloud run?
@kingychiu , all good questions! So that it’s easier to keep track of questions / answers for other folks. Could you post this as a new discussion topic on the AI/ML forums here (https://www.googlecloudcommunity.com/gc/AI-ML/bd-p/cloud-ai-ml)? And you can tag me there so that we can dig into the answers & discussion from there. Thanks!
@nadav_w , thanks for the question on billable components! Essentially there are usage-based costs on the hosted agent endpoint in Reasoning Engine, similar to Cloud Functions or other serverless compute options, and then there are usage-based costs for calls to the Gemini API for content generation & function calling (both of which are metered by token counts). Currently Reasoning Engine is in Public Preview stage, and when it goes to GA stage, full details on pricing will be posted in its documentation.
I was wondering since it is possible to assign multiple tools to the agent we created, s there any way to help the agent choose the tool to use correctly?
Is it possible instead using Langchain to orchestrate multiple agents to work simultaneously? For example one agent has task to do conversion between currencies of different countries and another one to do conversion on time zone between different countries and we want to create a structure where depending on the demand it responds the appropriate one. Is there any documentation on this?
@DanieleV : Great question! This is a quickly evolving field and I appreciate you asking about this. To handle (and improve) use cases with multiple tools and agents, I suggest the following (from simplest to more complex):
When defining your Python functions as tools that you use with Reasoning Engine, the more details that you give in your function name, type hints for parameters, and docstrings (including few-shot or many shot-examples of tool invocations that you consider good or bad), this will heavily influence how and when your agent will predict the use of a given tool and its associated parameters.
Beyond Reasoning Engine, you can look at what’s behind the LangChain template in the customization section of the Reasoning engine docs, and also suggest looking at or trying the implementation of Tool Calling Agents in LangChain and/or LangGraph Tool Calling to understand the differences in performance of how much of the “function calling reasoning” you want to defer to the LLM layer (LangChain & LangGraph approach) vs. the function calling layer of the LLM (Function Calling / Reasoning Engine approach).
Finally, the only way to know quantitatively which approach is working better than others is through evaluation frameworks like the Gen AI Evaluation Service in Vertex AI, and you can find lots of sample notebooks of that here in the generative-ai repo on GitHub.
can you explain the deployment of the reasoning engine and the difference between this approach and the approach mentioned with LangServe and CloudRun as presented in this blog?
thanks for the quick response, you probably already explained this but could you clarify again what are the advantages of a custom approach with LangChain and the ReasoningEngine instead of Agent Builder? Is it just a question of which framework is better or can we have cost and performance advantages?
I wanted to inquire about the possibility of implementing streaming with the Reasoning Engine in the future. Currently, I’m developing a chatbot using RE, but we need to stream the responses to enhance the user experience.
@nadav_w , thanks for the question, this is a common one! In the end, solutions such as Reasoning Engine, LangServe + Cloud Run, and other deployment options are all just different ways of deploying and hosting your agent as Python code. Some developers prefer to work directly with Cloud Run, while other developers prefer to work at a higher-level abstraction such as LangServe on Cloud Run -or- Reasoning Engine. If I’m starting with the agent and building the app around it, I appreciate starting with Reasoning Engine or LangServe. If I’m starting with an app that does more than just interact with an agent, I’ll typically start from Cloud Run. And as your agent and app grow in complexity, you can switch between approaches to make the app / agent more modular and maintainable!
@DanieleV , good question! The answer here is similar to the previous question on deployment, but this time focuses on the developer’s experience building the agent rather than deployment. Reasoning Engine, LangChain, and Agent Console are just different ways of constructing agents at different abstraction levels. If you spend most of your day at the LangChain layer, it might make sense to just use LangChain or LangGraph directly in your code. If you spend most of your day working with Google Cloud SDKs and APIs such as Vertex AI, then you might find Reasoning Engine the easiest to work with. Or if you want to quickly prototype an agent that matches up with the chatbot + RAG approach, then Agent Console is a good starting point. I often prototype simple versions of agents in 2 or more tools to get a feel for which approach will work best for a given use case.
@emerworth , yes! This has been a common feature request in Reasoning Engine and is being worked on. Feel free to open a new feature request on the public issue tracker and point me to it. That way we can learn more about your use case and let you know when it’s ready for testing / usage!
