Home    |

Learn    |

Listen    |
Read    |

Experience    |

|     Contact

It’s impossible to use Enterprise AI without understanding the API. The AI-powered leader will need to deeply understand what this is, how it works, what you need to make it run, and whether or not it’s worth it. A few tips for getting started.

Let’s start with the basics. “API” stands for Application Programming Interface. It’s a bridge that allows an external user to communicate and interact with tech on another server in a way that they can effectively understand. Using graphics, windows with natural language, big buttons to push and drop downs to choose from.

In the old days, only the Very Smart ones among us could effectively query a database. It involved using code such as MySQL, usernames and passwords, knowing exactly what you were looking for and asking in just the right way. asking for specific information. The command: SELECT * FROM table_name, for example, asks to see all the data in a specific table.

Imagine you’re at a restaurant. Querying the database yourself would be like pushing through the swinging doors into the kitchen and telling the chef what you want and how you want it. He would likely swear at you as chefs often do, and you would need to use your best jargon to make it clear – “au bain marie rather than skillet for the foie and if you’re 86 on Agar then use an egg white thickener for the glaze…”.  And then return to your seat and hope you get what you want without him spitting in your dinner.

The API acts like a waiter. He comes to your table, lays out the specials, asks you what you want in the order in which you want it and goes back to the kitchen to interface with the chefs. Not only is this a far more pleasant experience, it also allows you to more time to do other things while you’re waiting.

The API is a graphical messenger that takes your commands and tells the system what to do, and then brings back the results in the way you want it. APIs translate the natural language into query commands and retranslate it back through your graphical interface so you see what you’re looking for allow different software applications to talk to each other.

Who uses APIs? Nearly everyone; you interact with them all the time without realizing it. The Salesforce Platform APIs allow you to access data, automate business processes, and build custom applications without code[i]. The WhatsApp Cloud API lets you build chatbots and autoboots on top of their own messaging platform, allowing for fast, interactive conversations with users. PayPal APIs let you integrate merchant services into your applications; secure payment processing, subscriptions and refunds.

An AI API can also be a “wrapper app”; this is a white label AI engine (GPT, Palm, Falcon…) encased in your brand environment, operated by your people and trained on your data, but using the engine of the provider (OpenAI, Google, Meta, Inflection…). This means that your customers’ queries are necessarily passing through the whopper computers outside Silicon Valley to speak to you, and they can do anything they want with the information passing through their systems along the way without anyone knowing about it, including using it to train other models.

APIs are little packages you can download from the providers that you set up and install with a bit of language; most work with python, curl or JavaScript. You then install the provider library (which is different every time you download it) and set up your API key. This allows any developer access to your project without having to write any code.

Imagine you want to build a basic RAG (Retrieval Augmented Generation) AI which will allow your visitors to crawl your website and take natural language queries, generating unique responses to user questions rather than spitting back a pile of links that forces users to find it all out for themselves. Your crawled pages turn into embeddings using an Embeddings API, and then create a basic search option that allows users to query the embedded information.

Your first step is to download and clone the base software. Remember, this is Open Source, meaning, technically, anyone can use it who has a bit of basic programming understanding. Then, you will need text data that makes up the embeddings from your own content. This is “scraping”; which can either be written from scratch or using an open-source tool you can tweak to crawl your content. It will poke through every single web page on your server, follow every link, and ignore all links that send a user to off your site.

This crawler extracts all the text, strips the formatting (HTML) code, and deposits the information into a series of “buckets”, creating a relevant directory. It ignores all the clutter; spacing, commenting, formatting and exec language and focuses on the information.

The magic happens in the next step; tokenization. The model crunches down all the viable information it finds, breaking down sentences into words, and words into weighted tokens (one token in the English language is about 4 characters, or ¾ of a word).

Next, you will need a way to take the user’s question, create an “embedding”, and compare that with the embeddings from your tokenized library, build a coherent response, and respond in an understandable way. This is how the service assesses user intent. Then, the service is tested and deployed on your website, wrapped again in a graphical interface: a nice, friendly, branded Little <Your Company Here> Friend.

If you are going for an API, how to choose? There are so many different ones out there. Aside from the obvious GPT models, OpenAI offers wrappers for DALL·E, to generate and edit images with natural language, TTS, that convert text into audio, “Whisper”, which does the reverse and “Moderation”, which is fine-tuned to detect sensitive or unsafe user input[i]. And so many more.

Building APIs requires people on your team who can write code. there is no getting away from the reality of “duct taping”, which is the act of taking two or more open-source bits of code and stitching them together so they work seamlessly for a custom solution. This might solve the issue quickly but may not be the most efficient long term, and may break in the future. It’s like plugging a leak with whatever you have in your closet to buy you time for a more permanent solution.

AI Leaders building APIs will not need to write code or understand the details about how this works, but know what the build means for your data. You will need to constantly ask your developers whether solutions are “duct tape” or proprietary, regressive-tested solutions. You will need to understand what this does for your customer or employee experience, with the goal of improving everyone’s lives.

They are one and the same: improving the lives of your team definitionally improves the customer experience because happier and better-supported employees mean happier customers 100% of the time.

Reach out to me for advice – I have a few nice tricks up my sleeve to help guide you on your way, as well as a few “insiders’ links” I can share to get you that free trial version you need to get started.

No eyeballs to read or watch? There’s a podcast for you!

Search for the “Working Humans” podcast everywhere you like to listen. Twice a month, Fiona will dive into the nitty-gritty of employee engagement, communication, company culture and how AI is changing everything about how we work now and in the future. Subscribe so you never miss an episode. Rate, review and share.

About Fiona Passantino

Fiona is an AI Integration Specialist, coming at it from the Human approach; via Culture, Engagement and Communications. She is a frequent speaker, workshop facilitator and trainer.

Fiona helps leaders and teams engage, inspire and connect; empowered through our new technologies, to bring our best selves to work. Her company is Executive Storylines. She is a speaker, facilitator, trainer, executive coach, podcaster blogger, YouTuber and the author of the Comic Books for Executives series. Her next book, “AI-Powered”, is due for release soon.