Dialogflow Messenger missing toolCall data while Agent Builder playbook shows it correctly

Other Questions AI Agent
1

I’m working with Vertex AI Agent Builder and trying to set up Function Tools. The documentation illustrates that when an agent decides to utilize a tool, the response should contain a toolCall object with relevant tool information.

{
  "queryResult": {
    "text": "check temperature in San Francisco",
    "languageCode": "en",
    "responseMessages": [
      {
        "source": "VIRTUAL_AGENT",
        "toolCall": {
          "tool": "<tool-identifier>",
          "action": "fetch-temperature",
          "inputParameters": {
            "city": "San Francisco"
          }
        }
      }
    ]
  }
}

This works flawlessly in the Agent Builder playbook. When I inquire about temperature, the network request to dialogflow.clients6.google.com/v3alpha1/ retrieves the full toolCall object:

{
  "queryResult": {
    "text": "what's the temperature in Berlin?",
    "languageCode": "en",
    "responseMessages": [
      {
        "source": "VIRTUAL_AGENT",
        "toolCall": {
          "tool": "projects/myproject/locations/us/agents/12345678-abcd-1234-5678-123456789012/tools/98765432-efgh-5678-9012-987654321098",
          "action": "fetchTemperature",
          "inputParameters": {
            "city": "Berlin, Germany",
            "scale": "fahrenheit"
          }
        }
      }
    ]
  }
}

However, when utilizing the Dialogflow Messenger integration, it accesses dialogflow.googleapis.com/v3/ and the toolCall is not present:

{
  "queryResult": {
    "text": "what's the temperature in Berlin?",
    "languageCode": "en",
    "responseMessages": [
      {}
    ]
  }
}

This creates complications since the session anticipates tool execution results, leading to errors such as “Session is waiting for tool call result of tool and action fetchTemperature”.

What causes the difference in behavior between the playbook and Dialogflow Messenger? How can I ensure that the toolCall data is included in Dialogflow Messenger responses?

2

This exact thing caught me off guard on a recent project. The problem is that Dialogflow Messenger is hardcoded to use the stable v3 API, which doesn’t show toolCall metadata in responses. But the Agent Builder console runs on v3alpha1 where you can see all the function calling details. I figured out through trial and error that the messenger widget was built for basic conversations, not complex function stuff. The toolCall objects exist internally but get stripped out before they reach your frontend. My solution was a hybrid approach - I kept the messenger for basic interactions but added a parallel detection system. When the conversation hits tool execution mode, I switch to direct API calls using the sessions endpoint with v3alpha1. You need to monitor conversation state and detect when the agent starts calling functions, but it keeps the UX smooth while giving you access to the toolCall data you need for proper function execution and results.

3

The API version mismatch is exactly what’s causing this headache. I hit the same issue 8 months ago setting up function calling for our customer support bot.

The playbook uses v3alpha1 which has full toolCall support, but Dialogflow Messenger is stuck on stable v3 that doesn’t include toolCall objects in responses yet.

Here’s what worked:

Ditch the messenger widget and use detectIntent API calls directly. You can still embed it but handle conversation logic yourself.

Use v3alpha1 in your custom implementation:

POST https://dialogflow.googleapis.com/v3alpha1/projects/{project}/locations/{location}/agents/{agent}/sessions/{session}:detectIntent

For the messenger widget, intercept responses and handle tool execution manually. Listen for session state and trigger your tools when the agent expects them.

I built a small middleware layer that catches these “waiting for tool call” states and executes functions based on conversation context. Not ideal but works.

Google’s been slow rolling out v3alpha1 features to stable API. Probably fixed in the next few months but no guarantees.

4

yeah, this is frustrating but there’s a workaround i used. skip the messenger widget and build a custom frontend that hits the v3alpha1 endpoint directly. you can still style it to match the messenger look, but you’ll actually get the toolCall data. just proxy requests through your backend to dodge cors issues.