WEBVTT

00:00.040 --> 00:07.320
Modern AI applications demand far more than fluent text generation, as introduced on the opening slide

00:07.320 --> 00:08.160
of this deck.

00:08.520 --> 00:15.600
Real systems must interact with databases, invoke APIs, and execute business logic in a controlled

00:15.600 --> 00:16.760
and reliable way.

00:17.200 --> 00:20.080
Traditional language models operate in isolation.

00:20.360 --> 00:24.120
They can describe what should be done, but they cannot actually do it.

00:24.600 --> 00:31.680
Tool using Llms change this paradigm by enabling models to request actions through structured interfaces.

00:31.880 --> 00:35.640
We move from conversational AI to operational AI.

00:36.360 --> 00:42.200
The language model becomes an intelligent decision maker that understands intent, selects the correct

00:42.200 --> 00:46.040
action, and provides structured inputs for execution.

00:46.520 --> 00:49.400
This shift is foundational for production systems.

00:49.840 --> 00:56.280
Instead of relying on humans to interpret and execute model outputs, applications can integrate Llms

00:56.280 --> 01:02.970
directly into workflows, whether it's fetching records, triggering processes or coordinating services.

01:03.290 --> 01:08.890
Tool using LMS allow AI to participate meaningfully in real world systems.

01:08.930 --> 01:14.290
Throughout this section, we'll explore how function calling enables this transformation.

01:14.650 --> 01:22.410
Why structured outputs are mandatory and how these concepts form the backbone of modern AI agents.

01:23.050 --> 01:27.610
This slide highlights a critical limitation of traditional language models.

01:27.930 --> 01:32.330
They are confined to text as shown on page two of the deck.

01:32.570 --> 01:39.810
Plain LMS excel at generating explanations, suggestions and summaries, but they cannot interact with

01:39.810 --> 01:41.010
external systems.

01:41.610 --> 01:44.810
Any real action still requires human intervention.

01:45.210 --> 01:46.570
Production applications.

01:46.570 --> 01:54.610
However, demand automation systems must be able to query databases, call Rest APIs, execute business

01:54.610 --> 01:56.970
logic, and coordinate workflows.

01:57.490 --> 02:04.140
Tool using LMS bridge this gap by allowing models to interface directly with existing infrastructure.

02:04.700 --> 02:12.380
The most important shift described here is conceptual llms evolve from advisors to operators, instead

02:12.380 --> 02:14.420
of merely suggesting what should be done.

02:14.580 --> 02:19.660
They actively participate in executing tasks within your system architecture.

02:20.420 --> 02:27.700
This change unlocks new classes of applications, from intelligent customer support to automated operations

02:27.700 --> 02:29.060
and internal tooling.

02:29.660 --> 02:36.700
It also reduces friction, error rates and latency by removing humans from repetitive execution loops.

02:37.380 --> 02:40.020
Tool using Llms are not just a feature.

02:40.260 --> 02:43.580
They are a requirement for production grade AI systems.

02:44.420 --> 02:51.140
Function calling is the mechanism that enables Llms to interact with tools in a safe and structured

02:51.140 --> 02:51.540
way.

02:52.220 --> 02:59.060
As described on page three of the deck, the model analyzes user intent, evaluates available tools,

02:59.220 --> 03:05.350
and generates a structured request specifying which function should be called and with what parameters.

03:06.030 --> 03:08.590
There are three core capabilities involved.

03:08.910 --> 03:10.750
First, tool selection.

03:11.030 --> 03:14.910
The model chooses the most appropriate function based on the user's request.

03:15.270 --> 03:21.830
Second argument structuring the model generates properly formatted parameters that conform to the function

03:21.830 --> 03:22.430
schema.

03:22.990 --> 03:25.150
Third execution timing.

03:25.470 --> 03:30.110
The model determines when a function call is required rather than a text response.

03:30.630 --> 03:32.870
A critical distinction is emphasized here.

03:33.390 --> 03:35.510
Llms do not execute code.

03:35.790 --> 03:37.590
They never run functions directly.

03:37.870 --> 03:44.950
Instead, they generate structured requests that your application validates and executes within a controlled

03:44.950 --> 03:45.830
environment.

03:46.150 --> 03:51.870
This separation is essential for safety, security, and reliability.

03:52.310 --> 03:59.470
The model handles reasoning and decision making while your system retains full control over execution.

03:59.480 --> 04:06.600
Understanding the end to end architecture of tool calling is essential for building reliable systems.

04:07.240 --> 04:12.200
As shown on page four of the deck, the process begins with tool definition.

04:12.640 --> 04:19.840
Developers explicitly define available tools, including parameter schemas, types, and descriptions.

04:20.400 --> 04:22.680
Next comes context assembly.

04:23.120 --> 04:29.200
The LM receives the user request along with the complete tool schemas and system instructions.

04:29.800 --> 04:37.440
Using this context, the model analyzes intent and outputs a structured JSON object specifying the selected

04:37.440 --> 04:39.240
function and its arguments.

04:39.800 --> 04:41.840
The application then takes over.

04:42.200 --> 04:48.240
It, validates the parameters against the schema, and executes the function within a controlled environment.

04:48.560 --> 04:55.040
The result of that execution is passed back to the LM, which can interpret it and generate a final

04:55.040 --> 04:56.520
response for the user.

04:56.680 --> 05:00.980
This architecture enforces a clean separation of concerns.

05:01.580 --> 05:08.140
The LM is responsible for reasoning and selection while the application controls execution.

05:08.900 --> 05:15.660
This design is what makes tool using LM safe, auditable, and production ready.

05:15.700 --> 05:23.020
Natural language is powerful for communication, but it is fundamentally unreliable for system integration.

05:23.500 --> 05:30.700
As outlined on page five of the Dec, free form text is ambiguous, difficult to parse, and inconsistent

05:30.700 --> 05:31.500
in structure.

05:32.180 --> 05:38.300
Extracting data from natural language requires fragile logic that often fails in edge cases.

05:38.900 --> 05:45.340
Back end systems, on the other hand, require precision APIs expect specific types.

05:45.700 --> 05:51.980
Databases rely on strict schemas, and validation logic depends on deterministic formats.

05:52.540 --> 05:57.060
Natural language outputs simply cannot meet these requirements at scale.

05:57.580 --> 06:00.350
This is why structured outputs are Inputs are mandatory.

06:00.910 --> 06:05.910
JSON provides a predictable, machine readable format that systems can trust.

06:06.350 --> 06:13.670
It enables type safety, schema validation, and deterministic parsing by forcing Llms to communicate

06:13.670 --> 06:15.110
through structured outputs.

06:15.390 --> 06:20.110
We transform unpredictable text into reliable system inputs.

06:20.750 --> 06:22.510
This is not an optimization.

06:22.750 --> 06:26.550
It is a prerequisite for safe and scalable deployment.

06:27.030 --> 06:31.670
Without structured outputs, tool calling becomes brittle and unsafe.

06:31.990 --> 06:36.510
This slide shows how structured outputs work in real systems.

06:36.910 --> 06:44.350
JSON serves as a contract between the LLM and your application, as shown on page six of the deck.

06:44.670 --> 06:51.110
Each function call includes a deterministic structure with a function identifier and a typed parameters

06:51.110 --> 06:51.750
object.

06:52.590 --> 06:57.710
Deterministic structure ensures consistent parsing and predictable error handling.

06:58.190 --> 07:02.600
Type safety Prevents invalid values from propagating through the system.

07:03.160 --> 07:08.240
Schema based validation allows applications to catch errors before execution.

07:08.360 --> 07:10.080
Protecting system integrity.

07:10.760 --> 07:17.320
The example JSON illustrates common fields such as the function name, parameter keys, and values that

07:17.320 --> 07:19.200
conform to predefined types.

07:19.800 --> 07:26.640
This structure allows backend services to integrate seamlessly with Lem outputs without brittle parsing

07:26.640 --> 07:27.320
logic.

07:27.320 --> 07:34.040
In practice, structured outputs dramatically reduce runtime errors and simplify debugging.

07:34.680 --> 07:40.960
They also enable logging, monitoring and auditing, all critical for enterprise systems.

07:41.400 --> 07:50.240
Structured outputs turn Llms into dependable components within a larger software architecture tool using

07:50.280 --> 07:57.640
Llms shine in real world applications that require orchestration across systems, as illustrated on

07:57.640 --> 07:58.920
page seven of the deck.

07:59.160 --> 08:06.930
They can execute complex database operations, automate workflows, and coordinate external APIs in

08:06.930 --> 08:08.210
database scenarios.

08:08.450 --> 08:15.330
Llms can generate structured queries, fetch records, update profiles, or aggregate analytics across

08:15.330 --> 08:18.730
multiple tables in workflow automation.

08:18.850 --> 08:25.010
They can trigger multi-step processes, manage approvals, and coordinate event driven architectures.

08:25.690 --> 08:32.890
External API integration allows Llms to synchronize data across platforms and orchestrate microservice

08:32.930 --> 08:33.890
interactions.

08:34.330 --> 08:41.050
They can also perform computational tasks such as financial calculations, report generation, and statistical

08:41.050 --> 08:42.810
analysis with high precision.

08:43.610 --> 08:48.450
The key insight here is powerful llms become orchestrators.

08:48.770 --> 08:54.770
They understand intent, choose the right actions, and coordinate execution across systems.

08:55.450 --> 08:59.780
This elevates AI from a conversational layer to an operational one.

08:59.780 --> 09:06.700
This final slide summarizes the transformation enabled by tool calling, as shown on page eight of the

09:06.700 --> 09:07.900
deck tool.

09:07.900 --> 09:15.060
Using LMS allow systems to move beyond conversation into real integration with production infrastructure.

09:15.660 --> 09:17.740
Structured outputs are not optional.

09:18.220 --> 09:24.020
JSON based communication is essential for safety, reliability and validation.

09:24.580 --> 09:28.420
Without it, systems cannot be trusted to behave predictably.

09:28.660 --> 09:33.740
Most importantly, tool using LMS form the foundation for AI agents.

09:34.340 --> 09:41.180
These agents can reason about tasks, select appropriate tools, and execute complex, multi-step workflows

09:41.180 --> 09:42.140
autonomously.

09:42.700 --> 09:44.500
The transformation is complete.

09:44.940 --> 09:47.540
Language models are no longer just chatbots.

09:47.980 --> 09:51.940
They become software components that integrate directly into your systems.

09:52.540 --> 09:58.660
This shift unlocks a new generation of intelligent applications that are reliable, controllable, and

09:58.660 --> 09:59.740
production ready.