Function Calling in LLMs: How It Works in Production
Function calling lets a large language model ask your software to do something: look up a record, query a database, create a ticket. The model does not run anything itself. It returns a structured request, your application executes it, and the result goes back to the model so it can finish the answer. The same capability is also called tool use, and the two terms describe one idea. This guide explains the mechanism, shows the Python pattern, and then covers what matters when the system touches real documents and real money: permissions, audit trails, testing and Malaysian regulatory expectations.
TL;DR
Function calling is a contract: you describe tools with a schema, the model returns a function name and arguments, and your application decides whether and how to run them.
“Tool use” is the broader capability; function calling is the interface that formalises it.
A demo is a single call. A production system is an orchestration layer with a tool registry, validation, retries, permissions and logging.
For high-impact actions such as payments, require human approval and keep a full trace of every call.
In Malaysia, PDPA breach duties, MyCERT guidance and, for banks, Bank Negara Malaysia’s technology risk policy shape how you deploy.
Table of Contents
What function calling is, and how it relates to tool use
Function calling is a mechanism that allows a model to interact with external tools by outputting structured data, typically JSON, that represents a request to use a specific function. The model is given a schema describing what each tool does and what arguments it accepts. When a question needs data or an action outside the model, it responds with a call instead of prose.
Tool use is the wider idea: a model that can reach beyond its training data to retrieve information or act. Function calling is how that capability is made precise. Without a schema, a model can only suggest in words that someone should check a balance. With one, it can emit a well-formed request that a system can validate and run.
The distinction matters for enterprise buyers. The model supplies judgement about which tool fits the request. Everything that carries risk, such as execution, access rights and data handling, stays in your code. That division is what makes the pattern governable.
The loop between request and answer
The flow is the same across the major providers. Anthropic’s documentation describes how the model decides when and how to call tools from the conversation, while the application runs the operation and returns the result. OpenAI’s guide describes the same sequence: the model returns a function name and arguments, and the application executes it and sends the result back.
In practice that gives you six moments:
The user asks a question. Your application sends it with the list of tool definitions. The model either answers directly or returns one or more tool calls. Your application validates and runs each call. It appends the results to the conversation, matched to the call by an identifier. The model is called again and writes the final answer.
A production guide on the topic makes a point worth repeating: the loop requires the application to manage conversation state, orchestrate calls, handle timeouts and retries, and append correlated results. The model is one component in a pipeline, not a direct line to your systems.
A Python implementation in five steps
The reference implementation in OpenAI’s documentation is a good template, whichever provider you finally use. It defines tools as JSON Schema with strict mode, parses the returned arguments with json.loads, runs the matching Python function, appends a function_call_output with the call_id, and calls the model again.
First, define the tool. Each entry has a type of function, a name, a plain-language description, and a parameters object listing properties and required fields, with additionalProperties set to false and strict set to true.
Second, send the tool list with the conversation in your first request.
Third, loop over the response output and pick out the items of type function_call. Parse the arguments with json.loads.
Fourth, look up the function in a registry, run it and append its result as a function_call_output carrying the same call_id.
Fifth, call the model again with the extended conversation to get the final answer.
A minimal registry looks like this:
TOOL_REGISTRY = {"get_invoice_status": get_invoice_status}
for item in response.output:
if item.type == "function_call":
args = json.loads(item.arguments)
result = TOOL_REGISTRYitem.name
input_list.append({
"type": "function_call_output",
"call_id": item.call_id,
"output": json.dumps(result),
})
A company engineering write-up recommends always setting strict mode so the schema is enforced during generation, and still validating parsed arguments before execution as a second line of defence. We agree: treat the model’s output as untrusted input, the same way you treat a web form.
Let your framework do the schema work
If you would rather not write JSON Schema by hand, frameworks derive it from your code. DSPy’s tool class derives the name, description and argument types from the function signature, type hints and docstring, and validates arguments against the schema before execution. It also returns an unknown tool or an execution exception to the model as a result, so a failed turn is not lost. The Strands SDK takes a similar route with a decorator that extracts metadata from docstrings and type hints and validates input with a Pydantic model, raising a detailed error when validation fails.
Designing tools the model can use reliably
Most production failures trace back to the contract, not the model. Three habits prevent the majority of them.
First, write descriptions as you would brief a new colleague. Say what the tool does, when to use it and when not to. Vague descriptions lead to missed calls or the wrong tool being chosen.
Second, keep the toolbox small and specific. A tool called get_policy_status with two required arguments is easier for a model to use correctly than a general run_query tool. Narrow tools are also easier to permission and audit.
Third, validate in both directions. Arguments are checked before execution, and results are checked before they re-enter the conversation. One practitioner argues the tool result is the most overlooked seam: define a result model next to the handler, and keep execution failures and schema failures as separate error stages so the model can tell a transient outage from a malformed response.
Tools that reach out to public websites add a further class of failure. Blocked requests and rate limits look like tool errors to the model, so it helps to understand why AI agents get blocked and to pair web-facing tools with scoped permissions and human oversight rather than letting an agent retry without limit.
Where function calling pays off in document-heavy industries
The commercial case sits in documents. Claims, loan files, shipping papers, quality certificates and supplier invoices arrive as unstructured text and images. A model can read them, but reading is only half the job. Function calling is what lets it then validate a policy number against the core system, check a customs code, file the extracted fields and route exceptions to a person.
In insurance, Microsoft’s open content-processing accelerator illustrates the shape of the opportunity, with automated claim intake that can reduce processing from hours to minutes. The same pattern applies elsewhere:
Banking operations teams can extract fields from onboarding documents and call internal checks before an officer reviews the file. Manufacturers can match supplier invoices to purchase orders and goods receipts. Logistics managers can read bills of lading and call tracking and customs tools to reconcile discrepancies. Underwriters can have submissions summarised and enriched from internal data before a decision is made.
In each case the model handles variation in the documents, and your tools handle the rules. That keeps decisions explainable. For a deeper look at how banks move from assisted tasks towards autonomy, see our four-stage view of agentic AI in banking, and for operational rollouts our pilot-to-scale playbook for AI agents.
Securing and governing tool use
Once a model can call tools, a prompt becomes a route into your systems. The controls are familiar from enterprise security, applied to a new actor.
Start with least privilege. Guidance on governing agentic systems says organisations should use least privilege, sandboxing and human approval for high-impact actions, and log every prompt, plan, tool call, argument and response with stable trace IDs. The same source says destructive actions, such as sending money, need explicit human confirmation. Build that rule into the tool itself, not into the prompt.
Use a central registry. A production-ready design maps tool names to schemas, handlers and required permissions, so the model only sees tools the current user is authorised to use. That also limits the damage of prompt injection: an instruction hidden in a document cannot call a tool the session was never given.
Separate read from write. Give read-only tools broad availability and put every write behind an approval step, a limit or both. Make writes idempotent so a retried call does not pay an invoice twice.
Keep the trace. An audit trail that links the user request, the model’s chosen call, the arguments, the result and any approval is what lets compliance teams and auditors reconstruct a decision months later. Our guides to LLM observability and running AI agents with runbooks set out what to implement first.
Malaysian requirements to plan for
Function calling usually moves personal data between your documents, a model and your internal systems, so data protection comes first. This section is general information, not legal advice, so confirm specifics with your counsel and compliance team.
Under the amended Personal Data Protection Act, a law firm’s summary notes that the changes took effect in stages between 1 January and 1 June 2025. Controllers must notify the Commissioner within 72 hours of discovering a breach likely to cause significant harm, and notify affected individuals within seven days after that. A tool that can read customer records therefore needs logging good enough to say what was accessed.
On access control, MyCERT’s guidance on deploying AI systems recommends separating regular users from administrators, requiring MFA and privileged access workstations for admin access, and using role-based or preferably attribute-based access control. That maps directly to the permissions column of a tool registry.
Malaysia’s National Guidelines on AI Governance and Ethics set seven principles, including privacy and security. Practitioners note they have no legal effect but are the principal policy instrument for responsible AI, and they stress proper procedures, informed consent and secure storage for financial or health data.
For banks and other regulated financial institutions, Bank Negara Malaysia reissued its Risk Management in Technology policy document on 28 November 2025. A regulatory summary says it is technology-neutral, with no AI-specific obligations, but its appendix on emerging technologies requires consultation with the Bank before first-time adoption for critical systems. Third-party risk is in scope too, so the model provider and your hosting choices belong in the assessment. We cover the broader controls in running LLMs on private data safely.
Testing and monitoring in production
A tool-calling system can reach the right final answer and still take a wrong step on the way. One evaluation guide warns that an agent that achieves its goal but takes an irreversible wrong action en route is not a success in production. Score the path, not only the outcome.
Before launch, build a test set of real requests with the expected tool, the expected arguments and the cases where no tool should be called. Include adversarial documents. Measure whether the right tool was chosen, whether arguments were valid and whether the model asked for approval when it should have.
After launch, the same source advises watching efficiency metrics such as token usage, tool-call count per task and error recovery rates to catch silent regressions and cost creep. Add latency per tool, because a slow downstream API often looks like a slow model. Our LLM evaluation metrics guide and LLMOps practices go deeper, and if you are choosing a model for these workloads, our note on open versus closed LLMs explains how to route proofs of concept.
Perspective
We see the same pattern in enterprise projects. The demo works in a week, and the project stalls at the moment someone asks who owns the tool registry, who approves a payment action and who is paged when a call fails at two in the morning. Function calling is not a feature to bolt on. It is the point where a language model meets your systems of record, so strategy, build and operation have to be designed together. When one team defines the use case, writes the schemas, deploys the loop and then runs it, the permissions, audit trail and evaluation set are decisions made on day one, not retrofitted after an incident. That is why we engineer for production from the start. Our approach is built around continuity, governance, auditability and measured business results, with one senior team accountable across the lifecycle. For document-heavy functions such as claims, underwriting, trade documents and supplier invoices, we think that is the difference between a pilot that impresses and a system that stays in service. Thomas Samuel
Taking function calling from pilot to production
Sentient Concepts is an end-to-end AI firm. We handle strategy, readiness and data diligence, use-case prioritisation, engineering, deployment and managed operations, so the team that designs your tool-calling system is the team that runs it. We work with enterprises in finance, manufacturing, logistics and insurance, with a focus on document-process automation and conversational agents.
If you are deciding where function calling should start, begin with use-case prioritisation and value mapping, or see how we build AI and GenAI solutions and deploy and operate them. To talk through your workflow, start from our services overview.
FAQ
Is function calling the same as tool use?
In most documentation the terms are used interchangeably. Tool use is the broad capability of a model working with external systems, and function calling is the structured interface through which the model requests a named function with arguments. Your application, not the model, performs the execution.
Does the model actually run my function?
No. The model returns the function name and arguments as structured data, and your application executes the operation and returns the result. That is why validation, permissions and approval steps belong in your code and can be audited.
How do I call an LLM with tools in Python?
Define each tool with a JSON Schema, send the list with the conversation, parse the returned arguments, run the matching function and send the result back with its call identifier. Then call the model again for the final answer. Frameworks such as DSPy can generate the schema from type hints.
What should require human approval?
Anything hard to reverse or with financial, legal or customer impact: payments, record deletion, outbound messages to customers and changes to credit or claims decisions. Read-only lookups can usually run automatically, within least-privilege limits and with every call logged.
Do Malaysian banks need to tell Bank Negara Malaysia before using it?
BNM’s technology risk policy is technology-neutral, but it requires consultation with the Bank before first-time adoption of emerging technology for critical systems. Confirm the position for your own institution with your compliance team and the policy document itself.
Sources
Recommended