A practical guide to OpenAI Function Calling

We all know large language models (LLMs) can talk a big game. They can churn out emails, answer trivia, and even whip up a sonnet on command. But what about actually doing things? How do we get them to stop just talking and start interacting with the real world, like looking up an order, updating a support ticket, or querying a database?

That's the job of OpenAI Function Calling. It’s the piece of the puzzle that connects an AI's conversational skills to real-world action. It's what turns a simple Q&A bot into an agent that can actually work with your business software.

In this guide, we’ll walk through what function calling is, how it works, and some of the hidden complexities you'll run into if you try to build with it from scratch. We'll also look at a different starting point for support work: using eesel CLI to operate a teammate with its own knowledge and instructions, instead of building that application yourself.

What is OpenAI Function Calling?

Put simply, OpenAI Function Calling is a feature that lets you tell an LLM about the tools you have available. You describe your functions to the model, and it can then analyze a user's request and ask to use one of them. It does this by spitting out a neat JSON object with all the details your app needs to run the function.

A common mix-up is thinking the model runs the code itself. It doesn't. It just tells your application what code it should run and what information to use.

Think of the LLM as a really smart assistant who knows your entire toolbox inside and out. When a task comes up, they can't use the tools themselves, but they can hand you the right one (the function name) and tell you exactly how to use it (the arguments). Your application is the one that actually gets its hands dirty and does the work.

OpenAI also calls this tool calling. A function is one kind of tool; the wider tool category also includes built-in capabilities such as web search.

How does the OpenAI Function Calling flow work?

Getting an AI to use a tool isn't a single API call; it’s more of a back-and-forth conversation between your app and the model. It’s a little dance that follows a pretty predictable pattern.

Here’s a step-by-step look at how it plays out:

1. You show the model your tools. First, you give the model a list of the functions it can use. This includes the function's name, a clear description of what it does, and the specific parameters it needs to work (all laid out in a format called a JSON schema). The quality of your description is everything, it's how the model figures out when to suggest a tool.

2. The user asks for something. A user types a request in plain English, like, "What's the status of my order, #12345?"

3. The model picks a tool. The model reads the request. If it spots a match with one of your function descriptions, it responds with a special message asking your application to call that function. It also provides the arguments it pulled from the user’s prompt (for example, "{"function": "get_order_status", "arguments": {"order_id": "12345"}}").

4. Your app does the work. Your code grabs this structured response and runs the actual "get_order_status" function. It might connect to your database or an external API to get the info, which in this case is "Shipped."

5. You pass the result back to the model. You send the function result back to the model. It can then answer, for example, "Your order #12345 has been shipped," or request another tool call if the task needs more information.

This little round trip allows the AI to blend its conversational skills with real-time data and actions, making it a whole lot more useful.

Common use cases for OpenAI Function Calling

Function calling is what takes a chatbot from a simple novelty to a powerful agent that can handle real business workflows. Here are a few of the most common ways people are putting it to work.

Plugging into your live data

This is the most straightforward use case. It lets an AI access real-time, private, or dynamic information that wasn't in its original training data. An AI can become an expert on your specific business operations almost instantly.

For example, a customer support AI could look up an order status in a Shopify database, check flight availability through an airline's API, or pull up account details from your internal CRM.

Getting things done in other apps

Beyond just fetching information, function calling lets an AI trigger workflows and make changes in other systems. It can become an active part of your business processes.

For instance, an IT support bot could get a request and automatically create a new ticket in Jira Service Management. Or, a sales assistant could take details from a conversation and add a new lead to your CRM without anyone having to do manual data entry.

Turning messy text into clean data

Sometimes, the goal isn't to answer a question but to reliably pull out and format information. Function calling is great for this because you can define a function's parameters as a blueprint you want the data to fit into.

A perfect example is processing an inbound support email. The AI can read a wall of text, pull out the user's name, company, issue type, and urgency level, and then format it all into a perfect JSON object. That object can then be used to create a new, perfectly categorized ticket in your help desk.

The hidden challenges of building with OpenAI Function Calling

Going from a cool demo to a production-ready application that uses function calling is a pretty big leap. Building directly with the API is powerful, but it comes with some engineering responsibilities that many teams don't see coming.

Orchestration challenges

What happens when a task needs multiple steps? To find a customer's order, you might first need to find their customer ID using their email, and then use that ID to look up their orders. The model can request those calls in sequence. Your application must execute them, return their results, and handle failures. That loop is part of the application you ship, not something a function definition supplies.

As one developer on Reddit put it, it’s like instructing an intern. You have to give them a series of instructions, check their work at each step, and then tell them what to do next. You're responsible for building and debugging that entire orchestration layer.

Reddit

Reliability and error handling

Models don't always act the way you expect. They can sometimes "hallucinate" arguments that don't exist, call the wrong function, or just fail to call one when it's obviously needed. This means your team has to write a ton of validation, error-checking, and retry logic to make the system dependable.

Some developers even resort to practically yelling at the model in their system messages, writing things like "DO NOT ASSUME VALUES FOR PARAMETERS" in all caps, just to get it to behave. That’s hardly a scalable way to build a production system.

Test the whole tool sequence

A successful lookup does not prove the full workflow works. Test what happens when the first call finds no customer, the next service times out, or an action needs approval. OpenAI documents a loop that can return further tool calls; your application still needs clear rules for when to continue, stop, or ask a person.

Development and maintenance can be a real drag

Defining function schemas in JSON is tedious work and it's easy to make a syntax error. Every time you want to add a new tool or update an old one, you have to dive back into the code. Keeping this code in sync with your actual tools, managing different versions, and just keeping up with frequent changes to the OpenAI API becomes a constant drain on engineering time.

Operate a support teammate with eesel CLI

If you're exploring function calling to build a custom product, the API gives you control over its tools and execution. If your immediate job is to give a support teammate the right policies and check its answers, I would start with eesel CLI. Its commands let you operate the same eesel teammate your support team uses in the dashboard.

You configure an existing teammate's knowledge, instructions, and connected apps, then review its activity. A developer can run those commands directly, a script can repeat them, or a coding agent such as Claude Code, Cursor, or Codex can use them while helping you configure support.

Try a policy question against your existing teammate

For an existing eesel workspace, use Node.js 18.17 or newer and sign in first:

npx @eesel/cli login
npx @eesel/cli agents

Pick the intended agent from the list. Replace <agent-id> below with its ID, and use a real local policy file:

npx @eesel/cli instructions --agent <agent-id>
npx @eesel/cli files upload ./refund-policy.pdf --agent <agent-id>
npx @eesel/cli chat "According to our refund policy, what should we tell a customer who asks for a refund after 45 days?" --agent <agent-id>

Check that the upload succeeds before asking the question. Then compare the answer with the policy and the teammate's instructions. This tests a concrete support situation using the teammate you already operate, without first writing a document-search function and an application to run it.

For knowledge from a connected helpdesk or website, npx @eesel/cli status --agent <agent-id> shows the connections and whether their content has downloaded. Connecting a source and having its content ready are separate checks.

Make it usable by scripts and coding agents

The CLI returns JSON and structured errors with a hint and retryability information. A coding agent can read those results to decide what to check next. For example, ask it to inspect your teammate's instructions and connected sources, then report what is missing before making changes. The same setup remains visible to colleagues in the dashboard.

Use approvals to inspect actions held for human review and activity to see what the teammate has been doing. For write commands, --dry-run previews the server request without sending it. The preview shows what would be sent to the server; test the teammate's answers separately.

Choose between building an application and operating a teammate

Function calling makes sense when you need your own application behavior and want to own the tool execution. eesel CLI makes sense when you want terminal or agent-driven control of a ready-made support teammate. It does not turn your existing OpenAI function definitions into eesel commands.

If support is the use case behind your function-calling research, try eesel and follow the CLI setup guide. Start with one policy and one realistic question, then inspect the answer before expanding the workflow.