Q&A

Practical AI Integration: From API Call to Production Feature

• By David Ramel
• 09/15/2026

For application developers, adding generative AI no longer necessarily means building an entirely new system around a language model. Increasingly, the more practical question is how to bring selected AI capabilities into applications that already exist -- and do it in a way that fits familiar development, testing, security and operations practices.

Microsoft's Microsoft.Extensions.AI libraries, for example, provide common .NET abstractions for working with AI services, including the IChatClient interface for chat capabilities and IEmbeddingGenerator for generating embeddings. Those abstractions are intended to reduce coupling to a particular AI provider while giving developers familiar patterns for integrating model capabilities into .NET applications.

Embeddings also underpin another increasingly common application pattern: semantic search. Rather than relying only on exact keyword matches, developers can represent text as vectors and compare those representations to retrieve conceptually similar information. Microsoft's .NET vector-search guidance shows how that approach can be used for semantic search and retrieval-augmented generation (RAG), in which relevant information from an organization's own data is retrieved and supplied to a language model to help ground its response.

Then there is function calling, or tool calling, which can connect a model to the capabilities developers have already built. Microsoft's .NET documentation on AI tool calling describes a pattern in which a model requests that an application invoke a .NET method, external API or other executable operation and then receives the result. That can turn an LLM from a text generator into another interface for interacting with existing application logic.

Those are among the patterns that Kevin Feasel, Microsoft Data Platform MVP and proprietor of Catallaxy Services, LLC, will explore in the intermediate-level Practical AI Integration: From API Call to Production Feature session at Live! 360 Tech Con 2026 in Orlando.

Kevin's Nov. 17 presentation takes a deliberately practical approach. The session description promises five feature types -- classification, summarization, semantic search, data extraction and content generation -- along with demonstrations of LLM APIs, embeddings, RAG pipelines and function calling. Attendees will also hear about the less glamorous but essential parts of production AI development, including error handling, testing and cost control.

That production focus is significant because a successful model call is only the beginning. As Kevin explains in the Q&A below, developers eventually need to contend with imperfect real-world data, end-user workflows, authentication and authorization, monitoring, failures and AI-specific risks such as plausible-sounding but incorrect output. The goal is not simply to bolt a chatbot onto an application, but to decide where AI adds value and then integrate it without abandoning the engineering disciplines that make conventional software dependable.

Kevin brings a broad data background to that discussion. His conference bio describes him as a Microsoft Data Platform MVP whose work spans analytics, T-SQL, R, Spark and Kafka. In his view, generative AI is most useful when treated as one component of a larger solution rather than as the solution itself -- a theme that runs throughout both his session and the following Q&A.

We caught up with Kevin to learn what inspired the presentation, where developers should begin with AI integration, when RAG and function calling make sense, and what teams need to consider before putting an AI-powered feature into production.

PureAI: What Inspired You to Present on This Topic?
Kevin: My inspiration for this session comes from delivering AI trainings and from my own experiences in building up production AI solutions in my own workplace. As technologists, we tend to get wrapped up in the hot new technology and how neat it is, rather than focusing on treating generative AI as a means rather than the end. This desire to make generative AI a part of the puzzle rather than some kind of solution in itself inspired me to come up with this session.

Which AI Feature Is Usually the Easiest Starting Point for Developers Adding AI to an Existing Application?
I think classification is probably the easiest starting point for adding AI to an existing application. Classification is a single call with a constrained output--we define the set of viable answers beforehand and ask the language model to choose from that list. We typically have an evaluation set already available to us--either this is classification work that humans are already doing (such as triaging support tickets or defining which customer accounts might need a closer investigation), or it is work where your subject matter experts can give you solid information on what correct answers look like.

What Separates a Successful LLM API Demo from a Production-Ready Application Feature?
There are several differences between a basic application and a final product. On the development side, this includes working with the data as it is, rather than some sample dataset you can generate without flaws. It involves understanding the workflow for your end users and how they will actually get value from the application. On the infrastructure side, this includes ensuring that we can track calls, monitor the service, ensure (to the best of our ability) that the service is doing what we expect it to, and is resilient to failure. On the security side, this includes the standard rules of authorization and authentication, as well as ensuring against data leakage, inappropriate escalation of privileges, and preventing issues like injection attacks.

What Is the Clearest Sign That an Application Would Benefit from RAG?
Retrieval-augmented generation (RAG) is all about semantic search over text-based documents. In other words, I want to search for something but I don't want to guess exactly the right words the author used. That's the sweet spot for RAG. If your search capabilities are just a set of numeric or date range comparisons, or choosing items from drop-down lists with limited selection, RAG isn't necessary. If your users are searching on exact terms and proper nouns, RAG likely won't help. But when you want to enable people to use their own words and try to find relevant answers in long-form natural language text, that's when RAG pays off.

Where Does Function Calling Become Especially Useful in an Existing Application?
Function calling is actually what opens up a lot of our existing applications to AI capabilities. Language models have no understanding of the world and certainly no ability on their own to know your company's business rules or internal requirements. But with functions (or tools), we open a world of new capability for models. We can perform mathematical operations, look up business records, apply payments to invoices, and so much more, all using the same code we've developed, tested, and know works. Function calling turns your language model into a new form of user interface, and if you've developed applications that expose well-behaved APIs, you enable not only new functionality within an application, but also across applications.

What AI-Specific Failure Condition Should Developers Plan for from the Beginning?
The most important AI-specific failure condition is that your model will confidently provide incorrect answers. Language models will happily play make-believe with you, and the language models are geared toward giving an answer rather than saying, "Sorry, dunno." And the tricky part is, the shape of a wrong answer looks very similar to the shape of a right one. This means that all of the protections we build into our software around error handling, tracking response codes, checking output formats, retrying failed requests, and so on won't catch a model that confidently spews out syntactically correct nonsense. And for people who are not knowledgeable about the topic, it may even be facially plausible. A language model might say that the person installing the ABC widget needs a 5/8" socket wrench for installation and requires the installer to adjust the fastener to exactly 15 foot-pounds of torque, when a practitioner knows those numbers are way off. But as IT professionals, we might look at the answer and figure that it's good enough, as it seems reasonable enough and wows us with precision. There are a few things we can do to minimize this risk. One is to constrain the model output, like in the classification example from earlier. If we provide a bounded set of available options, the language model is less likely to provide us incorrect results. Second, we want to make use of our own datasets and capabilities outside of the language model to verify as much information as possible. If we can look up specific values and write our own queries against the data to verify results, this provides us a valuable check against a rogue response. Third, ensure that the model is allowed to respond with "I don't know the answer" or "There is insufficient information to provide an answer." If you let it, models will make-believe an answer for you, and many language models tend by default to be overly agreeable due to their training promoting giving answers over not giving answers. Finally, ensure that there is a human in ultimate control. Let the model suggest an answer, but ensure that the knowledgeable human is the one making the call.

Which Cost-Control Practice Should Teams Implement Before Their AI Feature Reaches Production Traffic?
There are three cost control practices that I think are critical before going to production. The first is understanding just how many tokens your conversations are using. This means having appropriate monitoring software in place that can break things down on a per-conversation basis. It's hard for humans to estimate token usage and what that actually means in hard currency, so getting those actual costs (not just token counts) before going to production is vital. Second, it's critical to choose the right model for the job. We all love seeing what the latest and greatest models can accomplish, but those models are expensive. For many tasks, if we clearly define the scope of that task and provide clarity on what to do, we can get away with much less expensive models. This can be a 100x difference in terms of cost per operation. Finally, the biggest cost risk factor is variance, especially if you have an agent loop that makes tool call after tool call after tool call. If you do not set a maximum number of tokens per call and hard input caps, you run the risk of unexpected high costs.

How Can Attendees Learn More About This Topic, and Prepare for Your Session?
If you want to learn more about the topic in advance, my recommendation is to spend a bit of time playing with an online tokenizer, just to see how a paragraph of your own data turns into a series of tokens. Tokens are the unit you get billed in, so this is how we make cost concrete. From there, check out an online glossary of some of the most important terms, like "tokens," "vectors," "embeddings," "RAG," and "vector search." Even having a superficial understanding of the concepts can help demystify language models. Finally, make a raw API call against your language model of choice using curl or a simple library like Python's requests. The goal is to understand what the response object looks like in raw JSON, including information about input and output token counts. Understanding that this is the foundation of how we interact with language models helps make it clear why our tooling works the way it does. To prepare for the session, think about one real application and one real problem. Specifically, choose a brownfield application you own and one repetitive judgement call in it, like categorization, routing, tagging, or prioritizing. Find some historical results in your existing data, and this will give you your answer key. Paste twenty or so of these into ChatGPT with a description of your categories and see how many it gets right. Whatever number you get back, you have the starting point for an AI feature you can put on the backlog. Come to the talk and we'll cover the rest.

Note: Those wishing to attend the session can save money by registering early, according to the event's pricing page. "Save $400 by registering by the Super Early Bird deadline of Sept. 25," said the organizer of the event, which is presented by the parent company of Pure AI.