[PLUGIN] - Bubble Agentic AI - (turns backend workflows into tools)

Showcase Plugins
1

Hi,

I’ve just released the final AI plugin that now complements a trio of some really well designed AI plugins, and this one is called Bubble Agentic AI.

It pretty much turns your backend workflows into tools so they can be executed by the AI automatically. The AI within the plugin decides when to call the tools (your backend workflows) in order to answer questions or complete more complex tasks. It also supports multi-tool calling, meaning multiple backend workflows can be chained and triggered together when needed. For example, if a task would require calling at least three separate workflows before being marked as complete, then it will intelligently execute all three in the correct sequence to complete that task, and there’s no limit to how many can be chained together like this either.

Demo and Instructions:
https://demo-plugins-13689.bubbleapps.io/version-test/bubble_agentic_ai

Plugin:
https://bubble.io/plugin/bubble-agentic-ai-1779033290379x305185967176941600

image
image1446×738 98.1 KB

How it works
When a backend workflow is called, any parameters it has are taken into account and filled in by the AI. If you’ve set up tools before, you’ll know that each tool and its parameters need clear descriptions so the AI knows when and how to use them.

Because tools are just regular backend workflows, there’s nothing new to learn with regards to setting them up. They can do anything a workflow can do, like search your database, run calculations, send emails, create/update records etc. The only extra two extra steps that are required, is that any workflow you want to use has to end with a special prefix (like _agent for example), and every workflow must finish with a ‘Return data from API’ action.

There’s a dedicated action called Generate Tools that connects to your app, reads the swagger file, and builds the tool list for you. Once that’s done, you just need to add the descriptions yourself and paste the finished JSON into the required field within the relevant plugin setting. This is documented in the demo page.

The plugin works with OpenAI, Anthropic, and Gemini, and you can switch between them at any time without touching your workflows. They all handle tool calling really well. Gemini and Anthropic support ‘thinking’ which can be enabled if required. Alongside the normal client-side action there is a server-side ‘Send Message’ action, so the agent can run securely. It accepts and returns the same conversation format, so you can hand a session back and forth between the page and the server.

Other things worth mentioning

  • Two authentication modes for tool calls: as the signed-in user, so privacy rules apply, or as admin with an API token.
  • A configurable cap on the tool-calling loop, with automatic retries when a tool call fails.
  • Extended thinking and reasoning mode on the models that support it.
  • Stop a response mid-stream, clear the conversation, or reload a saved conversation from your database.
  • Token usage reported both per turn and across the whole session.
  • Configurable system prompt, model, and tool-choice behaviour.
  • Debug mode that logs the full agent loop, every tool call, and every provider request to the console while you are getting set up.

A note on cost
Worth understanding before you start. A single user message is not necessarily a single AI call. The agent works in a loop, and each pass of that loop is one API call, one to decide what to do, then another after each round of tool results to decide the next step or write the final reply. A plain question with no tools is a single call, a message that uses a tool or two is usually somewhere between two and four. Most tasks settle within three. You can use the plugin without any tools if required.

The tool calls themselves are calls to your own backend workflows, so they use Bubble workload units like any other workflow run would.

On the AI side, the default models (things like gpt-4o-mini) are cheap, and you’re usually looking at a fraction of a cent per message. The per-turn and per-session token states let you keep an eye on it. The things that increase cost are all under your control, so a higher ‘Max turns’ cap allows longer loops, and more ‘Retry attempts’ means more calls when a tool misbehaves. Sensible defaults are set.

I’ll be supporting the plugin, so if you run into anything or have questions, give me a shout.

I hope it is useful!

Paul

2

As a heads up, this would leak the Bubble admin API token to the client.

CleanShot 2026-05-22 at 09.18.45@2x
CleanShot 2026-05-22 at 09.18.45@2x1522×918 97.2 KB

Sensitive values should only ever be defined in plugin settings.

3

Thanks George…

That’s a server action meaning it can (and should be run in a backend workflow) - it’s only initiated through the client for testing purposes so I didn’t have to schedule an API workflow to kick it off.

Kicking off server-side actions directly from the client in this way, does not leak the keys to the client.

Documented through the instructions but appreciated for pointing it out.

Paul

4

Ah okay, it’s kind of a footgun though (given let’s be honest most people don’t read the docs)? Why not just define it as a private plugin value? Does Bubble not let SSAs take a private value in the same way as client side actions?

5

private plugin values can not be dynamic. SSA fields can be dynamic just like a client side action and when building plugins a server side action in the plugin editor is chosen as opposed to a client side, but in the app editor a server side action can be initiated from client side (ie: page workflows) and would function like a bubble server side action (such as create a new thing) that is part of page workflows.

6

Yeah but in this plugin’s use case, the only database the user would be using would surely be their own backend (and would therefore benefit from having the API token defined globally, privately, and securely). Sorry for hijacking the thread @pork1977gm, I’ve seen a ton of users expose Bubble admin keys, Stripe keys etc like this

If it gets updated I’ll delete the comments so the thread is clean

7

I wouldn’t say surely on that…putting a half a cents worth of thought into I conjured up a couple use cases that could benefit from being able to call different bubble app databases. I think a good plugin developer would leave the door open for flexible use of their product to allow any good developer to come up with any potential use case for the product and not be pigeonholed by a development choice that assumed developers do not know how to develop responsibly and with basic security steps in place. It’s not uncommon for bubble developers to know to use a server side action to secure sensitive api keys. There’s enough material out since late 2018 on the subject.

I’m glad it’s documented in the plugin documentation to give extra guidance because it’s so easy to provide an LLM with plugin docs and ask, how do I use this.

8

The world we live in though :rofl:

But the docs literally describe putting the action on a page, with API token hence I’m a bit confused by this as it’s basically instructing the configuration which will leak their admin token (and there’s no other docs to the effect of ‘don’t use admin token on a page workflow’)

CleanShot 2026-05-23 at 17.18.42@2x
CleanShot 2026-05-23 at 17.18.42@2x2128×536 72.6 KB

9

The plugin has been updated with the ‘Bubble API Token’ moved to a private shared key. That is required when using the ‘Send Message’ server-side action.

The ‘Send Message’ client side action which I’ve added simply for flexibility, will use the ‘Bubble API Token’ inside the main plugin settings if you select the Admin option under ‘Auth mode for tools’ option in the main plugin settings.

The documentation has been updated to reflect these changes. Are you planning on using it @georgecollier ?

10

But if it’s a client side action then it’s going to access the Bubble API token no?

We can empty the thread when it’s sorted haha

But there’s been enough plugins that let users leak their API keys, so imo important to flag when they do

11

Correct and that’s per design. You get two actions, secure and unsecure, you choose which one you want.

There’s no way to make the client one work securely simply because it’s being invoked directly from the browser, well not unless the provider uses things such as ephemeral keys or other short-lived access tokens - something I haven’t looked into yet (but even that isn’t 100% fool proof).

I added both simply for flexibility, if anyone has concerns over security then the answer is to use the server-side action.

There might actually be some legitimate use case for running client-side calls like this, I mean it’s a lot faster for sure and you can stream too which can’t be done through server-side actions. Also, if an app was designed where each user had their own key held in the User table, then you could dynamically populate it through the plugin settings therefore making it visible only to them when they’re logged in.

But from my point of view, all I’m doing is providing one of each and allowing whoever uses it to make that decision for themselves.

Paul

17

All, I just deleted a string of replies in here. You can debate the merits of your work, apps, plugins, templates, etc all day long. But as always, we draw the line at personal attacks.

Let’s keep it friendly and positive for everyone. Thank you.