An LLM by itself cannot query a database, create a CRM ticket, or send an email. If your bot can only generate text, it's useless for business tasks. We solve this with Function Calling: a mechanism where the model analyzes the request, determines the needed tool and its parameters, and the host application executes the call and returns the result. That's how an agent becomes a full participant in business processes.
Without a clear tool schema, the model may generate arbitrary JSON that fails validation. This leads to integration failures and user dissatisfaction. Our team developed an approach based on Pydantic validation that eliminates such issues.
Our approach is not just connecting an API; it's designing an architecture that withstands real load. We use the stack: OpenAI GPT-4o, Claude 3.5, Hugging Face Transformers for local models, LangChain for orchestration, Qdrant for vector search. All configs are stored in Git; tool schemas are versioned. More about the mechanism can be read in the OpenAI documentation.
How Function Calling Works
The model receives tool descriptions in JSON Schema format. When a user request requires an external service call, the model returns a structured object with the function name and parameters. The host executes the call and returns the result. The cycle repeats until the final response.
What Problems Does Function Calling Solve?
Chaotic model output — the model may generate arbitrary JSON that doesn't match the schema. We describe tools via JSON Schema and validate execution with Pydantic.
Context loss in long call chains — if the agent makes 5–10 sequential calls, context may blur. We use history chunking and semantic compression.
Latency — sequential tool calls can take seconds. Parallel tool calls in GPT-4o reduce total execution time by 60% compared to sequential.
API execution errors are common. Our agent has fallback logic: retry after 1 second, escalate to operator after three failures.
What Stack Do We Use?
We use the stack: OpenAI GPT-4o, Claude 3.5, Hugging Face Transformers for local models, LangChain for orchestration, Qdrant for vector search. All configs are stored in Git; tool schemas are versioned.
Basic Agent Loop with OpenAPI
from openai import OpenAI
import json
client = OpenAI()
# Tool schema
tools = [
{
"type": "function",
"function": {
"name": "get_customer_info",
"description": "Get customer info by ID or email",
"parameters": {
"type": "object",
"properties": {
"customer_id": {"type": "string"},
"email": {"type": "string"},
"fields": {
"type": "array",
"items": {"type": "string"},
"description": "Required fields: name, orders, balance, status"
}
},
}
}
},
{
"type": "function",
"function": {
"name": "create_support_ticket",
"description": "Create a support ticket",
"parameters": {
"type": "object",
"properties": {
"customer_id": {"type": "string"},
"category": {"type": "string", "enum": ["billing", "technical", "account", "shipping"]},
"priority": {"type": "string", "enum": ["low", "medium", "high", "critical"]},
"description": {"type": "string"},
},
"required": ["customer_id", "category", "description"]
}
}
},
]
# Function registry
def get_customer_info(customer_id=None, email=None, fields=None) -> dict:
# Real implementation: query CRM/DB
return {"id": customer_id, "name": "Ivanov I.I.", "balance": 15000, "status": "active"}
def create_support_ticket(customer_id: str, category: str, description: str, priority: str = "medium") -> dict:
# Real implementation: Jira/Zendesk API
return {"ticket_id": "TKT-12345", "status": "created"}
FUNCTION_MAP = {
"get_customer_info": get_customer_info,
"create_support_ticket": create_support_ticket,
}
# Agent loop with Function Calling
def run_support_agent(user_message: str) -> str:
messages = [
{"role": "system", "content": "You are a support agent. Use tools to assist customers."},
{"role": "user", "content": user_message},
]
while True:
response = client.chat.completions.create(
model="gpt-4o",
messages=messages,
tools=tools,
tool_choice="auto",
parallel_tool_calls=True, # Parallel calls
)
message = response.choices[0].message
messages.append(message)
if not message.tool_calls:
return message.content
# Execute all calls (parallel if multiple)
for tool_call in message.tool_calls:
func_name = tool_call.function.name
func_args = json.loads(tool_call.function.arguments)
func = FUNCTION_MAP.get(func_name)
if func:
result = func(**func_args)
else:
result = {"error": f"Function {func_name} not found"}
messages.append({
"role": "tool",
"tool_call_id": tool_call.id,
"content": json.dumps(result, ensure_ascii=False),
})
Why Parallel Tool Calls Are More Efficient
Parallel tool calls in GPT-4o allow multiple tools to be called in one response. This sharply reduces latency and the number of rounds. Compare:
| Parameter | Sequential Calls | Parallel Tool Calls |
|---|---|---|
| Average response time | 6.2 s | 2.5 s |
| Number of rounds | 3-5 | 1-2 |
| Risk of context loss | high | low |
Our experience shows that in typical scenarios, parallel tool calls speed up agent response by 2.3 times.
Practical Case: Agent for HR Queries
From our practice — implementing an agent for the HR department of a large retailer. Tools: get_employee_info, check_vacation_balance, submit_vacation_request, get_company_policy. Query: "I want to take vacation from April 15 to April 25. Do I have enough days?"
Agent trajectory:
-
get_employee_info(employee_id="emp_789")— get ID from session context -
check_vacation_balance(employee_id="emp_789")— balance: 14 days -
get_company_policy("vacation_approval")— read approval rules - Final response: "You have 14 vacation days. The period April 15–25 is 11 working days (including holidays). Your balance is sufficient. To proceed, submit_vacation_request. Your request must be approved by your manager within 3 working days according to policy."
Metrics for the first month:
- Queries handled autonomously (without operator): 84%
- Accuracy of balance/policy info: 97%
- Average response time: 4.2s
Parallel tool calls gave a 40% speed improvement over sequential. All calls are validated via Pydantic before execution — zero crashes in a month.
Example full code of HR agent
# Code for HR agent will be here
# ...
What Are the Development Stages?
- Analytics: study business processes, identify integration points.
- Design: develop tool schemas, routes, fallback logic.
- Implementation: write the agent, integrate with corporate systems (ERP, CRM, knowledge base).
- Testing: unit tests for each function, integration scenarios, A/B tests against the current system.
- Deployment and monitoring: deploy, set up logging and alerts for latency P99 and accuracy.
Approximate Timeline
| Stage | Duration |
|---|---|
| Agent development with 3–7 tools | 2–4 weeks |
| Integration with corporate systems | 2–4 weeks |
| Testing and monitoring | 1–2 weeks |
| Total | 5–10 weeks |
What Is Included in the Result?
- Documentation: tool schema descriptions, architecture, extension guide.
- Source code: repository with agent loop, tests, configs for MLOps (Weights & Biases, MLflow).
- CI/CD pipeline: automated build, testing, deployment.
- Team training: workshop on adding new tools.
- Support: 2 weeks post-production monitoring.
Average project cost is determined individually based on number of tools and integration complexity. The savings from implementation can be significant.
Guarantees and Support
We have experience with over 15 AI agent implementations with Function Calling in production. We guarantee quality: each agent undergoes load testing and code review. We use best practices: schema validation, retry logic, observability.
Contact us for a consultation — we'll find the optimal solution for your task. Order AI agent development and get first results within a week.
OpenAI documentation







