Function Calling

The model's token generation is guided by a formal schema (e.g., JSON Schema) that defines required fields, data types, and valid value ranges. This ensures the output is syntactically valid and machine-parseable every time.

• Grammar enforcement: The decoder masks invalid tokens, forcing compliance with the schema
• Type safety: Guarantees strings, integers, booleans, and arrays appear in the correct fields
• Required field completion: The model must populate all mandatory parameters before terminating the output
• Eliminates brittle regex parsing and post-hoc validation of unstructured text

Each callable function is declared with a JSON Schema specification that describes the function's purpose, parameters, and their constraints. The model selects the appropriate tool and populates its arguments based on the user's natural language intent.

• Function declarations include name, description, and a parameters schema
• The model reasons over available tools and selects the semantically correct one
• Parameter grounding: Extracts specific values from the conversation context (e.g., 'Machine 4' → machine_id: 4)
• Supports parallel tool calls when multiple independent actions are required simultaneously

The structured JSON output is not a suggestion—it is a machine-readable instruction that triggers a definitive action in an external system. This bridges the gap between probabilistic language generation and deterministic software execution.

• The JSON payload is passed directly to a pre-defined function in your codebase
• Execution is idempotent when designed with proper error handling
• Enables integration with MES, ERP, SCADA, and PLC systems via their APIs
• The function's return value can be fed back into the model's context for multi-step reasoning loops

By forcing the model to operate within the strict boundaries of a predefined schema, function calling dramatically reduces the surface area for hallucination. The model cannot invent fictional API endpoints or fabricate parameter names.

• Constrained vocabulary: Only valid function names and parameter keys are available
• Enum fields restrict values to a pre-approved set (e.g., status: "active" | "idle" | "fault")
• Invalid tool selections are caught before execution, not after
• Provides a verifiable contract between the AI's reasoning and the system's actions

Function calling enables agentic loops where the model calls a tool, receives the result, reasons about the output, and decides on the next action. This supports complex, multi-step manufacturing workflows.

• ReAct pattern: The model alternates between reasoning and acting
• The conversation history accumulates tool call results as structured context
• Enables error recovery: If a tool call fails, the model can analyze the error and retry with corrected parameters
• Supports conditional branching based on real-time sensor data or database query results

Modern function calling implementations support dispatching multiple independent tool calls in a single response, reducing latency for operations that don't depend on each other.

• The model returns an array of tool calls in one generation step
• Each call is executed concurrently by the orchestration layer
• Example: Simultaneously querying the vibration sensor on Machine 3 and the production schedule for Line B
• Results are aggregated and presented to the model for holistic reasoning in the next turn

The core mechanism that enables a model to produce valid JSON or other machine-parseable formats instead of free-form text. This is achieved through constrained decoding techniques that mask the model's token probability distribution, forcing it to select only tokens that conform to a predefined JSON Schema. In manufacturing, this guarantees that a function call to set_temperature always contains a numeric target_celsius field, preventing runtime API errors.

A formal specification, typically written in JSON Schema or a framework-specific format, that declares the available functions a model can call. Each definition includes:

• name: The unique function identifier (e.g., query_mes_database)
• description: Natural language explaining when to use the tool
• parameters: The expected input schema with types and constraints This schema is injected into the system prompt, teaching the model the 'API contract' it must adhere to.

A critical failure mode where the model generates a function call with plausible but fabricated arguments. For example, it might invent a non-existent machine_id or guess a timestamp without retrieving it from context. Mitigation strategies include grounding the model with retrieved context before the call, using few-shot examples that demonstrate correct sourcing of arguments, and implementing server-side validation that rejects calls with parameters not found in the authoritative system of record.

The ability to request multiple independent function calls in a single turn, dramatically reducing latency for complex queries. A model can simultaneously request the current status of machine_A and the last maintenance log for machine_B rather than sequencing them. This requires the orchestration layer to manage concurrent API execution and aggregate the results back into the model's context window for a final synthesized response.

An agentic loop that interleaves Chain-of-Thought reasoning with function calling. The model first reasons about what information it needs, calls a function to get it, observes the result, and then reasons about the next step. This is foundational for complex manufacturing diagnostics where an agent might query a sensor, analyze the reading, and then decide to call a different diagnostic tool based on the result, creating a dynamic, non-linear execution path.