In an era of technological innovation, the convergence of Artificial Intelligence (AI), Large Language Models (LLMs) and intent-driven workflows has emerged as a transformative force, reshaping the landscape of how we approach and execute tasks in various domains.
This symbiotic relationship between AI/LLMs and intent-driven workflows represents a paradigm shift, hinting at a future of seamless automation and intelligent decision-making.
We are going to dive into the intricacies of this dynamic alliance, exploring how AI-driven systems can intuitively understand and respond to user intentions, fostering efficiency, agility, and a new frontier of possibilities in the realm of work processes.
Understanding Intent and Entities
First off, it is important to understand intent and entity in natural language processing. Therefore, “intent” refers to the intention or purpose behind a user’s input, while “entity” refers to specific information within that input.
Below are three examples and we are going to break down the intent and entities of each of the given sentences using ChatGPT the widely used platform:
- Book my flight to Germany
- Intent: Book a flight
- Entities:
- Action: Book
- Object: Flight
- Destination: Germany
- Add an apple to my basket
- Intent: Add an item to a basket
- Entities:
- Action: Add
- Object: Apple
- Container: Basket
- Update my address in your database
- Intent: Update address
- Entities:
- Action: Update
- Object: Address
- Location: Database
We can see that Large Language Models (LLMs) are extremely good at generalising intent and entities from day-to-day conversational sentences – most of which are likely to have been in the training data.
More impressive though is a well-trained LLM’s ability to do the same trick on more technical inputs, such as:
| What is the intent and entity when GETing data from the following Hubspot API endpoint: /crm/v3/objects/contacts The primary intent of this API request is to retrieve information about contacts. Object Type: contacts HTTP Method: GET |
Once we have extracted and abstracted the entities and intents, it opens up the possibility of creating integration workflows between disparate APIs with little or no intervention.
For instance this example below:
| which Salesforce API endpoint best matches the “Add” intent from this list: /api/prospect/version/4/do/query/ /api/prospect/version/4/do/update/id/ /api/prospect/version/4/do/read/id/ /api/prospect/version/4/do/create/ /api/prospect/version/4/do/delete/id/ The Salesforce API endpoint that best matches the “Add” intent from the provided list is: /api/prospect/version/4/do/create |
This way, we can map intent-driven integrations between systems automatically.
Machine Readable Responses
So, extracting intents and entities conversationally is a good start, but how can we use this to build integrations?
Well, it’s as simple as asking nicely!
| Convert this sentence: “Retrieve contacts from HubSpot” to JSON using this JSON format {“method”:””, “entity”:””, “application”:””} { “method”: “retrieve”, “entity”: “contacts”, “application”: “HubSpot” } |
Now we can use the previous list-picking technique to match the intent with a suitable API method from the HubSpot documentation:
| from this list of endpoints, pick the best match for “retrieve contacts“ GET /crm/v3/objects/contacts/search GET /crm/v3/objects/contacts/ POST /crm/v3/objects/contacts/ DELETE /crm/v3/objects/contacts/ in this JSON format: {“httpMethod:””, “endpoint”:””} { “httpMethod”: “GET“, “endpoint”: “/crm/v3/objects/contacts/” } |
Notice how we’ve successfully converted the conversational “retrieve” to the HTTP Method GET and found the best endpoint to carry out that intent.
Piecing it all Together
Using these techniques, we can try an end-to-end example of building an intent-driven integration:
Here’s our intent:
| “Take all contacts from HubSpot and add them to Salesforce as prospects” |
So let’s get the intents, entities, and applications as before:
| Convert this sentence: “take all contacts from HubSpot and add them to Salesforce as prospects” to JSON using this JSON format {“steps”: [{“method”:””, “entity”:””, “application”:””} ]} |
| { “steps”: [ { “method”: “take”, “entity”: “contacts”, “application”: “HubSpot” }, { “method”: “add”, “entity”: “prospects”, “application”: “salesforce” } ] } |
Let’s infer the first method call to “HubSpot” from the list of methods we know from the documentation:
| from this list of endpoints, pick the best match for “take contacts“ GET /crm/v3/objects/contacts/search GET /crm/v3/objects/contacts/ POST /crm/v3/objects/contacts/ DELETE /crm/v3/objects/contacts/ in this JSON format: {“httpMethod:””, “endpoint”:””} { “httpMethod”: “GET”, “endpoint”: “/crm/v3/objects/contacts/” } |
Now Salesforce in the same way:
| from this list of endpoints, pick the best match for “add prospects“ POST /api/prospect/version/4/do/query/ POST /api/prospect/version/4/do/create/email/ POST /api/prospect/version/4/do/update/id/ POST /api/prospect/version/4/do/delete/id/ in this JSON format: {“httpMethod:””, “endpoint”:””} { “httpMethod”: “POST”, “endpoint”: “/api/prospect/version/4/do/create/email/” } |
So, we’ve taken the conversational sentence, “Take all contacts from HubSpot and add them to Salesforce as prospects”, and extracted the intent, entities, and applications.
Using the discovered application API documentation, we have inferred the best endpoints to carry out our intent to be used in an integration:
- GET /crm/v3/objects/contacts/
- POST /api/prospect/version/4/do/create/email/
Going Further with Artificial Intelligence and Intent-Driven Workflows
Of course, this is a naive approach to demonstrate how intent could drive integrations using Large Language Models. There is plenty of opportunity for further work here to improve both accuracy and reduce calls to the LLM service.
Training a custom LLM using API documentation would allow the intent matching to be baked in. As a result, it would eliminate passing lists of endpoints to be picked from, the model could return the endpoint that matched the intent directly from the training data.
For popular SaaS Applications, the API documentation is already in the training set and you can sometimes successfully one-shot the question.
For example:
| return the API endpoint for this request: “get all my contacts from HubSpot“ return this answer in this JSON format: {“service”: “”, “httpMethod”: “”, “methodEndPoint”: “”} {“service”: “HubSpot”, “httpMethod”: “GET”, “methodEndPoint”: “/contacts/v1/lists/all/contacts/all” } |
Notice this answered v1 of the HubSpot API – custom models would still be recommended in this scenario.
We could also use similar techniques to add field mappings between Entities – or even better, create canonical entities that you could convert between via your custom model.
Here’s another example of an LLM getting it right first try:
| Map from this JSON object: { “fname”:””, “lname”:””, “salutation”:””, “role”:””, “dob”:”” } to this JSON object { “date_of_birth”:””, “title”:””, “Jobe_title”:””, “last_name”:””, “first_name”:”” } { “fieldMappings”: [ { “sourceField”: “name”, “destinationField”: “first_name” }, { “sourceField”: “name”, “destinationField”: “last_name” }, { “sourceField”: “salutation”, “destinationField”: “title” }, { “sourceField”: “role”, “destinationField”: “Job_title” }, { “sourceField”: “dob”, “destinationField”: “date_of_birth” } // Add more mappings as needed ] } |
Final Thoughts on Artificial Intelligence and Large Language Models
Right now, artificial intelligence is as bad as it will ever be. What I mean to say is it will never get worse at performing tasks, from creating images to taking a sentence and turning it into a useful structure.
We are in a golden age of experimentation and growth. However, a careful hand is still needed to guide the raw musings of large language models and their cousins into reliable information usable in the real world.
As they say, watch this space!
