Function Calling Part 2

Last week we explored how a chat-based finance app could retrieve current stock prices using function calls; giving it access to information outside its training set.

Today we’re enhancing our finance app so that it generates side-effects and gather user input dynamically.

Quick Recap

So far, our AI uses a function call to quote realtime stock prices.

When the user asks for a stock price, the model doesn’t have that information but it uses a function call to retrieve the price from the app environment and the conversation can continue.

Setting Price Alerts

The next feature our app will offer is customizable price alerts. Users inquiring about stock prices may want to be notified if the price goes beyond some amount.

Another Tool Definition

We’ll create a function in our app called “set_price_alert” and add its tool definition it to our system prompt.

This tool definition has a few interesting patterns worth examining:

Property Types
These can be any json value type (e.g. string, number, boolean, etc..) and they’re used to tell the model what format we expect it to send input.

Enums
String properties are unavoidable but are open ended. Enums are an excellent way to inform the AI what options are accepted for a given input.

Additional Properties? False.
Informing the model that there are no additional properties is a common pattern that reduces the likelihood that extra properties are hallucinated and passed through the function call.

The New Feature In Action

At this point the model has two of the three required inputs for the set_price_alert function call: stock and price. But it still needs to know if the alert should trigger if the price rises above $140 or falls below, so the model asks the user for more information.

Now the model has all the data it needs to make a function call to set the price alert.

When the function call returns a successful response, the model sends a chat to confirm to the user that the price alert has been created.

With zero configuration within our app the model was able to engage the user until it has all the information it needs to complete the request!

A Note On Safety

We’ve deliberately excluded contact information from the function call parameters, even though the implementation of our “set_price_alert” will require it.

At this point, its much safer to rely on the app itself to determine the active user than it would be to allow sensitive user information to flow through the model.

Pondering Agentic Program Flow

When our model was asked to set a price alert for GOOG at $140 it required another input: whether the alert should trigger if the price rises above or falls below the target price.

In our example, the model asked the user to supply this input, but since the model also has the “get_stock_price” tool, theoretically the model could retrieve the current price, observe that it is above the target price, and self-determine that the trigger_condition should be “BELOW”, all without involving the user.

As you build more tools that support complex behaviour, function calls can often result in the usage of other function calls, often in unpredictable ways.

This marks the departure from well-defined logical program flow into the brave new world of Agentic Program Flow, and there’s a whole lot more to explore, so stay tuned!

Explore More

Want to dive deeper into this and other ways AI can elevate your web apps? Our AI-Driven Laravel course and newsletter covers this and so much more!

👉 Check Out the Course: aidrivenlaravel.com

If you’ve missed previous newsletters, we got you: aidrivenlaravel.com/newsletters

Thanks for being part of our community! We’re here to help you build smarter, AI-powered apps, and we can’t wait to share more with you next week.