When building an LLM application, one of the first design decisions we have to make is:
Workflow or agent?
Workflow vs. Agent: A Quick Recap
The workflow paradigm follows a sequence we define in advance. This makes the application easy to understand and gives us clear control over how information moves from one stage to the next. It works well when we know exactly which operation should happen at each stage. For more open-ended questions, however, the next useful action may depend on what the system discovers along the way.
The agent paradigm, on the other hand, starts with a goal and decides which actions or tools to use along the way. This makes it more flexible when the solution path is uncertain. However, that flexibility also means we give up some control over how the solution unfolds.
But why make this choice for the entire application?
In practice, many applications contain both kinds of work. Some stages might perform a known transformation, where the workflow paradigm is a good fit. Other stages might need to adapt based on intermediate results, which naturally calls for the agentic approach. For these applications, a hybrid workflow-agent pattern is a better fit.
In this post, we’ll explore this hybrid pattern through a concrete case study. The overall solution path will remain fixed, while an agent is placed inside the stage where the path cannot be determined in advance.
Note: In this post, we configure a simple agent that only has access to pre-defined tools. If you’d like to upgrade your agent with code execution and web browsing capabilities, check my posts here: Build an LLM Agent That Can Write and Run Code, and How to Give an LLM Agent a Browser.
1. Case Study: LLM-Assisted Hyperparameter Tuning
For the case study, let’s build an LLM application that helps select algorithms and tune hyperparameters for classification problems—a common task as of 2026, with the rise of automated machine learning (AutoML) tools.
This application works as follows: it first receives a labeled dataset and a plain-language modeling request. It then runs model experiments and recommends one of the tested configurations. Finally, it summarizes the result. Naturally, we can break this work into three stages.
1.1 Prepare the Experiment
The purpose of this stage is to translate the modeling request into a brief that contains the objective, evaluation metric, and cross-validation setup. Since we already know the input, the desired operation, and the expected output, a single LLM call is sufficient for this stage.
1.2 Hyperparameter Tuning
At this stage, we run the experiments. We know the goal—finding the best model and hyperparameters—but we don’t know the exact sequence of actions required to reach it. The next useful experiment should depend on the results observed so far. As a result, this stage is better handled by an agent, which can dynamically choose classifier configurations, evaluate them, and continue exploring.
1.3 Summarization and Reporting
Finally, we summarize the completed run. At this stage, the experiment brief, trial history, and recommendation are already available. Turning them into a structured report is a known operation, so a single LLM call is again sufficient.
As you can see, in our intended LLM application, the overall problem-solving sequence is fixed—preparation, exploration, and reporting. Within this predefined workflow, we introduce autonomy only at the middle stage to enable adaptive model experimentation. This way, we combine the clarity of a workflow with the flexibility of agentic experimentation.
In the following sections, we’ll dive into the implementation details of this hybrid pattern, showing how to configure the agent, define tools, and manage the interaction between workflow stages. We’ll also discuss practical considerations, such as cost, latency, and debugging, to help you apply this pattern in your own projects.