Function Calling in AI Agents: Practical Beginner’s Guide

QUICK ANSWER

Function calling—also called tool calling—lets an AI model request a predefined operation, such as checking inventory, querying a database, creating a support ticket, or sending an approved notification. The model normally selects the function and generates structured arguments; the application validates those arguments, executes the operation, and returns the result to the model.

Function calling does not automatically make a model trustworthy or give it unrestricted access. Production systems should use strict schemas where supported, server-side authorization, least-privilege credentials, input validation, timeouts, audit logs, and human approval for sensitive or irreversible actions.

What Is Function Calling in an AI Agent?

Function calling is a structured method for connecting a large language model (LLM) to external data or actions.

A developer gives the model descriptions of available functions, including:

A unique function name
A clear description of its purpose
The accepted parameters
Parameter types and constraints
Which parameters are required

When the user makes a relevant request, the model can return a structured tool call instead of guessing an answer.

For example, a user might ask:

Is printer PRN-204 covered by warranty?

The model could request:

{
  "name": "get_device_warranty",
  "arguments": {
    "asset_id": "PRN-204"
  }
}

The application—not the model—then validates the request, checks the user’s permissions, calls the asset-management system, and returns the result.

Function calling is called tool use or tool calling by some platforms. The exact API format differs between providers, but the underlying workflow is similar.

Why Function Calling Matters

A language model generates responses from its available context. It does not inherently know current ticket statuses, private company records, live prices, or what exists in an organization’s database.

Function calling helps an agent:

Retrieve current information from approved sources
Perform accurate calculations
Search internal systems
Create or update records
Trigger controlled workflows
Connect natural-language requests to existing APIs
Separate conversational reasoning from application logic

This is more reliable than asking the model to invent an answer, but it is not automatically safe or error-free. The model can select the wrong function, omit parameters, provide invalid values, or misunderstand the user’s intent.

How Function Calling Works

A typical function-calling cycle contains five stages:

The application sends the user’s request and available function definitions to the model.
The model either answers normally or returns one or more function calls.
The application validates and authorizes each requested call.
The application executes the approved function and returns its result.
The model uses that result to produce an answer or request another function.

The workflow can repeat when an agent needs multiple operations. For example, it might first locate a user account and then retrieve that account’s open support tickets.

Some models can request independent functions in parallel. Applications must therefore be prepared to receive zero, one, or multiple tool calls in a response.

Function Calling Architecture

Component	Responsibility
User	States the request or approves an action
AI model	Chooses a function and proposes its arguments
Agent or application	Controls the workflow and conversation state
Validation layer	Verifies the function name, schema, values, and business rules
Authorization layer	Confirms that the current user may perform the operation
Function or tool	Executes application code or calls an external service
External system	Supplies data or performs the requested action
Audit system	Records requests, approvals, results, and failures

The model should never be treated as the authorization layer. A valid-looking tool call is still untrusted input.

Read-Only and Action Functions

Functions usually fall into two categories.

Read-only functions

These retrieve information without changing external state. Examples include:

Looking up a knowledgebase article
Checking a device record
Retrieving an order status
Reading monitoring data
Calculating a value

Read-only operations are generally lower risk, although access controls and data privacy still apply.

Action functions

These change data or cause real-world effects. Examples include:

Sending an email
Resetting a password
Deleting a file
Issuing a refund
Creating an administrator account
Restarting a production server

Action functions require stronger controls. Important parameters should be displayed to the user before execution, and high-impact actions should require explicit confirmation or administrator approval.

A useful design is to separate preparation from execution:

prepare_refund(order_id, amount)
approve_refund(preview_id)
execute_refund(approval_id)

This is safer than allowing a model to submit an unrestricted refund in one step.

Designing a Function Definition

A function definition should be narrow, explicit, and easy to validate. The following is a provider-neutral example using a JSON Schema-style structure:

{
  "name": "get_ticket",
  "description": "Retrieve one service-desk ticket by its exact ticket ID. This function does not modify the ticket.",
  "parameters": {
    "type": "object",
    "properties": {
      "ticket_id": {
        "type": "string",
        "pattern": "^INC-[0-9]{6}$",
        "description": "Ticket ID in INC-123456 format."
      }
    },
    "required": ["ticket_id"],
    "additionalProperties": false
  }
}

A well-designed definition should:

Describe exactly when the function should be used
Explain what the function does not do
Use meaningful parameter names
Restrict values with types, patterns, ranges, or enumerations
Mark required properties
Reject unexpected properties where supported
Avoid asking the model for values the application already knows
Keep unrelated actions in separate functions

Provider support for JSON Schema keywords varies. Check the selected model and API documentation before relying on a particular keyword.

The Application-Side Execution Loop

The following pseudocode demonstrates the essential control flow without depending on a specific AI provider:

response = model.request(
    user_message = message,
    tools = approved_tool_definitions
)

while response contains tool calls:
    for call in response.tool_calls:
        verify_function_is_allowlisted(call.name)
        arguments = parse_and_validate(call.arguments)
        verify_user_authorization(current_user, call.name, arguments)

        if action_is_sensitive(call.name, arguments):
            require_human_approval(current_user, call)

        result = execute_with_timeout(call.name, arguments)
        record_audit_event(current_user, call, result)

        add_tool_result_to_conversation(call.id, result)

    response = model.continue_conversation()

return response.final_text

Do not use a model-supplied function name to dynamically invoke arbitrary code. Map approved names to explicit handlers:

handlers = {
    "get_ticket": get_ticket,
    "search_articles": search_articles
}

If a requested function is not in the allowlist, reject it.

Validation and Authorization

Schema validation is necessary, but it is not sufficient.

A schema may prove that amount is a number, but it cannot prove that:

The user owns the order
The refund is permitted
The amount is within company policy
The same refund has not already been processed
An administrator has approved the action

Apply validation at several levels:

Structural validation

Confirm that the arguments follow the expected schema:

Required fields are present
Values have the correct types
Unexpected properties are rejected
Strings and arrays respect size limits
Numeric values are within permitted ranges

Business-rule validation

Check application-specific rules, such as:

A ticket is still open
A device belongs to the correct tenant
A requested date is allowed
A refund does not exceed the original payment
A record has not changed since it was retrieved

Authorization

Authorize every function call against the authenticated user or service identity. Never assume that authorization is valid because the user mentioned a record ID or because the model requested the action.

For multi-tenant systems, enforce tenant boundaries in application code and database queries.

Security Risks and Controls

Prompt injection

Prompt injection occurs when malicious instructions influence the model. These instructions can appear in a user message, webpage, email, document, or retrieved knowledgebase content.

For example, a retrieved document might contain hidden text instructing the agent to disclose credentials or call an administrative function.

Recommended controls include:

Treat model output and retrieved content as untrusted
Separate instructions from external content
Expose only the tools needed for the current task
Enforce permissions outside the model
Require approval for privileged operations
Restrict network destinations and file access
Never place secrets in prompts or function descriptions
Test direct and indirect prompt-injection scenarios

Prompt filtering alone cannot guarantee protection.

Excessive permissions

An agent with broad credentials can cause more damage if it makes a mistake or is manipulated.

Use:

Separate service identities
Short-lived credentials where available
Read-only access by default
Tenant- and resource-level restrictions
Network allowlists
Limited API scopes
Separate tools for normal and administrative operations

Destructive or irreversible actions

Require human confirmation before operations such as:

Deleting data
Sending external communications
Changing access permissions
Making purchases or payments
Deploying to production
Disabling security controls

The confirmation should show the exact target, action, and important parameters. Do not ask the model to approve its own proposed action.

Duplicate execution

Retries, network failures, and repeated tool calls can accidentally perform the same action more than once.

Use idempotency keys, transaction identifiers, duplicate detection, and operation status checks for state-changing functions.

Data leakage

Do not return entire database records when the model only needs one field. Redact secrets, authentication tokens, personal data, and internal metadata before placing tool results into the model context.

Also consider the AI provider’s data-handling terms, retention settings, residency requirements, and organizational policies.

Operational Safeguards

Production implementations should include:

Maximum tool calls per request
Execution timeouts
Retry limits with exponential backoff
API rate limits
Tool-result size limits
Conversation and request identifiers
Structured error responses
Centralized audit logging
Cost and token monitoring
Circuit breakers for failing dependencies
Versioned tool definitions
Alerts for unusual or repeated actions

Avoid sending raw stack traces, database errors, or credentials back to the model. Return a controlled error object instead:

{
  "status": "error",
  "code": "TICKET_NOT_FOUND",
  "message": "No accessible ticket matched the supplied ID.",
  "retryable": false
}

How to Verify a Function-Calling Implementation

Test each layer independently.

Verify schema handling

Submit:

Valid arguments
Missing required properties
Incorrect data types
Unexpected properties
Oversized strings
Values outside permitted ranges
Invalid JSON

The application should reject invalid input before running the function.

Verify authorization

Test with:

An authorized user
An unauthorized user
A user from another tenant
An expired session
A disabled account
A service identity with insufficient scope

Verify agent behavior

Test whether the model:

Selects the correct function
Avoids unnecessary calls
Requests clarification when required information is missing
Handles tool errors without inventing results
Processes multiple calls correctly
Stops when the maximum call limit is reached
Seeks confirmation before sensitive actions

Verify security controls

Include adversarial tests containing:

Direct prompt-injection instructions
Malicious instructions inside retrieved documents
Attempts to access unlisted functions
Attempts to modify protected parameters
Requests to reveal secrets
Repeated requests intended to duplicate an action

Use recorded test cases or evaluations so that behavior can be checked again after changing the model, prompt, schema, or application code.

Common Problems and Troubleshooting

The model chooses the wrong function

Possible causes include overlapping tools, vague descriptions, or too many functions being presented at once.

Improve the function names and descriptions, explain when each function should and should not be used, and expose only the tools relevant to the current task.

Required arguments are missing

Make required properties explicit in the schema. Instruct the agent to ask the user for missing information rather than guessing it.

Server-side validation must still reject incomplete calls.

Arguments contain invalid values

Use enumerations, ranges, patterns, and strict schema enforcement where supported. Validate again in application code because schema compliance does not establish authorization or business validity.

The same action runs twice

Add idempotency keys and store the result of completed operations. Before retrying, check whether the original operation succeeded.

The model invents a result after a tool failure

Return a structured error and instruct the model to report the failure accurately. Do not allow it to substitute an assumed result.

A tool-calling loop does not stop

Set limits for tool calls, elapsed time, tokens, retries, and total cost. Record the sequence for diagnosis and return a controlled failure when a limit is reached.

The final response ignores the tool result

Ensure the tool result is associated with the correct call identifier and included in the next model request using the provider’s required message format.

Function Calling, Structured Output, and Retrieval

These techniques solve different problems:

Technique	Primary purpose
Function calling	Requests that application code retrieve data or perform an action
Structured output	Formats the model’s response according to a defined schema
Retrieval-augmented generation	Supplies relevant documents or records as context
Workflow engine	Runs predetermined business processes and approval steps
Direct API integration	Executes fixed logic without model-based tool selection

Use ordinary application code or a workflow engine when the sequence is deterministic. Function calling is most useful when natural-language interpretation is needed to select a controlled operation or populate its parameters.

Important Limitations

Function calling does not guarantee that:

The model will choose the correct tool
Tool arguments will be accurate
A function call is authorized
External information is trustworthy
The model will use the returned result correctly
An action will execute only once
Prompt injection will be prevented
The same model will behave identically after an update

Strict schema enforcement improves structural reliability, but it does not validate user intent, permissions, business rules, or factual correctness.

Organizations using function calling may also need administrator involvement for API credentials, identity management, network access, logging, data governance, compliance review, and approval policies.

FAQ

Frequently Asked Questions

Is function calling the same as running a function?

No. In the common client-side pattern, the model proposes a function name and arguments. The application decides whether to execute it. Some providers also offer server-hosted tools, but execution still occurs in a controlled platform environment rather than inside the language model itself.

Is function calling the same as an AI agent?

No. Function calling is one capability an agent can use. An agent usually also manages instructions, conversation state, planning, retries, tool results, limits, and completion conditions.

Is function calling safe for production systems?

It can be used safely only with appropriate controls. Treat calls as untrusted requests, validate every argument, authorize every operation, use least-privilege credentials, log activity, and require human approval for high-risk actions.

Does JSON Schema prevent invalid tool calls?

It can reduce structurally invalid arguments, particularly when strict enforcement is supported. It does not enforce permissions, ownership, business policies, or user intent. Application-side validation remains mandatory.

Should an agent have direct database access?

Usually, a narrow service API is safer. It can enforce authentication, tenant isolation, permitted queries, field filtering, and audit logging. If database access is necessary, use restricted credentials and parameterized queries; never execute model-generated SQL without strong controls.

Can an agent call multiple functions?

Many tool-capable models can request multiple functions, either in parallel or sequentially. The application must associate each result with the correct call and avoid parallel execution when operations depend on one another or modify the same data.

When should a user be asked for confirmation?

Require confirmation when an action is destructive, costly, externally visible, security-sensitive, difficult to reverse, or materially different from what the user explicitly requested.

Can function calling eliminate hallucinations?

No. It can ground answers in external systems and calculations, but the model may still select the wrong tool, misunderstand results, or make unsupported claims. Verify important outputs and make the application authoritative for critical decisions.

FINAL RECOMMENDATION / CONCLUSION

Use function calling as a controlled interface between an AI model and trusted application services—not as unrestricted permission for the model to operate systems. Start with narrow, read-only functions; define precise schemas; validate and authorize every call; and add timeouts, audit logs, idempotency protection, and tool-call limits.

Introduce state-changing functions only after read-only workflows have been tested. Require explicit human approval for sensitive actions, apply least privilege at every layer, and retest the complete workflow whenever the model, prompt, function schema, permissions, or connected service changes.

#FunctionCalling #AIAgents #ToolCalling #ArtificialIntelligence #LargeLanguageModels #LLM #APIIntegration #JSONSchema #StructuredOutputs #AgentSecurity #PromptInjection #LeastPrivilege #HumanInTheLoop #AIAutomation #ApplicationSecurity #ITProfessionals #SoftwareDevelopment #WorkflowAutomation #AITools #Knowledgebase

SOURCES