Hello, Been broken now for 1 day. Using blocks, using a tool-call step, the tool is not passing variable values in payload, but the actual variable paths. example (call payload captured at api)

{
    "message": {
        "timestamp": 1735110507709,
        "type": "tool-calls",
        "toolCalls": [
            {
                "type": "function",
                "function": {
                    "name": "tool",
                    "parameters": {
                        "type": "object",
                        "properties": {
                            "email": {
                                "type": "string"
                            }
                        },
                        "required": [
                            "email"
                        ]
                    },
                    "arguments": {
                        "email": "{{start.output.email}}"
                    }
                },
                "id": "09859655-73e4-4972-800e-93f0059a4ef6"
            }
        ],
....

ref: https://discord.com/channels/1211482211119796234/1211484481848873020/1320725299985514506

@Lucas van Staden Hello! It seems like there might be an issue with the way the variables are being referenced or parsed in your tool-call step. The payload should contain the actual values of the variables rather than the variable paths. To resolve this, you should ensure that the variable paths are being correctly evaluated before the API call is made. This usually involves making sure that the system responsible for executing the tool-call step is correctly accessing the variable values and substituting them into the payload. If you're using a visual programming interface or a specific development environment, you might need to check the documentation or settings to ensure that variable substitution is set up correctly. If you've already checked this and the issue persists, it could be a bug or a misconfiguration that needs further investigation. In that case, please provide more details or reach out to the support team for a deeper look into the problem. If you need assistance with closing a support ticket once the issue is resolved, I can help with that using the

functions.close_ticket

function. Just let me know when you're ready!

@Vapi The issue is at VAPI side, not MY side. I am not making the API call, VAPI systems is, so I have no control over initiating the parser. The issue is with your systems.

Got it. Tagging @User for additional help.

sometimes, after the tool-call, i get an immediate line drop, and then a status upsate of LLM fail.

"message": {
        "timestamp": 1735113341799,
        "type": "status-update",
        "status": "ended",
        "endedReason": "pipeline-error-openai-llm-failed",
        "artifact": {
            "messages": [
....

@Lucas van Staden I'm truly sorry to hear about the issues you're experiencing. It's important to us that you have a smooth and reliable experience with VAPI. I understand how frustrating it can be when things don't work as expected. If you're encountering immediate line drops followed by a status update indicating an LLM (Large Language Model) failure, it suggests there might be an intermittent issue with the service or a specific problem in the processing pipeline. I would recommend reaching out to our support team with the details of the errors you're seeing, including timestamps and any relevant log entries. They will be able to provide more targeted assistance and work on a resolution. In the meantime, if there's anything specific I can do to help address your concerns or if you have any further questions, please let me know. We value your business and would like to ensure that your issues are resolved to your satisfaction.

@Vapi is this not a support request already?

@Lucas van Staden Yes, this is indeed a support request, and I'm here to help you to the best of my abilities. I apologize for any confusion. It seems there are multiple issues at play here, including the variable substitution problem and the LLM failures. For the variable substitution issue, our technical team needs to investigate the problem further. As for the LLM failures, these could be due to a variety of reasons, such as service outages, network issues, or problems with the specific requests being made. Since these issues are impacting your experience and you're considering alternatives, I want to ensure that your concerns are addressed promptly. I will escalate this to our technical support team to ensure they are aware of the urgency. In the meantime, if there's any additional information you can provide or specific questions you have, please let me know, and I'll do my best to assist you. Your satisfaction is very important to us, and we're committed to resolving these issues as quickly as possible.

sofar millisai seems like a good alternative, already started experimenting.

Hi @User , I'm experiencing the same issue, the variables get replaced in the conversation blocks, but not on the tool calls. Nevertheless, I've experienced one tool call, just one for some weird reason, where the variable gets replaced, and it's when the assistant comes back to a previous step, and it's a tool call; then it's getting replaced.

@Lucas van Staden @ZamJAM as of know Vapi Blocks is not ready for development and production use and we are working on make it ready to use pretty fast.

@Shubham Bajaj any projected timeline on when it will be released? IMO, seems pointless to continue development of agents using prompting, when blocks will fix known issues I am having with the large prompt (reason why blocks are being created) Just seems pointless to go on until blocks is ready.

I agree with @Lucas van Staden, in our case it's not worth to continue using normal prompting, as our logic has been translated into more than 10 blocks, only for one of our use-cases. Using a normal agent will most probably produce hallucinations. Best regards, Antonio

@Lucas van Staden we will announce it, for now ETA is End of March.

Sadly this is still brokwn 😦 was hoping at leat the function calls woudl have been sorted, as they used to work. Things had gone worse in fact. https://cdn.discordapp.com/attachments/1321375442644762625/1327597655089479751/image.png?ex=6783a52a&is=678253aa&hm=5f396741c172fda687369fee86a8e671c9d3fc589b699683b9d23b3d6aac9c2f&

@Lucas van Staden Sorry for your experience, but Blocks are not ready as they're in beta status. We will let you know through announcements once they are ready for production.

I know, that is why I am having to wait. 😦

@Lucas van Staden good news is we are doing heavy testing internally and by end of this Quarter it will be released.

@Shubham Bajaj So blocks (beta) is being replaced by workflows, now in beta..... so, should I be afraid to pend time on workflows, to have that get replaced by next thing before it is even out of Beta?

@Lucas van StadenMy apologies for the delay. Workflows are not currently in beta; instead, they are suitable for simple production use. We will implement new features gradually as users request them. Therefore, you are covered on that aspect.

@Shubham Bajaj thanks. Sadly there are some limitation on workf lows that will prevent me from using this. It is still very basic and limiting. IMO, you guys are concentrating to much or the UI/UX, (so more a fixed/set workflow) - and not on how transient agents being created with data ready for usage on the call). It has a lot of potential, but very limited at present. Not dynamic enough. I have posted a few suggestions: https://roadmap.vapi.ai/feature-requests/p/workflows-prevent-dynamic-personalised-assistants-to-be-created https://roadmap.vapi.ai/feature-requests/p/ability-to-call-existing-tools-functions https://roadmap.vapi.ai/feature-requests/p/ability-to-use-call-data-as-variables-in-workflow-conditions-and-api-calls https://roadmap.vapi.ai/feature-requests/p/workflows-api-requests-ability-to-use-assistant-phone-number-or-account-level-as For example, the inability to use call data within a workflow (so as to make an api call to fetch client data, based on their phone number) is quite limiting. Or not being able to use call data in conditionals Or not being able to use existing tools for data fetching, as in most cases those will be re-sused accross multiple workflows. The API calls in workflows limits usage of global assigned urls on api calls, since it is now a required field....going backwards there IMO. One might have to duplicate a few api calls that could have benn a single unction, re-used. Still testing, but that was after a few hours. Blocks was more dynamic. Hope to see workflows get there.

@Lucas van Staden Thanks for the feedback, I will forward this to the team.