We are working on making it easier and safer to build end to end automated AI workflows in production via AI Agents.
We are starting with an AI Agent block that allows you to safely use AI in production through a human confirmation step and eval functions.
We are looking for beta testers and more use cases to better understand what we should build for the next generation of AI agents.
Let us know your use case here and we will be in touch for hopefully making it possible in Retool soon!
Hey, is this available now?
@Tamar_Ben-Shachar Can we get the example in this video?
@qinfeng I've attached the app and the workflow that powers it. You'll need to import both into your instance of Retool. You'll also need to create 3 database tables to make it work, which you can do by running the following against your Retool DB:
CREATE SEQUENCE reagent_messages_id_seq;
CREATE SEQUENCE reagent_steps_id_seq;
CREATE SEQUENCE reagent_threads_id_seq;
-- Create the tables
CREATE TABLE reagent_messages (
id INTEGER NOT NULL DEFAULT nextval('reagent_messages_id_seq'::regclass),
created TIMESTAMP WITH TIME ZONE DEFAULT now(),
message_text TEXT,
message_type TEXT,
thread_id INTEGER,
complete BOOLEAN DEFAULT FALSE
);
CREATE TABLE reagent_steps (
id INTEGER NOT NULL DEFAULT nextval('reagent_steps_id_seq'::regclass),
message_id INTEGER,
step JSONB,
artifact JSONB DEFAULT '{}'::jsonb
);
CREATE TABLE reagent_threads (
id INTEGER NOT NULL DEFAULT nextval('reagent_threads_id_seq'::regclass),
uuid UUID NOT NULL DEFAULT gen_random_uuid(),
owner_email TEXT,
created TIMESTAMP WITH TIME ZONE DEFAULT now(),
title TEXT
);
[Reagent] Orchestrator - copy for sharing.json (159.1 KB)
Reagent (2).json (87.1 KB)
I got a question about the workflow you've shared (big thank you btw for that!):
Obviously the select workflow should be changed to select the newly created workflow id, but ignoring that does this recursive call create a whole new external REST request to the workflow or is the backend able to shortcut this sending to http://localhost:xx (or even better, restructure/wrap the workflow in a loop). I'm mostly wondering about the resource usage on the call stack since recursive calls within JS and Python have limits and in the case of JS it depends on the browser. I'm wondering how easily the extra overhead of a recursive REST request could cause a call stack overflow.... you could stick the whole workflow itself into a multi-step function and wrap it in a loop block to avoid the recursiveness, so I guess I'm just curious about the design choice
side note: i LOVE the use of multi-step functions here so much I'm going back to restructuring my own workflows to make use of them as well.... might I suggest adding a couple of extra screenshots on the docs page to highlight how these can start and end with multiple blocks and how a multi-step with 1 block can be reused (ie an update function that can be reused to insert, update or delete records):
I found this last one the most intriguing,:
while the same thing could be done with a single-step function and/or a JS block:
There's a downside to V2 and V3 from above though, if you decide you need to store a backup in another location you now have to add new blocks and connect the input/output of each whereas with the multi-step you're able to keep the workflow structure the same:
Short answer is that the backend shortcuts it when the Workflow is called from another Workflow! I wouldn't worry about the call stack - Workflows are orchestrated with Temporal, so there's essentially a queueing system built in that should handle the load. Also just wanted to confirm that these Workflows aren't running on the client, so there shouldn't be anything to worry about from the browser perspective.
You definitely could stick the whole workflow in a loop block (or in a JS loop) and accomplish the same thing - that would work fine too, this was just the method that I chose here.
Indeed - my saveState subflow could have been handled by a single block. There is no reason that it needs to be this case, it was just that while building this, I was preemptively encapsulating that functionality because I assumed I'd need multi-step logic there.
Hi 
Is there anything happening in the AI agent -front at Retool? The original post is from last summer...
I'm interested to hear are you building "native agentic capabilities" within retool?
Let's say:
The video example kinda does this but it is 10-fold more complex than what, let's say n8n (Advanced AI Workflow Automation Software & Tools - n8n) is doing. I absolutely love retool ( 
) but the "agentic" part is a bit lacking at the moment.
@Kimi great question
There is LOTS happening on the AI Agent front at Retool.
What you described (a workflow-like authoring UI, memory, the ability to pass state across agent iterations, etc.) is very aligned with our thinking. We're building this right now. We'll launch it in May.
As you pointed out, building Agents with Retool Workflows (as in the examples above) technically works... but it is very complex. I've been building and sharing these things more as an exploration of Agentic capabilities in Retool and because people want to explore these patterns in Retool today, but the ultimate goal is a tailored Agent product offering.
Sounds like you might be open to being one of our early testers?
@kent Thanks for your answer
Our team, myself included, would be very happy to be your "earlier than early" -testers!!
You got it! I'll reach out right now.
Heads up for everyone following this thread! 
If you're interested in AI Agents, you might want to check out our live session tomorrow on using multiple AI models together.
Details & registration info here: 📢 We’re diving into AI models—join us tomorrow!
Hope to see you there! 
Also, feel free to drop any questions in the main event thread ^^
cc: @Kimi @bobthebear @Gautam_Sawhney @qinfeng @nocodev @matei @icodeday @trz-justin-dev @MiguelOrtiz @qinfeng @juan
