We’ve added two new mechanisms that are really powerful. Together, they allow you to connect an external system or application to the AI processes in a thunk. Both these mechanisms are accessed through the Connections icon in the left pane of your thunk.
- Inbound: you can send information from other systems to a thunk via a webhook. It is easy to create a new webhook.
- Outbound: You can define new capabilities (“tools”) for your AI agent to use in a thunk. This mechanism will evolve over the next few weeks, but you can start using it immediately.
Here’s a couple of videos demonstrating the use of these integration abilities – showing how to connect a thunk to an existing app (built with AppSheet). This is just one example of a generic pattern – adding an AI+human workflow to an existing application.
2 Likes
Awesome jobs to get started and open new possibilities!
Just a quick question after viewing “Tony’s Corner”… 
Is this simple Webhook feature, i.e. just throw a request to Thunk.AI from external service? Is there no capability that the requester get the response back from Thunk.AI?
Currenlty, external app send the request to Thunk.AI. Then AI agent does bits and pieces, but Agent need to invoke another API (in this case AppSheet API) to send the result back to the requester. Without step for Agent to invoke API, I thought the story could be made much simple and easier set up, if new feature could CONSUME the response back from Thunk.AI.
Using the sample of AppSheet. Automation invoke Webhook (or proper API?) to Thunk, and wait for the response (json or even object format) after Agent finished a job. If this could be possible, we dont need to involve AppSheet API step in the Agent plan.
Second question is pretty much AppSheet related… Tony throw the image from AppSheet to Thunk.AI, the image could be “published” to anyone so that Thunk AI can access to the posted image? Bearing in mind the tools will be used as business solution, many companies do not wish to EXPOSE image file to the public. This is not Thunk AI direct issues, but this might be developped to the new challenge in terms of how to pass the image/file data from external service to Thunk AI agent within “Closed Space”
1 Like
Thanks for the feedback Koichi.
-
I think you are asking if we can provide a synchronous API to invoke a thunk. While it is possible, I don’t think it is a good idea at the moment because (a) AI processes by their nature take more time than a code-implemented API call, (b) these are meant to be processes that have a potential for human-in-the-loop behavior (eg: some things may be ambiguous and need a human review). If all you need is a cheap call to an AI model, you could direct call OpenAI or any other API directly from an AppSheet app workflow. So there is very little extra value-add you’d get from a thunk doing the same thing. Is the motivation to avoid using the AppSheet API for cost reasons? If so, I understand that.
-
I remember there was a mechanism in AppSheet to make images accessible to external parties (eg: for use in a workflow report). Admittedly this makes the image public. Another solutions would involve including a key on the image url (would still need the AppSheet platform to do some kind of minor feature work for this).
1 Like
The general benefit of going the webhook route is that it is a way to kick off work and the sender is not dependent on the nature and duration of the work. So it allows for a variety of integration patterns (see Thunk.AI as an AI process platform | Thunk.AI Help Center)
That is one of the reason.
In case we expect simple answer back from the agent, then it is easy to get the response as “return” value as a result of webhook. AppSheet now can consume the return value anyway. To simply get easy answer, using and setting up proper api is kind of tedious to the users, dont you think so?
Borrowing the sample case of Tony, if we expect one or two key/value pair answers from agent, then it is easy to get such a requst out of API call then user can move on without using proper API;
Another possibilties? I m not sure if this is really workable or not, but we just "Share file with Thunk.AI (Agent hold Google account or MS account whasoever available).
It could be rediculous idea though but this idea came up in my mind.
This comment is simply for discussion purpose.
Sorry for talking about too much about AppSheet. AppSheet API is only available to AppSheet Enterprise lisense holders, so the number of the users are limited. that is another reason.
So I thought the path of “Throw request and get response back from AI Agent” could broad the usage of this fantastic features.
For the “Template” ai tools, is there a way to refresh the operation that you are running when first instantiating the tools? ie. when the schema gets updated on the 3rd party connector.
Currently, I’ve just been updated the JSON schema manually.
2 Likes
Could you clarify this please Stefan?
So let’s say you add a tool T that allows your Thunk AI agent to talk to a specific AppSheet app A. The tool has a JSON schema as part of the “Tool Definition” which captures the inputs from the AI agent when invoking the tool, and a “Tool Implementation” which describes the payload sent via HTTP to the AppSheet app’s REST API.
What is the change you want to manage? Does the AppSheet app change and so you want to update the Tool Implementation? Or do you want to update the Tool Definition?
Yes at the moment, the tool building templates are useful to get started with a “stable” external system, but there isn’t an intelligent detect-adapt-modify behavior. We just didn’t know if this was a common enough scenario yet to implement that.
That makes sense. The main use case is Schema changing on that AppSheet side, and therefore I need to update the Tool Definition for Add/Update api calls.
My assumption is that behind the scenes of the Template setup for a new ai tool you’re making a call to some OpenAPI spec that AppSheet (3rd party system) exposes? It was really nice how much the ai tool innately understood about the nature of communicating with AppSheet.
Actually, unfortunately AppSheet does not expose an OpenAPI spec manifest (it should but it doesn’t). So for the builtin “templates” we have a few options:
*) For services that expose an OpenAPI manifest, we could read that
*) For services where we “know” what the pattern looks like, we could hardcode that
*) or we can use an LLM :] — which is what Tony does
The LLM/chat on the side is used in tool building. It can read a manifest. It can read a doc page, find in it a curl command, and then get the JSON payload structure from it. In the case of AppSheet apps, it uses the list() API endpoint which is generic, then looks at the structure of the payload coming back, and uses that to craft the update payload. Which is brilliant actually!
So there are a couple of other answers to your original question:
- you can just create another tool when the schema changes, and drop the old one.
- you can tell the AI agent in the chat: “run the list_ tool again, and then update the definition of the update_ tool based on the latest data schema.” And it may surprisingly just do it for you.
That last answer is the “right” one and definitely our “medium-term” answer. Juts because this is week one of the new capability, we don’t yet have the confidence to assert it will be reliable just yet.