Who said that an AI agent's usage of APIs is limited? Yes, APIs whose documentation is specifically targeted at machines would be easier to integrate with. However, any API could be the target of an AI agent. And, even better than that, you should be able to set it up without having to write any code. I've been experimenting with a low-code approach that lets me connect any AI agent to any API. Keep reading to learn more about it.
This article is brought to you with the help of our supporter, n8n.
n8n is the fastest way to plug AI into your own data. Build autonomous, multi-step agents, using any model, including self-hosted. Use over 400 integrations to build powerful AI-native workflows.
AI agents try to understand how an API works by reading its machine-readable definition and any available documentation. Targeting your documentation at machines is a way to make the consumption process the most efficient. While that's true, it's possible to create a strong connection between an AI agent and any API, even when there's no documentation available. And that's what I'm exploring in this article.
If there's no documentation, how can an AI agent understand what API it should call? Additionally, how would an AI agent know which parameters to use to fulfill your intent? The answer is seemingly simple, yet you need the right workflow engine to make it work. I'm using n8n's latest version, which lets you connect any node to its AI Agent's Tool output. You can connect any existing n8n node so it behaves as a tool that the AI Agent can use. Some of those nodes have already been preconfigured, so connecting them is straightforward. However, connecting any API requires a specific configuration.
To make an AI Agent understand how it should interact with any API, you need to tell it what it can do. The good news is that you can use human language to do it. You can effectively instruct an AI Agent by writing your instructions in plain English (or your favorite language, as long as the AI model understands it). That's exactly what I did. I created a project to interact with GitHub's freely available issue search API. My goal is to let people ask questions such as "List five issues where the language is Python." The answer should be in plain English and should give me enough information to open each issue and do further exploration.
I created a workflow where the trigger is a chat message and connected an AI Agent to its output. The first thing I did was provide the AI Agent instructions using the "System Message" option. This message is sent to the AI model before anything a human writes on the chat input. Its goal is to give the model enough context—and instructions—about the human message and the output of any tool. My instructions involve explaining how the agent can interpret the output and how it should use parameters to query the results based on the human input. To help the agent with the output, I wrote that "each result is available as an item on the items
array of the tool output." GitHub's issues search API returns an array of items
, so telling the agent how to use it is mandatory.
I then connected the OpenAI Chat Model to the AI Agent, the Window Buffer Memory, and an HTTP Request node to its Tools connector. I configured the HTTP Request so it connects to the GitHub issue search API. The URL of the API is https://api.github.com/search/issues
, and I configured the single q
GET parameter that accepts the search query. Testing the workflow by entering "List five issues" on the chat input produced the correct result. I then added instructions on how to perform different types of queries.
- To search for issues of a specific language, use the `language:{language}` query option, replacing {language} with the language you want to search for.
- To search for issues that are a pull request (PR), use the `is:pr` query option.
- To search for open issues, use the `is:open` query option.
- To search for closed issues, use the `is:closed` query option.
All these instructions were added to the AI Agent System Message option. You can add as many instructions as you like. In fact, the more precise you can be, the better the AI model will be able to interact with the API. After having all the instructions configured, I tested the workflow again by asking it to show me "three closed pull requests involving the Go language." And, as I hoped, it worked! I did a few more searches involving other terms, and the workflow worked as I had expected. Having OpenAI as the model also helped because it has knowledge about the GitHub API and its capabilities.
As a last experiment, I tried replacing OpenAI with a local llama running on Ollama. The first thing I noticed was that everything was much slower than before. The local Ollama isn't obviously a match for OpenAI. I tried one of the questions I had previously asked to see if there were any differences. The Ollama model followed my instructions perfectly and was able to translate my input into a query on GitHub's issue API. The output was not as clear as before, but it provided the answer I was looking for. It was much more verbose than OpenAI's, though, as it even explained what the JSON payload contained. I believe that adding further instructions to the AI Agent configuration can make the output more human-friendly.
I'll keep exploring the possibilities with this approach. One thing I'll experiment with next is having multiple API operations as tools and letting the AI Agent decide which one to use. I'll post my updates here, so stay tuned.