A guide to agentic AI workflows in 2025

To cut through the noise, it’s helpful to think about how to build agents that can automate and optimize your critical workflows with tools you already use. To demystify some of the decisions you need to make, we're breaking down the basic building blocks of genAI agents and how they can be composed to build AI agents yourself. In many cases, you’ll realize that you can build these tools with a lot of the same technology and patterns you’re already familiar with.

So, let’s take a step back and look at agentic AI workflows from first principles.

What is an AI agent? Before we get there, let’s align on some foundations. Not all systems that include LLMs are agents, and sometimes systems that aren’t agents might be the best solution for the problem at hand. We can demonstrate with some examples.

A genAI workflow is a predefined process where the LLM is involved at one or more steps to generate some or all of the final output.

Think of a customer support tool that parses messages from a customer, looks up some information about that user from our database, passes that into an LLM, and asks it to suggest a response. This is an example of a genAI Workflow, and is the simplest AI enhancement to implement.

A genAI workflow is not an agent, but it can be very useful. Many successful content generation use cases use an architecture like this.

An agentic workflow is a system where an LLM informs the control flow of the application.

In the customer support example, this could be a simple tool that routes new messages to either a billing or a technical support inbox.

In this case, we have a business process where the LLM isn’t just generating content, but actually generating a decision. It’s not a true agent, but we are getting more agentic because the LLM is making decisions about next steps. This makes agentic workflows very useful for certain jobs, like routing tasks or handling support deflection.

An agent is a system in which the LLM is not only responsible for managing the application’s control flow but, specifically, for determining the application’s termination. You might hear people refer to AI agents as “autonomous”, but in the case of the systems we’re building, the important characteristic of autonomy is that they decide when to stop.

Going back to the customer support example, a true agent can decide to use any of the tools available to solve the user’s problem—from looking up information and referencing docs to ultimately closing the ticket.

Agents can be highly flexible and capable of handling open-ended, complex tasks—but they can be costly. While the agent still operates within an explicitly defined environment (it can only leverage the tools that you give it access to) it can fail in ways that are hard to fix. Handing over so much control to the LLM can mean they easily get stuck in loops, burn a bunch of tokens, waste resources, and provide confusing user experiences to the people interacting with them.

Agents are getting a lot of buzz, and while they have a lot of potential, there's still a lot of opportunity to automate business processes with the simpler Agentic Workflow framework.

If you have work being done by humans that can be expressed as a process or a series of steps, a simpler, more deterministic agentic workflow can be more efficient and easier to implement than an AI agent. If a business process can be condensed into something like the following is a great candidate for an agentic workflow.

An agent might be useful for open-ended tasks like research, debugging, or data exploration. But once you have a standard playbook of processes, whether that’s in customer support, product development, or running payroll in Finance, you can encode those processes into a deterministic workflow and just use the LLM for the human-level judgement at a few key steps.

If you build a full agent system for a process like generating a monthly report, every time the agent runs it has to figure out the process and steps to solve the problem. It's not efficient, and poses an increased risk of failure when you actually already have a repeatable process.

I would suggest that tons of automation can be handled with agentic workflows, and it’s much easier to implement.

Now we’re all on the same page about what an AI agent is, we can start to think about actually building one. There are some requirements for an AI agent platform:

Any AI-powered workflow or tool integrates with at least one LLM, but these workflows aren’t very useful in isolation because they can’t interact with the outside world. Making LLMs more robust and powerful requires access to tools so they can interact with other systems, calling APIs, or updating data.

The next enhancement is state: so the system can keep track of context and tasks in between multiple calls to the LLM. Then, access to data—usually via a vector database—so they can access more up-to-date or business-specific data.

Following Anthropic’s lead, we’ll call the LLM with tools, state, and data the “augmented LLM”—a prerequisite for building useful generative AI or agentic workflows, or true AI agents.

Agents need to maintain context across steps. This can be implemented through:

Simple agents might only need conversation history, while complex ones might require multiple storage types for different contexts. There are some tradeoffs to consider with respect to speed and flexibility.

For example, in the demo, our AI Agent reads and writes a lot to a Retool Database table, which is a Postgres database. It’s flexible and persistent, and we can keep track of historic agent state as we go. It allows us to step back in time and see a history of all our conversations and each step, which can be handy for debugging or running evals on. It’s effectively a “hot path short-term memory store,” because it’s happening as part of the application logic and it’s thread-specific.

Reading and writing to a database is, however, a pretty slow operation compared to using an in-memory store (like most agent frameworks provide). The overhead of querying a database is relatively small compared to the wait for the models, but if you’re optimizing for performance, this is something you’d want to keep in mind.

What’s key here is flexibility—the way that you need to build memory into your agents is going to be application-specific, and ultimately, having the control over how you implement it (whether that’s in Retool or LangGraph) is what will prevent you from getting stuck while building.

LLMs aren’t very useful on their own because they cannot a) use data that wasn’t present in their training set and b) take action in the external systems we use to run our businesses. Tools give LLMs a structured way to specify that they want to call some functionality that we provide to them. For example, we might provide an LLM with a “get_weather” tool so it can get accurate, up-to-date information when a user requests it.

From a developer’s perspective, tools can be thought of as an interface. The LLM specifies the tool call and the parameters that it wants to use, and passes these back to our application, where we implement the request to the service providing that functionality, whether it is something we’re hosting or an external service. Essentially, any REST API could be provided to an LLM as a tool (so you can build your own tools) or you could just build the tool interface on top of a third-party API.

Retool Workflows can be a handle tool for both sides of this equation. We have customers defining their tools as a Retool Workflow triggered via a webhook, and then calling them from frameworks like LangGraph. This approach is great if your team are experts in Python but don’t want to worry about hosting web services.

We also have customers doing the exact opposite: defining agents inside of Retool Workflows, but hitting tools that they’re hosting outside of Retool, which is good if you potentially have agents running in multiple different environments, but want to maintain a single set of tools that you’re hosting. Where you host your tools will depend on your team’s needs.

Many agentic frameworks have the ability to pause and ask a human for input on particular steps. In most cases, the agent emits a string, asks the human to respond, parses their response and passes it to the LLM. This is sufficient validation for simple use cases, but if you’re building agents as part of critical business processes, you will likely want to have more control.

Whatever platform you’re using, it’s good to think ahead about how you’re going to integrate with your existing approval processes, tools, systems, or software.

We have some customers combining agents built in Retool Workflows with our human-in-the-loop beta feature. Rather than just asking a user to approve before continuing a task, you can create an auditable, permissionable, customizable task that would need to be approved by one or many people in certain permission groups before proceeding. This combination of Retool agents and human-in-the-loop tasks makes it possible to automate approval processes inside of Retool, giving confidence that the right approvals will be given to an agent before continuing its execution.

Most agentic frameworks are Python packages—they’re not trying to give you a fullstack app. But UIs are important to think about for at least a couple of reasons:

So you will need to give some thought to how you will build UIs. Chat (for now at least) is still the primary interface that most people are using to interact with agents and many tools offer an out-of-box chat UI. If you need a custom UI though, you will likely be building it yourself.

And Retool users can already build a custom UI on top of your agents, allowing them to experiment quickly and get stakeholders on board. Being able to show people an agent in action—or better yet, letting them play with it—is far more effective than explaining how agents work by visually representing the flow.

We’ve covered the foundational requirements for building your own AI agent. You can do all of this in Retool (and we hope you give it a try), but it’s possible on any platform with the ability to call an LLM and implement some logic.

Since you can implement genAI agent architecture anywhere, it’s wiser to focus on choosing tools that integrate with your data, systems and skills rather than learning a bunch of new frameworks. With a solid understanding of the architecture (and the ability to build an agent from scratch yourself), you’re in a strong position to judge whether the latest new agentic framework is actually right for your real world automation needs.