Chapter 13: Building AI-powered applications

Introduction

This chapter introduces integrating generative AI into applications through APIs, especially function calling that turns model output into structured input for application logic.

• AI application integration: Describe how generative AI can be added to application features through standard REST APIs without requiring deep AI-model expertise. Give examples from the section, such as natural-language interaction with data, document sorting, realistic test-data creation, or automated data cleanup.
  Why it matters: This frames AI integration as an accessible application-development capability rather than a specialized AI research task.
• Function calling purpose: Explain function calling as an API feature that makes an AI model return output matching predefined functions so application logic can use it. Distinguish this meaning from ordinary programming functions or a generic chat interface.
  Why it matters: Function calling provides the bridge between flexible natural-language model output and reliable, structured application behavior.
• Integration platform choices: State that the chapter concentrates on OpenAI's function-calling implementation because it is popular and easy to use, while recognizing that other models offer similar features and Microsoft provides Copilot-, plugin-, connector-, and Azure-based integration options.
  Why it matters: Knowing that function calling is an integration pattern rather than an OpenAI-only idea helps you evaluate platform choices for your environment.

Key terms: generative AI, REST APIs, AI integration, function calling, predefined functions, application logic, structured data, OpenAI, OpenAI function calling, Microsoft Copilot

13.1 Function calling

This section introduces OpenAI function calling as a way for an application to receive structured AI output and safely execute its own functions.

• Function calling workflow: Trace how OpenAI function calling moves from defined function specifications to model-generated JSON, then to application code that parses the JSON and executes the matching function.
  Why it matters: This workflow lets you connect a model’s response to useful, controlled application behavior.
• Application-controlled execution: Explain why application code, rather than the OpenAI API, executes functions, including the opportunity to add security measures, validate inputs, and handle errors.
  Why it matters: Keeping execution in your application gives you control over what AI-generated requests are allowed to do.
• Function calling versus GPT Actions: Distinguish function calling, which structures AI output for an application to use, from OpenAI GPT Actions, which enable access to live data.
  Why it matters: Separating these capabilities helps you choose the right OpenAI feature for structured application behavior versus live-data access.

Key terms: function calling, OpenAI API, function specifications, JSON, parameters, security measures, validate inputs, handle errors, application code, OpenAI GPT Actions

13.1.1 Chatting with the OpenAI API

This section compares the Chat Completions and Assistants APIs and explains why the Assistants API is used to build context-aware AI copilots.

• OpenAI API interaction models: Distinguish the Chat Completions API from the Assistants API in terms of their inputs, responses, customization, context handling, and suitable uses.
  Why it matters: Choosing the appropriate API model determines whether an AI application can provide the continuity its users need.
• Assistants API copilot choice: Justify using the Assistants API for an AI copilot by explaining how retained conversation context and developer-defined goals let it interpret later user questions effectively.
  Why it matters: A copilot needs continuity across turns so that its responses reflect both the ongoing user conversation and the application's intended role.

Key terms: Chat Completions API, Assistants API, messages, conversation threads, tools, function calling, AI copilot, conversation context, developer goals, instructions

13.1.2 Building a database copilot

This section frames a database copilot proof of concept and explains how system, user, and assistant roles provide database context and structure its conversations with the OpenAI API.

• Database copilot purpose: Explain what a database copilot does and how it differs from a basic chatbot in the Northwind proof of concept.
  Why it matters: A copilot becomes useful when it helps people work with specialized data and tasks rather than merely chatting.
• Data sent to OpenAI: Describe the proof-of-concept data flow: the application sends database information to OpenAI for answering questions rather than requiring OpenAI to access the local database directly.
  Why it matters: This approach avoids treating the model as a direct connection into a production database.
• Conversation role responsibilities: Describe the respective responsibilities of the system, user, and assistant roles in the API payload for the database copilot.
  Why it matters: Correct role setup gives the model lasting context, a clear request, and an appropriately structured response.
• System context and token tradeoffs: Explain why database-schema instructions in the system role should be specific enough for the application while being balanced against the model's token limit, including function definitions.
  Why it matters: A well-sized system payload can improve answer relevance without exceeding the available context window.

Key terms: copilot, database copilot, proof of concept (POC), Northwind sample database, OpenAI API, local agents, firewall changes, production data, API payload, system role

13.1.3 Implementing function calling

This section explains how an application uses OpenAI function calling to generate, validate, and safely execute database SQL in response to a user question.

• Function-calling application control: Explain how function calling links an AI model to application-defined functions and why the application, rather than OpenAI, controls their implementation. Describe the JSON function-call response and the application's role in parsing it, running the appropriate code, and enforcing security, validation, and error handling.
  Why it matters: Function calling lets an AI assistant request useful actions without giving the model uncontrolled access to your systems.
• Database copilot query workflow: Trace the database copilot workflow from a user's data question through SQL generation, SQL validation, database execution, and return of the result. Explain that the copilot mirrors the steps an experienced database developer follows.
  Why it matters: Separating query creation from checking helps an AI assistant answer database questions through a deliberate, safer workflow.
• Unsafe query rejection: Describe how the copilot handles SQL that is unsafe or invalid: it rejects the query and handles the error rather than executing it. Use the request to delete all 1996 orders as an example of a potentially harmful operation that should produce an error message.
  Why it matters: Rejecting harmful or invalid queries prevents an AI assistant from turning a natural-language request into damaging database changes.

Key terms: function calling, OpenAI API, JSON, security, validation, error handling, database copilot, get_sql_query, examine_sql, SQL query

13.2 The functions

This section introduces the end-to-end function-calling workflow for a natural-language database assistant and emphasizes database safety safeguards.

• Database assistant query workflow: Trace how an AI database assistant handles a natural-language question, from generating SQL through validating and running it to returning a natural-language answer.
  Why it matters: This workflow shows how function calling connects an AI assistant to a database without making the database interaction invisible to the application.
• Layered database query protection: Explain why AI-generated database queries need safeguards beyond AI validation, including read-only database accounts or other security measures.
  Why it matters: Validation can reduce risk, but database permissions provide a separate safeguard if an AI-generated query is dangerous.
• Implementation tool choices: State that the example uses PowerShell and Invoke-DbaQuery because they are familiar to many SQL Server IT professionals, while equivalent implementations can use C# with Microsoft.Data.SqlClient, the OpenAI Python SDK, or curl.
  Why it matters: The function-calling pattern is not tied to one programming language or client tool.

Key terms: function calling, examine_sql, Invoke-DbaQuery, OpenAI API, REST, PowerShell, read-only database accounts, query validation, dangerous queries, SQL Server

13.2.1 What matters in AI function design

This section explains how well-defined AI functions produce structured JSON that an application can parse, validate, and use predictably for database-related tasks.

• Structured function-call workflow: Trace the application flow for AI function calling: the API payload defines functions and expected data structures, the model selects an appropriate function for a user request, returns matching JSON, and the application extracts that data to perform a task or respond to the user.
  Why it matters: This workflow makes AI features more predictable and manageable than relying on unstructured natural-language responses.
• Structured SQL response handling: Describe how a SQL query generated through a function call is returned in layered AI response data, parsed into a simple JSON object, and then available for validation or direct use by the application.
  Why it matters: Parsing a structured SQL value lets the application handle a query consistently rather than trying to extract it from conversational text.
• Application query execution integration: State that, after structured data has been processed, an application can execute database queries and return results to the AI assistant, for example by using Invoke-DbaQuery locally or by calling the REST API from application code with libraries such as Python requests or Node axios.
  Why it matters: The structured response becomes useful only when application code connects it to real operations and, when needed, sends results back to the assistant.

Key terms: functions, API payload, structured JSON, function calling, SQL query, examine_sql, parsed SQL query, Invoke-DbaQuery, REST API, Python requests

13.3 Validating SQL queries with examine_sql

Introduces the examine_sql function as an ad hoc AI validation step that identifies whether generated SQL is valid and potentially dangerous before it affects a database.

• examine_sql validation role: Explain that examine_sql checks generated SQL queries for validity and potential danger, helping protect database security and integrity.
  Why it matters: Checking AI-generated SQL before use reduces the risk of unsafe queries damaging or exposing a database.
• validation result JSON: Describe the JSON object returned by examine_sql: it indicates whether a SQL query is valid and potentially dangerous, and includes an explanation when the query is dangerous.
  Why it matters: A structured result lets the application act on a safety finding and communicate the reason for it.
• ad hoc completion usage: State that get_sql_query and examine_sql use ad hoc chat completions, meaning quick, separate AI responses outside the main conversation.
  Why it matters: Using separate completions distinguishes these focused function operations from the application's ongoing conversation.

Key terms: examine_sql, generated SQL queries, valid, potentially dangerous, database security, database integrity, JSON object, explanation, get_sql_query, ad hoc chat completions

13.3.1 Defining what makes a query dangerous

This subsection defines application-specific rules for recognizing dangerous SQL so examine_sql can keep AI-generated queries safe.

• Application-specific SQL danger rules: Explain that what makes an SQL query dangerous depends on an application's own requirements, and describe the example rules used to flag risky queries.
  Why it matters: Explicit danger rules let an application decide which AI-generated database actions are safe to permit.
• Natural-language function calls: State that developers can use natural language with function calls, and explain why the subsection characterizes this as powerful.
  Why it matters: Natural-language interaction can make application functions easier to use while application rules still constrain their actions.

Key terms: dangerous, examine_sql, DELETE, UPDATE, WHERE clauses, database schema, natural language, function calls

13.3.2 Generating a user-friendly response

This subsection explains that, after a SQL query is generated, validated, and executed, the assistant turns its results into a conversational response while function calling provides a safer interface to database operations.

• Conversational query-result responses: Describe how the assistant produces a user-friendly conversational response after a SQL query has passed the generate, validate, and execute steps.
  Why it matters: A database copilot must communicate query results in a form that users can understand and use.
• Function-calling database interface: Explain how function calling forms a clear interface between an AI model and database operations, reducing security risks while preserving flexibility.
  Why it matters: This interface enables AI capabilities to be integrated into database workflows without giving the model uncontrolled database access.

Key terms: generate, validate, execute, conversational response, function calling, AI models, database operations, security risks, flexibility

13.3.3 AI-powered SQL assistance in action

This section illustrates how function calling can power a practical AI workflow by automating HR training-data cleanup from vendor CSV files into a SharePoint list.

• AI-driven HR cleanup workflow: Describe the HR data-cleanup case study as an AI-powered workflow that extracts and cleans messy vendor training-data exports, then updates a target SharePoint list.
  Why it matters: This shows how a concrete business process can be redesigned around AI rather than handled manually.
• Workflow architecture and rollout: Trace the components and delivery steps of Chrissy's solution: vendor CSV files in a SharePoint document library, a Power App to start processing, Azure OpenAI Service with function calling, automated SharePoint-list updates, and testing with HR before deployment.
  Why it matters: Being able to describe the surrounding workflow helps turn an AI capability into an adoptable business application.
• Automation opportunity lessons: Explain the business results and lessons from the case study: removing manual processing saved HR time, AI consistency checks improved accuracy, stakeholder collaboration and existing platforms accelerated implementation, and demonstrated business impact supported technical leadership.
  Why it matters: The case shows that successful AI work combines a worthwhile automation target, user collaboration, and visible business value.

Key terms: function calling, Azure OpenAI Service, Power App, SharePoint Online, SharePoint list, vendor CSV files, SharePoint Online document library, testing and refining, deployment and documentation, automation opportunities

13.4 Practical applications and security considerations

This section introduces real-world uses of function calling beyond databases and highlights the need for strong security practices.

• Practical function-calling applications: Describe how function calling can simplify practical tasks by letting AI interpret a natural-language request and trigger the appropriate function, including currency conversion, data extraction, and image processing.
  Why it matters: This connects AI conversations to useful application actions rather than limiting them to database work.
• Function-calling security needs: Explain why function-calling applications require solid security practices: enabling AI to trigger real functions gives it powerful capabilities that must be protected.
  Why it matters: Security safeguards are essential when an AI can cause application functions to run in response to user requests.

Key terms: function calling, natural requests, currency conversion, data extraction, image processing, security practices

13.4.1 Example: AI-powered currency conversion

This subsection illustrates function calling with an AI-powered Python currency converter and highlights how external functions and structured data expand AI application capabilities.

• Currency converter architecture: Describe how the currency-conversion assistant divides work between OpenAI's API and the forex_python library: the AI interprets the user's request, while the library performs the actual conversion.
  Why it matters: This division lets an application use natural-language AI without asking the model to perform or invent the external-data operation itself.
• Function calling applications: Explain that function calling enables AI to complete specific tasks through external data and custom functions, including data-entry validation, extracting structured image information, and pulling action items or key points from meeting notes.
  Why it matters: Recognizing this pattern helps you identify tasks where AI can turn unstructured requests or content into useful structured application output.
• Structured AI application capabilities: Explain that function calling improves AI applications by providing structured data and enabling more capable AI features, while developers must treat security as a top priority when implementing it.
  Why it matters: More capable AI integrations also create security responsibilities when a model can trigger application functions or access outside services.

Key terms: OpenAI API, forex_python, function calling, currency conversion, external data, custom functions, typed values, structured labels, action items, structured data

13.4.2 Security considerations for function calling

This section explains how to secure AI function-calling applications by treating model output as untrusted and applying layered safeguards before production.

• Untrusted AI input handling: Explain why function-call arguments from even trusted AI models must be treated as potentially malicious or unexpected input, and describe validation measures for SQL, file paths, and structured responses.
  Why it matters: Treating AI output as untrusted prevents a model response from becoming an injection attack, unsafe file access, or executable code.
• Layered function access safeguards: Describe the operational safeguards around AI functions: minimum permissions, nonrevealing error handling, rate limits based on call characteristics, and audit logging with alerts.
  Why it matters: Validation alone is not enough, because limited access, controlled failures, and audit trails reduce the impact and improve detection of unsafe calls.
• Adversarial security testing: Describe testing a function-calling application with adversarial prompts that attempt forbidden data access or dangerous commands, then correcting discovered weaknesses before production.
  Why it matters: Deliberately trying to break the application exposes security holes before attackers or unexpected model behavior do.
• Structured outputs distinction: Distinguish structured outputs from function calling: function calling lets an AI wait for external data or actions, whereas structured outputs enforce an exact response format without expecting a return call.
  Why it matters: Choosing the right approach helps produce reliable, machine-processable AI data for cloud or local models.

Key terms: input validation, strict type checking, whitelisting, parameterized queries, string concatenation, path validation, access controls, minimum permissions, read-only accounts, human review

13.5 Prompts used in this chapter

This section provides an editorial prompt for organizing and revising chapter content with AI.

• Chapter revision prompt: Describe the prompt’s three requested editorial tasks: suggesting where to place an attached case study in the chapter, advising whether GPT Actions information belongs in the chapter or appendix, and reordering summary bullets to match their order of appearance.
  Why it matters: A single clear prompt can help organize chapter material and align its summary with the content.

Key terms: case study, GPT Actions, appendix, summary bullets

13.6 Summary

This summary recaps how AI-powered applications use function calling, context-aware copilots, automation integrations, and security controls to make IT workflows safer and more effective.