I recently watched Nick from the Retool team's post on Linked In here that summarizes what most of our team has found when helping clients in Retool.
The Retool Agents launch has to have been the best advertisement for Retool workflows. Our clients tend to be excited about Retool agents, understand the concept more intuitively than Retool workflows, and often assume that a task would be better handled by agents. But realistically many of those tasks better belong with Retool workflows due to it being more deterministic - maybe with an AI step peppered in.
I'd love hear if anyone has a decision matrix or rules of thumb for when a Retool agent makes more sense than a workflow (I get the whole researc bit,. I think its easy to identify when something makes more sense as a Retool workflow, but its harder to identify when something makes more sense as an agent.
6 Likes
This is a really good question! We have a blog post coming out very soon that goes into some more detail about this. It should be a good resource for you to hopefully forward along to your clients or use as a resource yourself.
TL;DR The key tradeoff between workflows and agents is more predictable execution vs flexibility. And I always recommend choosing the simplest, most predictable solution that fits your use case. In some cases that means reaching for a workflow, but there are some cases where you really do need an agent.
Workflows
If the path from problem to solution is relatively well-defined and doesn't have that much variance in how you walk that path every time, a workflow is probably where you want to go. With the addition of LLM blocks that either generate content/output mid-workflow or LLM blocks that are making decisions of how the workflow executes, you can actually achieve quite a bit of flexibility in workflows. The upside of using workflows over agents is they're generally easier to understand the execution and easier to debug. And there's usually less variance in how they execute.
Agents
That said, that "less variance" is often a roadblock. For some use cases, the path from problem to solution isn't always clear or repeatable. And that's when agents are useful. When a problem might need multiple iterations on a solution or when a end-to-end workflow isn't getting the accuracy you want, that's when introducing an agent can be helpful. The downside is, they can be harder to debug and don't always run the same way every time. That's where evals can help, but you're definitely trading off a bit of certainty for access to the "creativity" in problem solving.
If you have a couple specific use cases, happy to walk through my thinking on them to show what I mean through a more specific example!
6 Likes
Thanks @KeananKoppenhaver, very helpful. And thanks @JoeyKarczewski for posting
On top of what you said there's also the hybrid option of workflows with an agent block for a specific step of the process. And this is where I think the magic happens as you can then manage how much variance you need each step of the way.
Looking forward to reading the blog post
1 Like
Agents
That said, that "less variance" is often a roadblock. For some use cases, the path from problem to solution isn't always clear or repeatable. And that's when agents are useful. When a problem might need multiple iterations on a solution or when a end-to-end workflow isn't getting the accuracy you want, that's when introducing an agent can be helpful. The downside is, they can be harder to debug and don't always run the same way every time. That's where evals can help, but you're definitely trading off a bit of certainty for access to the "creativity" in problem solving.
Curious on how this manifests in team's internal tool stacks and whose building them - @KeananKoppenhaver - has Retool seen a different type of user profile adopting agents in Retool? The actual use-cases where I could see 'less variance being a roadblock' tend to be more high level flows that aren't developer focused.
Curious if you have any more these are perfect examples.
We're definitely seeing agents across the spectrum! You're right that many of the most effective agent workflows are non-developer focused.
Some non-developer examples I'm running:
- Generate short videos based on new Retool features
- Build in Minecraft based on a specification
- Automatically nudge me to follow up on sales conversations based on web activity
But there are compelling developer-focused use cases too. I'm working on one (pending OAuth support for MCP) that reviews PRs on GitHub and suggests docs changes. This benefits from agent capabilities like searching through codebases and making multiple investigations to clarify changes - things that make it more powerful than a simple workflow.
Other developer-focused patterns include:
- Writing DB queries where the agent can inspect multiple tables if uncertain about output or errors
- Querying and analyzing data across different systems where multiple queries are required and decisions on those queries are dynamic depending on the input
- Any scenario requiring dynamic investigation and tool chaining
The hybrid approach we're seeing most is developers building specialized tools with technical behavior baked in (like custom database query workflows), then give these tools to agents for less technical users. This pattern lets the whole team leverage more sophisticated capabilities without everyone needing deep technical knowledge.
2 Likes
The workflow vs agent vs hybrid framework makes a lot of sense for tasks that live entirely inside Retool. The scenario we keep running into is when the workflow involves agents that are not Retool agents. For example a Retool workflow handling the data side and an external agent (Claude, Devin, a custom MCP agent) handling a classification or review step.
In that case it is not really a question of Retool workflow vs Retool agent. It is a question of what coordinates between the Retool piece and the non-Retool piece. We have been trying a few things for this. n8n for the routing, teamoffsite.ai for the shared context and handoff between agents, and some manual webhook setups. Each handles a different part and none of them integrate as cleanly as staying fully inside Retool would.
Curious whether others here are running mixed-platform setups like this or whether most teams keep everything inside Retool when possible.